RE: [LinkSec] Teleconf notes 5/27/03 (5 criteria update)
> 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.
??? I disagree. The required changes are very small and manageable.
It might take just a day or three to put the necessary changes in and be
done with this effort. Why reinvent from a blank slate.
Also ... 802.10 SDE was implemented and worked quite well. It just
happens that it was on Government devices that you can not buy at Fry's.
Paul
>-----Original Message-----
>From: Dolors Sala [mailto:dolors@ieee.org]
>Sent: Tuesday, May 27, 2003 4:49 PM
>To: stds-802-linksec@ieee.org; Allyn Romanow
>Subject: 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
>>
>>
>>
>