RE: Resend: Re: [LinkSec] Proposed Scope for LinkSec PAR
If the secured frame format does not use an Ethertype instead of a SAP then
some company or companies will have to band together to produce an SFF which
does use an Ethertype (the only sensible way to cope with overlength
frames). This SFF will then be usable for frames that satisfy the proper
size limits, so will simply be the only one deployed.
By chosing a new Ethertype we will be able to remove any traces of
historical baggage, and will not have to allow as optional items that need
to be mandatory. Options are an invitation to lack of testing and lack of
interoperability, and should be avoided if at all possible.
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: Friday, May 09, 2003 9:11 AM
To: Norman Finn; LinkSec
Subject: Resend: Re: [LinkSec] Proposed Scope for LinkSec PAR
Norm:
> d. Within the SDE protocol, certain deficiencies need to be addressed:
> 1. The LLC encapsulation now used cannot support giant frames, and
> support for giant frames is needed. Therefore, we need EtherType.
802.10e tells how to carry a protected EtherType and associated
payload. This was the first standard that acknowledged the EtherType, and
at the time it was very difficult to get through the Exec Comm. Times have
changed. Are you suggesting that SDE have its own EtherType instead of a
reserved SAP? At the time that SDE was developed, the EtherType was
politically unacceptable.
> 2. The current header format, I believe, precludes adding a sequence
> number to each data frame, which is required for replay protection.
It is actually quite easy to add things like this. For example, 802.10
defines an optional security label. The sequence number should be handled
in the same manner.
> 3. The current SDE requires unicast frames to use an Individual SAID,
> and multicast frames to use a Group SAID. Group SAIDs are an
> IEEE-managed address space. This seems to preclude, for example,
> a single security association between two bridges that encrypts
> every frame exchanged between them.
I disagree with your interpretation of the standard. An individual SAID is
used when two SDE entities are party to the security association, that is
it is a pairwise security association. A group SAID is used when more than
two SDE entities are party to the security association.
The text describing the handling of multicast traffic was not written with
adjacent bridge-like devices in mind. It seems like a straight forward
improvement to describe how "transport mode" and "tunnel mode" are handled.
> 4. There may be some issues with the scope of SAIDs and Provider
> Bridges.
I do not understand this one.
Russ