Re: LL11: Add security consideration

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