Subject: LL11 Add security consideration for the threat where an attacker forces address reconfiguration

From: Stuart Cheshire <[email-masked]>
Date: Tue, 11 Feb 2003 19:31:40 -0800

Erik Nordmark proposed:

>A host implementing IPv4 link-local configuration has the
>additional vulnerability to selective reconfiguration and
>disruption. It is possible for an on-link attacker to issue ARP
>packets which would cause a host to break all its connections by
>switching to a new address. The attacker could force the host
>implementing IPv4 link-local configuration to select certain
>addresses, or prevent it from ever completing address selection.
>This is a distinct threat from that posed by fraudulent ARPs,
>described in the preceding paragraph.

I disagree that this is a materially different threat from the normal 
chaos that ensues when two hosts are accidentally given the same IP 
address.

In an on-link attacker spoofs ARP packets, then in reality you will lose 
all your TCP connections to resets and timeouts, even if you do refuse to 
pick a new address. The difference is that if you refuse to pick a new 
address, you will be unable to establish any reliable new TCP connections 
either.

If you doubt this, open a bunch of telnet or ssh connections, and then 
set another local machine to the same IP address and see what happens. 
(Note: don't try to do this with a Mac, because Macs implement IPv4ACD to 
guard against accidentally or deliberately setting two hosts to the same 
IP address. Using some other OS you should be able to set two machines to 
the same IP address and see what happens.)

The reason I am reluctant to support the proposed change is that I do not 
feel it meets one of the important requirements for text in an RFC: 
namely that it help the reader come to a true and accurate understanding 
of the relevant issues.

As written, the proposed text overstates the vulnerability of IPv4LL to 
this kind of attack, while at the same time implying that 
manually-configured and DHCP-configured hosts are less vulnerable to the 
effects of the very same attack (or accidental misconfiguration). To 
imply this would be, I feel, a disservice to the reader.

Stuart

---

From: Stuart Cheshire <[email-masked]>
Date: Sat, 15 Feb 2003 14:19:03 -0800

Robert Elz wrote:

>I agree with you (I think) that none of this is severe enough, compared
>with what currently is possible, to warrant requiring any changes to
>the protocol itself.   But there is enough here that noting the issue
>in the security considerations is important.

It is important that we describe the relevant issues clearly, but my 
concern is that the document is not serving its intended purpose if we 
fail to find the right balance between honest clarity and alarmist 
language.

Some of the problems are simply inherent properties of (a) any network 
which does not have full connectivity to every other host in the world, 
and/or (b) any network where no single authority has been designated, so 
that in the absence of authority, the hosts have to agree to work 
cooperatively (or not work at all).

If the document does not distinguish between (i) the inherent problems of 
an isolated authority-less network, and (ii) the specific problems due to 
*this* particular solution, then we are not informing the reader.

This is not an irrelevant academic concern. One of the problems I face 
frequently is talking to vendors who have decided that their device does 
need link-local autoconfiguration, but they are not going to do it "the 
IETF way" because "the IETF way is known to be full of massive security 
holes". Instead they have invented some bizarre mechanism of their own, 
which works much less well, and has all the same security problems (and 
more).

If we write a document that ends up convincing a large minority of its 
readers that they should go off and invent their own solution instead, 
then the standard will have failed its primary purpose, which is to 
increase interoperability, not decrease it.

I'm not saying we shouldn't clearly describe the problems, but excessive 
harping on those problems to the point where vendors (continue to) invent 
their own solutions instead of implementing the standard is 
self-defeating rather than helpful.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org