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