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

    Date:        Tue, 24 Jun 2003 20:10:55 -0700
    From:        Stuart Cheshire <[email protected]>
    Message-ID:  <[email protected]>

  | 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.

Opinions differ.   I do not want to buy a networking product that allows
others to trivially easily steal my connections, and I'd rather that other
people didn't have to either.

This all depends on what the devices are doing, there is not, and cannot
be, one right answer for everyone.

  | No, it happens when network operators have Spanning Tree port blocking 
  | times set too high.

This is something that only affects initial address assignment.  You may
recall that I made several different proposals for how to deal with this
one (one being as simple as to never assign a LL address for at least a
minute, to make sure that this problem won't occur in any practical sense).

  | 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.

I'd advise that anyway, for ports where no other switch is connected,
it speeds up getting operational - regardless of appletalk.

Still, I agree, we need a method to assign addresses initially which isn't
broken by something that we know exists in the world.

But we don't need "any time an address conflict is ever detected, give
up and start again" for this purpose.

If we have probed the address after the network (link) is operational
(which we can tell when we receive any packets that aren't link level
management noise - STP packets and such) and not found a conflict, then
this startup problem doesn't exist.   If we haven't received any real
packets from the network, then the issue I'm concerned with doesn't
exist (we can't be talking to anyone else yet, as we can't have received
an ARP reply from anyone).

  | Late conflict detection provides MUCH improved behaviour in these 
  | situations.

If the only thing that you want to fix is this one thing, and you don't
care about any other problems, then yes, it does.   I care about the
other problems, and unconstrained late conflict resolution (detection
is harmless) causes way too many problems to allow in general (for some
nodes it is fine, for others it is not).

  | 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.

Fine.   But avoiding the mistakes of appletalk should not mean introducing
problems that appletalk never had!    That is, we aren't free to do anything
at all we can imagine, constrained only by not repeating a mistake that
was in appletalk.

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

So, we need to find a fix that works, the one you're proposing would be
worse that the issues that you saw - you just haven't seen it happen yet
(just like apple obviously didn't see the STP related problems before
they started shipping ethertalk the way it was shipped, or that would
have been fixed before it was too late, I'm sure).

  | 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, we already had agreement in this WG on L11, you're the only
one arguing against what is there now.   That is, implementations must
consider carefully whether they should simply abandon an address upon
detecting a conflict.   And they certainly should.

Note, also this isn't a question of "ignore" late conflicts, but with what
the host does once it detects one.   So, while I expect everyone would
agree with you on the question as you phrased it above, that isn't really
the relevant question, is it?

If you want to re-open one of the issues (or was there just one?) that
related to initial address assignment procedures, and the timers used for
that, you might find me agreeing with you (even though the WG more or
less decided to simply ignore the problems caused by STP).   But not on
this one.

kre