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.
> > >
> > >
> >
> >
> >