RE: FW: [LinkSec] Requirements
Russ,
I'm not sure our models have converged yet, but they are probably getting
closer, so let me see if this answer makes any sense as a reply to your
question, or at least gets us another step forward.
In my basic model (at least the only variant of it that has seriously been
worked out and deployed) all the links that are ever at a network perimeter
(statically or dynamically as the network 'grows' from its core) are point
to point and protection is applied on a link hop by link hop basis so the
answer to the question 'where is the bridge through which I wish to access
the rest of the network' is an easy one. It is the bridge at the other end
of the link.
A bridge or end station that has multiple links will independently attempt
to seek connectivity on all its links. This process takes no account of the
spanning tree active topology at any time, .1D has a section that explains
that getting connectivity from a port to the rest of the network is
independent of the relay connectivity provided by the spanning tree
controlled MAC Relay Entity. This means that all the possible links
are/should be preauthenticated and preauthorised before the spanning tree
active topology needs to use them - so A&A doesn't impact reconfig time.
Clearly this model needs extending and refining to shared or semi-shared
media, and how that is done depends on the number of possible links. For a
.3ah ONU there is really only one link (to the OLT) so the fact that the
media is (semi) shared doesn't alter the basic procedure at all. Note that,
just as with Link Aggregation, A&A needs to run below any 'fixup bridging'
layer which converts the intrinsic point-to-multipoint nature of .3ah to a
shared media (this is not an architectural problem, and has no bearing on
which group should do the work).
For a shared media such as wireless there may be an embarassing number of
links. If I were designing a (rapid) data roaming service (as opposed to a
telephone roaming service) I would use an unprotected link layer discovery
protocol which selectively elicited responses on some criteria that would
avoid a deluge of replies to identify two or three likeley network access
ports/points and then preauth at those points, selecting one of the points
to be the active attachment point (and firing a couple of multicasts into
the network with the roaming stations MAC address to teach the rest of the
network where the roamer is, note that the attachment points themselves
don't have to know which is the active one, so they are out of the time
critical piece).
Note that in my models (basic and roaming extended) the end station never
has the task of finding out which bridge is doing crypto after that bridge
has begun crypto. The crypto wrapper is removed and separately applied hop
by hop.
In the bridged networks we deployed across the country we didn't imagine of
course that we could safeguard all control traffic back to the (twinned)
NOCs by such hop by hop protection. In each metro area we had a IPSEC tunnel
(the real picture is rather more sophisticated to cope with all sorts of
network partitions and failures in unattended locations without opening up
points of attack, but that detail is not relevant here) inside the enclave
(to borrow your term) for that area which went back to the NOC enclave. So
basically any time the protection couldn't be covered by hop by hop layer 2
mechansism it goes in a fixed higher layer tunnel (only for control
traffic).
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: Thursday, January 02, 2003 6:43 AM
> To: mick_seaman@ieee.org; stds-802-linksec@ieee.org
> Subject: RE: FW: [LinkSec] Requirements
>
>
>
> Mick:
>
> I hope you had a great holiday season.
>
> We agree that security associations must be able to terminate
> at stations
> or bridges. This give us three scenarios to consider:
> station-to-station,
> station-to-bridge, and bridge-to-bridge.
>
> Station-to-station is the easiest to handle. No
> crypto-enabled bridge
> discovery is needed.
>
> When a bridge is providing the crypto processing for an
> enclave, the other
> end must discover the appropriate bridge. Of course, if the
> spanning tree
> changes and the enclave has two bridges, this can change. In
> this sense,
> the bridge-to-bridge case is easier because bridges know
> about spanning
> tree changes, but stations do not.
>
> Do you have a proposal, other than probes, for a station to
> discover the
> appropriate crypto-enabled bridge?
>
> Russ
>
>
> At 03:20 PM 12/16/2002 -0800, Mick Seaman wrote:
>
>
> >In case I was obscure (more than usual) I should make it clear that I
> >believe any LAN security architecture should support protection over
> >vulnerable LANs/LAN segments where one (MAC addressed) end
> of the bridged
> >conversation is on an end station attached to a physically
> secured LAN, and
> >hence has no interest in implementing the LAN security protocol.
> >
> >To do otherwise gives us a huge "can't get there from here"
> problem. This
> >would mean that the bridge I am considering would have to
> decrypt/encrypt
> >all conversations from its vulnerable to its invulnerable
> side, proxing for
> >the true M-SAP destinations.
> >
> >Today's implementations of RSTP (Rapid Spanning Tree Protocol) can
> >reconfigure after failure in a few hundred milliseconds or better (I
> >consider two milliseconds per bridge in path to be
> achievable) in networks
> >where tens of thousands of conversations can be carried.
> That's a peak probe
> >issuance/response rate of ~10**5 per second. It is just such
> large networks
> >where the demand for security may be highest. The best
> bridges can (or
> >claim) to learn source addresses at line rate after
> reconfiguration, I don't
> >think anyone has an architecture which could issue/respond
> to probes at
> >anywhere close to that rate.
> >
> >Mick
> >
> > > -----Original Message-----
> > > Russ,
> > >
> > > The performance implications of using such a probe technique
> > > on network
> > > reconfiguration and failure recovery are awful to put it
> > > mildly. I can do a
> > > thorough justification of this statement given time, but this
> > > is probably a
> > > five beer conversation.
> > >
> > > 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: Monday, December 16, 2002 7:25 AM
> > > > To: mick_seaman@ieee.org
> > > > Cc: stds-802-linksec@ieee.org
> > > > Subject: Re: FW: [LinkSec] Requirements
> > > >
> > > >
> > > >
> > > > Mick:
> > > >
> > > > This is simply not true!
> > > >
> > > > Secure Data Exchange (SDE) (802.10b) can be either
> > > > station-to-station or
> > > > station-to-bridge or bridge-to-bridge. In fact, Annex 3A
> > > > (which is part of
> > > > the key management document (802.10c)), specifies the probe
> > > > frames that are
> > > > used to locate a remote SDE entity. These are needed when
> > > > the destination
> > > > address is not the same as the decryptor address.
> > > >
> > > > Russ
> > > >
> > > > At 10:15 AM 12/12/2002 -0800, Mick Seaman wrote:
> > > > >That sounds trite, but isn't. What I mean to say (and this
> > > > is the bridge
> > > > >point again) that if part of the newtork is believed
> > > > physically secured and
> > > > >frames are transmiteed in the clear, then 802.10 does
> not support
> > > > >encrypt/decrypt/protect etc. by the intervening bridges to
> > > > carry the traffic
> > > > >over part of the network deemed exposed. Setting up a tunnel
> > > > for the frames
> > > > >is really nnot a solution here.
> > > >
> > > >
> > >
> > >
> > >
>
>