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

Stuart Cheshire wrote:
>>The correct response is to make an advised decision whether to implement
>>it or not.
> 
> 
> Erik, I asked an *extremely* simple question, and you have still skirted 
> around answering it.
> 
> When you write "it" in your sentence what are you talking about?
> 
> Are you saying, "The correct response is to make an advised decision 
> whether to implement IPv4LL or not."
> 
> Are you saying, "The correct response is to make an advised decision 
> whether to pick a new address in response to a conflict."
> 
> Which is it? This ambiguity is precisely the point I am making. Until I 
> know what you are saying, I can't tell if I agree with you or not.

One can either implement the entire specification - abiding by *all*
requirements, as standardized, or not.  We cannot prevent those
who are determined to from violating standards.  But the IETF must
expect that if vendors are interested in interoperability, 
administrability and their products functioning correctly and
appropriately on the network, they will implement specifications
abiding by the rules.  A MUST is a MUST.

>>If one implements the protocol, with the risks in mind,
>>one can take the necessary precautions - for instance using
>>application layer security, or whatever.
> 
> 
> How does application layer security protect against Erik Nordmark's 
> "distinct threat".
> 
> 
>>You are suggesting toning down security considerations which have 
>>achieved consensus in the WG.
> 
> 
> No, I'm saying that the document should be providing answers, not 
> unanswered questions. Having explained the "distinct threat", the 
> document should give developers guidance about what they should do about 
> that threat, not raise the issue and then leave the question unanswered.

    In all cases, whether or not Link-Local IPv4 addresses are used, it
    is necessary for implementers of devices supporting the Internet
    Protocol to analyze the known and credible threats to which a
    specific host or device might be subjected, and to the extent that it
    is feasible, to provide security mechanisms which ameliorate or
    reduce the risks associated with such threats.

Security can be provided for applications which are using ipv4 ll which
'ameliorate or reduce the risks' described above.  For example, use of
application layer security.  In the case we are discussing, where one
can use the weakness of ARP combined with its central role in IPv4 LL
to disable hosts, there is no direct defense.  One extremely concerned
about these specific on-link active attacks might decide for this reason
to avoid implementing IPv4 LL entirely.

If the criteria for publishing this RFC on the standards track is that
we come up with a secure solution to the problems exposed by IPv4 LL,
we will not publish this document.  In this case, I believe it is
sufficient to document weaknesses which are exposed but not countered.
IPv4 LL relies on ARP and which has known vulnerabilities; IPv4 LL 
amplifies those vulnerabilities in ways we document.

Erik