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