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

Recap (it's been a while):

We were discussing whether the "Security Considerations" text might lead 
some implementers to conclude that it's better to cling to a conflicting 
address and fight over it, rather than give up and pick another.

I wrote:
>What is the typical implementer to conclude?
Robert Elz wrote:
>That there is an issue that needs careful consideration, and for which
>there is not one right answer that will necessarily suit everybody.

This was precisely the point I was making:

If a vendor of home Hi-Fi equipment hires me as a consultant to advise 
them, I'll tell them the device should pick a new address on conflict.

If a vendor hires Robert Elz as a consultant to advise them, he will tell 
them the device should cling to its address and not pick a new one.

This is no good. The spec needs to define the rules for the protocol 
objectively, not subject to individual interpretation.

I wrote:
>I do not want a document with this ambiguity in it.
Robert Elz wrote:
>I do.   Even more than is there now preferably.

This is no good.

I wrote:
>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.
Robert Elz wrote:
>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.

So, it is very clear. We have absolutely no prospect of agreement on 
this. The Working Group needs to come to a decision. Are devices required 
to pick a new address on conflict or not?

I believe that in the hostile environments Robert Elz is talking about, 
IPv4LL is simply not suitable at all, so warping it to accommodate an 
environment where we know it can never work anyway, is pointless. We 
should just say that IPv4LL requires cooperating hosts, and if you don't 
have cooperating hosts, then don't use IPv4LL. It's that simple.

When it is not possible to please everyone, the Working Group needs to 
make a decision and accept that some group of people will be unhappy with 
the result. To try to please everyone just results in unending stalemate. 
It has now been five years since IPv4LL shipped in Windows 98 and Mac OS 
8.5.

The way to make a protocol specification is not to make it sufficiently 
vague that all of the participants are able to interpret it differently, 
such that they all think it can be read to support their point of view.
That gives only the illusion of consensus, not real consensus.

Let's try to make a decision here, and make the document state that 
decision clearly, so that it's not subject to individual 
re-interpretation.

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