Re: [LinkSec] Teleconf notes 5/27/03 (5 criteria update)
The current version of the 5 criteria as updated in the call is the
following:
Broadmarket potential
[a) Broad sets of applicability
b) Multiple vendors and numerous users
c) Balanced costs (LAN versus attached stations)]
-----
1.. Public/Provider networks for residential and business applications
represent a new and very broad application space for IEEE802 wireline
technologies. This project complements EFM, RPR and future projects by
addressing the security issues with a general view and acknowledging
Ethernet subscriber and metro access networks.
2.. At the Call for Interest on November 2002, 32 individuals from 18
companies representing both vendors and users expressed their support for
the project. 50-70 individuals from more than 30 companies have attended
the study group sessions.
3.. IEEE 802.1 vendors and users are able to achieve an optimal cost
balance between the network infrastructure components and the attached
stations.
-----
Compatibility
[a) Conformance with 802 Overview and Architecture
b) Conformance with 802.1D, 802.1Q, 802.1f
c) Compatible managed object definitions1.]
-----
1.. As a new IEEE Std 802.1 standard, the proposed project will remain in
conformance with the 802 Overview and Architecture.
2.. As a new IEEE Std 802.1 standard, the proposed project will remain in
conformance with 802.1D, 802.1Q, 802.1f.
3.. As a new IEEE Std 802.1 standard, the proposed project will remain in
conformance with 802.1x, though extensions to these standards may be
proposed as additional work items.
4.. As a new IEEE Std 802.1 standard, the proposed project will remain in
conformance with provider bridge specification defined by 802.1ad TG.
5.. As a new IEEE Std 802.1 standard, the proposed project will remain in
conformance with point-to-multipoint specification defined by 802.3ah TF.
---------
Distinct Identity
[a) Substantially different from other IEEE 802 standards.
b) One unique solution per problem (not two solutions to a problem).
c) Easy for the document reader to select the relevant specification.]
------------
1.. There is no existing link security specification for IEEE 802 wireline
technologies.
2.. IEEE802.10 is a general security mechanism applicable to all MAC
technologies. However, it has never been used and it requires too many
changes to be used for the target applications of the proposed project.
3.. The proposed project will leverage as much as possible from existing
802 link security mechanisms that are defined in 802.10, 802.11, 802.15,
802.16.
4.. The proposed project will be formatted as a new IEEE Std 802.1
document.
-------
Technical Feasibility
[a) Demonstrated system feasibility.
b) Proven technology, reasonable testing.
c) Confidence in reliability.]
-----
1.. Security mechanisms for IEEE802 wireless access networks have been
defined. IEEE 802 security expertise and additional expertise from other
security forums such as IETF Security Area will be used to define the
specification for this project.
2.. The proposed project will be based on mature security technologies and
re-use specifications developed by IEEE802 and other standards bodies to the
extent possible. It will only develop new mechanisms when necessary.
3.. IEEE802.1 has a successful track record in defining security protocols
for IEEE 802 technologies and also in defining link protocols independent of
the access technologies. This experience will be used for the definition of
this project and will follow the rigorous review process of IEEE802.1 WG.
-----
Economic Feasibility
[a) Known cost factors, reliable data.
b) Reasonable cost for performance.
c) Consideration of installation costs.]
------
1.. Similar technologies have been implemented in 802.11 and IPsec and
both have been proven to be cost effective solutions.
2.. Link security mechanisms are incorporated to other link mechanisms at
a reasonable cost increment. Initial studies show that encryption at the
Gbps rate is also possible with a similar relative low cost increment.
3.. The security mechanism will add negligible cost relative to the
installation cost of the access technology.
----- Original Message -----
From: "Allyn Romanow" <allyn@cisco.com>
To: <stds-802-linksec@ieee.org>
Sent: Tuesday, May 27, 2003 6:53 PM
Subject: [LinkSec] Teleconf notes 5/27/03
>
> LinkSec Teleconf 5/27/03
> Dolors Sala, chair, dolors@ieee.org
> Allyn Romanow, notes, allyn@cisco.com
>
> Attendees:
> Antti Pietliainen, Dan Romascanu, Dolors Sala, David Nelson, Allyn
> Romanow, Dennis Volpano, Tom Dineen, Mani Mahalingam
>
>
> Summary
> -------
>
> Discussion of the 5 criteria as described in Dolors note on mailing
> list 5/26
> Minor disagreements and clarifications, see below.
>
> Future work - update of 5 criteria. Will come to consensus at the
> Interim meeting.
>
> No teleconference next week, interim meeting in Ottawa, June 2-3.
>
>
>
>
> ==================================================
> Discussion of attendance at upcoming meeting in Ottawa. If we have
> trouble with attendance, we should see about co-locating with
> 802.3. This time, 802.3 was already meeting 3 weeks later than 802.1.
>
> Discussion of 5 criteria, mail sent by Dolors
>
> Broadmarket potential
> Is it intentional to specify wireline exclusively?
> While could be extended to larger scope, it is important to reflect
current
> interested parties. If we extend to a scope where people aren't
> participating, we would not be able to deliver.
> why use term public network?
> Because Mick used in his scope.
> Carriers would be a better name, we don't want to get into community
networks
> Re-word from "transition" to emergence of ethernet style connectivity into
> subscriber and metro access networks
> IF we mention RPR we need to mention metro access
> It is important to describe only new work that needs to be done, not
> work already undertaken
>
>
> Conformity
> 802.1f - common definitions and procedures for 802 management information
> a background chore that is always done
>
> Distinct Identity
> #2. discussion of "requires too many changes"
> There is some disagreement whether 802.10 should be re-worked, however
> there seems to be a consensus that we should start from scratch
> .10 only needs tweaking, vs. .10 not enough on target to use it
> We should have a slide for the presentation stating reasons why not using
.10,
> as this argument is likely to come up again
>
> #3 Antti, 802.1 is bridging, whereas this, LinkSec, isn't bridging so it
> shouldn't be an 802.1 document
> 802.1 is architecture as well
> What we do within 802, has to be compatible with 802.1 bridging, an
> historical requirement. Require interoperability with dot1 bridging
> Just as dot1x is within the 802.1 umbrella, linksec also can be
>
> Technical Feasibility - no discussion
>
> Economic Feasibility
> #1 - Similar technologies in 802.11 and IPSec, in both h/w and s/w. Cost
> factors known and in proportion. Have proven to be cost effective
> solutions. The issue in a) is "known"
>
> Discussion of key management being "out of scope" for the PAR. The
> consensus was that key management is indeed required as part of the
> complete link security solution, that we would re-use existing, well
> understood key management protocols as appropriate, and that the PAR
> under discussion isn't the entire link security solution, but only the
> Ethernet frame format portion.
>
> So, yes, key management is "out of scope" for the current PAR but not
> out of scope for the entire link security solution, which will likely
> require follow-on PARs and projects.
>
>
> Future work - update of 5 criteria
>
> No teleconf next week as we have the Interim meeting
>
>
>
LinkSec5criteria.doc