Re: [LinkSec] Proposed Scope for LinkSec PAR
Mick,
I *think* you're taking exception to the line in the proposed scope:
Modify the Secure Data Exchange protocol to use an Ethertype
encapsulation, support replay protection, provide for a single
Security Association to connect up to all of the MACs attached
to a single LAN, and support Provider Bridges (802.1AD).
It's hard to walk the line between saying too much and saying too
little. If you'd like to offer words to loosen this up, I'd most
likely agree with you. It's entirely possible, of course, that by
the time we modified the SDE to address the named tasks, we'd have
an encapsulation in which the remnants of 802.10 might be very hard
to detect.
If you'd like to reorder the three pieces of work to avoid the
implication that the packet format is to be settled first, I'd have
no objection, either.
-- Norm
Mick Seaman wrote:
>
> Norm,
>
> While I agree with your general direction and agree that there is much good
> material in 802.10 I could not support a PAR that dragged the whole of
> existing 802.10 into the subtask of designing an encrypted packet format. I
> continue to believe that designing extensible packet formats (while great
> fun) and letting the rest of the work follow on after, is a receipe for
> vendor specific deviation, unneccessary complexity, and simply missing the
> mark at times. (At the same time I'd be very happy to work on following up
> on your ideas as to what a format should look like, as a strawman to be
> constantly examined while we complete the rest of the work. I believe that
> one needs to iterate and learn from a design, not establish a soviet 5 year
> plan model of setting objectives and then running without feedback to
> produce all parts of the machine separately.)
>
> The recent conversation on this list causes me to believe that we still
> haven't got the system aspects of the design clear and universally agreed
> and to breathe new life into an old part of the solution which contains
> things that are not in an appropriate system design would be a mistake.
>
> By all means let us recognize the extremely valuable contribution to the
> present work made by those who participated in 802.10 work. There are a
> number of ways we could publicly acknowledge that in a new standard. By all
> means let us borrow extensively, perhaps huge chunks from some of the
> background work carefully assembled and presented in .10. But let's not end
> up by reratifying options and opportunities that don't fit into an agreed
> system design.
>
> Mick
>
> -----Original Message-----
> From: owner-stds-802-linksec@majordomo.ieee.org
> [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Norman
> Finn
> Sent: Tuesday, April 22, 2003 12:09 PM
> To: LinkSec
> Subject: [LinkSec] Proposed Scope for LinkSec PAR
>
> For your discussion, here is a proposed scope for one PAR for LinkSec.
>
> First, the Scope and Purpose of the existing IEEE Std. 802.10-1998:
>
> his standard was developed to provide security in IEEE 802 Local Area
> Networks (LANs) and Metropoli-tan Area Networks (MANs). The model for
> providing security services is described in Clause 1. A Secure Data
> Exchange (SDE) protocol for IEEE 802 LANs and MANs is defined in
> Clause 2. Key management in IEEE 802 LANs and MANs is described in
> Clause 3 (published separately as IEEE Std 802.10c-1998). While SDE
> is independent of any key management or system management
> implementation, the security services described in this standard
> depend on management information provided by management entities.
>
> Now, a proposal for a scope for a new LinkSec PAR:
>
> Amend IEEE Std. 802.10-1998 in the following ways: 1) Modify the
> Secure Data Exchange protocol to use an Ethertype encapsulation,
> support replay protection, provide for a single Security Association
> to connect up to all of the MACs attached to a single LAN, and support
> Provider Bridges (802.1AD). 2) Modify the description of bridge usage
> of 802.10 to use this single LAN Security Association. 3) Specify how
> to use IEEE Std. 802.1X-2001 (and its successors) to perform Secure Key
> Management.
>
> Brief justification and/or discussion starter:
>
> a. The suggestion is to amend 802.10-1998, as it has a lot of good
> stuff.
>
> b. Three parts to the scope: encapsulation (SDE protocol), the
> description (not specification) of how bridges use it, and
> specifying how to apply 802.1X to the problem of key exchange.
>
> c. This PAR does not cover the changes to 802.1X required to support
> the new LinkSec document; that would be a separate PAR.
>
> 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.
> 2. The current header format, I believe, precludes adding a sequence
> number to each data frame, which is required for replay protection.
> 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.
> 4. There may be some issues with the scope of SAIDs and Provider
> Bridges.
>
> -- Norm