RE: [LinkSec] Failure of probe mechanisms to scale
Mats,
Depends what you mean by fundamental, since this is a question of scale i.e.
of numbers. How many systems appear to move, in what timescale, in what time
do other systems need to detect and restore or replace out dated
information, where are the systems that can directly detect the move and how
much information do they need to transfer to those that need to know but
have no way of detecting the change. Conversely, is the set of information
that could be shared before hand to remedy a time race large, and indeed
what classifications of system types against a number of architectural
variants are permitted.
I suppose that if the number of end stations is 'E' and their mobility rate
'e' while the number of bridges is 'B' and their acceptable reconfiguration
time rate for 95% upper case failure is 'b' then one could describe
solutions as fundamentally different as they scale as O(Ee) or O(Bb) or some
powers thereof or relationship between these and other parameters. In those
cases one could identify, against any particular solution, that some network
changes are fundamentally different to some others.
Mick
-----Original Message-----
From: owner-stds-802-linksec@majordomo.ieee.org
[mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Mats
Naslund
Sent: Wednesday, May 07, 2003 7:37 AM
To: Russ Housley
Cc: mick_seaman@ieee.org; stds-802-linksec@ieee.org
Subject: 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
>