Network Working Group B. Aboba, Ed. INTERNET-DRAFT Internet Architecture Board Category: Informational 2 July 2005 The IEEE 802/IETF Relationship By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 22, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract Since the mid 1990s, IEEE 802 and IETF have cooperated in the development of SNMP MIBs and 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. IAB Informational [Page 1] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 Table of Contents 1. Introduction .......................................... 3 1.1 Current Issues .................................. 5 2. Security Considerations ............................... 7 3. IANA Considerations ................................... 7 4. References ............................................ 7 4.1 Informative References .......................... 7 Acknowledgments .............................................. 12 Appendix A - Relationship History ............................ 13 A.1 MIB Development ................................. 13 A.2 AAA/EAP ......................................... 16 Appendix B - IAB Members ..................................... 20 Intellectual Property Statement .............................. 20 Disclaimer of Validity ....................................... 20 Copyright Statement .......................................... 21 IAB Informational [Page 2] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 1. Introduction Since the late 1980s, participants in IEEE 802 and the IETF have cooperated in the development of MIBs and AAA applications relating to IEEE standards. This has included the Bridge MIB [RFC1493], the multicast filtering and VLAN extension MIB [RFC2674], 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], RADIUS/EAP [RFC3579], IEEE 802.1X RADIUS usage guidelines [RFC3580], the revised EAP specification [RFC3748], and the EAP State Machine specification [EAPSTATE]. 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 IESG and IAB (including Bert Wijnen, James Kempf and Bernard Aboba) met with the IEEE 802 Executive Committee in Vancouver, Canada during the IEEE 802 Plenary in January 2004. At that meeting a number of issues were discussed and the following procedures were put in place: [a] Access to IEEE 802 archives. Access to IEEE 802 standards more than 12 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. IEEE 802 and IETF follow different models with respect to document access. While IETF Internet-Drafts are freely available, IEEE 802 keeps documents restricted to the participants in the IEEE 802 standards process. Within IEEE 802, a participant is required to physically attend at least one IEEE meeting. While in the past IETF WGs have successfully negotiated access to IEEE 802 work-in-progress, each instance has been handled separately and may take significant time to set up. 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 a general process by which IETF WGs could obtain access to IEEE 802 work-in-progress. IEEE 802 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 members of 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 with anyone who requests it. However, since IEEE 802 work-in- progress is copyrighted, incorporating material into IETF documents IAB Informational [Page 3] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 or posting the username/password on mailing lists or websites is not permitted. [b] 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 PARs, it was proposed that the New Work mailing list be used. The IEEE 802 Executive Committee was subscribed to the list, so that they can receive proposed IETF WG Charters. Paul Congdon, Vice-Chair of IEEE 802.1 took on the task of posting proposed IEEE 802 PARs 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. [c] 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 which involved chartering a work item within an IETF WG. In order to encourage wider review of MIBs developed by IEEE 802 WGs, it was recommended that SNMP MIBs developed in IEEE 802 follow the MIB guidelines [GUIDELINES] 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 assure quality while decreasing overhead. A trial run of this process has taken place in IEEE 802.1 where David Harrington has agreed to review IEEE 802.1 MIBs. [d] 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. Recently, interest has arisen within the IETF BMWG WG to review the work of IEEE 802.11TGT. As part of the IETF CAPWAP WG charter, IEEE 802.11 was asked to review the CAPWAP Taxonomy Document [CAPARCH]; Dorothy Stanley organized an adhoc 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. Similarly, IETF participants can comment as part of the IEEE 802 ballot process, regardless of their voting status within IEEE 802. [e] Ethertype allocation. While a fee is normally charged by IEEE 802 for the allocation of Ethertypes, IEEE 802 will consider waiving the fee for allocations relating to an IETF standards track document, based on a request from the IESG. IAB Informational [Page 4] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 1.1. Current Issues Going forward, a number of issues have arisen: [a] Need for increased reliance on online communication. In these times of travel restriction it is important to be able to conclude IETF/IEEE 802 cooperative projects successfully without requiring physical attendance at both IETF and IEEE 802 meetings. This is somewhat of a challenge because in the past having participants attend both standards bodies has been an important contributor to success. While the cross-organizational review process has been relatively successful, there are times where joint forums might be helpful. An example of this occurred with the EAP WG review of IEEE 802.16e [EAPREVIEW], where considerable discussion within IEEE 802.16e was required in order to develop a response to the review. [b] Need for earlier review of New Work. While the New Work list has been successful in keeping IETF and IEEE 802 management appraised of new WGs, the posting of proposed Charter and PARs has often come too late to significantly affect the process. 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. It is therefore recommended that IETF and IEEE 802 explore mechanisms for earlier consultation on new work items. [d] Need to transfer MIB work to IEEE 802. Due to the lack of interest within IETF in continued work on IEEE 802.1 MIBs, arrangements are being discussed by which change control of selected IEEE 802.1 MIB documents published as RFCs would be transferred to IEEE 802.1. Since these MIBs have a long history of work within the IETF (see Appendix A for details), there is a desire on the part of the IETF to continue to provide MIB Doctor review and maintain open availability of documents, while at the same time allowing future work to transition over to IEEE 802.1. [e] Need for EAP review. In general, it is not advisable for IEEE 802 to develop its own EAP methods or new applications for EAP key management. With respect to EAP, [RFC3748] describes the procedures for IANA allocation of EAP protocol parameters, including Type values. The guidelines for EAP Key Management are described in [KEYFRAME]. Where new EAP functionality is required by IEEE 802, a liaison request should be sent to the EAP WG, outlining the required functionality or requesting a review of draft text. Such a review was conducted by the EAP WG on behalf of IEEE 802.16e [EAPREVIEW], at the request of the IEEE 802.16 Chair, IAB Informational [Page 5] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 Roger Marks [IEEE-802.16-Liaison1][IEEE-802.16-Liasion2]. [f] Need for AAA review. In general, it is not advisable for IEEE 802 to develop its own AAA applications, particularly when those applications involve AAA key management [Housley]. IEEE 802 WGs requiring new AAA applications are encouraged to alert the IETF to those requirements by contacting the IETF AAA or RADEXT WGs rather than proceeding on their own. Where new AAA attributes are required rather than a new application, the attributes may be submitted to the IETF AAA or RADEXT WGs for standardization, or if that is not appropriate, an individual submission can be prepared, and review can be requested from the AAA or RADEXT WGs. In addition the AAA Doctors list has been created within the IETF Operations and Management Area Directorate. The AAA Doctors serve 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, it is conceivable that group could be of assistance to IEEE 802 with their AAA requirements. [g] Preference for IETF standard AAA attributes, and a single IEEE Vendor-Specific attribute format. Currently several standards organizations, including IEEE 802, have taken to allocating their own vendor-specific AAA attributes. 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. Since IEEE 802 vendor-specific attributes are not specific to only one vendor's implementation of RADIUS and interoperability is generally deemed useful, use of vendor-specific attributes represents a last resort. For AAA attributes of general utility, and particularly those useful in multiple potential applications, allocation from the IETF standard attribute space is preferred. The RADIUS IANA Considerations [RFC3575] now requires review for many RADIUS parameter allocations. Where allocation of Vendor-Specific Attributes (VSAs) is required, it is recommended that IEEE 802 create a uniform format for all of IEEE 802, rather than letting each IEEE 802 WG create their own format. The format defined in [IEEE-802.11F] is inappropriate for this, since it only defines a single octet Type field, allowing for only 255 attributes. Now that [IEEE-802.11F] has been deprecated, it is recommended that IEEE 802 abandon the IEEE 802.11F vendor- specific attribute format in order to design a new vendor-specific attribute format suitable for use by all of IEEE 802. IAB Informational [Page 6] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 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 are 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 a relevant IETF WG can assist 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 [EAPSTATE] 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] lead 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 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. 3. IANA Considerations This document does not create any registries or allocate any protocol parameters. 4. References 4.1. Informative References [CAPARCH] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", draft-ietf-capwap-arch-06.txt, Internet draft (work in progress), November 2004. IAB Informational [Page 7] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 [EAPREVIEW] EAP WG letter to Roger Marks, June 2005, http://www.drizzle.com/~aboba/EAP/review.txt [EAPSTATE] Vollbrecht, J., Eronen, P., Petroni, N. and Y. Ohba, "State Machines for EAP Peer and Authenticator", draft- ietf-eap-statemachine-06.pdf, Internet draft (work in progress), December 2004. [GetIEEE-802] IEEE Standards Association Get IEEE 802 (R) Program, http://standards.ieee.org/getIEEE-802/ [GUIDELINES] Heard, C.M., "Guidelines for Authors and Reviewers of MIB Documents", draft-ietf-ops-mib-review-guidelines-04.txt, Internet draft (work in progress), February 2005. [IDSEL] Adrangi, F., Lortz, V., Bari, F. and P. Eronen, "Identity selection hints for Extensible Authentication Protocol (EAP)", draft-adrangi-eap-network-discovery-13.txt, Internet draft (work in progress), June 2005. [Housley] Housley, R. and B. Aboba, "AAA Key Management", draft- housley-aaa-key-mgmt-00.txt, Internet draft (work in progress), June 2005. [IABLINK] Aboba, B., "Architectural Implications of Link Indications", draft-iab-link-indications-01.txt, Internet draft (work in progress), January 2005. [IEEE-80211Liaison1] IEEE 802.11 liaison letter to Harald Alvestrand, February 2002, http://www.ietf.org/IESG/LIAISON/ieeeIEEE-802.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-802Liaison] IEEE 802 Liaison letter to Bert Wijnen and Bernard Aboba, July 26, 2004, http://www.ietf.org/IESG/LIAISON/file41.pdf [IEEE-802.1X-MIB] Norseth, K., "Definitions for Port Access Control (IEEE 802.1X) MIB", Internet draft (work in progress), draft- ietf-bridge-8021x-03.txt, November 2003. IAB Informational [Page 8] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 [IEEE-802.1X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001. [IEEE-802.1X-2004] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2004, December 2004. [IEEE-802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990. [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.5] ISO/IEC 8802-5 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 5: Token ring access method and physical layer specifications, (also ANSI/IEEE Std 802.5-1998), 1998. [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 Std. 802.11-2003, 2003. [IEEE-802.11i] Institute of Electrical and Electronics Engineers, "Supplement to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access IAB Informational [Page 9] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security", IEEE 802.11i, July 2004. [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-Liasion2] 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", draft-ietf-eap-keying-06.txt, Internet draft (work in progress), April 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. [RFC1493] Decker, E., et al., "Definitions of Managed Objects for Bridges", RFC 1493, July 1993. [RFC2108] Graaf, K., et al., "Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2", RFC 2108, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [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. [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2674] Bell, E., et al., "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions", RFC 2674, August 1999. IAB Informational [Page 10] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2867] Zorn, G., Mitton, D. and B. Aboba, "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", RFC 3575, July 2003. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS 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 RADIUS Usage Guidelines", RFC 3580, September 2003. [RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC 3621, December 2003. [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. IAB Informational [Page 11] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 [RFC4017] Stanley, D., Walker, J. and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005. Acknowledgments 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] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 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 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. 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 IAB Informational [Page 13] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 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 Interfaces 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 user name and password for IEEE 802.3 document access are not for publication on any IETF Web site or mail list. A.1.3 802.1p/Q MIB In 1996 as the 802.1p and 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 which 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. 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. IAB Informational [Page 14] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 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 IEEE 802.1 as well as 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 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 draft within the Bridge WG, there was not sufficient interest to complete its publication as an RFC. As a result, the draft has now expired. 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 re- writing of part of [RFC1493]. IAB Informational [Page 15] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 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 cut-backs. 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 lead 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. 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]. IAB Informational [Page 16] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 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 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 [EAPSTATE] and revised EAP specification [RFC3748] proceeded in parallel within 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 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 [EAPSTATE] Due to the deep dependencies between [IEEE-802.1X-2004], [RFC3748] and [EAPSTATE], a liaison was established between IEEE 802.1X-REV and the IETF EAP WG in August 2002. This enabled members of 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 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], [EAPSTATE], 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 IAB Informational [Page 17] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 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 [EAPSTATE], 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 with 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.lX-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-802Liaison1] 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-802Liaison2]. This included a request from IEEE 802.11i for 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 IAB Informational [Page 18] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 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, as well as new RADIUS commands, defined 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 were revised so as to require IETF review [RFC3575] in most cases. 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. Since IEEE 802.11F was a Recommended Practice, it was required that the document be renewed by July 2004. Since that deadline passed without ratification, IEEE 802.11F is now deprecated. This raises the question of whether the RADIUS parameters allocated for use by IEEE 802.11F should be reclaimed. IAB Informational [Page 19] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 Appendix B - IAB Members at the time of this writing Bernard Aboba Loa Andersson Leslie Daigle Patrik Falstrom Bob Hinden Kurtis Lindqvist David Meyer Pekka Nikander Eric Rescorla Pete Resnick Jonathan Rosenberg Lixia Zhang Intellectual Property Statement 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. Disclaimer of Validity 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. IAB Informational [Page 20] INTERNET-DRAFT IEEE 802/IETF Relationship 2 July 2005 Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. IAB Informational [Page 21]