RE: [LinkSec] Failure of probe mechanisms to scale
Russ,
Of course in the single hop scenario the recipient always knows who
encrypted the frame :-)
In the multihop intermediate encryptor case (which I believe is important IF
general multihop is to be included) I think the form of the solution you
indicate is the right one. With this solution I believe almost all time race
probes and the associated dropped frames (a good bridge design would never
hang on to a frame to await a probe result) could be eliminated. The
encryptors (it should be reasonably possible for there to be at least a
factor of 10 less of these that end stations in a service provider net,
although of course this is a design constraint albeit a rather lesser one)
can share information in advance - unlike the probe solution there is no
necessity for the path between X and Y to pass through a given encryptor E
for that encryptor to share information with a decryptor D about the
encryption (to be) applied to an X,Y conversation. Since E can now identify
itself in the frame it can in effect say 'if you ever see a frame encrypted
by me here is what I will be using' in advance.
A very important subset of the multihop case (one of the few I can convince
myself as fully designable in reasonable time in all aspects including
performance and high availability) in a provider net is customer edge to
customer edge on a VPLS (virtual private line point to point service). In
this case presharing and continuous updating of the necessary shared
information is not burdensome. However this is a case that could be easily
dealt with by installing existing tunneling technology, calling into
question the need for a link layer solution here at all. Perhaps a better
test case to choose (excuse me while I argue with myself to work this out)
is where the 'real' service provider has a flaky exposed network as a front
end access network. It seems that full presharing and updating of keys
(given the explicit identification of the encryptor as per above) could also
be supported in this scenario so that specific address probes are never
required (if a bridge can't decrypt a packet but needs to it simply discards
it and does not have to accumulate pending actions at wire rate). In the
case where each service provider connection only connects a single station
the scenario is revealed as the one that you already remarked is easy to
solve.
Unfortunately, as we go beyond wire service to LAN like service, multihop
scenarios seem to give rise to requirements for group keying and the
complexities thereof.
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 11:26 AM
To: mick_seaman@ieee.org
Cc: stds-802-linksec@ieee.org
Subject: 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