INTERNET-DRAFT Scott O. Bradner <draft-iesg-vendor-extensions-02.txt> Harvard University Thomas Narten IBM June 4, 2004 Considerations on the Extensibility of IETF protocols <draft-iesg-vendor-extensions-02.txt> Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. 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. Experience with IETF protocols has shown that extensibility of protocols without IETF review can cause problems. The document also recommends that major extensions to IETF draft-iesg-vendor-extensions-02.txt [Page 1]
INTERNET-DRAFT June 4, 2004 protocols only take place through normal IETF processes or in coordination with the IETF. Contents Status of this Memo.......................................... 1 1. Introduction............................................. 2 2. Interoperability......................................... 3 3. Extensibility............................................ 4 3.1. Minor Extensions.................................... 5 3.2. Major Extensions.................................... 6 3.3. Classification of Major vs. Minor Extensions........ 6 4. Review of Proposed Protocol Extensions................... 7 5. Recommendation........................................... 7 6. Summary.................................................. 8 7. Examples................................................. 8 7.1. RADIUS Extensions................................... 9 7.2. RSVP Extensions..................................... 10 7.3. L2TP Extensions..................................... 10 8. IANA Considerations...................................... 11 9. Security Considerations.................................. 11 10. Acknowledgments......................................... 11 11. Informative References.................................. 11 12. Editor's Addresses...................................... 11 1. Introduction When developing protocols, IETF working groups typically include mechanisms whereby these protocols can be extended in the future. Vendors, standards development organizations and technology fora have used those facilities. Sometimes the result is a poorly designed mechanism and non-interoperability. It is of course a good principle to design extensiblity into protocols; one common definition of a successful protocol is one that draft-iesg-vendor-extensions-02.txt [Page 2]
INTERNET-DRAFT June 4, 2004 becomes widely used in ways not originally anticipated. Well-designed extensibility mechanisms facilitate the evolution of protocols and help make it easier to roll-out incremental changes in an interoperable fashion. At the same time, experience has shown that 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. 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. This memo makes 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, and that proposed extensions should be reviewed by subject-matter experts familiar with the protocol itself and how it is used in currently deployed systems. The IESG is presently applying some version of these principles in evaluating proposals for new extensions and in evaluating the extensibility of new protocols. 2. Interoperability The importance of extending protocols only in carefully thought-out ways is driven by the overall goal of acheiving good interoperability. Good interoperability stems from a number of factors, including: - having a well-written spec, that makes clear and precise what an implementor needs to implement and what impact each individual operation (e.g., a message sent to a peer) will have when invoked. However, while necessary, a well-written spec is not by itself sufficient to result in good interoperability. - learning lessons from deployment, including understanding what current implementations do and how a proposed extension will interact with deployed systems. - having an adequate transition story for deploying the new extension. What impact will the proposed extension have on implementations that do not understand it? Is there a way to negotiate or determine the capabilities of a peer? draft-iesg-vendor-extensions-02.txt [Page 3]
INTERNET-DRAFT June 4, 2004 - being archtitecturally compatable with the base protocol. For example, does the extension make use of features as envisioned by the original protocol designers, or is a new mechanism being invented? - respecting underlying architectural or security assumptions (including those that may not be well-documented, those that may have arison as a result of operational experience, or those that only became understood after the original protocol was published). - will the proposed extension (or its proposed usage) operationally stress existing implementations or the underlying protocol itself if widely deployed? - some protocols have become critical components of the Internet infrastructure. Does the proposed extension (or its proposed usage) have the potential for negatively impacting such infrastructure to the point where explicit steps would be appropriate to firewall existing uses from new ones? - does the proposed extension extend the data model in a major way? Does the extension fundamentally change basic assumptions about data handling within the protocol? For example, do the extensions reverse the flow of data, allow formerly static parameters to be changed on the fly, add new data types or change assumptions relating to the frequency of reads/writes? In practice, the only way to ensure that a proposed extension makes sense and will result in good interoperability is to have the extension reviewed by subject-matter experts familiar with the technology. Ideally, the document that defines a base protocol's extension mechanisms will include guidance to future extension writers that help them use extension mechanisms properly. It may also be possible to define classes of extensions that need little or no review, while other classes need wide review. The specific details will necessarily be technology-specific. 3. Extensibility The best defense against poorly thought-out extensions is review by subject matter experts. Such experts can identify potential problems early and suggest alternative approaches with fewer problems. To improve interoperability, such review must take place before significant deployment of an extension takes place. Once an extension draft-iesg-vendor-extensions-02.txt [Page 4]
INTERNET-DRAFT June 4, 2004 is deployed and in use, it becomes difficult or impossible to deprecate the extension or otherwise recall implementations. Protocols that permit easy extensions with minimal or no review, make it likely that unreviewed extensions will be deployed and used in practice. Consequently, protocols should not be made more extensible than clearly necessary at inception, and the process for defining new extensibility mechanisms must ensure that adequate review of proposed extensions will take place before widespread adoption. In practice, this means First Come First Served [IANA-CONSID] and similar policies should be used very carefully, as they imply minimal or no review. 3.1. Minor Extensions The amount and type of review necessary for a proposed extension can vary considerably. For example, many protocols are designed to carry opaque data, without examining or acting on the data at all. For example, DHCP [DHC] transports options, but the contents of an individual option is 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. A new extension may be nothing more than having an existing protocol carry a different kind of opaque data. In such cases, minimal review may be adequate.. For the purposes of this document, we call such extensions "Minor Extensions". Important points to note about Minor 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. Moreover, no changes are required to existing and currently deployed implementations of the underlying protocol 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]. In order to increase the likelyhood that minor extensions are truly minor, protocol documents should provide guidelines explaining how draft-iesg-vendor-extensions-02.txt [Page 5]
INTERNET-DRAFT June 4, 2004 they should be done. For example, even though DHCP carries opaque data, defining a new option using completely unstructured data may lead to an option that is (unnecessarily) hard for clients and servers to process. In contrast, using widely-supported encoding formats leads to better interoperability [XXX need ref]. Similarly, SNMP MIB guidelines exist for defining the MIB objects that SNMP carries [MIB-GUIDELINES]. 3.2. Major Extensions Some extensions change the protocol itself (e.g, the bits-on-the- wire), change the interpretation of previously defined Protocol Data Units (PDUs), or require protocol-specific changes in the client, server, or other intermediate nodes. Such changes can be both subtle and significant, and generally warrant careful review. Examples here would include new protocol message types. For the purposes of this document, we call such extensions Major Extensions. 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 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. 3.3. Classification of Major vs. Minor Extensions 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 draft-iesg-vendor-extensions-02.txt [Page 6]
INTERNET-DRAFT June 4, 2004 opaque data, whether a proposed usage qualifies as a major extension may involve considerable debate. For example, RADIUS is designed to carry AVPs and allow definition of new AVPs. 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. 4. Review of Proposed Protocol Extensions Major extensions to IETF protocols 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. 5. 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. o Protocols should include IANA considerations section that ensure that protocol code point assignments that are needed to deploy extensions are not made until after a proposed extension has received adequate review. Ideally, extensions should be done by IETF working groups using 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 be able to claim (or create the appearance) that the extensions are part of the IETF protocol. It should also be noted that the second bullet above leads to the possibility of a denial-of-service issue, as it implies that any draft-iesg-vendor-extensions-02.txt [Page 7]
INTERNET-DRAFT June 4, 2004 major extension must be done within or reviewed by the IETF, and that the IETF is required to take on all such work. In practice, 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. 6. Summary IETF protocols should not be designed to encourage the definition of major extensions outside the IETF process. Documents defining 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]. 7. 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 draft-iesg-vendor-extensions-02.txt [Page 8]
INTERNET-DRAFT June 4, 2004 some of the debates that have been had?] 7.1. RADIUS Extensions The RADIUS [RFC2865] protocol was designed to be extensible via addition of Attributes to a Data Dictionary on the server, without requiring code changes. However, this extensibility model assumed that Attributes would conform to a limited set of data types and that vendor extensionns would be limited to use by vendors in situations in which interoperability was not required. Recent developments have stretched those assumptions. [RFC2865] Section 6.2 defines a mechanism for Vendor-Specific extensions (Attribute 26), and states that use: "... 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." However, in practice usage of Vendor-Specific Attributes (VSAs) has been considerably broader than this; in particular, VSAs have been used by SDOs to define their extensions to the RADIUS protocol. This has caused a number of problems. Since the VSA mechanism was not designed for interoperability, VSAs do not contain a "mandatory" bit. As a result, RADIUS clients and servers may not know whether it is safe to ignore unknown attributes. For example, [RFC2865] Section 5 states: "A RADIUS server MAY ignore Attributes with an unknown Type. A RADIUS client MAY ignore Attributes with an unknown Type." However, in the case where the VSAs pertain to security (e.g. Filters) it may not be safe to ignore them, since [RFC2865] also states: "A NAS that does not implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a NAS that is unable to offer ARAP service MUST NOT implement the RADIUS attributes for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an unavailable service as an access-reject instead." Since it was not envisaged that multi-vendor VSA implementations would need to interoperate, [RFC2865] does not define the data model for VSAs, and allows multiple subattributes to be included within a single Attribute of type 26. However, this enables VSAs to be defined which would not be supportable by current implementations if placed within the standard RADIUS attribute space. This has caused draft-iesg-vendor-extensions-02.txt [Page 9]
INTERNET-DRAFT June 4, 2004 problems in standardizing widely deployed VSAs. In addition to extending RADIUS by use of VSAs, SDOs have also defined new values of the Service-Type attribute in order to create new RADIUS commands. Since [RFC2865] defined Service-Type values as being allocated First Come, First Served (FCFS), this essentially enabled new RADIUS commands to be allocated without IETF review. This oversight has since been fixed in [RFC3575]. 7.2. RSVP Extensions 7.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-02.txt [Page 10]
INTERNET-DRAFT June 4, 2004 8. IANA Considerations None. 9. 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. 10. Acknowledgments The initial version of this document was put together by the IESG in 2002. Since then, it has been reworked in response to feedback from John Loughney, Henrik Levkowetz, Mark Townsley, Randy Bush, Bernard Aboba and others. 11. 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. [MIB-GUIDELINES] draft-ietf-ops-mib-review-guidelines-02.txt [RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial In User Service). B. Aboba. July 2003. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 12. Editor's Addresses Scott Bradner Harvard University 29 Oxford St draft-iesg-vendor-extensions-02.txt [Page 11]
INTERNET-DRAFT June 4, 2004 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 Phone: +1 919 254 7798 EMail: narten@us.ibm.com 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 draft-iesg-vendor-extensions-02.txt [Page 12]
INTERNET-DRAFT June 4, 2004 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). 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. draft-iesg-vendor-extensions-02.txt [Page 13]
