Subject: Re: LL11: Add security consideration

From: Stuart Cheshire <[email-masked]>
Date: Thu, 22 May 2003 12:05:20 -0700

>There is no precedent for including additional stern and palliating text
>to Security Considerations sections.  When the protocol specification
>says a feature MUST be implemented, this is unambiguous.  An implementor
>has to be informed about the security implications, and that's what
>belongs in the Security Considerations section.
>
>It is dangerous to mention a that specific feature is 'still' required,
>despite a vulnerability it exposes.  This could imply (to a reader with
>imagination) that other requirements are not necessarily firm and
>*could* be ignored to address vulnerabilities.

The underlying problem is that I don't agree with the proposed warning.

I believe it is incorrect, misleading, unhelpful, and ultimately 
counter-productive with respect to the purpose of the document, which is 
supposed to be to help vendors make products that work well and 
interoperate.

The proposed warning says that a rogue host on the local link could send 
fraudulent ARPs to trick you into changing your address, and furthermore:

    This is a distinct threat from that posed by fraudulent ARPs,
    described in the preceding paragraph.

The simple fact is this: If two devices on the same link are broadcasting 
ARP packets with the same sender IP address and different sender hardware 
addresses, neither will achieve reliable TCP communication until one or 
other stops doing that (e.g. by changing to a different address). Anyone 
who doubts this should try it with a pair of Linux machines and see for 
themselves what happens.

The truth is that changing to a different address is the *solution* to 
the problem of two hosts trying to use the same address, and any text 
that casts this in the light of "problem" rather than "solution" leads to 
less clarity of understanding, rather than more.

I know that Erik Nordmark views changing your IP address firmly in the 
category of "problem" rather than "solution", which is why he wants 
language in the draft to encourage other people to see it that way too, 
but speaking as someone who has to deal with vendors making actual 
products, encouraging them to perceive changing your IP address as a bad 
idea is leading to a bunch of crummy products that don't work. By making 
their product guard against this hypothetical malicious attack (which in 
reality will *never* happen on the typical user's home network) they make 
their product fail in the face of accidental address conflicts (which -- 
counting all home networks on the entire planet -- is likely to happen 
relatively frequently). Let us be clear on this: If a fraudulent ARP 
attack were to happen on your home network, having your LL devices fail 
to reconfigure is not going to help one little bit. Stopping the attack 
is going to help you.

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

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 26 May 2003 12:03:10 +0200 (CEST)

> language in the draft to encourage other people to see it that way too, 

Stuart,

I truly believe you've misunderstood what I've said. The alternative
is that you are intentionally misconstruing my comments, which I do not
think is the case.

My first point is that the change to the way ARP is used from
detecting and doing nothing, to detecting and changing the IP address,
is a significant change hence it makes sense to think carefully about
this change.

My second point is that without being able to secure ARP,
there is a very difficult tradeoff between reacting to ARP messages
by changing the IP address (helps when the box doesn't need a long-term
stable IP address when there are no attackers on the link)
and defending the address (helps when those are not true).
Glossing over the existence of this tradeoff would be a disservice to the 
quality and integrity of the standards issued by the IETF.
Since we are not going to get a secure ARP deployed at a minimum
the specification needs to present this tradeoff to the readers/implementors.

So this is not a black and white technical discussion.

   Erik