diff options
Diffstat (limited to 'doc/rfc/rfc4441.txt')
| -rw-r--r-- | doc/rfc/rfc4441.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc4441.txt b/doc/rfc/rfc4441.txt new file mode 100644 index 0000000..1c85cb5 --- /dev/null +++ b/doc/rfc/rfc4441.txt @@ -0,0 +1,1235 @@ + + + + + + +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: + + - 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: + + - a revised RADIUS usage appendix based on [RFC3580] + - clarifications based on [RFC3579] + - 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] + |