Network Working Group B. Carpenter (ed) Internet-Draft IBM Expires: September 1, 2007 March 6, 2007 Design considerations for protocol extensions draft-carpenter-extension-rocs-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 1, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document discusses issues related to the extensibility of Internet protocols, with a focus on the architectural design considerations involved. Concrete case study examples are included. It is intended to assist designers of both base protocols and extensions. Carpenter (ed) Expires September 1, 2007 [Page 1] Internet-Draft Design considerations for extensions February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 3 3. Specific Considerations for Robust Extensions . . . . . . . . 5 3.1. Checklist for Interoperability of Extensions . . . . . . . 5 3.2. Use of Registered Values . . . . . . . . . . . . . . . . . 6 3.3. When is an Extension Routine? . . . . . . . . . . . . . . 6 3.4. Specific Issues with Major Extensions . . . . . . . . . . 7 4. Considerations for the Base Protocol . . . . . . . . . . . . . 7 4.1. Version Numbers . . . . . . . . . . . . . . . . . . . . . 8 4.2. Reserved Fields . . . . . . . . . . . . . . . . . . . . . 8 4.3. Encoding Formats . . . . . . . . . . . . . . . . . . . . . 9 4.4. Avoiding Unnecessary Extensibility . . . . . . . . . . . . 9 4.5. Documenting Extensibility . . . . . . . . . . . . . . . . 9 5. Running Code Must Run Right . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. Change log [RFC Editor: please remove this section] . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 A.1. Already documented cases . . . . . . . . . . . . . . . . . 13 A.2. RADIUS Extensions . . . . . . . . . . . . . . . . . . . . 13 A.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . . 15 A.4. L2TP Extensions . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Carpenter (ed) Expires September 1, 2007 [Page 2] Internet-Draft Design considerations for extensions February 2007 1. Introduction For the origins of this draft, please see the Acknowledgements section. Authorship will be updated. When an initial protocol design is extended, there is always a risk of introducing interoperability defects, security defects, etc., along with the additional functionality. This risk is especially high if the extension is performed by a different team than the original designers, who may stray outside implicit design constraints or assumptions. This document aims to describe technical considerations for protocol extensions that will minimize such risks. Although written in general terms, it is largely aimed at people considering extending an IETF protocol. This document is intended to be technical. Formal procedures for extending IETF protocols are discussed in BCP 125 [RFC4775]. IETF protocols typically include mechanisms whereby they can be extended in the future. It is of course a good principle to design extensiblity into protocols; one common definition of a successful protocol is one that 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 suggests that extensibility features should be limited to what is clearly necessary when the protocol is developed and that any later extensions should be done carefully and with a full understanding of the base protocol, existing implementations, and current operational practice. This is hardly a recent concern. "TCP Extensions Considered Harmful" [RFC1263] was published in 1991. "Extend" or "extension" occurs in the title of more than 300 existing RFCs. Yet generic extension considerations have not been documented previously. This document is intended to to assist designers of both base protocols and extensions. A good extension design depends on a good base protocol. Although Section 3 is aimed principally at extension designers, and Section 4 at base protocol designers, readers are advised to study the whole document, since the two sets of considerations are closely linked. 2. Interoperability Global interoperability is a primary goal of IETF protocol design. Experience shows that software is often used outside the particular Carpenter (ed) Expires September 1, 2007 [Page 3] Internet-Draft Design considerations for extensions February 2007 special environment it was originally intended for, so extensions cannot be designed for an isolated environment. Designers of extensions must assume the high likelihood of a system using the extension having to interoperate with systems on the global Internet. For this reason, an extension may lead to interoperability failures unless the extended protocol correctly supports all mandatory and optional features of the unextended base protocol, and implementations of the base protocol operate correctly in the presence of the extensions. Consider for example a "private" extension installed on a work computer which, being portable, is sometimes installed on a home network or in a hotel. If the "private" extension is incompatible with an unextended version of the same protocol, problems will occur. Another aspect is that that mechanisms included to allow the extension of protocols should not be used to create incompatible forks in development instead. Ideally, the protocol mechanisms for extension and versioning should be sufficiently well described that compatibility can be assessed on paper. Otherwise, when two "private" extensions encounter each other on a public network, unexpected interoperability problems may occur. An example of what might go wrong is misuse of the X- mail headers originally defined in SMTP [RFC0822]. X-anything was a valid mail header; but it had no defined meaning in the standard. Suppose a mail implementation assigns specifc semantics to X-anything that causes it to take specific action, such as discarding a message as spam. If it encounters a message from a different implementation that assigns different semantics, it may take quite inappropriate action, such as discarding a valid message. Thus, relying on the implied semantics of an X- header automatically creates a risk of operational failures. X- headers were removed from [RFC2822]. Even when they are assigned semantics, as in [RFC4356], great care must be taken that implementations do not rely on such semantics in messages that have crossed the open Internet. Thus we observe that a key requirement for interoperable extension design is that the base protocol must be well designed for interoperability, and that extensions must have unambiguous semantics. Additionally, it should be noted that protocol variations - specifications that look very similar to the original but are actually different - are even more harmful to interoperability than extensions. In general, such variations should be avoided. If they cannot be avoided, as many of the following considerations as possible should be applied, to minimize the damage to Carpenter (ed) Expires September 1, 2007 [Page 4] Internet-Draft Design considerations for extensions February 2007 interoperability. 3. Specific Considerations for Robust Extensions This section makes explicit some design considerations based on the community's experience with extensibility mechanisms. 3.1. Checklist for Interoperability of Extensions Good interoperability stems from a number of factors, including: 1. 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. 2. learning lessons from deployment, including understanding what current implementations do and how a proposed extension will interact with deployed systems. 3. having an adequate transition or coexistence 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? 4. being architecturally compatible 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? 5. 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). 6. will the proposed extension (or its proposed usage) operationally stress existing implementations or the underlying protocol itself if widely deployed? 7. 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 isolate existing uses from new ones? 8. 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? 9. can the extended protocol negotiate with an unextended partner to find a common subset of useful functions? Carpenter (ed) Expires September 1, 2007 [Page 5] Internet-Draft Design considerations for extensions February 2007 3.2. Use of Registered Values An extension is often likely to make use of additional values added to an existing IANA registry (in many cases, simply by adding a new "TLV" (type-length-value) field). To avoid conflicting usage of the same value, it is essential that all new values are properly registered by the applicable procedures. See BCP 26, [RFC2434] for the general rules, and individual protocol RFCs, and the IANA web site, for specfic rules and registries. If this is not done, there is nothing to prevent two different extensions picking the same value. When these two extensions "meet" each other on the Internet, failure is inevitable. A surprisingly common case of this is misappropriation of assigned TCP (or UDP) registered port numbers. This can lead to a client for one service attempting to communicate with a server for another service. Numerous cases could be cited, but not without embarassing specific implementors. In some cases, it may be appropriate to use values designated as "experimental" or "local use" in early implementations of an extension. For example, [RFC4727] discusses experimental values for IP and transport headers, and [RFC2474] defines experimental/local use ranges for differentiated services code points. Such values should be used with care and only for their stated purpose: experiments and local use. They are unsuitable for Internet-wide use, since they may be used for conflicting purposes and thereby cause interoperability failures. Packets containing experimental or local use values must not be allowed out of the domain in which they are meaningful. 3.3. When is an Extension Routine? An extension may be considered relatively routine if it basically amounts to a new data element that is opaque to the protocol itself (i.e. does not substantially change the pattern of messages and responses). For this to apply, the protocol must have been designed to carry opaque data elements, so that 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. Using the existing protocol to carry a new type of opaque data should not impact existing implementations or cause operational problems. Typically this means that the protocol is specified to silently discard unknown data elements. Carpenter (ed) Expires September 1, 2007 [Page 6] Internet-Draft Design considerations for extensions February 2007 Examples of routine extensions include the DHC vendor-specific option, the enterprise OID tree for MIB modules, vendor MIME types, and some classes of (non-critical) certification extensions. Such extensions can safely be made with minimal discussion and are usually indicated by having IANA Considerations that allow assignments of code points with minimal overhead (e.g., First Come First Served) [RFC2434]. 3.4. Specific Issues with Major Extensions Major extensions may have some or all of the following characteristics, each of which leads to a risk of interoperability failure: 1. 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 may 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. (Note that a base protocol without a "silent discard" rule for unknown data elements may automatically enter this category, even for apparently minor extensions.) 2. Change basic architectural assumptions about the protocol that have been an assumed part of the protocol and its implementations. For example, add a requirement for session state to a previously stateless protocol. 3. 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. A specific example would be a new DNS RR type that is too big to fit into a single UDP packet. Each of these leads directly to a need to pay extremely close attention to backward compatibility with implementations and deployments of the unextended protocol, and to the risk of inadvertent introduction of security or operational exposures. Extension designers should examine their design for the above three issues. 4. Considerations for the Base Protocol Ideally, the document that defines a base protocol's extension mechanisms will include guidance to future extension writers that Carpenter (ed) Expires September 1, 2007 [Page 7] Internet-Draft Design considerations for extensions February 2007 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 details will necessarily be technology-specific. 4.1. Version Numbers Any mechanism for extension by versioning must include provisions to ensure interoperability, or at least clean failure modes. Imagine someone creating a protocol and using a "version" field and populating it with a value (1, let's say), but giving no information about what would happen when a new version number appears in it. That's bad protocol design and description; it should be clear what the expectation is and how you test it. For example, stating that 1.X must be compatible with any version 1 code, but version 2 or greater is not expected to be compatible, has different implications than stating that version 1 must be a proper subset of version 2. An interesting example here is ROHC (Robust Header Compression). ROHCv1 [RFC3095] supports a certain set of compression algorithms. But experience has shown that these profiles have limitations, so the ROHC WG is developing ROHCv2. A ROHCv1 implementation will not contain code for the ROHCv2 profiles. As the ROHC WG charter says: ...It should be noted that the v2 profiles will thus not be compatible with the original (ROHCv1) profiles, which means less complex ROHC implementations can be realized by not providing support for ROHCv1 (over links not yet supporting ROHC, or by shifting out support for ROHCv1 in the long run). Profile support is agreed through the ROHC channel negotiation, which is part of the ROHC framework and thus not changed by ROHCv2. Thus in this case both backwards-compatible and backwards- incompatible deployments are possible. The important point is a clearly thought out approach to the question of operational compatibility. 4.2. Reserved Fields Protocols commonly include one or more "reserved" fields, clearly intended for future extensions. It is good practice to specify the value to be inserted in such a field by the sender (typically zero) and the action to be taken by the receiver when seeing some other value (typically no action). If this is not done, future implementation of new values in the reserved field may break old software. Similarly, protocols should carefully specify how receivers should react to unknown TLVs etc., such that failures occur only when that is truly the desired result. Carpenter (ed) Expires September 1, 2007 [Page 8] Internet-Draft Design considerations for extensions February 2007 4.3. Encoding Formats Using widely-supported encoding formats leads to better interoperability and easier extensibility. An excellent example is the SNMP SMI. Guidelines exist for defining the MIB objects that SNMP carries [RFC4181]. Also, multiple textual conventions have been published, so that MIB designers do not have to reinvent the wheel when they need a commonly encountered construct. For example, the "Textual Conventions for Internet Network Addresses" [RFC4001] can be used by any MIB designer needing to define objects containing IP addresses, thus ensuring consistency as the body of MIBs is extended. 4.4. Avoiding Unnecessary Extensibility Protocols that permit easy extensions may have the perverse side effect of making it easy to construct incompatible extensions. Consequently, protocols should not be made more extensible than clearly necessary at inception, and the process for defining new extensibility mechanisms should ensure that adequate review of proposed extensions will take place before widespread adoption. In practice, this means First Come First Served [RFC2434] and similar policies that allow routine extensions should be used sparingly, as they imply minimal or no review. In particular, they should be limited to cases, such as allowing new opaque data elements, that are unlikely to cause protocol failures. In order to increase the likelihood that routine extensions are truly routine, protocol documents should provide guidelines explaining how they should be performed. 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. 4.5. Documenting Extensibility Some protocol components are designed with the specific intention of allowing extensibility. These should be clearly identified, with specific and complete instructions on how to extend them, including the process for adequate review of extension proposals: do they need community review and if so how much and by whom? For example, the definition of additional data formats that can be carried opaquely may require no review, while the addition of new protocol message types might require a Standards Track action. Guidance on writing appropriate IANA Considerations text may be found in [RFC2434]. In a number of cases, there is a need for explicit guidance relating to extensions beyond what is encapsulated in the IANA considerations section of the base specification. The usefulness of [RFC4181] would Carpenter (ed) Expires September 1, 2007 [Page 9] Internet-Draft Design considerations for extensions February 2007 appear to suggest that protocols whose data model is likely to be widely extended (particularly using vendor-specific elements) need a Design Guidelines document specifically addressing extensions. 5. Running Code Must Run Right Experience shows that it is insufficient to correctly specify extensibility and backwards compatibility in an RFC. It is also of importance that every implementation must fully respect the compatibility mechanisms; if not, non-interoperable pairs of implementations may arise. The TLS case study below shows how important this may be. 6. Security Considerations An extension must not introduce new security risks without also providing adequate counter-measures, and in particular it must not inadvertently defeat security measures in the unextended protocol. Thus, the security analysis for an extension needs to be as thorough as for the original protocol - effectively it needs to be a regression analysis to check that the extension doesn't inadvertently invalidate the original security model. This analysis may be simple (e.g. adding an extra opaque data element is unlikely to create a new risk) or quite complex (e.g. adding a handshake to a previously stateless protocol may create a completely new opportunity for an attacker). 7. IANA Considerations This draft requires no action by IANA. 8. Acknowledgements This document is heavily based on an earlier draft under a different title by Scott Bradner and Thomas Narten. That draft stated: 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. Valuable comments and suggestions on the current form of the document were made by Jari Arkko, Ted Hardie, Loa Andersson, Eric Rescorla, Carpenter (ed) Expires September 1, 2007 [Page 10] Internet-Draft Design considerations for extensions February 2007 Bernard Aboba, Pekka Savola, Leslie Daigle... The text on TLS experience was contributed by Yngve Pettersen. This document was produced using the xml2rfc tool [RFC2629]. 9. Change log [RFC Editor: please remove this section] draft-carpenter-extension-recs-01: 2007-02-22. Updated according to comments, especially the wording about TLS, added various specific examples. draft-carpenter-extension-recs-00: original version, 2006-10-12. Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by focussing on architectural issues; the more procedural issues in that draft were moved to RFC 4775. 10. References 10.1. Normative References [RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. Carpenter (ed) Expires September 1, 2007 [Page 11] Internet-Draft Design considerations for extensions February 2007 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002. [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005. [RFC4356] Gellens, R., "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail", RFC 4356, January 2006. [RFC4521] Zeilenga, K., "Considerations for Lightweight Directory Access Protocol (LDAP) Extensions", BCP 118, RFC 4521, June 2006. [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. [RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures for Protocol Extensions and Variations", BCP 125, RFC 4775, December 2006. 10.2. Informative References [I-D.andersson-rtg-gmpls-change] Andersson, L. and A. Farrel, "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", draft-andersson-rtg-gmpls-change-07 (work in progress), November 2006. [RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered Harmful", RFC 1263, October 1991. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, Carpenter (ed) Expires September 1, 2007 [Page 12] Internet-Draft Design considerations for extensions February 2007 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003. [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible Provisioning Protocol (EPP)", RFC 3735, March 2004. [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", RFC 4485, May 2006. Appendix A. Examples This section discusses some specific examples, as case studies. A.1. Already documented cases There are certain documents that specify a change process or describe extension considerations for specific IETF protocols: The SIP change process [RFC3427], [RFC4485] The (G)MPLS change process (mainly procedural) [I-D.andersson-rtg-gmpls-change] LDAP extensions[RFC4521] EPP extensions[RFC3735] DNS extensions[RFC2671] It is relatively common for MIBs, which are all in effect extensions of the SMI data model, to be defined or extended outside the IETF. BCP 111 [RFC4181] offers detailed guidance for authors and reviewers. A.2. 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. Subsequent developments have stretched those assumptions. Carpenter (ed) Expires September 1, 2007 [Page 13] Internet-Draft Design considerations for extensions February 2007 [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 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]. Carpenter (ed) Expires September 1, 2007 [Page 14] Internet-Draft Design considerations for extensions February 2007 A.3. TLS Extensions The Secure Sockets Layer (SSL) v2 protocol was developed by Netscape to be used to secure online transactions on the Internet. It was later replaced by SSL v3, also developed by Netscape. SSL v3 was then further developed by the IETF as the Transport Layer Security (TLS) protocol. The SSL v3 protocol was not explictly specified to be extended. Even TLS 1.0 did not define an extension mechanism explicitly. However, extension "loopholes" were available. Extension mechanisms were finally defined in [RFC3546]: o New versions o New cipher suites o Compression o Expanded handshake messages o New record types o New handshake messages The protocol also defines how implementations should handle unknown extensions. Of the above extension methods, new versions and expanded handshake messages have caused the most interoperability problems. Implementations are supposed to ignore unknown record types but to reject unknown handshake messages. The new version support in SSL/TLS includes a capability to define new versions of the protocol, while allowing newer implementations to communicate with older implementations. As part of this functionality some Key Exchange methods include functionality to prevent version rollback attacks. The experience with this upgrade functionality in SSL and TLS is decidedly mixed. o SSL v2 and SSL v3/TLS are not compatible. It is possible to use SSL v2 protocol messages to intiate a SSL v3/TLS connection, but it is not possible to communicate with a SSL v2 implementation using SSL v3/TLS protocol messages. o There are implementations that refuse to accept handshakes using newer versions of the protocol than they support. o There are other implementations that accept newer versions, but have implemented the version rollback protection clumsily. The SSL v2 problem has forced clients to use SSL v3 and TLS clients to continue to use SSL v2 Client Hellos for their initial handshake with almost all servers until 2006, much longer than would have been desirable, in order to interoperate with old servers. Carpenter (ed) Expires September 1, 2007 [Page 15] Internet-Draft Design considerations for extensions February 2007 The problem with incorrect handling of newer versions has also forced many clients to actually disable the newer protocol versions, either by default, or by automatically disabling the functionality, to be able to connect to such servers. Effectively, this means that the version rollback protection in SSL and TLS is non-existent if talking to a fatally compromised older version. SSL v3 and TLS also permitted expansion of the Client Hello and Server Hello handshake messages. This functionality was fully defined by the introduction of TLS Extensions, which makes it possible to add new functionality to the handshake, such as the name of the server the client is connecting to, request certificate status information, indicate Certificate Authority support, maximum record length, etc. Several of these extensions also introduces new handshake messages. It has turned out that many SSL v3 and TLS implementations that do not support TLS Extensions, did not, as specified in the protocols, ignore the unknown extensions, but instead failed to establish connections. Several of the implementations behaving in this manner are used by high profile Internet sites, such as online banking sites, and this has caused a significant delay in the deployment of clients supporting TLS Extensions, and several of the clients that have enabled support are using heuristics that allow them to disable the functionality when they detect a problem. Looking forward, the protocol version problem, in particular, can cause future security problems for the TLS protocol. The strength of the Digest algorithms (MD5 and SHA-1) used by SSL and and TLS is weakening, and work is underway to define TLS 1.2 which will permit new methods to be used in the protocol instead of the currently used methods. If MD5 and SHA-1 weaken to the point where it is feasible to mount successful attacks against older SSL and TLS versions, the current error recovery used by clients would become a security vulnerability (among many other serious problems for the Internet). The lesson to be drawn from this experience is that it isn't sufficient to design extensibility carefully; it must also be implemented carefully by every implementer, without exception. A.4. L2TP Extensions L2TP [RFC2661] 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 Carpenter (ed) Expires September 1, 2007 [Page 16] Internet-Draft Design considerations for extensions February 2007 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 [RFC2661] 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. Author's Address Brian Carpenter (ed) IBM 8 Chemin de Blandonnet 1214 Vernier, Switzerland Email: brc@zurich.ibm.com Carpenter (ed) Expires September 1, 2007 [Page 17] Internet-Draft Design considerations for extensions February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Carpenter (ed) Expires September 1, 2007 [Page 18]