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