RFC 4441

The IEEE 802/IETF Relationship

📅 published March 2006, from ietf

📜 RFC 4441: The IEEE 802/IETF Relationship 💖

Written by B. Aboba, Ed., published by the Internet Architecture Board. It's Informational and dated March 2006. Its title block lists no obsoleted or updated RFCs, so it doesn't replace or change anything. 🎀

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

Status of This Memo ✨

This memo gives information to the Internet community. It is not a spec for any Internet standard, and anyone can distribute it freely. 🦋

Copyright (C) The Internet Society (2006).

Abstract 🧚

Since the late 1980s, IEEE 802 and IETF have been working together on Simple Network Management Protocol (SNMP) MIBs and Authentication, Authorization, and Accounting (AAA) applications. ngl, that's a long history of teamwork 🫶. This doc explains the policies and procedures that were built to coordinate the two orgs, plus a bit of how the relationship got here. 💅

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

1. Introduction ✨

Okay so since the late 1980s, people in IEEE 802 and the IETF have been co-building Management Information Bases (MIBs) and AAA applications for IEEE standards, and it's giving collab goals 🌈. The list is iconic: 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], the 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]. 😭 That's a lot of slay. This document covers the policies and procedures put in place to help the IETF and IEEE 802 cooperate. The full relationship history is in Appendix A.

Bestie, here's the context 👑. To improve communication 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. A bunch of issues got discussed there, and new procedures were set up as a result. Main character energy 🎬.

1.1. Liaison Communications 🦋

Here's the structure, iykyk. IETF Working Groups are organized into areas, and each area has one or more Area Directors. The Area Directors, plus the IETF Chair, make up 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, make up the IEEE 802 Executive Committee (ExComm).

The IAB or IESG appoints IETF participants as liaisons to other organizations, as appropriate. That includes a liaison to IEEE 802, and liaisons to specific IEEE 802 Working Groups too. The IETF liaison web page has a list of IETF liaisons, plus a pointer to the archive of liaison statements the IETF has received [Liaison-Page]. IETF processes for managing liaison relationships are described in [BCP102], and the procedures for handling incoming liaison statements are in [BCP103]. To make sure liaison statements from IEEE 802 to the IETF get archived and answered, IEEE 802 liaisons to the IETF are encouraged to use the IETF liaison management tool to submit liaison communications. ✨ You can get a username and password for the tool by mailing iesg-secretary@ietf.org. If there's no liaison management account, liaison communications can go to the IETF liaison(s) to IEEE 802 with a copy to statements@ietf.org.

Heads up though 🙈: that route is way slower, because the IETF Secretariat staff have to handle it by hand.

Liaison requests from the IETF to IEEE 802 should go to the Chair(s) of the IEEE 802 WG the request is about, with a copy to the IEEE 802 Chair and the IEEE 802 liaison(s) to the IETF. How IEEE 802 talks to other standards bodies is described in Section 14.1 of [Policy]. Liaison communications to IEEE 802 WGs are archived by each individual WG. 🍓

1.2. Access to IEEE 802 Archives 🔥

Access to IEEE 802 standards that are more than six months old is free on the IEEE 802 website, through the Get IEEE 802 Program [GetIEEE-802]. 🎀 Getting access to IEEE 802 work-in-progress has come up a lot in IETF and IEEE 802 cooperation. IETF Working Groups (WGs) have negotiated access before, but every single instance was handled separately and took a lot of time and effort. To make document access easier for IETF WGs working with IEEE 802, Paul Nikolich, Chair of IEEE 802, sent a liaison statement to the IETF in July 2004 [IEEE-802Liaison]. It describes how IETF WGs can get access to IEEE 802 work-in-progress. 🫶

IEEE 802 WG Chairs have the authority to grant membership in their WGs, and they can use that power to grant membership to an IETF WG chair who asks. The IETF WG chair gets the username and password for the IEEE 802 WG archives, and is allowed to share them with participants in the IETF WG. You don't have to attend meetings or even join a mailing list to take part in the IETF, so IETF WG chairs will give the information to anyone who requests it. 💜 BUT (and this is a big but 💀), since IEEE 802 work-in-progress is copyrighted, you are not permitted to incorporate material into IETF documents, or to post the username/password on mailing lists or websites.

⚠️ Reminder: sharing the username/password publicly or copying IEEE 802 work-in-progress into IETF documents is not allowed. Don't do it, bestie. 🙅‍♀️

1.7. Document Review 🎀

okay so the teamwork between IEEE 802 and IETF is getting SO big, and the document review stuff has gone way past the classic stuff like SNMP MIBs and AAA 🌸 For example, the IETF CAPWAP WG charter asked IEEE 802.11 to review the CAPWAP Taxonomy Document [RFC4118], and Dorothy Stanley put together an ad hoc group just for that 🧚 IEEE 802.11 has also reviewed [IDSEL] and [IABLINK] ✨ Inside the IETF, IEEE 802 comments get resolved with the usual WG and IETF processes, no special drama needed 💖

IETF folks can totally comment as part of the IEEE 802 ballot process, even if they don't have a vote in IEEE 802 🫶 The comments need to be written in the format the ballot asks for, and they have to get in before the ballot deadline ⏰ no late arrivals bestie 😭

1.8. EtherType Allocation 🦋

the EtherType field is super limited, so allocations only happen on an "as needed" basis 💅 If you have a bunch of related uses, you should request one single EtherType and use extra fields as sub-protocol identifiers, instead of applying for a pile of EtherTypes 🍓 The full allocation policy is in [TYPE-TUT] 📖

Normally IEEE 802 charges a fee for an EtherType allocation, but IEEE 802 will consider waiving it for allocations tied to an IETF standards track document, as long as the IESG asks for it 👑 that's giving teamwork 🥹

2. Security Considerations 🔥

okay this part is serious, so listen up 💀 As IEEE 802 gets more and more into writing link-layer security standards, experience has shown that it really helps to get outside review of work-in-progress before publication 🔐 That's been kinda tricky though, because access to IEEE 802 work-in-progress documents is often locked down tight 😤 For example, IEEE 802.11i needed special permission just 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 get the level of review that's needed ✨

Experience has also shown that IETF standards might not be written as clearly as the IEEE 802 standards process needs 📝 For EAP [RFC3748], building the EAP state machine specification [RFC4137] was super useful for finding parts that needed clarifying 🔍 and the joint review process put IEEE 802 and IETF documents-in-progress in front of a wider audience than might have happened otherwise 🌈

The work on [IEEE-802.11i], [RFC3748], [KEYFRAME], and [RFC4017] led to a much 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, like the one provided in [KEYFRAME] ⚠️ this is a MUST-READ energy moment, no cap 🫠

Heads up: because of weaknesses in the RADIUS specification [RFC2865], it is relatively easy for protocol extensions to introduce serious security vulnerabilities 🚨 So IETF review of IEEE 802 RADIUS extensions is advisable, and the RADIUS IANA Considerations [RFC3575] have been revised to require that review in most cases 💜

3. Informative References ✨

okay bestie, the reference list is LONG 😭 but every single entry is here, tags, titles, dates and links, exactly as they were. no skipping 🫶

  • [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.
  • [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.
  • [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.
  • [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.
  • [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.

4. Acknowledgements 🫶

the authors wanted to thank these legends for their contributions to this doc 💖 Les Bell, Dan Romascanu, Dave Harrington, Tony Jeffree, Fred Baker, Paul Congdon, Paul Langille, and C. M. Heard 👑

Appendix A. Relationship History 🌈

A.1. MIB Development 🦋

A.1.1. Bridge MIB ✨

okay so the IETF and IEEE 802 friendship started in the late 1980s 🌸 with SNMP MIBs for the original IEEE 802.1D standard. The IEEE spec [IEEE-802.1D] only had a functional definition of the counters and operations, so the IETF's Bridge MIB WG took on defining the Bridge MIB [RFC1493], which got published as an RFC. Fred Baker and later Keith McCloghrie chaired the Bridge WG 👑

The Bridge MIB was a team effort 🫶 Keith McCloghrie, Eric Decker, and Paul Langille did the main work, and Anil Rijsinghani brought the spanning tree expertise. On the IEEE 802.1 side, the main contacts were Mick Seaman (author of 802.1D) and Floyd Backes (who wrote the code for Digital Equipment's spanning tree implementation). Mick, Floyd, Anil, and Paul all worked at Digital Equipment Corporation back then, so most of the coordination between IEEE 802.1 and the Bridge MIB WG happened in the hallways at Digital instead of through official channels 🙈

A.1.2. MAU and Hub MIBs 🔌

In the early 1990s, IEEE 802.3 was finishing the first Ethernet standards, but SNMP wasn't the dominant network management protocol yet 💀 So a "protocol independent" MIB got included in Clause 30 of the IEEE 802.3 standard [IEEE-802.3], and it gets updated every time Ethernet is upgraded for higher speeds. At the same time, IEEE 802 folks who cared about network management were helping form the IETF HUBMIB WG, which took IEEE 802 definitions and turned them into SNMP MIBs documented as Standards Track RFCs. Dan Romascanu was in the mix, and he's been Chair of the IETF HUBMIB WG since 1996 🧚

The HUBMIB WG charter says outright that IEEE 802.3 is the starting point for the Ethernet MIB, but the WG also reserves the right to deviate from the IEEE model 🦋 That means covering only part of what the standard offers, or adding MIB objects that aren't directly derived from the IEEE model (mostly the ones implemented in software). And if management needs lead to hardware support requirements, the IETF HUBMIB WG is supposed to pass that input along to IEEE 802.3 in a timely manner ⭐

The IETF HUBMIB WG and IEEE 802.3 have kept working together for more than a decade, and they still are today 💜 Mostly it's a few editors, backed by their companies, taking the IEEE standards and mapping them into a management data model and MIBs. Here's what's on the list:

  • The Hub MIB [RFC2108], which has gone through three iterations and is probably wrapping up its evolution, since repeaters are less used in Ethernets.
  • The MAU MIB, which gets updated every time a new Ethernet speed comes out, with [RFC3636] covering 10-Gbps Ethernet.
  • The Ethernet-like Interfaces MIB wasn't originally a HUBMIB WG work item, 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 both IEEE 802.3 and the IETF HUBMIB WG 🎀

In 2000, an official liaison was set up between IEEE 802.3 and the IETF HUBMIB WG, and Dan Romascanu was appointed as the IETF liaison 🌈 The liaison agreement lets editors and other HUBMIB WG participants access work-in-progress drafts in IEEE 802.3 on a personal basis, so they can work on MIBs before the standard is released. But 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, while 802.1p and 802.1Q [IEEE-802.1Q] were being finished, people realized they needed an SNMP MIB based on the management clauses of those standards 🍓 IEEE 802 management clauses are written so they don't depend on any particular protocol used to implement them.

At that point there were a bunch of proprietary VLAN management MIBs, and they were both inadequate and hard to understand 😭 So there was a need for a more comprehensive, simpler model for VLAN management, covering the priority and multicast filtering management those standards also define.

A small group from the 802.1 WG started working on the problem on their own, then merged their work. The original authors of the Bridge MIB, which some of this work was based on, reviewed the initial work 👑

By the end of 1997, the work was ready for a bigger audience. Andrew Smith worked with Keith McCloghrie, chair of the Bridge MIB WG (which was dormant at the time), to get a meeting slot at the March 1998 IETF meeting. After that, review and development of the MIB kept going 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. It still turned out well, 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 🧩

For the IEEE 802.3ad and IEEE 802.1X standards work, the group decided it would be better to develop a MIB as part of the standards, instead of waiting for an IETF WG to form and developing the MIBs separately. The goal was to avoid a big time lag in development ⏰

Les Bell was the participant in IEEE 802.3ad and IEEE 802.1 who knew SNMP MIB development best, so he put together the initial MIBs based on the management framework the groups had come up with. Both MIBs got more help from inside the IEEE 802.3ad and IEEE 802.1X groups. Tony Jeffree, editor of both standards, also acted as editor of the MIBs 💅

The problem with IEEE 802 developing these MIBs without IETF involvement was the lack of review. IEEE 802 members generally aren't familiar with MIBs, so very few comments came in during the balloting process for either MIB 😬

For the IEEE 802.3ad MIB, that meant basic errors weren't found until just before publication. Unfortunately, by then it was too late. The corrections sent to the IEEE 802.3ad chair and document editor didn't make it into the published version 💀

After [IEEE-802.1X] was published, the IEEE 802.1X MIB was reviewed within the Bridge WG, and several syntax errors turned up. These were fixed in the version of the MIB module developed as part of [IEEE-802.1X-2004]. But even though [IEEE-802.1X-MIB] was originally published as a work in progress within the Bridge WG, there wasn't enough interest to finish it as an RFC, so 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, and they needed some additions to the MIB published in [RFC2674]. 802.1v was a new feature extending the VLAN classification schemes of 802.1Q, which also required extensions to [RFC2674]. 802.1w was a new version of Spanning Tree, which meant rewriting part of [RFC1493] 🎀

When Les Bell became Chair of the IETF Bridge MIB WG in 2001, these issues were raised as new work items, and two volunteers stepped up to become editors of the Internet-Drafts. There was also a work item to publish the IEEE 802.1X MIB as an Informational RFC 🫶

It worked well for a while, but then it got hard for participants, including the editors and the Chair, to keep up enough interest to get past the difficulties caused by budget cutbacks 😮‍💨 As a result, the drafts have now expired, although there are no significant technical issues still outstanding 🌸

A.2. AAA/EAP 🔐

Since the late 1990s, IEEE 802.1 has been working on authentication and authorization [IEEE-802.1X]. That work uncovered issues in several IETF specifications, including [RFC2284] and [RFC2869]. IETF participants have also found issues in early versions of RADIUS usage specifications like [RFC3580], as well as in the IEEE 802.1X state machine [Mishra] 🧠

To deal with these issues and keep IEEE 802.1 and the IETF EAP and AAA WGs in sync, a liaison arrangement was used while [IEEE-802.1X] and [IEEE-802.1X-2004] were being developed 🤝

IEEE 802.11 groups like IEEE 802.11i and IEEE 802.11F also ended up depending on EAP and AAA work. This relationship was way more challenging, because IEEE 802.11 needed EAP methods and the EAP Key Management Framework to be developed, which was a lot of new IETF work. IEEE 802.1 only needed clarifications and updates 😤✨

A.2.1. IEEE 802.1X ✨

okay so IEEE 802.1X-2001 [IEEE-802.1X] is the spec that defined how EAP [RFC2284] gets carried over IEEE 802, plus a state machine for how 802.1X and EAP work together. it's giving foundation 🧱💖

then during development, people found several problems in the RADIUS/EAP spec [RFC2869], so work started on a revision [RFC3579]. there were also questions about how IEEE 802.1X implementations should read the RADIUS attributes defined in [RFC2865], [RFC2866], [RFC2867], [RFC2868], [RFC2869], and [RFC3162]. to sort that out, a non-normative RADIUS usage appendix got added to [IEEE-802.1X], and it was published as [RFC3580] 🎀

then a formal analysis of the IEEE 802.1X state machine by the University of Maryland found several security issues [Mishra] 😭. IEEE 802.1 discussions pointed to the lack of clarity in [RFC2284], and that came from there being no specification for the EAP state machine. 💀

at that point EAP was handled by the IETF PPPEXT WG, which was pretty much inactive 🥀. so to work on a revised EAP spec and the EAP state machine spec, the IETF EAP WG got formed in July 2002. Bernard Aboba, who was in both IEEE 802.1 and PPPEXT, became co-chair 👑

work on the EAP state machine [RFC4137] and the revised EAP spec [RFC3748] happened side by side inside the EAP WG. if something changed in one doc, it often meant changes in the other, plus revisions to [IEEE-802.1X-2004] 🔄. the revised RADIUS/EAP spec [RFC3579] also got reviewed by the EAP WG, since the RADEXT WG didn't exist yet at that point 🧚

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]

because [IEEE-802.1X-2004], [RFC3748], and [RFC4137] are so deeply dependent on each other, a liaison got set up between IEEE 802.1X-REV and the IETF EAP WG in August 2002. that let EAP WG folks see the IEEE 802.1X revision while it was still in progress 👀🌸

IEEE 802 groups have to consider every comment they get, no matter where it comes from 🫶. so IETF folks can comment as part of the IEEE 802 ballot process, whatever their voting status in IEEE 802 is. when there's active cooperation, IETF WGs can be told when IEEE 802 ballots are happening and that their comments are welcome. IEEE 802.1X-REV and IEEE 802.11i ballots got announced on the EAP WG mailing list, and so did IEEE 802 interim meeting arrangements 📣

same story for the IEEE 802.1X-REV ballot: comments came in about [RFC3748], [RFC4137], and [RFC3579]. those got tracked on the EAP WG Issues List and then addressed in the documents ✅

in April 2003, the IESG approved [RFC3580] for publication as an RFC, and in May 2003, [RFC3579] got approved too 🎉. both drafts went through IETF last call, and then the last-call announcement got reposted on the IEEE 802.1 mailing list. ballot comments on IEEE 802.1X-REV also showed up as changes in both docs, but both docs had to be approved as RFCs well before Sponsor Ballot so their RFC numbers would be assigned in time and publication wouldn't get delayed 🗓️

overall, even with all those tangled dependencies between [IEEE-802.1X-2004], [RFC3748], and [RFC4137], everything got produced without undue delay. that was mostly thanks to people who participated in both IEEE 802.1 and the 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] used IEEE 802.1X, it depended on [IEEE-802.1X-2004] 🔐. so IEEE 802.11i and IEEE 802.1 held joint meetings at IEEE 802 plenaries and set up a liaison arrangement. that let members of either group (and EAP WG participants too) get access to IEEE 802.11i work-in-progress 🤝

because [IEEE-802.11i] depended on [IEEE-802.1X-2004], it also inherited all of [IEEE-802.1X-2004]'s dependencies, including work on EAP, EAP methods, and AAA support for EAP 🧩. plus, IEEE 802.11i used EAP for key management, and [IEEE-802.1X] doesn't, so extra security requirements came up for EAP methods 🚨

in February 2002, IEEE 802.11 sent a liaison letter to the IESG [IEEE-80211Liaison1] asking for more work on EAP, EAP methods, and EAP key management 📝. that letter got presented at the second EAP BOF at IETF 53 and was used as input for the EAP WG charter. in March 2003, another liaison letter came in with more clarifications on requirements for EAP method work [IEEE-80211Liaison2]. it included a request from IEEE 802.11i asking the EAP WG to consider changing the mandatory-to-implement EAP method in [RFC3748], so there'd be a method that meets the IEEE 802.11i security requirements 🔁

during IETF 56, the EAP WG looked at changing the mandatory-to-implement method. Internet Area Director Erik Nordmark recommended two things: document the IEEE 802.11i requirements in an RFC, and have 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 wasn't chartered to do method work. instead, the group decided to write a doc describing EAP method requirements for WLAN usage, and that one got published as [RFC4017] ✨

more recently, IEEE 802.11r has been talking about fast handoff, which might need AAA extensions and changes to the EAP key hierarchy 👀. the direction of that work isn't decided yet, so no liaison request has been formulated 🤷‍♀️

in April 2003, Dorothy Stanley was appointed as the liaison from IEEE 802.11 to the IETF. her job is 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 to develop a recommended practice for Inter-Access Point Communications. as part of building an Inter-Access Point Protocol (IAPP), the access points needed to secure their communications with each other 🔒. they also needed reverse resolution of the MAC address of the previous access point to its IP address, so the two access points could talk over IAPP 📡. since the two access points might not be on the same link, Inverse ARP [RFC2390] wasn't considered enough in every case 🙅‍♀️

IEEE 802.11F decided to extend the RADIUS protocol [RFC2865] to provide inverse address resolution as well as IPsec key management 🛠️. this was done with Vendor-Specific Attributes (VSAs), plus new RADIUS commands, added by defining extra values for the RADIUS Service-Type attribute. because of that, IETF review wasn't required under the IANA considerations included in [RFC2865]. later on, the RADIUS IANA considerations [RFC3575] got revised so that IETF review is required in most cases 📋

no liaison arrangement got set up between IEEE 802.11F and IETF WGs like the AAA WG or SEAMOBY WG. that means IETF participants didn't get access to the IEEE 802.11F specs before publication 🙃. once IEEE 802.11F entered Recirculation ballot, only comments about changes to the spec could be considered. so issues raised about the IEEE 802.11F RADIUS extensions got 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 that were allocated for IEEE 802.11F are available to be reclaimed ♻️💅

Appendix B. IAB Members at the Time of This Writing 👑

these are the IAB members when this doc was written 🌟

  • 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

Copyright (C) The Internet Society (2006) 🌸

this document is subject to the rights, licenses and restrictions in BCP 78. except as set out there, the authors keep all their rights 🫶

this doc and the info in it 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 doesn't take a position on whether any Intellectual Property Rights or other rights claimed for the tech in this doc are valid or in scope, or whether any license under those rights is available. it also doesn't say it's looked into those rights itself 🔍. info about how rights work for RFC docs is in BCP 78 and BCP 79 📚

copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses to be made available, can be found in the IETF online IPR repository at http://www.ietf.org/ipr. the same goes for any attempt to get a general license or permission for implementers or users to use those proprietary rights 🗂️

the IETF invites anyone to point out any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 📨💖

Acknowledgement 🙏

funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 💅✨

📦 where this page comes from