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

Stuart Cheshire <[email protected]>
Newsgroups gmane.ietf.zeroconf
Message-ID <[email protected]>
>Of course, so you do implement that part, and make sure you get a
>unique address.   Then, if it later turns out you were wrong, one
>reasonable option is to just say "I give up".

I do not agree. I do not think it is reasonable for a networking product 
to just "give up". I do not want to buy a product that just gives up, and 
I'd rather that other people didn't have to either.

>Aside from deliberate attacks, which nothing in the LL draft will allow
>a host to survive

Agreed. The entire specification is predicated on cooperating hosts. If 
the other participants refuse to cooperate, systematically denying every 
probe, then this (or any other mechanism based on cooperation) cannot 
succeed.

>the only way this problem can occur, that I'm aware
>of, if when two previously independent links are connected to become
>one link (bridging enabled, or whatever).

No, it happens when network operators have Spanning Tree port blocking 
times set too high. AppleTalk had no late conflict detection, and failed 
badly in these environments. As a result, Apple had to advise all sites 
using AppleTalk to disable Spanning Tree, or at least dramatically reduce 
the port blocking time. It was an ongoing headache for Apple.

Late conflict detection provides MUCH improved behaviour in these 
situations.

>if address conflicts occur, it is entirely reasonable for a host,
>if it wants, to simply cling onto its address and refuse to let go.

No, I absolutely disagree.

The motivation for this Working Group (at least for some of us) since the 
first day has been to bring some of the benefits of AppleTalk to IP, 
without repeating the mistakes of AppleTalk.

Ignoring late conflicts was one of the disastrous mistakes of AppleTalk.
It caused endless problems.

If this Working Group cannot agree that a host MUST NOT ignore late 
conflicts, then I fear we will have arrived at an unresolvable deadlock.

Stuart Cheshire <[email protected]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.