INTERNET-DRAFT Scott O. Bradner <draft-iesg-vendor-extensions-01.txt> Harvard University Thomas Narten IBM October 27, 2003 Considerations on the Extensibility of IETF protocols <draft-iesg-vendor-extensions-01.txt> Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document discusses issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions need to be reviewed by the larger IETF community. The document also recommends that major extensions to IETF protocols only take place through normal IETF processes or in coordination with the IETF. Contents Status of this Memo.......................................... 1 1. Introduction............................................. 2 2. Principles............................................... 2 draft-iesg-vendor-extensions-01.txt [Page 1]
INTERNET-DRAFT October 27, 2003 3. Recommendation........................................... 4 4. Examples................................................. 6 4.1. RADIUS Vendor-Specific Attributes................... 6 4.2. LDAP Schema Extensions.............................. 6 4.3. L2TP Extensions..................................... 6 5. IANA Considerations...................................... 7 6. Security Considerations.................................. 7 7. Acknowledgments.......................................... 7 8. Informative References................................... 7 9. Editor's Addresses....................................... 7 1. Introduction When developing protocols, quite a few IETF working groups have made facilities whereby these protocols can be extended in the future. Vendors, other standards development organizations and technology fora have used those facilities. Sometimes the result is non- interoperability or poorly designed mechanisms. The purpose of this memo is to make explicit some guiding principles based on the community's experience with extensibility mechanisms. One of the key principles is that protocols should not be made more extensible than clearly necessary at inception. The IESG is presently applying some version of these principles when evaluating proposals for new standards. 2. Principles The most important principle driving this memo, and in fact the IETF as a whole is the principle of: o IETF Standards are intended to encourage and enable multiple implementers to build implementations of protocols that will interoperate. It is a good principle to design extensible protocols but extensibility features should be limited to what is clearly necessary when the protocol is developed and any later extensions should be done carefully and with a full understanding of the base protocol, existing implementations, and current operational practice. draft-iesg-vendor-extensions-01.txt [Page 2]
INTERNET-DRAFT October 27, 2003 If extensions to IETF protocols are done outside the IETF, experience has shown that documentation of these extensions can be hard to obtain, short-sighted design choices are sometimes made, basic underlying architectural principals of the protocol are sometimes violated, assessing the quality of the specification is hard, and achieving interoperability can be hard. It can be particularly difficult for a user to figure out who is at fault and what to do about it if two pieces of software that both claim to be implementations of an IETF standard do not work together. Yet there are situations where extensions to IETF protocols can make sense. There are two general ways in which protocols are extended. Many (if not most) protocols are designed to carry opaque data of some kind, where the protocol itself mostly doesn't care what the contents of that data is. For example, DHCP [DHC] transports options, but the contents of the option are generally of no concern to the DHCP protocol itself. Many other protocols provide such a capability, including OSPF LSAs, BGP, Radius Attributes, Diameter AVPs, etc. Important points to note about such extensions include: o The protocol is designed to carry such opaque data and no changes to the underlying base protocol are needed to carry a new type of data. Specifically, no changes are required to existing and currently deployed implementations unless they want to make use of the new data type. o Using the existing protocol to carry a new type of opaque data will not impact existing implementations or cause operational problems. Examples of minor extensions include the DHC vendor-specific option, the enterprise OID tree for MIB modules, vnd. MIME types, and some classes of (non-critical) certification extensions. Such extensions can safely be made with minimal IETF coordination and are indicated by having an IANA Considerations that allows assignments of code points with minimal overhead (e.g., first come first served) [IANA- CONSID]. The more interesting way in which protocols are extended is called a major extension. Major extensions have some or all of the following characteristics: o Change or extend the way in which the basic underlying protocol works, e.g., by changing the semantics of existing PDUs or defining new message types that require implementation changes in existing and deployed implementations of the protocols, even if they do not want to make use of the new functions or data draft-iesg-vendor-extensions-01.txt [Page 3]
INTERNET-DRAFT October 27, 2003 types. o Change basic architectural assumptions about the protocol that have been an assumed part of the protocol and its implementations. o Lead to new uses of the protocol in ways not originally intended or investigated, potentially leading to operational and other difficulties when deployed, even in cases where the "on-the- wire" format has not changed. For example, the overall quantity of traffic the protocol is expected to carry might go up substantially, typical packet sizes may increase compared to existing deployments, simple implementation algorithms that are widely deployed may not scale sufficiently or otherwise be up to the new task at hand, etc. Exactly what is considered to be a major extension and what is considered normal usage will depend on the specific protocol and the proposed extension at issue. Even for protocols designed to carry opaque data, whether a proposed usage qualifies as a major extension may involve considerable debate. But it is important that such discussion involve the IETF community of experts knowledgeable about the protocol's architecture and existing usage in order to fully understand the implications of a proposed extension. Major extensions should be well, and publicly, documented and reviewed by the IETF community to be sure that the extension does not undermine basic assumptions and safeguards designed into the protocol, such as security functions, or undermine its architectural integrity. 3. Recommendation The following principles are the main guiding principles concerning extensions to IETF protocols: o Extensibility features in IETF protocols should be limited to providing just the amount of extensibility that is seen as required. Protocols should not be extensible just for the sake of being extensible. o All major extensions to IETF protocols should be done with adequate review by or direct involvement of the IETF. o The decision on whether an extension is major or minor should be done with the direct involvement of the IETF. Ideally, extensions should be done by IETF working groups using draft-iesg-vendor-extensions-01.txt [Page 4]
INTERNET-DRAFT October 27, 2003 normal IETF processes or, if a working group does not consider a proposed extension to be general enough, at least documented in an IETF informational RFC that is reviewed by the working group and the IESG. No individual, vendor, standards development organization or forum should be able create what is viewed to be a major extension to an IETF protocol on its own and legitimately be able to claim that implementations that implement the extension are compliant to the IETF specification, or that the extension is a part of the IETF specification. It should be noted that the second bullet above leads to the possibility of a denial-of-service issue, as it implies that any major extension should be done within or reviewed by the IETF. At the same time, the IETF may not have the resources to develop (or even review) every possible extension and will need to prioritize the use of its resources. Thus, it is important to be pragmatic in terms of what work can and will be taken on by the IETF, and to set expectations accordingly. In those cases where the IETF is unable to take on a particular work item, it should be understood that the IETF will review extensions to its technology that it is asked to publish, and may approve publication only after changes are made, or may not agree to publish the extension at all. Thus, anyone proposing extensions outside of the IETF is advised to coordinate any such extensions with the IETF as early as possible. Waiting until the last minute before consulting with the IETF and then assuming quick publication of a finished extension is not recommended. It should also be noted that there are limits to what the IETF can do to prevent others from improperly extending protocols outside of the IETF. The IETF's leverage is limited to such actions as recommending against publication of an extension or denying the assignment of an IANA code point (e.g., when relevant IANA considerations guidelines apply). There is also the real possibility that the development of a poor extension will generate ill-will in the IETF community, which can greatly complicate subsequent attempts by the offending group to carry out future work in the IETF, whether directly related to the particular extension or not. IETF protocols should not be designed to encourage the definition of major extensions outside the IETF process. IETF protocols should carefully analyze and identify which protocol components can be extended safely with minimal or no community review and which need community review, and then write appropriate IANA considerations sections that ensure the appropriate level of community review prior to the assignment of numbers. For example, the definition of additional data formats that can be carried may require no review, while the addition of new protocol message types might require a Standards Track action [IANA-CONSID]. draft-iesg-vendor-extensions-01.txt [Page 5]
INTERNET-DRAFT October 27, 2003 4. Examples This section discusses some specific examples, as it is not always immediately clear what constitutes a major extension. [note: to be completed, are the following good and representative of some of the debates that have been had?] 4.1. RADIUS Vendor-Specific Attributes 4.2. LDAP Schema Extensions 4.3. L2TP Extensions L2TP [L2TP] carries Attribute-Value Pairs (AVPs), with most AVPs having no semantics to the L2TP protocol itself. However, it should be noted that L2TP message types are identified by a Message Type AVP (Attribute Type 0) with specific AVP values indicating the actual message type. Thus, extensions relating to Message Type AVPs would likely be considered major extensions. L2TP also provides for Vendor-Specific AVPs. Because everything in L2TP is encoded using AVPs, it would be easy to define vendor- specific AVPs that would be considered major extensions. L2TP also provides for a "mandatory" bit in AVPs. Recipients of L2TP messages containing AVPs they do not understand but that have the mandatory bit set, are expected to reject the message and terminate the tunnel or session the message refers to. This leads to interesting interoperability issues, because a sender can include a vendor-specific AVP with the M-bit set, which then cause the recipient to not interoperate with the sender. This sort of behavior is counter to the IETF ideals, as implementations of the IETF standard should interoperate successfully with other implementations and not require the implementation of non-IETF extensions in order to interoperate successfully. Section 4.2 of the L2TP specification [L2TP] includes specific wording on this point, though there was significant debate at the time as to whether such language was by itself sufficient. Fortunately, it does not appear that the above concerns have been a problem in practice. At the time of this writing, the authors are unaware of the existance of vendor-specific AVPs that also set the M- bit. draft-iesg-vendor-extensions-01.txt [Page 6]
INTERNET-DRAFT October 27, 2003 5. IANA Considerations None. 6. Security Considerations Insufficiently reviewed extensions can easily lead to protocols with significant security vulnerabilities. In addition, a poorly designed extension can circumvent strong security features that the IETF designed into a protocol. 7. Acknowledgments The initial version of this document was put together by the IESG. 8. Informative References [IANA-CONSID] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Peter, "Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999. [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. 9. Editor's Addresses Scott Bradner Harvard University 29 Oxford St Cambridge MA 02138 USA Phone: +1 617-495-3864 EMail: sob@harvard.edu Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA draft-iesg-vendor-extensions-01.txt [Page 7]
INTERNET-DRAFT October 27, 2003 Phone: +1 919 254 7798 EMail: narten@us.ibm.com draft-iesg-vendor-extensions-01.txt [Page 8]
