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