Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [LinkSec] linksec roadmap





> It resides at the top  of the MAC 
> layer, and this placement prevents it from being used to protect 
> MAC-specific management messages.

Only when MAC management and control messages are embedded in the MAC layer.  Some do need to be in the MAC layer ... others could/should be made into a distinct layer above the MAC specific functions.

Paul

> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: Tuesday, December 10, 2002 10:27 AM
> To: Marcus Leech
> Cc: stds-802-linksec@ieee.org
> Subject: Re: [LinkSec] linksec roadmap
> 
> 
> 
> Markus:
> 
> GULS is a significant part of the reason that the 802.10c key 
> management 
> was never accepted.
> 
> There is significant misunderstanding about 802.10b SDE.  It 
> is intended to 
> work in a bridge or in an end station.  This is similar to 
> the way that 
> IPsec works in a router or in a host.  It resides at the top 
> of the MAC 
> layer, and this placement prevents it from being used to protect 
> MAC-specific management messages.
> 
> <soapbox>
> As explained in the SDE appendix, this is the only placement 
> that allows 
> the encryption and authentication to work with multiple MACs. 
>  It allows 
> encryption and authentication in a bridged environment 
> between a station 
> connected to an Ethernet and another station connected to a 
> Token Ring and 
> another station using a Wireless LAN.
> <\soapbox>
> 
> Russ
> 
> At 12:33 PM 12/10/2002 -0500, Marcus Leech wrote:
> >Russ Housley wrote:
> > >
> > > A bit of history.
> > >
> > > When the VLAN standard began, several people advocated 
> the use of SDE
> > > (802.10b) as the protocol.  Cisco wan the most vocal 
> proponent.  There were
> > > a whole bunch of people that were concerned that the 
> encryption overhead
> > > would be too great.  The initial response to this was to 
> specify the
> > > Identity encryption function.  In this case, the key 
> identifier would
> > > provide the VLAN identifier.
> > >
> > > After a few months, the wind direction changed, and the 
> VLAN proposal that
> > > we all know was adopted.
> > >
> > > The recently posted roadmap essentially proposes a return 
> to the original
> > > proposal.
> > >
> > > Russ
> >What was it about 802.10 that caused it to be a failure?  
> I'm anticipating 
> >that
> >   the answer is the key-management layer (GULS?).
> >
> >The roadmap had me somewhat confused, and maybe it's because 
> I don't really
> >   understand what the *application space* of VLANs is.  But 
> it seems to me
> >   that a LAN segment with a group-shared key suffers from the same 
> > problems as
> >   a completely unsecured LAN segment--I can spy on my 
> neighbours, and forge
> >   traffic.  Having a single key that is shared among 500 of 
> my nearest and
> >   dearest is like having no key at all.  Granted, I won't 
> be able to forge
> >   traffic on a *different* VLAN, but that's only slightly 
> better than nothing
> >   at all.  But maybe that's not what Dennis intended?
> >
> >
> >--
> >-------------------------------------------------------------
> ---------
> >Marcus Leech                             Mail:   Dept 8M70, 
> MS 012, FITZ
> >Advisor                                  Phone: (ESN) 
> 393-9145  +1 613 763 
> >9145
> >Security Architecture and Planning       Fax:   (ESN) 
> 393-9435  +1 613 763 
> >9435
> >Nortel Networks                          mleech@nortelnetworks.com
> >-----------------Expressed opinions are my own, not my 
> employer's------
> 
>