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

Stuart Cheshire wrote:
>>>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."
>>
>>We disagree.  It says something like 'doing this exposes you to
>>vulnerabilities.'  Its like driving - you should know that you
>>could be smooshed every time you go on the freeway.  You don't
>>have to go on the freeway, but it would be extremely negligent
>>of your driving instructor to not let you know what you are facing.
>>You should not neglect what precautions you have like seat belts
>>insurance, etc (higher layer security protocols, no assumptions
>>that no one would ever perform an active attack as described).
> 
> 
> I'm afraid you are still not seeing the point I am making.
> 
> The point is not about the security issue. The point is about the implied 
> response to the security issue.
> 
> Having understood the security issue, is the correct response to not 
> implement IPv4LL AT ALL? Or, is the correct response to implement IPv4LL, 
> except the part about changing the address in response to a conflict?

The correct response is to make an advised decision whether to implement
it or not.  If one implements the protocol, with the risks in mind,
one can take the necessary precautions - for instance using application
layer security, or whatever.  IPv4LL is absolutely no different in this
respect than any other protocol published by the IETF.

If an implementor does not care about standards compliance, she or he
will probably ignore the standard.  If interoperation and vendor
reputation (delivering quality networking products to the market) is a
high priority, the implementor will not ignore requirements.

You are suggesting toning down security considerations which have 
achieved consensus in the WG.  Your argument is that this will avoid
alarming implementors, that the current wording tempts implementors to
ignore requirements.  This does argument does not persuade me.  What are
others' opinions?

Erik