Re: [LinkSec] Failure of probe mechanisms to scale
Mats:
The only difference is that a bridge will determine the change from
protocols associated with the spanning tree, but the access point will
determine the changes based on protocols that involve the mobile station.
Russ
At 04:37 PM 5/7/2003 +0200, Mats Näslund wrote:
>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
>