RE: [LinkSec] Proposed Scope for LinkSec PAR
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