Re: [LinkSec] Failure of probe mechanisms to scale
Hi
Out of curiosity: is there a fundamental difference (in terms
of discovering/solving) between this scenario and the case of "mobiltity"?
E.g. the fact that Y is connected via C rather than B could
depend either on the fact that:
* the path A -> B is down
* Y has moved and is reachable from C, but no longer from B
(e.g. Y pulled the 802.3 plug and is in the corridor using 802.11)
Thanks
/Mats
Russ Housley wrote:
>
> Mick:
>
> Perhaps the simple solution is to include a new plaintext header field when
> we make a revision to SDE. This would carry the address of A. Then, when
> C gets the encrypted frame that cannot be decrypted, the key exchange can
> begin without any need for the probe.
>
> I have not come up with a mechanism that replaces the probe the first time
> a frame is sent from X to Y.
>
> Russ
>
> At 09:35 AM 4/30/2003 -0700, Mick Seaman wrote:
>
> >One of the things we have to be clear about here is what we mean when
> we say
> >"SDE" here. If we are just talking "SDE like" where we can invent our
> >individual versions of "like" to suit our needs then much is possible
> (and I
> >support this along the lines that Norm has indicated, but in new focused
> >documentation). Given "SDE" then associations need to be probed on the
> basis
> >of individual MAC addresses. Given any bridge within the network that
> has
> >to verify any part of a packets integrity it needs to find association
> >information, even to verify that the MAC addresses have not been tampered
> >with.
> >
> >I have a problem with this as an underlying design for 802 security. If
> >there was a large SDE installed base I could agree to take advantage
> of that
> >installed base by crafting networks that were well served by that
> installed
> >base and looking specifically for deployment approaches that were
> reasonable
> >for SDE/probe. But there is no such installed base so that I don't
> want to
> >have to specially craft a particular type of provider net (and ignore
> other
> >networks).
> >
> >I would note that even for a rigid "provider edge box" scenario the
> number
> >of addresses that can move can be very large, all those on a customer
> site
> >for example. That's less than the figures I've been mentioning so far but
> >still could be 10,000. If the mechanisms is stimulated by failures on X,Y
> >address pairs that's an awful lot of stimulation. Sure we can figure out
> >extra ways around this, but in the absence of an installed SDE base
> with a
> >probe mechanism why are we operating in this pit? Given any fixed fact
> a lot
> >of ingenuity can be applied to work around that fact but as the number of
> >fixed facts rises the chances of a satisfactory solution diminishes
> rapidly.
> >There is no reason to choose a probe mechanism as a fixed fact, it
> just has
> >too many performance ramifications.
> >
> >Separately I am not talking about boxes (i.e. bridges) outside the
> physical
> >control of the operator, I am talking about fiber runs that are. Bridges
> >outside physical control have many more integrity issues and are
> unlikely to
> >be satisfactorily implemented using current commercial technology for
> >chassis let alone the links it supports. I don't expect customers to
> trust
> >providers on an internal hop by hop basis but providers need that
> protection
> >and it is difficult to use existing technology to tunnel protect all
> traffic
> >with internal dest/src. Separately I don't want to lose sight of the more
> >general scenarios in which an enterprise has a wholly owned network
> and is
> >deploying security part by part so there are intermediate bridges that
> >separate one region from another and have to deal with large numbers of
> >associations, again the figures for moves here can be in excess of
> 10,000 on
> >a single change (80,000 is not unknown in real continuous experience for
> >such a general topology bridged net).
> >
> >Mick
> >
> >-----Original Message-----
> >From: owner-stds-802-linksec@majordomo.ieee.org
> >[mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Russ
> >Housley
> >Sent: Wednesday, April 30, 2003 7:53 AM
> >To: mick_seaman@ieee.org
> >Cc: stds-802-linksec@ieee.org
> >Subject: RE: [LinkSec] Failure of probe mechanisms to scale
> >
> >
> >
> >Mick:
> >
> > >The point is that some changes in the core of the network will see a
> lot of
> > >changes. My focus is on securing these links as well, not just those
> at the
> > >edge of the net. I don't want a separate, not to be specified,
> mechanisms
> >to
> > >cover these core links. If SDE-enabled bridges are in front of
> protected
> > >networks, what is protecting the internals of these networks? These
> > >networks often have their fiber routed through patch panels not
> under the
> > >direct physical lock and key of the network provider but of the colo
> > >operator (your security mileage may vary).
> >
> >The physical environment is clearly important. This is actually part the
> >point that I was trying to make. There are reasonable deployment
> >approaches where an SDE-enabled bridge protects a physically protected
> LAN
> >segment. I am sure there are others ...
> >
> > >If your answer is that SDE associations are always tunneled across
> networks
> > >then I have other technology today I can use - with much pain and
> manual
> > >configuration so it is not really adequate but its problems are
> tunneling
> > >problems.
> >
> >I do not understand why a network operator would want the traffic to be
> >protected on a hop-by-hop basis, where some of the hops are in boxes
> >outside the physical control of the operator. Bridges that are installed
> >in the customer's physical space are my concern. If the keys in that box
> >can only be used to expose the customer's own traffic, then there is no
> >motive to tamper with the box. On the other hand, if keys in the
> box can
> >expose a neighbor's traffic, then there is a motive to mess with the
> >box. To thwart this, physical protections must be placed in the ox,
> which
> >significantly increases the cost.
> >
> > >I'd be interested in how you propose that an SDE bridge may be able to
> > >figure out what security associations are to be affected. In cases
> other
> > >than the SDE bridge being the edge bridge of the network I don't regard
> >this
> > >as possible in bridge networks as currently defined.
> >
> >You clearly know more about the spanning tree stuff than I do. If you
> >cannot figure it out, then I do not think I am going to find an insight
> >that you missed, However, we both seem to agree that it is not a big
> issue
> >to SDE-enabled bridges at the edges. Let's take advantage of that
> >situation.
> >
> >Russ
>