Subject: Re: [Issue 11] Attacker forces address reconfiguration

From: Bernard Aboba <[email-masked]>
Date: Sun, 9 Feb 2003 17:57:43 -0800 (PST)

On this issue, I'm struck that you can't have your cake and eat it too.

If we're going to say that a host should prefer a routable address if
available (Issue 1), then a host with only a v4LL address that
subsequently obtains a routable address will break its connections and
enable the attack described in Issue 11. For example, an attacker could
bring up a rogue DHCP server, hand out bogus routable addresses and bring
down existing connections.

I'd suggest that an additional paragraph about this attack should be
added, depending on what the chosen approach is. My advice would be to
continue to use existing connections, just not establish new ones, in
which case the attack won't break existing connections.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 9 Feb 2003 21:37:51 -0600

> down existing connections.

Not only does it bring down existing connections, but it prevents future
connections with ipv4ll-aware hosts that have been attacked similarly -
this was the big disagreement that kre and I had last week.

Consider the case where you have a bad guy who wants to prevent devices
on a link with no DHCP server from communicating using IPv4ll.   This 
bad
guy sets up a DHCP server which gives every host an IP address on a 
different
subnet, and provides a bogus default route that prevents communication.

In this case, even if all of the nodes on the subnet are IPv4ll-aware, 
and all
of them are doing LLMNS, there is no way for any of them to communicate 
-
each one will publish its "global" IP address with LLMNS, but none of 
the
global addresses are reachable, so no communication is possible in this
case.   This is a similarly nasty attack to the one allowed by RFC2563.

---

From: Robert Elz <[email-masked]>
Date: Mon, 10 Feb 2003 16:47:35 +0700

Date:        Sun, 9 Feb 2003 21:37:51 -0600
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | Not only does it bring down existing connections, but it prevents future
  | connections with ipv4ll-aware hosts that have been attacked similarly -
  | this was the big disagreement that kre and I had last week.

Yes, though we thought that we were disagreeing on a different point
(and from the outside, I suspect most others also thought we were
disagreeing on a different point - for the list, Ted and I discussed
this more in off-list mail, and eventually realised where the
disconnect was happening).

But, if done properly, it shouldn't "bring down existing connections"
(unless the node desires that outcome) but it certainly might prevent
future connections.

This is really the "security considerations" which is currently
applied to LL2 in the issues list - really it belongs to LL1 (and LL23 (??))
as issues (LL11 is just noting security considerations text).

  | Consider the case where you have a bad guy who wants to prevent devices
  | on a link with no DHCP server from communicating using IPv4ll.   This 
  | bad guy sets up a DHCP server which gives every host an IP address on a 
  | different subnet, and provides a bogus default route that prevents
  | communication.

Yes, this one is certainly possible.    Of course, the bad guy who can do
this can also prevent IPv4LL from working just by the ARP attack (defend
every possible IPv4LL address), so it isn't really very new.

How devices recover from each of those kinds of attacks depends entirely
upon how the device reacts in these circumstances.

That is, 2.2 of the draft says that a node that gets more than 10 LL
addresses rejected, as to slow down to no more than one attempt a minute,
but doesn't actually say it has to keep on trying - a node could just
give up and turn itself off if no LL address is available to it.

Similarly, a node given a (trash) DHCP address, with a (trash) default
router (etc) can just go away and sulk until its lease is due for
renewal, or it can notice that the address it was given doesn't seem to
actually work very well (it is not receiving any replies, not receiving
any queries), and decide that perhaps it should just try again to get
a DHCP assigned address.

The effect is that either attack may be successful as a one off, but to
truly succeed, the attacker has to wait around and be prepared to repeat
the attack over and over again.

The DHCP attack (but not the ARP attack) is also theoretically possible
from off-link.   In practice, the difficulty of guessing a 32 bit (random)
transaction I-D, and detecting just when the correct time to send a packet,
makes this one so improbable that it can mostly be ignored.

  | This is a similarly nasty attack to the one allowed by RFC2563.

The "2563 attack" is exactly the same attack as this one, not
"similarly nasty".   If we decide to the attack isn't something that
we really need to worry about here, for this issue, then it no longer
exists as far as 2563 is concerned either.

What this really boils down to, is whether we believe that the extra
method of denying a host a v4LL address that defining DHCP to work this
way certainly allows (but an extra method is all that it is), is something
so heinous that we need to abandon the general simplicity of only using
one routable address, most of the time (that is, exactly what IP hosts
have been doing - with the possibility of this attack ever since DHCP
was invented and started being used - for many years now).

My opinion is that there's nothing here bad enough, or new enough, that
it needs anything much more than noting in the security considerations,
just as the possibility of attacks on the ARP probe packets are mentioned.
Mentioning that a host that has an assigned address is entirely free to
reconfirm that address at any time, and should do so it it seems that the
address doesn't work, would be something useful for the security
considerations.    Depending upon the host, and its manual configuration
method, even a host that has been manually assigned an address might
sometimes decide to detect that the assigned address doesn't work, and
(attempt to) assign itself a LL address.

kre

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Feb 2003 05:02:47 -0800 (PST)

> the attack over and over again.

Unless the implementation gives up at some point. That's a bad idea -- but
is a likely choice unless we explicitly address this in the spec.

> just as the possibility of attacks on the ARP probe packets are mentioned.

Yes, this one has been around a long time -- and is not unique to LLv4.

> considerations.

And for reliability too.

> Depending upon the host, and its manual configuration

The trick of course is how to know that "the assigned address doesn't
work".

---

From: Robert Elz <[email-masked]>
Date: Mon, 10 Feb 2003 22:05:39 +0700

Date:        Mon, 10 Feb 2003 05:02:47 -0800 (PST)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | The trick of course is how to know that "the assigned address doesn't
  | work".

Sending packets and receiving replies is a good indication of "does work".
Getting (relevant) queries or messages also (where relevant probably means
addressed to a port where there's something waiting).

Having neither of those happen is a good clue to "not work" - it doesn't
need to be perfect, in a situation where the address would work, but the
net just happens to be quiet, the cost of wrongly assuming that the config
is broken is 1 DHCP exchange (4 packets if done all the way, which it
probably should be for this).

kre

---

From: "Philip Nye" <[email-masked]>
Date: Mon, 10 Feb 2003 15:57:25 -0000

> From: "Bernard Aboba" <[email-masked]>
>

This is particularly relevent when a host detects a reconnection or wakes up
after shutdown or sleep. It may have a static address or a perfectly valid
DHCP lease. How does it detect whether it is still on the same network where
these were valid?

In the case of DHCP it can attempt to renew, but that can take a long time
and might fail for other reasons - because the DHCP server is down doesn't
mean that the existing lease can't be used.

One quick method would be to ARP for the default router (and any other
routes). If it can't get to a router then assigning a LL address is probably
a good bet.

Is there any mileage in putting discussion of this case in the draft?

Philip

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Feb 2003 11:40:08 -0500

> This is particularly relevent when a host detects a reconnection or
> wakes up after shutdown or sleep. It may have a static address or a
> perfectly valid DHCP lease. How does it detect whether it is still on
> the same network where these were valid?

There are a whole set of issues related to host recovery from
moving, sleep/wakeup, network failures, dhcp failures, etc.,
all of which present the host with similar conditions but may require
different recovery techniques depending on exactly what has happened. 
It would be useful to work out recommendations for such recovery but I
doubt we'll be able to do this for this draft -- or for that matter, in
this working group.

For instance, hosts ought to be able to assume that a DHCP lease is
renewable in the event that the server cannot be contacted.  But this
isn't the way that DHCP was designed to work, and it can't be fixed
without changes in DHCP.

But the last thing I'd want is for a host that had a DHCP address, that
happened to try to renew its lease at a brief time when the DHCP server
was inaccessible, to deprecate its routable address in favor of a v4LL
address.  That would make the host nearly useless in many situations.

Keith