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

From: Stuart Cheshire <[email-masked]>
Date: Tue, 1 Jul 2003 11:57:34 -0700

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-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

---

From: Robert Elz <[email-masked]>
Date: Wed, 02 Jul 2003 04:40:15 +0700

Date:        Tue, 1 Jul 2003 11:57:34 -0700
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

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

That there is an issue that needs careful consideration, and for which
there is not one right answer that will necessarily suit everybody.

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

It has nothing whatever to do with being an experienced implementor.
Rather, it is probably more likely (from what I have observed) that
your average inexperienced implementor will simply follow the text of
the doc, and ignore side issues that require thought and making choices.

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

I do.   Even more than is there now preferably.   I seem to recall saying
way from the early days that that particular MUST is bogus.   But it is not
"ambiguity" (or should not be), it is a choice.   There is nothing wrong
with allowing choices where there is no one answer that is always correct.

  | 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.

There is nothing hidden about it - there's no question but that for
some environments (not all, certainly) keeping addresses rather than
silently releasing them is the right choice.

  | That's all I'm asking for: Make the document say 
  | exactly what it means in plain and clear language.

I have no problem with that.

  | 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.

Which is another way of saying that you'd really just prefer to hide the
security issue, not mention it at all - keep the MUST release the old address
and generate a new one, and ignore the issues that raises.   That's not
good enough.

kre