[LinkSec] Group SAID and SFF (secured frame format)
SFF needs to differ from 802.10 SDE in its definition and allocation of
group SAIDs. As Norm says group SAIDs are, according to 802.10-1998 an IEEE
managed address space, with allocated values of 21 bits in length.
Unfortunately no one on the IEEE RAC (Registration Authority Committee) was
aware of the requirement to have a registration authority manage and assign
such values, nor is there an IEEE staff activity in place which does so. I
can only conclude that no one has ever applied for one. There should be no
practical obstabcle to changes in this area.
I think it is most unlikely that the RAC would approve of setting up a new
registration authority to dispense 21 bit items when we already have a
working authority to dispense 24 bits (the OUI, and yes it is 24 bits not 22
to avoid dangerous variations and misunderstandings as to octet alignment).
If we have a similar format going forward it should use 24-bits (so long as
it can be satisfactorily shown that such use will be in proportion to, and a
very small fraction of, OUI assignments for station address use so it does
not fall into the 'new application' trap).
Mick
-----Original Message-----
From: owner-stds-802-linksec@majordomo.ieee.org
[mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Mick
Seaman
Sent: Friday, May 09, 2003 10:03 AM
To: 'LinkSec'
Subject: 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