RE: [LinkSec] Failure of probe mechanisms to scale
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