Subject: Re: LL11: Add security consideration

From: Stuart Cheshire <[email-masked]>
Date: Wed, 4 Jun 2003 14:36:42 -0700

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

Thanks for giving me the benefit of the doubt. I am not intentionally 
misconstruing your comments; I am struggling to understand them.

One of the things I learned from Mary Baker, my PhD advisor at Stanford, 
was that the difference between a good research paper and a great one 
comes not from seeing how much you can add, but from how much you can 
take away. One of the exercises she made me do was to take sentences from 
my papers and delete every adjective from them. Surprisingly often, the 
resulting sentence was a dramatic improvement. (Lest you doubt the 
effectiveness of Mary Baker's advice here, during the time I was in her 
research group we published a large number of research papers without a 
single one ever being rejected. When you are submitting to extremely 
competitive conferences and journals that on average reject over 90% of 
all submissions, getting a paper accepted at all is an achievement. 
Managing to do it time and again without fail is truly remarkable.)

In the case of this new paragraph for the IPv4LL document, I am trying to 
understand what concrete value it adds to the document.

Let me make my question very precise:

   Having read the new paragraph, what specific action should
   an implementer take, that they would not otherwise have taken
   were that new paragraph not in the document?

The best possible outcome I can think of is that the implementer takes no 
action. The danger is that some implementers might believe that some 
action is required, and then go and change their implementations in some 
way that breaks them.

The remainder of your email illustrates the difference of opinion that we 
still seem to have:

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

Who has to "think carefully about this change"? Us, or the implementers?

If is is "us", then it's our job to think carefully about it, make a 
decision, and then record that result in the document (which we have 
done).

If it is "the implementers", then that implies we should put information 
in the document so that implementers can each think carefully about this 
for themselves, arrive at their own separate decisions, and produce a 
bunch of implementations that don't do the same thing. Is that what we 
want?

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

When you say you want to "present a tradeoff" to someone, it implies 
giving a balanced argument, so that they can weigh up all the evidence on 
both sides and reach their own informed decision. Is that what we're 
doing here?

As it stands, the paragraph reads like something saying, "This standard 
says you should pick a new address if you detect a conflict; here are 
some reasons why making your implementation actually do that would be a 
terrible mistake."

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

---

From: Robert Elz <[email-masked]>
Date: Thu, 05 Jun 2003 17:00:25 +0700

Date:        Wed, 4 Jun 2003 14:36:42 -0700
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | If it is "the implementers", then that implies we should put information 
  | in the document so that implementers can each think carefully about this 
  | for themselves, arrive at their own separate decisions, and produce a 
  | bunch of implementations that don't do the same thing. Is that what we 
  | want?

I know you're expecting a "no way" answer to that one, but actually,
yes, that's exactly what I think we want.   Different implementations
have different needs.   Keeping on operating, no matter what, is
going to be useful for some implementations, and for those, address
conflict causes immediate selection of a new address, so there is
something that works may be the best solution.

However, implementors need to weigh that against the possibility that
after having been connected for some time, a "bad guy" can drive them
off the net, trivially easily, if they have adopted that strategy - all
that is needed is to claim the address, and then defend every other
address that the node tries.   Bye bye node, and it only takes a second.

Some implementations might actually prefer to keep actively attempting
to use the address upon detecting a conflict.   Two such implementations
will deadlock, until one of them is removed, but depending upon the needs
of the implementation in question, that may be the best result - that is,
only human activity (as in cycling my power) can cause me to abandon
what I was doing and start again.

Implementations only all need to do the same thing when that's required
for interoperability.   Here, that's not needed.

  | When you say you want to "present a tradeoff" to someone, it implies 
  | giving a balanced argument, so that they can weigh up all the evidence on 
  | both sides and reach their own informed decision. Is that what we're 
  | doing here?

Perhaps not, but it is better to at least give some hint that there
may be some problems that should be investigated, than to completely hide
the problem and hope no-one notices.

  | As it stands, the paragraph reads like something saying, "This standard 
  | says you should pick a new address if you detect a conflict; here are 
  | some reasons why making your implementation actually do that would be a 
  | terrible mistake."

When reduced to that simple form, it sounds fairly bizarre.   Maybe we
should simply stop saying that a new address "should" be picked, and just
say that it may be ?    With perhaps some of the reasons why doing so, or
not doing so, will sometimes be the best choice.

kre