Re: LL11 Security consideration for the threat where an attacker forces address reconfiguration

Thanks for your response Erik.

>One can either implement the entire specification - abiding
>by *all* requirements, as standardized, or not.

>A MUST is a MUST.

I am glad to see you take this position. I agree.

I'll ask you to take a moment to try to follow the chain of logic set out 
below, to try to understand why I am concerned about the current wording:

1. Draft-08 describes the "distinct threat" as follows:

   A host implementing Link-Local IPv4 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 Link-Local IPv4 configuration to select certain
   addresses, or prevent it from ever completing address selection.
   This is a distinct threat from that posed by spoofed ARPs

2. You wrote:

   In all cases ... it is necessary for implementers ... to
   analyze the known and credible threats ... and to the extent
   that it is feasible, to provide security mechanisms which
   ameliorate or reduce the risks associated with such threats.

Okay, so now we know two things: (1) there is a "distinct threat", and 
(2) it is the responsibility of the implementer to understand the threat 
and to take the appropriate action.

3. What is the typical implementer to conclude from this?

Will the typical implementer conclude that the appropriate action is "do 
nothing" and that the extent to which the threat can be ameliorated is 
"not at all" (which I believe is the correct answer)?

Alternatively, will the typical implementer conclude that, since there is 
a distinct threat, and it is their responsibility to take the appropriate 
action, then that means they are supposed to *do* something about it?

Clearly this is not a hypothetical discussion. Even Robert Elz, who has 
been involved with this document for a long time, wrote:

   it is entirely reasonable for a host, if it wants,
   to simply cling onto its address and refuse to let go.

If Robert thinks this, then how many inexperienced implementers will 
think the same thing?

I do not want a document with this ambiguity in it.

It is fine for you to say, "A MUST is a MUST," but at the same time, 
there is clearly a school of thought that believes a Security 
Consideration trumps a MUST.

All I am asking for is a very simple thing: The document should not be 
ambiguous. If there's a hidden agenda that some people do want 
implementers to make products that cling to their address no matter what, 
then we need to get that out in the open and discuss it properly. If 
there is no such hidden agenda, then lets make the document complete the 
unfinished line of reasoning that it introduces by describing the 
"distinct threat". That's all I'm asking for: Make the document say 
exactly what it means in plain and clear language.

I'm not asking for any change of direction for the document. If the true 
intent of the document is as I believe it is (and as you say, "A MUST is 
a MUST,") then all I am asking is that we explicitly close the loophole 
that will otherwise be used to justify "cling to your address" behaviour.

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