GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4441

Network Working Group B. Aboba, Ed. Request for Comments: 4441 Internet Architecture Board Category: Informational March 2006

                   The IEEE 802/IETF Relationship

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2006).

Abstract

 Since the late 1980s, IEEE 802 and IETF have cooperated in the
 development of Simple Network Management Protocol (SNMP) MIBs and
 Authentication, Authorization, and Accounting (AAA) applications.
 This document describes the policies and procedures that have
 developed in order to coordinate between the two organizations, as
 well as some of the relationship history.

Table of Contents

 1. Introduction ....................................................2
    1.1. Liaison Communications .....................................2
    1.2. Access to IEEE 802 Archives ................................3
    1.3. New Work Review ............................................3
    1.4. MIB Review .................................................4
    1.5. EAP Review .................................................4
    1.6. AAA Review .................................................5
    1.7. Document Review ............................................5
    1.8. EtherType Allocation .......................................6
 2. Security Considerations .........................................6
 3. Informative References ..........................................7
 4. Acknowledgements ...............................................12
 Appendix A.  Relationship History .................................13
    A.1.  MIB Development ..........................................13
    A.2.  AAA/EAP ..................................................16
 Appendix B.  IAB Members at the Time of This Writing ..............21

IAB Informational [Page 1] RFC 4441 IEEE 802/IETF Relationship March 2006

1. Introduction

 Since the late 1980s, participants in IEEE 802 and the IETF have
 cooperated in the development of Management Information Bases (MIBs)
 and Authentication, Authorization, and Accounting (AAA) applications
 relating to IEEE standards.  This has included the Bridge MIB
 [RFC1493] [RFC4188], the multicast filtering and VLAN extension MIB
 [RFC2674] [RFC4363], the Hub MIB [RFC2108], the Ethernet-like
 Interfaces MIB [RFC3635], the MAU MIB [RFC3636], the WAN Interfaces
 Sublayer MIB [RFC3637], the Power Ethernet MIB [RFC3621], IEEE 802.1X
 RADIUS usage guidelines [RFC3580], the revised Extensible
 Authentication Protocol (EAP) specification [RFC3748], RADIUS/EAP
 [RFC3579], and the EAP State Machine specification [RFC4137].  This
 document describes the policies and procedures that have been put in
 place to encourage cooperation between the IETF and IEEE 802.
 Details of the relationship history are included in Appendix A.
 In order to improve communications between the IETF and IEEE 802,
 members of the Internet Engineering Steering Group (IESG) and
 Internet Architecture Board (IAB) (including Bert Wijnen, James
 Kempf, and Bernard Aboba) met with the IEEE 802 Executive Committee
 in Vancouver, Canada, in January 2004.  At that meeting, a number of
 issues were discussed and new procedures were put in place.

1.1. Liaison Communications

 IETF Working Groups are organized into areas, which have one or more
 Area Directors.  The Area Directors, plus the IETF Chair, comprise
 the Internet Engineering Steering Group (IESG).  IEEE 802 Working
 Groups have one or more Task Groups.  The IEEE 802 Working Group
 Chairs, plus the IEEE 802 Chair, comprise the IEEE 802 Executive
 Committee (ExComm).
 Participants in the IETF are appointed as liaisons to other
 organizations by the IAB or IESG as appropriate.  This includes a
 liaison to IEEE 802 as well as liaisons to specific IEEE 802 Working
 Groups.  The IETF liaison web page includes a list of IETF liaisons,
 as well as a pointer to the archive of liaison statements received by
 the IETF [Liaison-Page].  IETF processes for management of liaison
 relationships are described in [BCP102]; procedures for handling of
 incoming liaison statements are described in [BCP103].  In order to
 ensure that liaison statements from IEEE 802 to the IETF are archived
 and responded to, IEEE 802 liaisons to IETF should utilize the IETF
 liaison management tool to submit liaison communications.  A username
 and password suitable for use with the tool can be obtained by
 sending mail to iesg-secretary@ietf.org.  If a liaison management
 account is not available, liaison communications can be sent to the
 IETF liaison(s) to IEEE 802 and copied to statements@ietf.org.

IAB Informational [Page 2] RFC 4441 IEEE 802/IETF Relationship March 2006

 However, in this case substantially greater processing delays will
 occur due to the need for manual handling by the IETF Secretariat
 staff.
 Liaison requests from the IETF to IEEE 802 should be sent to the
 Chair(s) of the IEEE 802 WG to which the request pertains, with a
 copy sent to the IEEE 802 Chair and the IEEE 802 liaison(s) to IETF.
 IEEE 802 procedures for communicating with other standards bodies are
 described in Section 14.1 of [Policy].  Liaison communications to
 IEEE 802 WGs are archived by the individual WGs.

1.2. Access to IEEE 802 Archives

 Access to IEEE 802 standards more than six months old is provided
 free of charge on the IEEE 802 website via the Get IEEE 802 Program
 [GetIEEE-802].  Access to IEEE 802 work-in-progress has frequently
 arisen as an issue in cooperation between IETF and IEEE 802.  While
 in the past IETF Working Groups (WGs) have successfully negotiated
 access to IEEE 802 work-in-progress, each instance has been handled
 separately and took significant time and effort to complete.  In
 order to more easily enable document access for IETF WGs
 collaborating with IEEE 802, a liaison statement was sent to the IETF
 in July 2004 by Paul Nikolich, Chair of IEEE 802 [IEEE-802Liaison],
 describing the process by which IETF WGs can obtain access to IEEE
 802 work-in-progress.  IEEE 802 WG Chairs have the authority to grant
 membership in their WGs, and can use this authority to grant
 membership to an IETF WG chair upon request.  The IETF WG chair will
 be provided with access to the username/password for the IEEE 802 WG
 archives, and is permitted to share that information with
 participants in the IETF WG.  Since it is possible to participate in
 IETF without attending meetings, or even joining a mailing list, IETF
 WG chairs will provide the information to anyone who requests it.
 However, since IEEE 802 work-in-progress is copyrighted,
 incorporating material into IETF documents or posting the
 username/password on mailing lists or websites is not permitted.

1.3. New Work Review

 In order to enable IEEE 802 review of proposed IETF WG charters, as
 well as to enable IETF review of proposed IEEE 802 Project
 Authorization Requests (PARs), the New Work mailing list is used.
 The IEEE 802 Executive Committee is subscribed to the list, so that
 it can receive proposed IETF WG Charters.  Proposed IEEE 802 PARs are
 posted to the New Work list as well.  Where a New Work announcement
 is of particular interest, it is also (manually) forwarded to the
 relevant IETF and IEEE 802 mailing lists.

IAB Informational [Page 3] RFC 4441 IEEE 802/IETF Relationship March 2006

 However, by the time an IETF WG Charter or IEEE 802 PAR appears on
 New Work, a IETF BOF or IEEE 802 "Call for Interest" has already
 occurred, interest has been demonstrated and considerable work has
 gone into development of the Charter or PAR.  If problems are found
 at that point, it is often too late in the process to make major
 changes.  Therefore, where a potential work item is likely to be
 controversial, discussions between IETF and IEEE 802 are encouraged
 to occur earlier in the process.

1.4. MIB Review

 With travel budgets under pressure, it has become increasingly
 difficult for companies to fund employees to attend both IEEE 802 and
 IETF meetings.  As a result, an alternative is needed to past
 arrangements that involved chartering MIB work items within an IETF
 WG.  In order to encourage wider review of MIBs developed by IEEE 802
 WGs, it is recommended that Simple Network Management Protocol (SNMP)
 MIBs developed in IEEE 802 follow the MIB guidelines [RFC4181] and be
 reviewed as part of the IETF SNMP quality control process ('MIB
 Doctors').  An IEEE 802 group may request assignment of a 'MIB
 Doctor' to assist in a MIB review by contacting the IETF Operations
 and Management Area Director.
 By standardizing IEEE 802 MIBs only within IEEE 802 while utilizing
 the SNMP quality control process, the IETF and IEEE 802 seek to
 ensure quality while decreasing overhead.  A trial run of this
 process has taken place in IEEE 802.1 where a MIB Doctor (David
 Harrington) has agreed to review IEEE 802.1 MIBs.  Currently,
 discussion is under way on how change control of selected IEEE 802.1
 MIB documents published as RFCs can be transferred to IEEE 802.1
 [MIB-TRANSFER].

1.5. EAP Review

 Several IEEE 802 standards, including [IEEE-802.1X-2004],
 [IEEE-802.11i], and [IEEE-802.16e], depend on EAP [RFC3748] and EAP
 key management, described in [KEYFRAME].  Rather than developing
 their own EAP methods, or extensions for EAP key management, IEEE 802
 working groups should send a liaison letter to the IETF, outlining
 the required functionality or requesting a review of draft text.
 Most recently, a security review of IEEE 802.16e D8 [EAPREVIEW] has
 been carried out by the EAP WG, at the request of the IEEE 802.16
 Chair, Roger Marks [IEEE-802.16-Liaison1] [IEEE-802.16-Liaison2].

IAB Informational [Page 4] RFC 4441 IEEE 802/IETF Relationship March 2006

1.6. AAA Review

 IEEE 802 WGs requiring new AAA applications should send a liaison
 request to the IETF.  Where new attributes are required rather than a
 new application, an Internet-Draft can be submitted and review can
 be requested from AAA-related WGs such as the AAA or RADEXT WGs.  For
 attributes of general utility, and particularly those useful in
 multiple potential applications, allocation from the IETF standard
 attribute space is preferred to creation of IEEE 802 Vendor-Specific
 Attributes (VSAs).  As noted in [RFC3575]:
 RADIUS defines a mechanism for Vendor-Specific extensions (Attribute
 26) and the use of that should be encouraged instead of allocation of
 global attribute types, for functions specific only to one vendor's
 implementation of RADIUS, where no interoperability is deemed useful.
 Where allocation of VSAs are required, it is recommended that IEEE
 802 create a uniform format for all of IEEE 802, rather than having
 each IEEE 802 group create their own VSA format.  The VSA format
 defined in [IEEE-802.11F] is inappropriate for this, since the Type
 field is only a single octet, allowing for only 255 attributes.
 Recently, the AAA Doctors list has been created within the IETF
 Operations and Management Area Directorate, serving a similar
 function to the MIB Doctors.  While the AAA Doctors have not yet been
 called upon to assist with and review AAA work outside of the IETF,
 this group could potentially be of assistance to IEEE 802 working
 groups requiring help with AAA.

1.7. Document Review

 With the areas of cooperation between IEEE 802 and IETF increasing,
 the document review process has extended beyond the traditional
 subjects of SNMP MIBs and AAA.  For example, as part of the IETF
 CAPWAP WG charter, IEEE 802.11 was asked to review the CAPWAP
 Taxonomy Document [RFC4118]; Dorothy Stanley organized an ad hoc
 group for this purpose.  IEEE 802.11 has also reviewed [IDSEL] and
 [IABLINK].  Within IETF, IEEE 802 comments are resolved using normal
 WG and IETF processes.
 IETF participants can comment as part of the IEEE 802 ballot process,
 regardless of their voting status within IEEE 802.  Comments must be
 composed in the format specified for the ballot, and submitted by the
 ballot deadline.

IAB Informational [Page 5] RFC 4441 IEEE 802/IETF Relationship March 2006

1.8. EtherType Allocation

 The EtherType field is very limited, so that allocations are made
 solely on an "as needed" basis.  For related uses, a single EtherType
 should be requested, with additional fields serving as sub-protocol
 identifiers, rather than applying for multiple EtherTypes.  EtherType
 allocation policy is described in [TYPE-TUT].
 While a fee is normally charged by IEEE 802 for the allocation of an
 EtherType, IEEE 802 will consider waiving the fee for allocations
 relating to an IETF standards track document, based on a request from
 the IESG.

2. Security Considerations

 As IEEE 802 becomes increasingly involved in the specification of
 standards for link-layer security, experience has shown that it is
 helpful to obtain outside review of work-in-progress prior to
 publication.  This has proven somewhat challenging since access to
 IEEE 802 work-in-progress documents is often tightly controlled.  For
 example, special permission had to be obtained for IEEE 802.11i to be
 able to circulate a version of its security standard-in-progress for
 review.  A liaison between an IEEE 802 group and an IETF WG can help
 in obtaining the necessary level of review.
 Experience has also shown that IETF standards may not be written to
 the level of clarity required by the IEEE 802 standards process.  In
 the case of EAP [RFC3748], the process of developing the EAP state
 machine specification [RFC4137] proved useful in uncovering aspects
 requiring clarification, and the joint review process exposed IEEE
 802 and IETF documents-in-progress to wider review than might
 otherwise have been possible.
 Similarly, the development of [IEEE-802.11i], [RFC3748], [KEYFRAME],
 and [RFC4017] led to a deeper understanding of the limitations and
 security vulnerabilities of the EAP/AAA system.  As described in
 [Housley], it is not advisable to develop new AAA key management
 applications without completing a security analysis, such as the
 analysis provided in [KEYFRAME].
 Due to weaknesses in the RADIUS specification [RFC2865], it is
 relatively easy for protocol extensions to introduce serious security
 vulnerabilities.  As a result, IETF review of IEEE 802 RADIUS
 extensions is advisable, and the RADIUS IANA Considerations [RFC3575]
 have been revised so as to require such a review in most cases.

IAB Informational [Page 6] RFC 4441 IEEE 802/IETF Relationship March 2006

3. Informative References

 [BCP102]        Daigle, L. and Internet Architecture Board, "IAB
                 Processes for Management of IETF Liaison
                 Relationships", BCP 102, RFC 4052, April 2005.
 [BCP103]        Trowbridge, S., Bradner, S., and F. Baker,
                 "Procedures for Handling Liaison Statements to and
                 from the IETF", BCP 103, RFC 4053, April 2005.
 [EAPREVIEW]     EAP WG letter to Roger Marks, June 2005,
                 http://www.drizzle.com/~aboba/EAP/review.txt.
 [GetIEEE-802]   IEEE Standards Association Get IEEE 802 (R) Program,
                 http://standards.ieee.org/getieee802/portfolio.html.
 [IDSEL]         Adrangi, F., Lortz, V., Bari, F., and P. Eronen,
                 "Identity Selection Hints for the Extensible
                 Authentication Protocol (EAP)", RFC 4284, January
                 2006.
 [Housley]       Housley, R. and B. Aboba, "AAA Key Management", Work
                 in Progress, November 2005.
 [IABLINK]       Aboba, B., "Architectural Implications of Link
                 Indications", Work in Progress, August 2005.
 [IEEE-80211Liaison1]
                 IEEE 802.11 liaison letter to Harald Alvestrand,
                 February 2002,
                 https://www.ietf.org/IESG/LIAISON/ieee802.11.txt.
 [IEEE-80211Liaison2]
                 Input To IETF EAP Working Group on Methods and Key
                 Strength, March 2003,
                 http://www.ietf.org/IESG/LIAISON/LS-ieee-80211.txt.
 [IEEE-802.11F]  Institute of Electrical and Electronics Engineers,
                 "IEEE Trial-Use Recommended Practice for Multi-Vendor
                 Access Point Interoperability via an Inter-Access
                 Point Protocol Across Distribution Systems Supporting
                 IEEE 802.11 Operation", IEEE 802.11F, June 2003 (now
                 deprecated).
 [IEEE-802Liaison]
                 IEEE 802 Liaison letter to Bert Wijnen and Bernard
                 Aboba, July 26, 2004,
                 http://www.ietf.org/IESG/LIAISON/file41.pdf.

IAB Informational [Page 7] RFC 4441 IEEE 802/IETF Relationship March 2006

 [IEEE-802.1X-MIB]
                 Norseth, K., "Definitions for Port Access Control
                 (IEEE 802.1X) MIB", Work in Progress, November 2003.
 [IEEE-802.1X]   IEEE Standards for Local and Metropolitan Area
                 Networks: Port based Network Access Control, IEEE
                 P802.1X-2001, June 2001.
 [IEEE-802.1X-2004]
                 IEEE Standards for Local and Metropolitan Area
                 Networks: Port based Network Access Control, IEEE
                 P802.1X-2004, December 2004.
 [IEEE-802.1D]   ISO/IEC 15802-3 Information technology -
                 Telecommunications and information exchange between
                 systems - Local and metropolitan area networks -
                 Common specifications - Part 3: Media access Control
                 (MAC) Bridges, (also ANSI/IEEE Std 802.1D-1998),
                 1998.
 [IEEE-802.1Q]   IEEE Standards for Local and Metropolitan Area
                 Networks: Draft Standard for Virtual Bridged Local
                 Area Networks, P802.1Q, January 1998.
 [IEEE-802.3]    ISO/IEC 8802-3 Information technology -
                 Telecommunications and information exchange between
                 systems - Local and metropolitan area networks -
                 Common specifications - Part 3:  Carrier Sense
                 Multiple Access with Collision Detection (CSMA/CD)
                 Access Method and Physical Layer Specifications,
                 (also ANSI/IEEE Std 802.3- 1996), 1996.
 [IEEE-802.11]   Information technology - Telecommunications and
                 information exchange between systems - Local and
                 metropolitan area networks - Specific Requirements
                 Part 11:  Wireless LAN Medium Access Control (MAC)
                 and Physical Layer (PHY) Specifications, IEEE
                 P802.11-2003, 2003.
 [IEEE-802.11i]  IEEE Supplement to Standard for Telecommunications
                 and Information Exchange Between Systems - LAN/MAN
                 Specific Requirements - Part 11:  Wireless LAN Medium
                 Access Control (MAC) and Physical Layer (PHY)
                 Specifications:  Specification for Enhanced Security,
                 IEEE P802.11i, July 2004.

IAB Informational [Page 8] RFC 4441 IEEE 802/IETF Relationship March 2006

 [IEEE-802.16e]  IEEE Standard for Local and Metropolitan Area
                 Networks - Part 16:  Air Interface for Fixed and
                 Mobile Broadband Wireless Access Systems, Amendment
                 for Physical and Medium Access Control Layers for
                 Combined Fixed and Mobile Operation in Licensed
                 Bands, IEEE P802.16e, September 2005.
 [IEEE-802.16-Liaison1]
                 Liaison letter from IEEE 802.16 to Bernard Aboba,
                 March 17, 2005,
                 http://ieee802.org/16/liaison/docs/L80216-05_025.pdf.
 [IEEE-802.16-Liaison2]
                 Liaison letter from IEEE 802.16 to Bernard Aboba, May
                 5, 2005,
                 http://ieee802.org/16/liaison/docs/L80216-05_039.pdf.
 [KEYFRAME]      Aboba, B., Simon, D., Arkko, J., Eronen, P., and H.
                 Levkowetz, "Extensible Authentication Protocol (EAP)
                 Key Management Framework", Work in Progress, October
                 2005.
 [Liaison-Page]  IETF Liaison Activities,
                 http://www.ietf.org/liaisonActivities.html.
 [MIB-TRANSFER]  Harrington, D., "Transferring MIB Work from IETF
                 Bridge WG to IEEE 802.1 WG",  Work in Progress,
                 October 2005.
 [Mishra]        Mishra, A. and W. Arbaugh, "An Initial Security
                 Analysis of the IEEE 802.1X Standard", Department of
                 Computer Science, University of Maryland College
                 Park, CS-TR-4328, February 2002.
 [Policy]        IEEE Project 802 LAN MAN Standards Committee (LMSC)
                 Policies and Procedures, September 14, 2005,
                 http://www.ieee802.org/policies-and-procedures.pdf.
 [RFC1493]       Decker, E., Langille, P., Rijsinghani, A., and K.
                 McCloghrie, "Definitions of Managed Objects for
                 Bridges", RFC 1493, July 1993.
 [RFC2108]       de Graaf, K., Romascanu, D., McMaster, D., and K.
                 McCloghrie, "Definitions of Managed Objects for IEEE
                 802.3 Repeater Devices using SMIv2", RFC 2108,
                 February 1997.

IAB Informational [Page 9] RFC 4441 IEEE 802/IETF Relationship March 2006

 [RFC2284]       Blunk, L. and J. Vollbrecht, "PPP Extensible
                 Authentication Protocol (EAP)", RFC 2284, March 1998.
 [RFC2390]       Bradley, T., Brown, C., and A. Malis, "Inverse
                 Address Resolution Protocol", RFC 2390, September
                 1998.
 [RFC2674]       Bell, E., Smith, A., Langille, P., Rijhsinghani, A.,
                 and K. McCloghrie, "Definitions of Managed Objects
                 for Bridges with Traffic Classes, Multicast Filtering
                 and Virtual LAN Extensions", RFC 2674, August 1999.
 [RFC2865]       Rigney, C., Willens, S., Rubens, A., and W. Simpson,
                 "Remote Authentication Dial In User Service
                 (RADIUS)", RFC 2865, June 2000.
 [RFC2866]       Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
 [RFC2867]       Zorn, G., Aboba, B., and D. Mitton, "RADIUS
                 Accounting Modifications for Tunnel Protocol
                 Support", RFC 2867, June 2000.
 [RFC2868]       Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
                 Holdrege, M., and I. Goyret, "RADIUS Attributes for
                 Tunnel Protocol Support", RFC 2868, June 2000.
 [RFC2869]       Rigney, C., Willats, W., and P. Calhoun, "RADIUS
                 Extensions", RFC 2869, June 2000.
 [RFC3162]       Aboba, B., Zorn, G., and D. Mitton, "RADIUS and
                 IPv6", RFC 3162, August 2001.
 [RFC3575]       Aboba, B., "IANA Considerations for RADIUS (Remote
                 Authentication Dial In User Service)", RFC 3575, July
                 2003.
 [RFC3579]       Aboba, B. and P. Calhoun, "RADIUS (Remote
                 Authentication Dial In User Service) Support For
                 Extensible Authentication Protocol (EAP)", RFC 3579,
                 September 2003.
 [RFC3580]       Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.
                 Roese, "IEEE 802.1X Remote Authentication Dial In
                 User Service (RADIUS) Usage Guidelines", RFC 3580,
                 September 2003.
 [RFC3621]       Berger, A. and D. Romascanu, "Power Ethernet MIB",
                 RFC 3621, December 2003.

IAB Informational [Page 10] RFC 4441 IEEE 802/IETF Relationship March 2006

 [RFC3635]       Flick, J., "Definitions of Managed Objects for the
                 Ethernet-like Interface Types", RFC 3635, September
                 2003.
 [RFC3636]       Flick, J., "Definitions of Managed Objects for IEEE
                 802.3 Medium Attachment Units (MAUs)", RFC 3636,
                 September 2003.
 [RFC3637]       Heard, C.M., Ed., "Definitions of Managed Objects for
                 the Ethernet WAN Interface Sublayer", RFC 3637,
                 September 2003.
 [RFC3748]       Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J.,
                 and H. Levkowetz, "Extensible Authentication Protocol
                 (EAP)", RFC 3748, June 2004.
 [RFC4017]       Stanley, D., Walker, J., and B. Aboba, "Extensible
                 Authentication Protocol (EAP) Method Requirements for
                 Wireless LANs", RFC 4017, March 2005.
 [RFC4118]       Yang, L., Zerfos, P., and E. Sadot, "Architecture
                 Taxonomy for Control and Provisioning of Wireless
                 Access Points (CAPWAP)", RFC 4118, June 2005.
 [RFC4137]       Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
                 "State Machines for Extensible Authentication
                 Protocol (EAP) Peer and Authenticator", RFC 4137,
                 August 2005.
 [RFC4181]       Heard, C., Ed., "Guidelines for Authors and Reviewers
                 of MIB Documents", BCP 111, RFC 4181, September 2005.
 [RFC4188]       Norseth, K. and E. Bell, "Definitions of Managed
                 Objects for Bridges", RFC 4188, September 2005.
 [RFC4363]       Levi, D. and D. Harrington, "Definitions of Managed
                 Objects for Bridges with Traffic Classes, Multicast
                 Filtering, and Virtual LAN Extensions", RFC 4363,
                 January 2006.
 [TYPE-TUT]      IEEE Standards Association, "Use of the IEEE Assigned
                 EtherType Field with IEEE Std 802.3, 1998 Edition
                 Local and Metropolitan Area Networks",
                 http://standards.ieee.org/regauth/ethertype/
                 type-tut.html.

IAB Informational [Page 11] RFC 4441 IEEE 802/IETF Relationship March 2006

4. Acknowledgements

 The authors would like to acknowledge Les Bell, Dan Romascanu, Dave
 Harrington, Tony Jeffree, Fred Baker, Paul Congdon, Paul Langille,
 and C. M. Heard for contributions to this document.

IAB Informational [Page 12] RFC 4441 IEEE 802/IETF Relationship March 2006

Appendix A. Relationship History

A.1. MIB Development

A.1.1. Bridge MIB

 The relationship between IETF and IEEE 802 began in the late 1980s
 with SNMP MIBs developed for the original IEEE 802.1D standard.
 Because the IEEE specification [IEEE-802.1D] contained only a
 functional definition of the counters and operations, the IETF's
 Bridge MIB WG took on the role of defining the Bridge MIB [RFC1493],
 which was published as an RFC.  Fred Baker and later Keith McCloghrie
 served as chairs of the Bridge WG.
 The Bridge MIB combined the work of Keith McCloghrie, Eric Decker,
 and Paul Langille, with spanning tree expertise provided by Anil
 Rijsinghani.  Mick Seaman (author of 802.1D) and Floyd Backes (who
 had written the code for Digital Equipment's spanning tree
 implementation) were the main contacts within IEEE 802.1.  Since
 Mick, Floyd, Anil, and Paul all worked for Digital Equipment
 Corporation at the time, much of the coordination between IEEE 802.1
 and the Bridge MIB WG took place in the hallways at Digital, rather
 than within official channels.

A.1.2. MAU and Hub MIBs

 In the early 1990s when IEEE 802.3 was completing the first Ethernet
 standards, SNMP was not yet the dominant network management protocol.
 As a result, a 'protocol independent' MIB is included in Clause 30 of
 the IEEE 802.3 standard [IEEE-802.3], which is updated each time the
 Ethernet standard is enhanced to support higher speeds.  In parallel,
 IEEE 802 participants interested in network management were active in
 the formation of the IETF HUBMIB WG, which took on the task of
 transforming IEEE 802 definitions into SNMP MIBs documented as
 Standards Track RFCs.  This included Dan Romascanu, Chair of the IETF
 HUBMIB WG since 1996.
 The Charter of the HUBMIB WG explicitly mentions that the IEEE 802.3
 standard is the starting point for the Ethernet MIB, but at the same
 time reserves the right to deviate from the IEEE model -- either to
 cover only part of the capabilities offered by the standard or to add
 MIB objects that are not directly derived from the IEEE model (mostly
 implemented in software).  If management needs lead to requirements
 for hardware support, the IETF HUBMIB WG is to provide this input to
 IEEE 802.3 in a timely manner.

IAB Informational [Page 13] RFC 4441 IEEE 802/IETF Relationship March 2006

 Cooperation between the IETF HUBMIB WG and IEEE 802.3 has continued
 for more than a decade until today, mostly based on the work of a few
 editors supported by their companies, who are taking the IEEE
 standards and mapping them into a management data model and MIBs.
 Work items include:
  1. The Hub MIB [RFC2108], which has gone through three iterations,

and is probably ending its evolution, as repeaters are less used

   in Ethernets.
 - The MAU MIB, which has been updated each time a new Ethernet speed
   is developed, with [RFC3636] accommodating 10-Gbps Ethernet.
 - The Ethernet-like Interfaces MIB was not originally a work item
   of the HUBMIB WG, but the WG took responsibility for a revision,
   published as [RFC3635].
 - The WAN Interface Sublayer MIB [RFC3637] and the Power Ethernet MIB
   [RFC3621] were developed in IEEE 802.3 and the IETF HUBMIB WG.
 In 2000, an official liaison was established between IEEE 802.3 and
 the IETF HUBMIB WG, and Dan Romascanu was appointed IETF liaison.
 The conditions of the liaison agreement allows editors and other
 participants in the IETF HUBMIB WG access to work-in-progress drafts
 in IEEE 802.3 on a personal basis, for the purpose of working on MIBs
 before the release of the standard.  However, the username and
 password for IEEE 802.3 document access are not for publication on
 any IETF website or mailing list.

A.1.3. 802.1p/Q MIB

 In 1996 as the 802.1p and 802.1Q [IEEE-802.1Q] standards were being
 completed, a need was perceived for development of an SNMP MIB, based
 on the management clauses of those standards.  IEEE 802 management
 clauses are written in a manner that was independent of any protocol
 that may be used to implement them.
 At that time, there were a number of proprietary VLAN management MIBs
 that were both inadequate and difficult to understand.  As a result,
 there was a need for a more comprehensive, simpler model for VLAN
 management, along with the priority and multicast filtering
 management also defined by these standards.
 A small group of participants from the 802.1 WG began working on the
 problem independently, then combined their work.  The original
 authors of the Bridge MIB, on which some of the work was based,
 reviewed the initial work.

IAB Informational [Page 14] RFC 4441 IEEE 802/IETF Relationship March 2006

 By the end of 1997, the work was ready for review by a larger
 audience.  Andrew Smith worked with Keith McCloghrie, chair of the
 Bridge MIB WG (dormant at the time), to obtain a meeting slot at the
 March 1998 IETF meeting.  After this, review and development of the
 MIB continued on the IETF standards track.
 During the development of [RFC2674], there was no official inter-
 working between the IETF Bridge MIB and IEEE 802.1 groups.
 Development of this MIB was successful, because the main developers
 (Andrew Smith and Les Bell) were involved in both the IEEE 802.1 and
 the IETF Bridge MIB WGs.

A.1.4. 802.3ad and 802.1X MIBs

 As part of the IEEE 802.3ad and IEEE 802.1X standards work, it was
 decided that it would be better to develop a MIB as part of the
 standards, rather than wait until an IETF WG was formed, and develop
 the MIBs separately, so as to avoid a significant time lag in their
 development.
 As Les Bell was the participant in IEEE 802.3ad and IEEE 802.1 most
 familiar with SNMP MIB development, he put together the initial MIBs
 based on the management framework the groups had come up with.
 Additional assistance was then received for both MIBs from within the
 IEEE 802.3ad and IEEE 802.1X groups.  Tony Jeffree, editor of both
 standards, acted as editor of the MIBs as well.
 The problem with IEEE 802 developing these MIBs without IETF
 involvement was the lack of review.  IEEE 802 members are generally
 not familiar with MIBs, and very few comments were received as part
 of the balloting process for either MIB.
 In the case of the IEEE 802.3ad MIB, this meant that basic errors
 were not discovered until just before publication.  Unfortunately, by
 then it was too late, and the corrections submitted to the IEEE
 802.3ad chair and document editor did not get applied to the
 published version.
 Subsequent to the publication of [IEEE-802.1X], the IEEE 802.1X MIB
 was reviewed within the Bridge WG, and several syntax errors were
 found.  These have been corrected in the version of the MIB module
 that was developed as part of [IEEE-802.1X-2004].  However, while
 [IEEE-802.1X-MIB] was originally published as a work in progress
 within the Bridge WG, there was not sufficient interest to complete
 its publication as an RFC.  As a result, the draft has now expired.

IAB Informational [Page 15] RFC 4441 IEEE 802/IETF Relationship March 2006

A.1.5. 802.1t, 802.1u, 802.1v, and 802.1w MIBs

 802.1t and 802.1u were minor amendments to the 802.1D and 802.1Q
 standards, requiring some additions to the MIB published in
 [RFC2674].  802.1v was a new feature extending the VLAN
 classification schemes of 802.1Q, also requiring extensions to
 [RFC2674].  802.1w was a new version of Spanning Tree, requiring
 rewriting of part of [RFC1493].
 When Les Bell took on the role of Chair of the IETF Bridge MIB WG in
 2001, these issues were raised as new work items and two volunteers
 were found to become editors of the Internet-Drafts.  A work item was
 also included to publish the IEEE 802.1X MIB as an Informational RFC.
 This approach worked well for a while, but it then became difficult
 for the participants, including the editors and the Chair, to sustain
 a level of interest sufficient to overcome the difficulties
 introduced by budget cutbacks.  As a result, the drafts have now
 expired, although there are no significant technical issues
 outstanding.

A.2. AAA/EAP

 Since the late 1990s, IEEE 802.1 has been involved in work relating
 to authentication and authorization [IEEE-802.1X], which led to
 discovery of issues in several IETF specifications, including
 [RFC2284] and [RFC2869].  Similarly, IETF participants have uncovered
 issues in early versions of the RADIUS usage specifications such as
 [RFC3580], as well as the IEEE 802.1X state machine [Mishra].
 In order to address these issues and ensure synchronization between
 IEEE 802.1 and the IETF EAP and AAA WGs, a liaison arrangement was
 utilized during the development of [IEEE-802.1X] and
 [IEEE-802.1X-2004].
 IEEE 802.11 groups such as IEEE 802.11i and IEEE 802.11F have also
 become dependent on EAP and AAA work.  This relationship was more
 challenging since IEEE 802.11 required development of EAP methods and
 the EAP Key Management Framework, which represented substantial new
 IETF work, as opposed to the clarifications and updates required by
 IEEE 802.1.

A.2.1. IEEE 802.1X

 IEEE 802.1X-2001 [IEEE-802.1X] defined the encapsulation of EAP
 [RFC2284] over IEEE 802, as well as a state machine for the joint
 operation of IEEE 802.1X and EAP.

IAB Informational [Page 16] RFC 4441 IEEE 802/IETF Relationship March 2006

 During the development of IEEE 802.1X-2001, several problems were
 discovered in the specification for RADIUS/EAP [RFC2869], and as a
 result, work was begun on a revision [RFC3579].  In addition,
 clarifications were required on how RADIUS attributes defined in
 [RFC2865], [RFC2866], [RFC2867], [RFC2868], [RFC2869], and [RFC3162]
 would be interpreted by IEEE 802.1X implementations.  To address
 this, a non-normative RADIUS usage appendix was added to
 [IEEE-802.1X], and published as [RFC3580].
 Subsequent to the publication of [IEEE-802.1X], a formal analysis of
 the IEEE 802.1X state machine by the University of Maryland disclosed
 several security issues [Mishra].  Discussion within IEEE 802.1
 pointed to lack of clarity in [RFC2284], which resulted from the
 absence of a specification for the EAP state machine specification.
 At that time, EAP was handled within the IETF PPPEXT WG, which was
 largely inactive.  In order to undertake work on a revised EAP
 specification as well as the specification of the EAP state machine,
 the IETF EAP WG was formed in July 2002.  Bernard Aboba, a
 participant in IEEE 802.1 as well as PPPEXT, was named co-chair.
 Work on the EAP state machine [RFC4137] and revised EAP specification
 [RFC3748] proceeded in parallel within the EAP WG, with issues or
 changes in one document requiring changes to the other document, as
 well as revisions to [IEEE-802.1X-2004].  The revised RADIUS/EAP
 specification [RFC3579] was also reviewed within the EAP WG, since at
 that time the RADEXT WG had not yet been formed.
 The revision to IEEE 802.1X [IEEE-802.1X-2004] included the
 following:
  1. a revised RADIUS usage appendix based on [RFC3580]
  2. clarifications based on [RFC3579]
  3. a revised IEEE 802.1X state machine, based on [RFC3748] and

[RFC4137]

 Due to the deep dependencies between [IEEE-802.1X-2004], [RFC3748],
 and [RFC4137], a liaison was established between IEEE 802.1X-REV and
 the IETF EAP WG in August 2002.  This enabled participants in the
 IETF EAP WG to obtain access to the IEEE 802.1X revision in progress.
 IEEE 802 groups are duty bound to consider all comments received,
 regardless of their origin.  This allows IETF participants to comment
 as part of the IEEE 802 ballot process, regardless of their voting
 status within IEEE 802.  Where there is active cooperation, IETF WGs
 may be made aware that IEEE 802 ballots are occurring and that their

IAB Informational [Page 17] RFC 4441 IEEE 802/IETF Relationship March 2006

 comments are welcome.  IEEE 802.1X-REV and IEEE 802.11i ballots were
 announced on the EAP WG mailing list, as are IEEE 802 interim meeting
 arrangements.
 Similarly, during the IEEE 802.1X-REV ballot process, comments were
 received relating to [RFC3748], [RFC4137], and [RFC3579].  These
 comments were tracked on the EAP WG Issues List, and were
 subsequently addressed in the documents.
 In April 2003, [RFC3580] was approved by the IESG for publication as
 an RFC, and in May 2003, [RFC3579] was approved for publication as an
 RFC.  The review process for both drafts involved bringing the
 documents to IETF last call, and then reposting the IETF last-call
 announcement on the IEEE 802.1 mailing list.  While ballot comments
 on IEEE 802.1X-REV were also reflected in changes to both documents,
 it was necessary for both documents to be approved for publication as
 RFCs well in advance of Sponsor Ballot, in order to ensure that RFC
 numbers would be assigned in time, so as to avoid delaying
 publication.
 Overall, despite the complex inter-dependencies between
 [IEEE-802.1X-2004], [RFC3748], and [RFC4137], the documents were
 produced without undue delay.  This was largely due to the work of
 joint participants in IEEE 802.1 and IETF EAP WG.

A.2.2. IEEE 802.11i

 IEEE 802.11i was chartered to specify security enhancements to
 [IEEE-802.11].  Since [IEEE-802.11i] utilized IEEE 802.1X, it
 depended on [IEEE-802.1X-2004].  As a result, IEEE 802.11i and IEEE
 802.1 held joint meetings at IEEE 802 plenaries and established a
 liaison arrangement that permitted members of either group (as well
 as EAP WG participants) access to IEEE 802.11i work-in-progress.
 Since [IEEE-802.11i] depended on [IEEE-802.1X-2004], it inherited the
 dependencies of [IEEE-802.1X-2004], including work on EAP, EAP
 methods, and AAA support for EAP.  In addition, since IEEE 802.11i
 utilized EAP for key management whereas [IEEE-802.1X] does not,
 additional security requirements arose with respect to EAP methods.
 In February 2002, IEEE 802.11 sent a liaison letter to the IESG
 [IEEE-80211Liaison1] requesting additional work on EAP, EAP methods,
 and EAP key management.  This letter was presented at the second EAP
 BOF at IETF 53, and was used as input to the EAP WG charter.  In
 March 2003, another liaison letter was presented, providing further
 clarifications on requirements for EAP method work
 [IEEE-80211Liaison2].  This included a request from IEEE 802.11i for

IAB Informational [Page 18] RFC 4441 IEEE 802/IETF Relationship March 2006

 the EAP WG to consider changing the mandatory-to-implement EAP method
 within [RFC3748], so as to provide a method meeting the security
 requirements of IEEE 802.11i.
 During IETF 56, the request for changing the mandatory-to-implement
 method was considered by the EAP WG.  A recommendation was made by
 the Internet Area Director Erik Nordmark that the IEEE 802.11i
 requirements be documented in an RFC and that the EAP WG consider the
 security requirements for EAP methods in various situations.  It was
 recommended not to change the mandatory-to-implement method, since
 the EAP WG was not chartered to do work on methods.  However, it was
 decided to produce a document describing the EAP method requirements
 for WLAN usage.  This document was subsequently published as
 [RFC4017].
 Most recently, IEEE 802.11r has been involved in discussions relating
 to fast handoff, which may potentially require AAA extensions as well
 as changes to the EAP key hierarchy.  However, the direction of this
 work has not yet been determined so that no liaison request has been
 formulated yet.
 In April 2003, Dorothy Stanley was appointed liaison from IEEE 802.11
 to the IETF, in order to help coordinate between IEEE 802.11 and IETF
 WGs, including AAA, BMWG, CAPWAP, and EAP.

A.2.3. IEEE 802.11F

 IEEE 802.11F was chartered with development of a recommended practice
 for Inter-Access Point Communications.  As part of development of an
 Inter-Access Point Protocol (IAPP), it was necessary to secure
 communications between the access points, as well as to support the
 reverse resolution of the MAC address of the previous access point to
 its IP address, so as to allow the two access points to communicate
 via IAPP.  Since the two access points might not be on the same link,
 Inverse ARP [RFC2390] was not considered sufficient in all cases.
 IEEE 802.11F elected to extend the RADIUS protocol [RFC2865] to
 provide inverse address resolution as well as IPsec key management.
 This was accomplished via use of Vendor-Specific Attributes (VSAs),
 as well as new RADIUS commands, added through definition of
 additional values for the RADIUS Service-Type attribute.  As a
 result, IETF review was not required under the IANA considerations
 included in [RFC2865].  Subsequently, the RADIUS IANA considerations
 [RFC3575] were revised so as to require IETF review in most cases.

IAB Informational [Page 19] RFC 4441 IEEE 802/IETF Relationship March 2006

 No liaison arrangement was developed between IEEE 802.11F and IETF
 WGs such as AAA WG or SEAMOBY WG, so as to allow IETF participants
 access to the IEEE 802.11F specifications prior to publication.  Once
 IEEE 802.11F entered into Recirculation ballot, only comments
 relating to changes in the specification could be considered.  As a
 result, issues raised relating to the IEEE 802.11F RADIUS extensions
 were rejected.
 IEEE 802.11F was a Trial Use Recommended Practice.  The IEEE 802
 Executive Committee approved its withdrawal on November 18, 2005.  As
 a result, the RADIUS parameters allocated for use by IEEE 802.11F are
 available to be reclaimed.

IAB Informational [Page 20] RFC 4441 IEEE 802/IETF Relationship March 2006

Appendix B. IAB Members at the Time of This Writing

 Bernard Aboba
 Loa Andersson
 Brian Carpenter
 Leslie Daigle
 Patrik Falstrom
 Bob Hinden
 Kurtis Lindqvist
 David Meyer
 Pekka Nikander
 Eric Rescorla
 Pete Resnick
 Jonathan Rosenberg
 Lixia Zhang

Author's Address

 Bernard Aboba
 Microsoft
 One Microsoft Way
 Redmond, WA  98052
 USA
 EMail: bernarda@microsoft.com

IAB Informational [Page 21] RFC 4441 IEEE 802/IETF Relationship March 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

IAB Informational [Page 22]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4441.txt · Last modified: 2006/03/20 23:36 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki