diff options
Diffstat (limited to 'doc/rfc/rfc6709.txt')
| -rw-r--r-- | doc/rfc/rfc6709.txt | 2355 |
1 files changed, 2355 insertions, 0 deletions
diff --git a/doc/rfc/rfc6709.txt b/doc/rfc/rfc6709.txt new file mode 100644 index 0000000..a9d51bf --- /dev/null +++ b/doc/rfc/rfc6709.txt @@ -0,0 +1,2355 @@ + + + + + + +Internet Architecture Board (IAB) B. Carpenter +Request for Comments: 6709 B. Aboba, Ed. +Category: Informational S. Cheshire +ISSN: 2070-1721 September 2012 + + + Design Considerations for Protocol Extensions + +Abstract + + This document discusses architectural issues related to the + extensibility of Internet protocols, with a focus on design + considerations. It is intended to assist designers of both base + protocols and extensions. Case studies are included. A companion + document, RFC 4775 (BCP 125), discusses procedures relating to the + extensibility of IETF protocols. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Architecture Board (IAB) + and represents information that the IAB has deemed valuable to + provide for permanent record. It represents the consensus of the + Internet Architecture Board (IAB). Documents approved for + publication by the IAB are not a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6709. + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + + + + + + + +Carpenter, et al. Informational [Page 1] + +RFC 6709 Design Considerations for Extensions September 2012 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Requirements Language ......................................4 + 2. Routine and Major Extensions ....................................4 + 2.1. What Constitutes a Major Extension? ........................4 + 2.2. When is an Extension Routine? ..............................6 + 3. Architectural Principles ........................................7 + 3.1. Limited Extensibility ......................................7 + 3.2. Design for Global Interoperability .........................8 + 3.3. Architectural Compatibility ...............................12 + 3.4. Protocol Variations .......................................13 + 3.5. Testability ...............................................16 + 3.6. Protocol Parameter Registration ...........................16 + 3.7. Extensions to Critical Protocols ..........................17 + 4. Considerations for the Base Protocol ...........................18 + 4.1. Version Numbers ...........................................19 + 4.2. Reserved Fields ...........................................22 + 4.3. Encoding Formats ..........................................23 + 4.4. Parameter Space Design ....................................23 + 4.5. Cryptographic Agility .....................................26 + 4.6. Transport .................................................27 + 4.7. Handling of Unknown Extensions ............................28 + 5. Security Considerations ........................................29 + 6. References .....................................................30 + 6.1. Normative References ......................................30 + 6.2. Informative References ....................................30 + 7. Acknowledgments ................................................35 + 8. IAB Members at the Time of Approval ............................35 + Appendix A. Examples .............................................36 + A.1. Already-Documented Cases ..................................36 + A.2. RADIUS Extensions .........................................36 + A.3. TLS Extensions ............................................39 + A.4. L2TP Extensions ...........................................41 + + + + + + + + + + + + + + + + + +Carpenter, et al. Informational [Page 2] + +RFC 6709 Design Considerations for Extensions September 2012 + + +1. Introduction + + When developing protocols, IETF Working Groups (WGs) often include + mechanisms whereby these protocols can be extended in the future. It + is often a good principle to design extensibility into protocols; as + described in "What Makes for a Successful Protocol" [RFC5218], a + "wildly 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. However, at the + same time, experience has shown that extensions carry the risk of + unintended consequences, such as interoperability issues, operational + problems, or security vulnerabilities. + + The proliferation of extensions, even well-designed ones, can be + costly. As noted in "Simple Mail Transfer Protocol" [RFC5321] + Section 2.2.1: + + Experience with many protocols has shown that protocols with few + options tend towards ubiquity, whereas protocols with many options + tend towards obscurity. + + Each and every extension, regardless of its benefits, must be + carefully scrutinized with respect to its implementation, + deployment, and interoperability costs. + + 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 400 existing Request for Comments (RFC) + documents. Yet, generic extension considerations have not been + documented previously. + + The purpose of this document is to describe the architectural + principles of sound extensibility design, in order to minimize such + risks. Formal procedures for extending IETF protocols are discussed + in "Procedures for Protocol Extensions and Variations" BCP 125 + [RFC4775]. + + The rest of this document is organized as follows: Section 2 + discusses routine and major extensions. Section 3 describes + architectural principles for protocol extensibility. Section 4 + explains how designers of base protocols can take steps to anticipate + and facilitate the creation of such subsequent extensions in a safe + and reliable manner. Section 5 discusses security considerations. + Appendix A provides case studies. + + Readers are advised to study the whole document, since the + considerations are closely linked. + + + +Carpenter, et al. Informational [Page 3] + +RFC 6709 Design Considerations for Extensions September 2012 + + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in "Key words for use in + RFCs to Indicate Requirement Levels" BCP 14 [RFC2119]. + +2. Routine and Major Extensions + + The risk of unintended consequences from an extension 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. As a result, it is highly desirable for the original + designers to articulate the design constraints and assumptions, so as + to enable extensions to be done carefully and with a full + understanding of the base protocol, existing implementations, and + current operational practice. + + To assist extension designers and reviewers, protocol documents + should provide guidelines explaining how extensions should be + performed, and guidance on how protocol extension mechanisms should + be used. + + Protocol components that are designed with the specific intention of + allowing extensibility should be clearly identified, with specific + and complete instructions on how to extend them. This includes the + process for adequate review of extension proposals: do they need + community review, and if so, how much and by whom? + + The level of review required for protocol extensions will typically + vary based on the nature of the extension. Routine extensions may + require minimal review, while major extensions may require wide + review. Guidance on which extensions may be considered 'routine' and + which ones are 'major' is provided in the sections that follow. + +2.1. What Constitutes a Major Extension? + + Major extensions may have characteristics leading to a risk of + interoperability failures, security vulnerabilities, or operational + problems. Where these characteristics are present, it is necessary + to pay close attention to backward compatibility with implementations + and deployments of the unextended protocol and to the potential for + inadvertent introduction of security or operational exposures. + + + + + + + + +Carpenter, et al. Informational [Page 4] + +RFC 6709 Design Considerations for Extensions September 2012 + + + Extension designers should examine their design for the following + issues: + + 1. Modifications or extensions to the underlying protocol. An + extension document should be considered to update the underlying + protocol specification if an implementation of the underlying + protocol would need to be updated to accommodate the extension. + This should not be necessary if the underlying protocol was + designed with a modular interface. Examples of extensions + modifying the underlying protocol include specification of + additional transports (see Section 4.6), changing protocol + semantics, or defining new message types that may require + implementation changes in existing and deployed implementations + of the protocol, even if they do not want to make use of the new + functions. A base protocol that does not uniformly permit + "silent discard" of unknown extensions may automatically enter + this category, even for apparently minor extensions. Handling of + "unknown" extensions is discussed in more detail in Section 4.7. + + 2. Changes to the basic architectural assumptions. This may include + architectural assumptions that are explicitly stated or those + that have been assumed by implementers. For example, this would + include adding a requirement for session state to a previously + stateless protocol. + + 3. New usage scenarios not originally intended or investigated. + This can potentially lead to operational difficulties when + deployed, even in cases where the "on-the-wire" format has not + changed. For example, the level of traffic carried by the + protocol may increase substantially, packet sizes may increase, + and implementation algorithms that are widely deployed may not + scale sufficiently or otherwise be up to the new task at hand. + For example, a new DNS Resource Record (RR) type that is too big + to fit into a single UDP packet could cause interoperability + problems with existing DNS clients and servers. Similarly, the + additional traffic that results from an extension to a routing + protocol could have a detrimental impact on the performance or + stability of implementations that do not implement the extension. + + 4. Changes to the extension model. Adverse impacts are very likely + if the base protocol contains an extension mechanism and the + proposed extension does not fit into the model used to create and + define that mechanism. Extensions that have the same properties + as those that were anticipated when an extension mechanism was + devised are much less likely to be disruptive than extensions + that don't fit the model. Also, changes to the extension model + itself (including changes limiting further extensibility) can + create interoperability problems. + + + +Carpenter, et al. Informational [Page 5] + +RFC 6709 Design Considerations for Extensions September 2012 + + + 5. Changes to protocol syntax. Changes to protocol syntax bring + with them the potential for backward-compatibility issues. If at + all possible, extensions should be designed for compatibility + with existing syntax, so as to avoid interoperability failures. + + 6. Interrelated extensions to multiple protocols. A set of + interrelated extensions to multiple protocols typically carries a + greater danger of interoperability issues or incompatibilities + than a simple extension. Consequently, it is important that such + proposals receive earlier and more in-depth review than unitary + extensions. + + 7. Changes to the security model. Changes to the protocol security + model (or even addition of new security mechanisms within an + existing framework) can introduce security vulnerabilities or + adversely impact operations. Consequently, it is important that + such proposals undergo security as well as operational review. + Security considerations are discussed in Section 5. + + 8. Performance impact. An extension that impacts performance can + have adverse consequences, particularly if the performance of + existing deployments is affected. + +2.2. When is an Extension Routine? + + An extension may be considered 'routine' if it does not meet the + criteria for being considered a 'major' extension and if its handling + is opaque to the protocol itself (e.g., does not substantially change + the pattern of messages and responses). For this to apply, no + changes to the base protocol can be required, nor can changes be + required to existing and currently deployed implementations, unless + they make use of the extension. Furthermore, existing + implementations should not be impacted. This typically requires that + implementations be able to ignore 'routine' extensions without ill + effects. + + Examples of routine extensions include the Dynamic Host Configuration + Protocol (DHCP) vendor-specific option [RFC2132], Remote + Authentication Dial In User Service (RADIUS) Vendor-Specific + Attributes [RFC2865], the enterprise Object IDentifier (OID) tree for + Management Information Base (MIB) modules, and vendor Multipurpose + Internet Mail Extension (MIME) types. Such extensions can safely be + made with minimal discussion. + + + + + + + + +Carpenter, et al. Informational [Page 6] + +RFC 6709 Design Considerations for Extensions September 2012 + + + Processes that allow routine extensions with minimal or no review + (such as "First Come First Served" (FCFS) allocation [RFC5226]) + should be used sparingly. In particular, they should be limited to + cases that are unlikely to result in interoperability problems or in + security or operational exposures. + + Experience has shown that even routine extensions may benefit from + review by experts. 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. + +3. Architectural Principles + + This section describes basic principles of protocol extensibility: + + 1. Extensibility features should be limited to what is reasonably + anticipated when the protocol is developed. + + 2. Protocol extensions should be designed for global + interoperability. + + 3. Protocol extensions should be architecturally compatible with the + base protocol. + + 4. Protocol extension mechanisms should not be used to create + incompatible protocol variations. + + 5. Extension mechanisms need to be testable. + + 6. Protocol parameter assignments need to be coordinated to avoid + potential conflicts. + + 7. Extensions to critical components require special care. A + critical component is one whose failure can lead to Internet-wide + reliability and security issues or performance degradation. + +3.1. Limited Extensibility + + Protocols should not be made more extensible than clearly necessary + at inception, in order to enable optimization along dimensions (e.g., + bandwidth, state, memory requirements, deployment time, latency, + etc.) important to the most common use cases. + + The process for defining new extensibility mechanisms should ensure + that adequate review of proposed extensions will take place before + widespread adoption. + + + + +Carpenter, et al. Informational [Page 7] + +RFC 6709 Design Considerations for Extensions September 2012 + + + As noted in "What Makes for a Successful Protocol" [RFC5218], "wildly + successful" protocols far exceed their original goals, in terms of + scale, purpose (being used in scenarios far beyond the initial + design), or both. This implies that all potential uses may not be + known at inception. As a result, extensibility mechanisms may need + to be revisited as additional use cases reveal themselves. However, + this does not imply that an initial design needs to take all + potential needs into account at inception. + +3.2. Design for Global Interoperability + + Section 3.1 of "Procedures for Protocol Extensions and Variations" + BCP 125 [RFC4775] notes: + + According to its Mission Statement [RFC3935], the IETF produces + high quality, relevant technical and engineering documents, + including protocol standards. The mission statement goes on to + say that the benefit of these standards to the Internet "is in + interoperability - that multiple products implementing a standard + are able to work together in order to deliver valuable functions + to the Internet's users". + + One consequence of this mission is that the IETF designs protocols + for the single Internet. The IETF expects its protocols to work + the same everywhere. Protocol extensions designed for limited + environments may be reasonable provided that products with these + extensions interoperate with products without the extensions. + Extensions that break interoperability are unacceptable when + products with and without the extension are mixed. It is the + IETF's experience that this tends to happen on the Internet even + when the original designers of the extension did not expect this + to happen. + + Another consequence of this definition of interoperability is that + the IETF values the ability to exchange one product implementing a + protocol with another. The IETF often specifies mandatory-to- + implement functionality as part of its protocols so that there is + a core set of functionality sufficient for interoperability that + all products implement. The IETF tries to avoid situations where + protocols need to be profiled to specify which optional features + are required for a given environment, because doing so harms + interoperability on the Internet as a whole. + + Since the global Internet is more than a collection of incompatible + protocols (or "profiles") for use in separate private networks, + implementers supporting extensions in shipping products or multi-site + experimental usage must assume that systems will need to interoperate + on the global Internet. + + + +Carpenter, et al. Informational [Page 8] + +RFC 6709 Design Considerations for Extensions September 2012 + + + 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. Ideally, the protocol + mechanisms for extension and versioning should be sufficiently well + described that compatibility can be assessed on paper. Otherwise, + when two "private" or "experimental" extensions encounter each other + on a public network, unexpected interoperability problems may occur. + However, as noted in the Transport Layer Security (TLS) case study + (Appendix A.3), it is not sufficient to design extensibility + carefully; it also must be implemented carefully. + +3.2.1. Private Extensions + + Experience shows that separate private networks often end up having + portable equipment like laptop computers move between them, and + networks that were originally envisaged as being separate can end up + being connected later. + + Consider a "private" extension installed on a work computer that, + being portable, is sometimes connected to networks other than the + work network, like a home network or a hotel network. If the + "private" extension is incompatible with an unextended version of the + same protocol, problems will occur. + + Similarly, problems can occur if "private" extensions conflict with + each other. For example, imagine the situation where one site chose + to use DHCP [RFC2132] option code 62 for one meaning and a different + site chose to use DHCP option code 62 for a completely different, + incompatible, meaning. It may be impossible for a vendor of portable + computing devices to make a device that works correctly in both + environments. + + One approach to solving this problem has been to reserve parts of an + identifier namespace for "limited applicability" or "site-specific" + use, such as "X-" headers in email messages [RFC822] or "P-" headers + in SIP [RFC3427]. However, as noted in "Deprecating the "X-" Prefix + and Similar Constructs in Application Protocols" [RFC6648], Appendix + B: + + The primary problem with the "X-" convention is that + unstandardized parameters have a tendency to leak into the + protected space of standardized parameters, thus introducing the + need for migration from the "X-" name to a standardized name. + Migration, in turn, introduces interoperability issues (and + sometimes security issues) because older implementations will + support only the "X-" name and newer implementations might support + only the standardized name. To preserve interoperability, newer + implementations simply support the "X-" name forever, which means + + + +Carpenter, et al. Informational [Page 9] + +RFC 6709 Design Considerations for Extensions September 2012 + + + that the unstandardized name has become a de facto standard (thus + obviating the need for segregation of the name space into + standardized and unstandardized areas in the first place). + + As a result, the notion of "X-" headers from the 1982 Internet + Message Format standard [RFC822] was removed when the specification + was updated in 2001 [RFC2822]. Within SIP, the guidance published in + 2002 regarding "P-" headers [RFC3427] was deprecated eight years + later in Section 4 of the 2010 update [RFC5727]. More generally, as + noted in Section 1 of the "X-" prefix deprecation document [RFC6648]: + + This document generalizes from the experience of the email and SIP + communities by doing the following: + + 1. Deprecates the "X-" convention for newly defined parameters in + application protocols, including new parameters for + established protocols. This change applies even where the + "X-" convention was only implicit, and not explicitly + provided, such as was done for email in [RFC822]. + +3.2.2. Local Use + + Values designated as "experimental" or "local use" are only + appropriate in limited circumstances such as in early implementations + of an extension restricted to a single site. + + For example, "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, + and TCP Headers" [RFC4727] discusses experimental values for IP and + transport headers, and "Definition of the Differentiated Services + Field (DS Field) in the IPv4 and IPv6 Headers" [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. + + Section 1 of "Assigning Experimental and Testing Numbers Considered + Useful" BCP 82 [RFC3692] provides guidance on the use of experimental + code points: + + Numbers in the experimentation range ... are not intended to be + used in general deployments or be enabled by default in products + or other general releases. In those cases where a product or + release makes use of an experimental number, the end user must be + + + +Carpenter, et al. Informational [Page 10] + +RFC 6709 Design Considerations for Extensions September 2012 + + + required to explicitly enable the experimental feature and + likewise have the ability to chose and assign which number from + the experimental range will be used for a specific purpose (i.e., + so the end user can ensure that use of a particular number doesn't + conflict with other on-going uses). Shipping a product with a + specific value pre-enabled would be inappropriate and can lead to + interoperability problems when the chosen value collides with a + different usage, as it someday surely will. + + From the above, it follows that it would be inappropriate for a + group of vendors, a consortia, or another Standards Development + Organization to agree among themselves to use a particular value + for a specific purpose and then agree to deploy devices using + those values. By definition, experimental numbers are not + guaranteed to be unique in any environment other than one where + the local system administrator has chosen to use a particular + number for a particular purpose and can ensure that a particular + value is not already in use for some other purpose. + + Once an extension has been tested and shown to be useful, a + permanent number could be obtained through the normal assignment + procedures. + + However, as noted in Appendix B of the "X-" prefix deprecation + document [RFC6648], assigning a parameter block for experimental use + is only necessary when the parameter pool is limited: + + "Assigning Experimental and Testing Numbers Considered Useful" ... + implies that the "X-" prefix is also useful for experimental + parameters. However, BCP 82 addresses the need for protocol + numbers when the pool of such numbers is strictly limited (e.g., + DHCP options) or when a number is absolutely required even for + purely experimental purposes (e.g., the Protocol field of the IP + header). In almost all application protocols that make use of + protocol parameters (including email headers, media types, HTTP + headers, vCard parameters and properties, URNs, and LDAP field + names), the name space is not limited or constrained in any way, + so there is no need to assign a block of names for private use or + experimental purposes.... + + Therefore, it appears that segregating the parameter space into a + standardized area and a unstandardized area has few, if any, + benefits and has at least one significant cost in terms of + interoperability. + + + + + + + +Carpenter, et al. Informational [Page 11] + +RFC 6709 Design Considerations for Extensions September 2012 + + +3.2.3. Multi-Site Experiments + + Where an experiment is undertaken among a diverse set of experimental + sites connected via the global Internet, the use of "experimental" or + "local use" code points is inadvisable. This might include, for + example, sites that take a prototype implementation of some protocol + and use that both within their site but, importantly, among the full + set of other sites interested in that protocol. In such a situation, + it is impractical and probably impossible to coordinate the + de-confliction of "experimental" code points. Section 4.1 of the + IANA Considerations guidelines document [RFC5226] notes: + + For private or local use ... No attempt is made to prevent + multiple sites from using the same value in different (and + incompatible) ways.... assignments are not generally useful for + broad interoperability. It is the responsibility of the sites + making use of the Private Use range to ensure that no conflicts + occur (within the intended scope of use). + + The Host Identity Protocol (HIP) [RFC5201] and the Locator/ID + Separation Protocol [LISP] are examples where a set of experimental + sites are collaborating among themselves, but not necessarily in a + tightly coordinated way. Both HIP and LISP have dealt with this by + having unique non-experimental code points allocated to HIP and LISP, + respectively, at the time of publication of their respective + Experimental RFCs. + +3.3. Architectural Compatibility + + Since protocol extension mechanisms may impact interoperability, it + is important that they be architecturally compatible with the base + protocol. + + This includes understanding what current implementations do and how a + proposed extension will interact with deployed systems. Is it clear + when a proposed extension (or its proposed usage), if widely + deployed, will operationally stress existing implementations or the + underlying protocol itself? If this is not explained in the base + protocol specification, is this covered in an extension design + guidelines document? + + As part of the definition of a new extension, it is important to + address whether the extension makes use of features as envisaged by + the original protocol designers, or whether a new extension mechanism + is being invented. If a new extension mechanism is being invented, + then architectural compatibility issues need to be addressed. + + + + + +Carpenter, et al. Informational [Page 12] + +RFC 6709 Design Considerations for Extensions September 2012 + + + To assist in the assessment of architectural compatibility, protocol + documents should provide guidelines explaining how extensions should + be performed, and guidance on how protocol extension mechanisms + should be used. + + Protocol components that are designed with the specific intention of + allowing extensibility should be clearly identified, with specific + and complete instructions on how to extend them. This includes the + process for adequate review of extension proposals: do they need + community review, and if so, how much and by whom? + + Documents relying on extension mechanisms need to explicitly identify + the mechanisms being relied upon. For example, a document defining + new data elements should not implicitly define new data types or + protocol operations without explicitly describing those dependencies + and discussing their impact. Where extension guidelines are + available, mechanisms need to indicate whether they are compliant + with those guidelines and offer an explanation if they are not. + + Examples of documents describing extension guidelines include: + + 1. "Guidelines for Extending the Extensible Provisioning Protocol + (EPP)" [RFC3735], which provides guidelines for use of EPP's + extension mechanisms to define new features and object management + capabilities. + + 2. "Guidelines for Authors and Reviewers of MIB Documents" BCP 111 + [RFC4181], which provides guidance to protocol designers creating + new MIB modules. + + 3. "Guidelines for Authors of Extensions to the Session Initiation + Protocol (SIP)" [RFC4485], which outlines guidelines for authors + of SIP extensions. + + 4. "Considerations for Lightweight Directory Access Protocol (LDAP) + Extensions" BCP 118 [RFC4521], which discusses considerations for + designers of LDAP extensions. + + 5. "RADIUS Design Guidelines" BCP 158 [RFC6158], which provides + guidelines for the design of attributes used by the Remote + Authentication Dial In User Service (RADIUS) protocol. + +3.4. Protocol Variations + + Protocol variations -- specifications that look very similar to the + original but don't interoperate with each other or with the original + -- are even more harmful to interoperability than extensions. In + + + + +Carpenter, et al. Informational [Page 13] + +RFC 6709 Design Considerations for Extensions September 2012 + + + general, such variations should be avoided. Causes of protocol + variations include incompatible protocol extensions, uncoordinated + protocol development, and poorly designed "profiles". + + Designing a protocol for extensibility may have the perverse side + effect of making it easy to construct incompatible variations. + Protocol extension mechanisms should not be used to create + incompatible forks in development. 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. In addition, it is necessary for + an extension to interoperate with other extensions. + + As noted in Section 1 of "Uncoordinated Protocol Development + Considered Harmful" [RFC5704], incompatible forks in development can + result from the uncoordinated adaptation of a protocol, parameter, or + code point: + + In particular, the IAB considers it an essential principle of the + protocol development process that only one SDO maintains design + authority for a given protocol, with that SDO having ultimate + authority over the allocation of protocol parameter code-points + and over defining the intended semantics, interpretation, and + actions associated with those code-points. + + Note that problems can occur even when one Standards Development + Organization (SDO) maintains design authority, if protocol parameter + code points are reused. As an example, EAP-FAST [RFC5421][RFC5422] + reused previously assigned Extensible Authentication Protocol (EAP) + type codes. As described in the IESG note in the EAP-FAST document + [RFC5421]: + + The reuse of previously assigned EAP Type Codes is incompatible + with EAP method negotiation as defined in RFC 3748. + +3.4.1. Profiles + + Profiling is a common technique for improving interoperability within + a target environment or set of scenarios. Generally speaking, there + are two approaches to profiling: + + a) Removal or downgrading of normative requirements (thereby + creating potential interoperability problems). + + b) Elevation of normative requirement levels (such as from a + MAY/SHOULD to a MUST). This can be done in order to improve + interoperability by narrowing potential implementation choices + + + +Carpenter, et al. Informational [Page 14] + +RFC 6709 Design Considerations for Extensions September 2012 + + + (such as when the underlying protocol is ill-defined enough to + permit non-interoperable yet compliant implementations) or to + meet specific operational requirements (such as enabling use of + stronger cryptographic mechanisms than those mandated in the + specification). + + While approach a) is potentially harmful, approach b) may be + beneficial. + + In order to avoid interoperability problems when profiled + implementations interact with others over the global Internet, + profilers need to remain cognizant of the implications of removing + normative requirements. As noted in Section 6 of "Key words for use + in RFCs to Indicate Requirement Levels" [RFC2119], imperatives are to + be used with care, and as a result, their removal within a profile is + likely to result in serious consequences: + + Imperatives of the type defined in this memo must be used with + care and sparingly. In particular, they MUST only be used where + it is actually required for interoperation or to limit behavior + which has potential for causing harm (e.g., limiting + retransmissions) For example, they must not be used to try to + impose a particular method on implementors where the method is not + required for interoperability. + + As noted in Sections 3 and 4 of the Key Words document [RFC2119], + recommendations cannot be removed from profiles without serious + consideration: + + [T]here may exist valid reasons in particular circumstances to + ignore a particular item, but the full implications must be + understood and carefully weighed before choosing a different + course. + + Even the removal of optional features and requirements can have + consequences. As noted in Section 5 of the Key Words document + [RFC2119], implementations that do not support optional features + still retain the obligation to ensure interoperation with + implementations that do: + + An implementation which does not include a particular option MUST + be prepared to interoperate with another implementation which does + include the option, though perhaps with reduced functionality. In + the same vein an implementation which does include a particular + option MUST be prepared to interoperate with another + implementation which does not include the option (except, of + course, for the feature the option provides.) + + + + +Carpenter, et al. Informational [Page 15] + +RFC 6709 Design Considerations for Extensions September 2012 + + +3.5. Testability + + Experience has shown that it is insufficient merely to specify + extensibility and backward compatibility correctly in an RFC. It is + also important that implementations respect the compatibility + mechanisms; if not, non-interoperable pairs of implementations may + arise. The TLS case study (Appendix A.3) shows how important this + can be. + + In order to determine whether protocol extension mechanisms have been + properly implemented, testing is required. However, for this to be + possible, test cases need to be developed. If a base protocol + document specifies extension mechanisms but does not utilize them or + provide examples, it may not be possible to develop effective test + cases based on the base protocol specification alone. As a result, + base protocol implementations may not be properly tested, and non- + compliant extension behavior may not be detected until these + implementations are widely deployed. + + To encourage correct implementation of extension mechanisms, base + protocol specifications should clearly articulate the expected + behavior of extension mechanisms and should include examples of + correct extension behavior. + +3.6. Protocol Parameter Registration + + As noted in Section 3.2 of "Procedures for Protocol Extensions and + Variations" BCP 125 [RFC4775]: + + An extension is often likely to make use of additional values + added to an existing IANA registry.... It is essential that such + new values are properly registered by the applicable procedures, + including expert review where applicable.... Extensions may even + need to create new IANA registries in some cases. + + Experience shows that the importance of this is often + underestimated during extension design; designers sometimes assume + that a new codepoint is theirs for the asking, or even simply for + the taking. + + Before creating a new protocol parameter registry, existing + registries should be examined to determine whether one of them can be + used instead (see http://www.iana.org/protocols/). + + To avoid conflicting usage of the same registry value, as well as to + prevent potential difficulties in determining and transferring + parameter ownership, it is essential that all new values are + + + + +Carpenter, et al. Informational [Page 16] + +RFC 6709 Design Considerations for Extensions September 2012 + + + registered. 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 + Transmission Control Protocol (TCP) (or User Datagram Protocol (UDP)) + registered port numbers. This can lead to a client for one service + attempting to communicate with a server for another service. Another + common case is the use of unregistered URI schemes. Numerous cases + could be cited, but not without embarrassing specific implementers. + For general rules, see the IANA Considerations guidelines document + [RFC5226], and for specific rules and registries, see the individual + protocol specification RFCs and the IANA web site. + + While in theory a "Standards Track" or "IETF Consensus" parameter + allocation policy may be instituted to encourage protocol parameter + registration or to improve interoperability, in practice, problems + can arise if the procedures result in so much delay that requesters + give up and "self-allocate" by picking presumably unused code points. + Where self-allocation is prevalent, the information contained within + registries may become inaccurate, particularly when third parties are + prohibited from updating entries so as to improve accuracy. In these + situations, it is important to consider whether registration + processes need to be changed to support the role of a registry as + "documentation of how the Internet is operating". + +3.7. Extensions to Critical Protocols + + Some protocols (such as the Domain Name System (DNS), the Border + Gateway Protocol (BGP), and the Hypertext Transfer Protocol (HTTP)) + or algorithms (such as congestion control) have become critical + components of the Internet infrastructure. A critical component is + one whose failure can lead to Internet-wide reliability and security + issues or performance degradation. When such protocols or algorithms + are extended, the potential exists for negatively impacting the + reliability and security of the global Internet. + + As a result, special care needs to be taken with these extensions, + such as taking explicit steps to isolate existing uses from new ones. + For example, this can be accomplished by requiring the extension to + utilize a different port or multicast address or by implementing the + extension within a separate process, without access to the data and + control structures of the base protocol. + + Experience has shown that even when a mechanism has proven benign in + other uses, unforeseen issues may result when adding it to a critical + protocol. For example, both IS-IS and OSPF support opaque Link State + Advertisements (LSAs), which are propagated by intermediate nodes + + + +Carpenter, et al. Informational [Page 17] + +RFC 6709 Design Considerations for Extensions September 2012 + + + that don't understand the LSA. Within Interior Gateway Protocols + (IGPs), support for opaque LSAs has proven useful without introducing + instability. + + However, within BGP, "attribute tunneling" has resulted in large- + scale routing instabilities, since remote nodes may reset the LOCAL + session if the tunneled attributes are malformed or aren't + understood. This has required modification to BGP error handling, as + noted in "Revised Error Handling for BGP UPDATE Messages" + [ERROR-HANDLING]. + + In general, when extending protocols with local failure conditions, + tunneling of attributes that may trigger failures in non-adjacent + nodes should be avoided. This is particularly problematic when the + originating node receives no indicators of remote failures it may + have triggered. + +4. Considerations for the Base Protocol + + Good extension design depends on a well-designed base protocol. To + promote interoperability, designers should: + + 1. Ensure a well-written base protocol specification. Does the base + protocol specification make clear what an implementer needs to + support, and does it define the impact that individual operations + (e.g., a message sent to a peer) will have when invoked? + + 2. Design for backward compatibility. Does the base protocol + specification describe how to determine the capabilities of a + peer and negotiate the use of extensions? Does it indicate how + implementations handle extensions that they do not understand? + Is it possible for an extended implementation to negotiate with + an unextended (or differently-extended) peer to find a common + subset of useful functions? + + 3. Respect underlying architectural or security assumptions. Is + there a document describing the underlying architectural + assumptions, as well as considerations that have arisen in + operational experience? Or are there undocumented considerations + that have arisen as the result of operational experience, after + the original protocol was published? + + For example, will backward-compatibility issues arise if + extensions reverse the flow of data, allow formerly static + parameters to be changed on the fly, or change assumptions + relating to the frequency of reads/writes? + + + + + +Carpenter, et al. Informational [Page 18] + +RFC 6709 Design Considerations for Extensions September 2012 + + + 4. Minimize impact on critical infrastructure. For a protocol that + represents a critical element of Internet infrastructure, it is + important to explain when it is appropriate to isolate new uses + of the protocol from existing ones. + + For example, is it explained when a proposed extension (or usage) + has the potential for negatively impacting critical + infrastructure to the point where explicit steps would be + appropriate to isolate existing uses from new ones? + + 5. Provide guidance on data model extensions. Is there a document + that explains when a protocol extension is routine and when it + represents a major change? + + For example, is it clear when a data model extension represents a + major versus a routine change? Are there guidelines describing + when an extension (such as a new data type) is likely to require + a code change within existing implementations? + +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. + This would be a bad protocol design and description; it should be + clear what the expectation is and how it can be tested. 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 example of an under-specified versioning mechanism is provided by + the MIME-Version header, originally defined in "MIME (Multipurpose + Internet Mail Extensions)" [RFC1341]. As noted in Section 1 of the + MIME specification [RFC1341]: + + A MIME-Version header field ... uses a version number to declare a + message to be conformant with this specification and allows mail + processing agents to distinguish between such messages and those + generated by older or non-conformant software, which is presumed + to lack such a field. + + + + + + + + +Carpenter, et al. Informational [Page 19] + +RFC 6709 Design Considerations for Extensions September 2012 + + + Beyond this, the 1992 MIME specification [RFC1341] provided little + guidance on versioning behavior, or even the format of the MIME- + Version header, which was specified to contain "text". The 1993 + update [RFC1521] better defined the format of the version field but + still did not clarify the versioning behavior: + + Thus, future format specifiers, which might replace or extend + "1.0", are constrained to be two integer fields, separated by a + period. If a message is received with a MIME-version value other + than "1.0", it cannot be assumed to conform with this + specification.... + + It is not possible to fully specify how a mail reader that + conforms with MIME as defined in this document should treat a + message that might arrive in the future with some value of MIME- + Version other than "1.0". However, conformant software is + encouraged to check the version number and at least warn the user + if an unrecognized MIME-version is encountered. + + Thus, even though the 1993 update [RFC1521] defined a MIME-Version + header with a syntax suggestive of a "Major/Minor" versioning scheme, + in practice the MIME-Version header was little more than a + decoration. + + An example of a protocol with a better versioning scheme is ROHC + (Robust Header Compression). ROHCv1 [RFC3095] supports a certain set + of profiles for compression algorithms. But experience had shown + that these profiles had limitations, so the ROHC WG developed ROHCv2 + [RFC5225]. A ROHCv1 implementation does not contain code for the + ROHCv2 profiles. As the ROHC WG charter said during the development + of ROHCv2: + + 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 backward-compatible and backward- + incompatible deployments are possible. The important point is to + have a clearly thought out approach to the question of operational + compatibility. + + + + + + + +Carpenter, et al. Informational [Page 20] + +RFC 6709 Design Considerations for Extensions September 2012 + + + In the past, protocols have utilized a variety of strategies for + versioning, each with its own benefits and drawbacks in terms of + capability and complexity of implementation: + + 1. No versioning support. This approach is exemplified by the + Extensible Authentication Protocol (EAP) [RFC3748] as well as the + Remote Authentication Dial In User Service (RADIUS) protocol + [RFC2865], both of which provide no support for versioning. + While lack of versioning support protects against the + proliferation of incompatible dialects, the need for + extensibility is likely to assert itself in other ways, so that + ignoring versioning entirely may not be the most forward thinking + approach. + + 2. Highest mutually supported version (HMSV). In this approach, + implementations exchange the version numbers of the highest + version each supports, with the negotiation agreeing on the + highest mutually supported protocol version. This approach + implicitly assumes that later versions provide improved + functionality and that advertisement of a particular version + number implies support for all lower version numbers. Where + these assumptions are invalid, this approach breaks down, + potentially resulting in interoperability problems. An example + of this issue occurs in the Protected Extensible Authentication + Protocol [PEAP] where implementations of higher versions may not + necessarily provide support for lower versions. + + 3. Assumed backward compatibility. In this approach, + implementations may send packets with higher version numbers to + legacy implementations supporting lower versions, but with the + assumption that the legacy implementations will interpret packets + with higher version numbers using the semantics and syntax + defined for lower versions. This is the approach taken by "Port- + Based Network Access Control" [IEEE-802.1X]. For this approach + to work, legacy implementations need to be able to accept packets + of known types with higher protocol versions without discarding + them; protocol enhancements need to permit silent discard of + unsupported extensions; and implementations supporting higher + versions need to refrain from mandating new features when + encountering legacy implementations. + + 4. Major/minor versioning. In this approach, implementations with + the same major version but a different minor version are assumed + to be backward compatible, but implementations are required to + negotiate a mutually supported major version number. This + approach assumes that implementations with a lower minor version + number but the same major version can safely ignore unsupported + protocol messages. + + + +Carpenter, et al. Informational [Page 21] + +RFC 6709 Design Considerations for Extensions September 2012 + + + 5. Min/max versioning. This approach is similar to HMSV, but + without the implied obligation for clients and servers to support + all versions back to version 1, in perpetuity. It allows clients + and servers to cleanly drop support for early versions when those + versions become so old that they are no longer relevant and no + longer required. In this approach, the client initiating the + connection reports the highest and lowest protocol versions it + understands. The server reports back the chosen protocol + version: + + a. If the server understands one or more versions in the + client's range, it reports back the highest mutually + understood version. + + b. If there is no mutual version, then the server reports back + some version that it does understand (selected as described + below). The connection is then typically dropped by client + or server, but reporting this version number first helps + facilitate useful error messages at the client end: + + * If there is no mutual version, and the server speaks any + version higher than client max, it reports the lowest + version it speaks that is greater than the client max. + The client can then report to the user, "You need to + upgrade to at least version <xx>". + + * Else, the server reports the highest version it speaks. + The client can then report to the user, "You need to + request the server operator to upgrade to at least version + <min>". + + Protocols generally do not need any version-negotiation mechanism + more complicated than the mechanisms described here. The nature of + protocol version-negotiation mechanisms is that, by definition, they + don't get widespread real-world testing until *after* the base + protocol has been deployed for a while, and its deficiencies have + become evident. This means that, to be useful, a protocol version- + negotiation mechanism should be simple enough that it can reasonably + be assumed that all the implementers of the first protocol version at + least managed to implement the version-negotiation mechanism + correctly. + +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 + + + +Carpenter, et al. Informational [Page 22] + +RFC 6709 Design Considerations for Extensions September 2012 + + + value (typically no action). In packet format diagrams, such fields + are typically labeled "MBZ", to be read as, "Must Be Zero on + transmission, Must Be Ignored on reception". + + A common mistake of inexperienced protocol implementers is to think + that "MBZ" means that it's their software's job to verify that the + value of the field is zero on reception and reject the packet if not. + This is a mistake, and such software will fail when it encounters + future versions of the protocol where these previously reserved + fields are given new defined meanings. Similarly, protocols should + carefully specify how receivers should react to unknown extensions + (headers, TLVs, etc.), such that failures occur only when that is + truly the intended outcome. + +4.3. Encoding Formats + + Using widely supported encoding formats leads to better + interoperability and easier extensibility. + + As described in "IAB Thoughts on Encodings for Internationalized + Domain Names" [RFC6055], the number of encodings should be minimized, + and complex encodings are generally a bad idea. As soon as one moves + outside the ASCII repertoire, issues arise relating to collation, + valid code points, encoding, normalization, and comparison, which + extensions must handle with care + [ID-COMPARISON][PRECIS-STATEMENT][PRECIS-FRAMEWORK]. + + An example is the Simple Network Management Protocol (SNMP) Structure + of Managed Information (SMI). Guidelines exist for defining the + Management Information Base (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, "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. Parameter Space Design + + In some protocols, the parameter space either has no specified limit + (e.g., Header field names) or is sufficiently large that it is + unlikely to be exhausted. In other protocols, the parameter space is + limited and, in some cases, has proven inadequate to accommodate + demand. Common mistakes include: + + a. A version field that is too small (e.g., two bits or less). When + designing a version field, existing as well as potential versions + of a protocol need to be taken into account. For example, if a + + + +Carpenter, et al. Informational [Page 23] + +RFC 6709 Design Considerations for Extensions September 2012 + + + protocol is being standardized for which there are existing + implementations with known interoperability issues, more than one + version for "pre-standard" implementations may be required. If + two "pre-standard" versions are required in addition to a version + for an IETF Standard, then a two-bit version field would only + leave one additional version code point for a future update, + which could be insufficient. This problem was encountered during + the development of the PEAPv2 protocol [PEAP]. + + b. A small parameter space (e.g., 8 bits or less) along with a First + Come, First Served (FCFS) allocation policy [RFC5226]. In + general, an FCFS allocation policy is only appropriate in + situations where parameter exhaustion is highly unlikely. In + situations where substantial demand is anticipated within a + parameter space, the space should either be designed to be + sufficient to handle that demand, or vendor extensibility should + be provided to enable vendors to self-allocate. The combination + of a small parameter space, an FCFS allocation policy, and no + support for vendor extensibility is particularly likely to prove + ill-advised. An example of such a combination was the design of + the original 8-bit EAP Type space [RFC2284]. + + Once the potential for parameter exhaustion becomes apparent, it is + important that it be addressed as quickly as possible. Protocol + changes can take years to appear in implementations and by then the + exhaustion problem could become acute. + + Options for addressing a protocol parameter exhaustion problem + include: + + Rethinking the allocation regime + Where it becomes apparent that the size of a parameter space is + insufficient to meet demand, it may be necessary to rethink the + allocation mechanism, in order to prevent or delay parameter space + exhaustion. In revising parameter allocation mechanisms, it is + important to consider both supply and demand aspects so as to + avoid unintended consequences such as self-allocation or the + development of black markets for the resale of protocol + parameters. + + For example, a few years after publication of PPP EAP [RFC2284] in + 1998, it became clear that the combination of an FCFS allocation + policy [RFC5226] and lack of support for vendor-extensions had + created the potential for exhaustion of the EAP Method Type space + within a few years. To address the issue, Section 6.2 of the 2004 + update [RFC3748] changed the allocation policy for EAP Method + Types from FCFS to Expert Review, with Specification Required. + Since this allocation policy revision did not change the demand + + + +Carpenter, et al. Informational [Page 24] + +RFC 6709 Design Considerations for Extensions September 2012 + + + for EAP Method Types, it would have been likely to result in self- + allocation within the standards space had mechanisms not been + provided to expand the Method Type space (including support for + vendor-specific method types). + + Support for vendor-specific parameters + If the demand that cannot be accommodated is being generated by + vendors, merely making allocation harder could make things worse + if this encourages vendors to self-allocate, creating + interoperability problems. In such a situation, support for + vendor-specific parameters should be considered, allowing each + vendor to self-allocate within their own vendor-specific space + based on a vendor's Private Enterprise Code (PEC). For example, + in the case of the EAP Method Type space, Section 6.2 of the 2004 + EAP specification [RFC3748] also provided for an Expanded Type + space for "functions specific only to one vendor's + implementation". + + Extensions to the parameter space + If the goal is to stave off exhaustion in the face of high demand, + a larger parameter space may be helpful; this may require a new + version of the protocol (such as was required for IPv6). Where + vendor-specific parameter support is available, this may be + achieved by allocating a PEC for IETF use. Otherwise, it may be + necessary to try to extend the size of the parameter fields, which + could require a new protocol version or other substantial protocol + changes. + + Parameter reclamation + In order to gain time, it may be necessary to reclaim unused + parameters. However, it may not be easy to determine whether a + parameter that has been allocated is in use or not, particularly + if the entity that obtained the allocation no longer exists or has + been acquired (possibly multiple times). + + Parameter transfer + When all the above mechanisms have proved infeasible and parameter + exhaustion looms in the near future, enabling the transfer of + ownership of protocol parameters can be considered as a means for + improving allocation efficiency. However, enabling transfer of + parameter ownership can be far from simple if the parameter + allocation process was not originally designed to enable title + searches and ownership transfers. + + A parameter allocation process designed to uniquely allocate code + points is fundamentally different from one designed to enable + title search and transfer. If the only goal is to ensure that a + parameter is not allocated more than once, the parameter registry + + + +Carpenter, et al. Informational [Page 25] + +RFC 6709 Design Considerations for Extensions September 2012 + + + will only need to record the initial allocation. On the other + hand, if the goal is to enable transfer of ownership of a protocol + parameter, then it is important not only to record the initial + allocation, but also to track subsequent ownership changes, so as + to make it possible to determine and transfer the title. Given + the difficulty of converting from a unique allocation regime to + one requiring support for title search and ownership transfer, it + is best for the desired capabilities to be carefully thought + through at the time of registry establishment. + +4.5. Cryptographic Agility + + Extensibility with respect to cryptographic algorithms is desirable + in order to provide resilience against the compromise of any + particular algorithm. Section 3 of "Guidance for Authentication, + Authorization, and Accounting (AAA) Key Management" BCP 132 [RFC4962] + provides some basic advice: + + The ability to negotiate the use of a particular cryptographic + algorithm provides resilience against compromise of a particular + cryptographic algorithm.... This is usually accomplished by + including an algorithm identifier and parameters in the protocol, + and by specifying the algorithm requirements in the protocol + specification. While highly desirable, the ability to negotiate + key derivation functions (KDFs) is not required. For + interoperability, at least one suite of mandatory-to-implement + algorithms MUST be selected.... + + This requirement does not mean that a protocol must support both + public-key and symmetric-key cryptographic algorithms. It means + that the protocol needs to be structured in such a way that + multiple public-key algorithms can be used whenever a public-key + algorithm is employed. Likewise, it means that the protocol needs + to be structured in such a way that multiple symmetric-key + algorithms can be used whenever a symmetric-key algorithm is + employed. + + In practice, the most difficult challenge in providing cryptographic + agility is providing for a smooth transition in the event that a + mandatory-to-implement algorithm is compromised. Since it may take + significant time to provide for widespread implementation of a + previously undeployed alternative, it is often advisable to recommend + implementation of alternative algorithms of distinct lineage in + addition to those made mandatory-to-implement, so that an alternative + algorithm is readily available. If such a recommended alternative is + not in place, then it would be wise to issue such a recommendation as + soon as indications of a potential weakness surface. This is + particularly important in the case of potential weakness in + + + +Carpenter, et al. Informational [Page 26] + +RFC 6709 Design Considerations for Extensions September 2012 + + + algorithms used to authenticate and integrity-protect the + cryptographic negotiation itself, such as KDFs or message integrity + checks (MICs). Without secure alternatives to compromised KDF or MIC + algorithms, it may not be possible to secure the cryptographic + negotiation while retaining backward compatibility. + +4.6. Transport + + In the past, IETF protocols have been specified to operate over + multiple transports. Often the protocol was originally specified to + utilize a single transport, but limitations were discovered in + subsequent deployment, so that additional transports were + subsequently specified. + + In a number of cases, the protocol was originally specified to + operate over UDP, but subsequent operation disclosed one or more of + the following issues, leading to the specification of alternative + transports: + + a. Payload fragmentation (often due to the introduction of + extensions or additional usage scenarios); + + b. Problems with congestion control, transport reliability, or + efficiency; and + + c. Lack of deployment in multicast scenarios, which had been a + motivator for UDP transport. + + On the other hand, there are also protocols that were originally + specified to operate over reliable transport that have subsequently + defined transport over UDP, due to one or more of the following + issues: + + a. NAT traversal concerns that were more easily addressed with UDP + transport; + + b. Scalability problems, which could be improved by UDP transport. + + Since specification of a single transport offers the highest + potential for interoperability, protocol designers should carefully + consider not only initial but potential future requirements in the + selection of a transport protocol. Where UDP transport is selected, + the guidance provided in "Unicast UDP Usage Guidelines for + Application Designers" [RFC5405] should be taken into account. + + + + + + + +Carpenter, et al. Informational [Page 27] + +RFC 6709 Design Considerations for Extensions September 2012 + + + After significant deployment has occurred, there are few satisfactory + options for addressing problems with the originally selected + transport protocol. While specification of additional transport + protocols is possible, removal of a widely used transport protocol is + likely to result in interoperability problems and should be avoided. + + Mandating support for the initially selected transport protocol while + designating additional transport protocols as optional may have + limitations. Since optional transport protocols are typically + introduced due to the advantages they afford in certain scenarios, in + those situations, implementations not supporting optional transport + protocols may exhibit degraded performance or may even fail. + + While mandating support for multiple transport protocols may appear + attractive, designers need to realistically evaluate the likelihood + that implementers will conform to the requirements. For example, + where resources are limited (such as in embedded systems), + implementers may choose to only support a subset of the mandated + transport protocols, resulting in non-interoperable protocol + variants. + +4.7. Handling of Unknown Extensions + + IETF protocols have utilized several techniques for the handling of + unknown extensions. One technique (often used for vendor-specific + extensions) is to specify that unknown extensions be "silently + discarded". + + While this approach can deliver a high level of interoperability, + there are situations in which it is problematic. For example, where + security functionality is involved, "silent discard" may not be + satisfactory, particularly if the recipient does not provide feedback + as to whether or not it supports the extension. This can lead to + operational security issues that are difficult to detect and correct, + as noted in Appendix A.2 and in Section 2.5 of "Common Remote + Authentication Dial In User Service (RADIUS) Implementation Issues + and Suggested Fixes" [RFC5080]. + + In order to ensure that a recipient supports an extension, a + recipient encountering an unknown extension may be required to + explicitly reject it and to return an error, rather than ignoring the + unknown extension and proceeding with the remainder of the message. + This can be accomplished via a "Mandatory" bit in a TLV-based + protocol such as the Layer 2 Tunneling Protocol (L2TP) [RFC2661], or + a "Require" or "Proxy-Require" header in a text-based protocol such + as SIP [RFC3261] or HTTP [RFC2616]. + + + + + +Carpenter, et al. Informational [Page 28] + +RFC 6709 Design Considerations for Extensions September 2012 + + + Since a mandatory extension can result in an interoperability failure + when communicating with a party that does not support the extension, + this designation may not be permitted for vendor-specific extensions + and may only be allowed for Standards Track extensions. To enable + fallback operation with degraded functionality, it is good practice + for the recipient to indicate the reason for the failure, including a + list of unsupported extensions. The initiator can then retry without + the offending extensions. + + Typically, only the recipient will find itself in the position of + rejecting a mandatory extension, since the initiator can explicitly + indicate which extensions are supported, with the recipient choosing + from among the supported extensions. This can be accomplished via an + exchange of TLVs, such as in the Internet Key Exchange Protocol + Version 2 (IKEv2) [RFC5996] or Diameter [RFC3588], or via use of + "Accept", "Accept-Encoding", "Accept-Language", "Allow", and + "Supported" headers in a text-based protocol such as SIP [RFC3261] or + HTTP [RFC2616]. + +5. Security Considerations + + An extension must not introduce new security risks without also + providing adequate countermeasures; 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). + + When the extensibility of a design includes allowing for new and + presumably more powerful cryptographic algorithms to be added, + particular care is needed to ensure that the result is, in fact, + increased security. For example, it may be undesirable from a + security viewpoint to allow negotiation down to an older, less secure + algorithm. + + + + + + + + + + + +Carpenter, et al. Informational [Page 29] + +RFC 6709 Design Considerations for Extensions September 2012 + + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4775] Bradner, S., Carpenter, B., Ed., and T. Narten, + "Procedures for Protocol Extensions and Variations", BCP + 125, RFC 4775, December 2006. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + +6.2. Informative References + + [ERROR-HANDLING] + Scudder, J., Chen, E., Mohapatra, P., and K. Patel, + "Revised Error Handling for BGP UPDATE Messages", Work in + Progress, June 2012. + + [ID-COMPARISON] + Thaler, D., "Issues in Identifier Comparison for Security + Purposes", Work in Progress, August 2012. + + [IEEE-802.1X] + Institute of Electrical and Electronics Engineers, "Local + and Metropolitan Area Networks: Port-Based Network Access + Control", IEEE Standard 802.1X-2004, December 2004. + + [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, + "Locator/ID Separation Protocol (LISP)", Work in Progress, + May 2012. + + [PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., + and S. Josefsson, "Protected EAP Protocol (PEAP) Version + 2", Work in Progress, October 2004. + + [PRECIS-FRAMEWORK] + Saint-Andre, P. and M. Blanchet, "PRECIS Framework: + Preparation and Comparison of Internationalized Strings in + Application Protocols", Work in Progress, August 2012. + + [PRECIS-STATEMENT] + Blanchet, M. and A. Sullivan, "Stringprep Revision and + PRECIS Problem Statement", Work in Progress, August 2012. + + + + +Carpenter, et al. Informational [Page 30] + +RFC 6709 Design Considerations for Extensions September 2012 + + + [RFC822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET + TEXT MESSAGES", STD 11, RFC 822, August 1982. + + [RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered + Harmful", RFC 1263, October 1991. + + [RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet + Mail Extensions): Mechanisms for Specifying and Describing + the Format of Internet Message Bodies", RFC 1341, June + 1992. + + [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet + Mail Extensions) Part One: Mechanisms for Specifying and + Describing the Format of Internet Message Bodies", RFC + 1521, September 1993. + + [RFC2058] Rigney, C., Rubens, A., Simpson, W., and S. Willens, + "Remote Authentication Dial In User Service (RADIUS)", RFC + 2058, January 1997. + + [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, March 1997. + + [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible + Authentication Protocol (EAP)", RFC 2284, March 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. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, + G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", + RFC 2661, August 1999. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, + April 2001. + + + + +Carpenter, et al. Informational [Page 31] + +RFC 6709 Design Considerations for Extensions September 2012 + + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", RFC + 2865, June 2000. + + [RFC2882] Mitton, D., "Network Access Servers Requirements: Extended + RADIUS Practices", RFC 2882, July 2000. + + [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. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., + and B. Rosen, "Change Process for the Session Initiation + Protocol (SIP)", RFC 3427, December 2002. + + [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote + Authentication Dial In User Service)", RFC 3575, July + 2003. + + [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. + Arkko, "Diameter Base Protocol", RFC 3588, September 2003. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers + Considered Useful", BCP 82, RFC 3692, January 2004. + + [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible + Provisioning Protocol (EPP)", RFC 3735, March 2004. + + [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. + Levkowetz, Ed., "Extensible Authentication Protocol + (EAP)", RFC 3748, June 2004. + + [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP + 95, RFC 3935, October 2004. + + + + + + +Carpenter, et al. Informational [Page 32] + +RFC 6709 Design Considerations for Extensions September 2012 + + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, February 2005. + + [RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of + MIB Documents", BCP 111, RFC 4181, September 2005. + + [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., + and T. Wright, "Transport Layer Security (TLS) + Extensions", RFC 4366, April 2006. + + [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors + of Extensions to the Session Initiation Protocol (SIP)", + RFC 4485, May 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. + + [RFC4929] Andersson, L., Ed., and A. Farrel, Ed., "Change Process + for Multiprotocol Label Switching (MPLS) and Generalized + MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, + June 2007. + + [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, + Authorization, and Accounting (AAA) Key Management", BCP + 132, RFC 4962, July 2007. + + [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication + Dial In User Service (RADIUS) Implementation Issues and + Suggested Fixes", RFC 5080, December 2007. + + [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. + Henderson, "Host Identity Protocol", RFC 5201, April 2008. + + [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful + Protocol?", RFC 5218, July 2008. + + [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression + Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and + UDP-Lite", RFC 5225, April 2008. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + + + +Carpenter, et al. Informational [Page 33] + +RFC 6709 Design Considerations for Extensions September 2012 + + + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + October 2008. + + [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines + for Application Designers", BCP 145, RFC 5405, November + 2008. + + [RFC5421] Cam-Winget, N. and H. Zhou, "Basic Password Exchange + within the Flexible Authentication via Secure Tunneling + Extensible Authentication Protocol (EAP-FAST)", RFC 5421, + March 2009. + + [RFC5422] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, + "Dynamic Provisioning Using Flexible Authentication via + Secure Tunneling Extensible Authentication Protocol (EAP- + FAST)", RFC 5422, March 2009. + + [RFC5704] Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated + Protocol Development Considered Harmful", RFC 5704, + November 2009. + + [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process + for the Session Initiation Protocol (SIP) and the Real- + time Applications and Infrastructure Area", BCP 67, RFC + 5727, March 2010. + + [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, + "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC + 5996, September 2010. + + [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on + Encodings for Internationalized Domain Names", RFC 6055, + February 2011. + + [RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines", + BCP 158, RFC 6158, March 2011. + + [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, + "Deprecating the "X-" Prefix and Similar Constructs in + Application Protocols", BCP 178, RFC 6648, June 2012. + + + + + + + + + + + +Carpenter, et al. Informational [Page 34] + +RFC 6709 Design Considerations for Extensions September 2012 + + +7. Acknowledgments + + This document is heavily based on an earlier draft by Scott Bradner + and Thomas Narten, other parts of which were eventually published as + RFC 4775. + + 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 and others." + + Valuable comments and suggestions on the current form of the document + were made by Loa Andersson, Ran Atkinson, Stewart Bryant, Leslie + Daigle, Alan DeKok, Roy Fielding, Phillip Hallam-Baker, Ted Hardie, + Alfred Hoenes, John Klensin, Barry Leiba, Eric Rescorla, Adam Roach, + and Pekka Savola. The text on TLS experience was contributed by + Yngve Pettersen. + +8. IAB Members at the Time of Approval + + Bernard Aboba + Jari Arkko + Marc Blanchet + Ross Callon + Alissa Cooper + Spencer Dawkins + Joel Halpern + Russ Housley + David Kessens + Danny McPherson + Jon Peterson + Dave Thaler + Hannes Tschofenig + + + + + + + + + + + + + + + + + + +Carpenter, et al. Informational [Page 35] + +RFC 6709 Design Considerations for Extensions September 2012 + + +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], [RFC5727] + The (G)MPLS change process (mainly procedural) [RFC4929] + LDAP extensions [RFC4521] + EPP extensions [RFC3735] + DNS extensions [RFC2671][RFC3597] + SMTP extensions [RFC5321] + + 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. This extensibility model assumed that + Attributes would conform to a limited set of data types and that + vendor extensions would be limited to use by vendors in situations in + which interoperability was not required. Subsequent developments + have stretched those assumptions. + + From the beginning, uses of the RADIUS protocol extended beyond the + scope of the original protocol definition (and beyond the scope of + the RADIUS Working Group charter). In addition to rampant self- + allocation within the limited RADIUS standard attribute space, + vendors defined their own RADIUS commands. This led to the rapid + proliferation of vendor-specific protocol variants. To this day, + many common implementation practices have not been documented. For + example, authentication server implementations are often typically + based on a Data Dictionary, enabling addition of Attributes without + requiring code changes. Yet, the concept of a Data Dictionary is not + mentioned in the RADIUS specification [RFC2865]. + + As noted in "Extended RADIUS Practices" [RFC2882], Section 1: + + The RADIUS Working Group was formed in 1995 to document the + protocol of the same name, and was chartered to stay within a set + of bounds for dial-in terminal servers. Unfortunately the real + world of Network Access Servers (NASes) hasn't stayed that small + and simple, and continues to evolve at an amazing rate. + + + +Carpenter, et al. Informational [Page 36] + +RFC 6709 Design Considerations for Extensions September 2012 + + + This document shows some of the current implementations on the + market have already outstripped the capabilities of the RADIUS + protocol. A quite a few features have been developed completely + outside the protocol. These features use the RADIUS protocol + structure and format, but employ operations and semantics well + beyond the RFC documents. + + The limited set of data types defined in the RADIUS specification + [RFC2865] led to subsequent documents defining new data types. Since + new data types are typically defined implicitly as part of defining a + new attribute and because RADIUS client and server implementations + differ in their support of these additional specifications, there is + no definitive registry of RADIUS data types, and data type support + has been inconsistent. To catalog commonly implemented data types as + well as to provide guidance for implementers and attribute designers, + Section 2.1 of "RADIUS Design Guidelines" [RFC6158] includes advice + on basic and complex data types. Unfortunately, these guidelines + [RFC6158] were published in 2011, 14 years after the RADIUS protocol + was first documented [RFC2058] in 1997. + + Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism + for Vendor-Specific extensions (Attribute 26) and states that use of + Vendor-Specific extensions: + + 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 Standards Development Organizations (SDOs) to define their + own extensions to the RADIUS protocol. This has caused a number of + problems. + + One issue concerns the data model for VSAs. Since it was not + envisaged that multi-vendor VSA implementations would need to + interoperate, the RADIUS specification [RFC2865] does not define the + data model for VSAs and allows multiple sub-attributes to be included + within a single Attribute of type 26. Since this enables VSAs to be + defined that would not be supportable by current implementations if + placed within the standard RADIUS attribute space, this has caused + problems in standardizing widely deployed VSAs, as discussed in + Section 2.4 of "RADIUS Design Guidelines" BCP 158 [RFC6158]: + + RADIUS attributes can often be developed within the vendor space + without loss (and possibly even with gain) in functionality. As a + result, translation of RADIUS attributes developed within the + vendor space into the standard space may provide only modest + + + +Carpenter, et al. Informational [Page 37] + +RFC 6709 Design Considerations for Extensions September 2012 + + + benefits, while accelerating the exhaustion of the standard space. + We do not expect that all RADIUS attribute specifications + requiring interoperability will be developed within the IETF, and + allocated from the standard space. A more scalable approach is to + recognize the flexibility of the vendor space, while working + toward improvements in the quality and availability of RADIUS + attribute specifications, regardless of where they are developed. + + It is therefore NOT RECOMMENDED that specifications intended + solely for use by a vendor or SDO be translated into the standard + space. + + Another issue is how implementations should handle unknown VSAs. + Section 5.26 of the RADIUS specification [RFC2865] states: + + Servers not equipped to interpret the vendor-specific information + sent by a client MUST ignore it (although it may be reported). + Clients which do not receive desired vendor-specific information + SHOULD make an attempt to operate without it, although they may do + so (and report they are doing so) in a degraded mode. + + However, since VSAs do not contain a "mandatory" bit, RADIUS clients + and servers may not know whether it is safe to ignore unknown VSAs. + For example, in the case where VSAs pertain to security (e.g., + Filters), it may not be safe to ignore them. As a result, Section + 2.5 of "Common Remote Authentication Dial In User Service (RADIUS) + Implementation Issues and Suggested Fixes" [RFC5080] includes the + following caution: + + To avoid misinterpretation of service requests encoded within + VSAs, RADIUS servers SHOULD NOT send VSAs containing service + requests to RADIUS clients that are not known to understand them. + For example, a RADIUS server should not send a VSA encoding a + filter without knowledge that the RADIUS client supports the VSA. + + 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 the RADIUS specification [RFC2865] + defined Service-Type values as being allocated First Come, First + Served (FCFS) [RFC5226], this permitted new RADIUS commands to be + allocated without IETF review. This oversight has since been fixed + in "IANA Considerations for RADIUS" [RFC3575]. + + + + + + + + + +Carpenter, et al. Informational [Page 38] + +RFC 6709 Design Considerations for Extensions September 2012 + + +A.3. TLS Extensions + + The Secure Sockets Layer (SSL) Version 2 Protocol was developed by + Netscape to be used to secure online transactions on the Internet. + It was later replaced by SSLv3, also developed by Netscape. SSLv3 + was then further developed by the IETF as the Transport Layer + Security (TLS) 1.0 [RFC2246]. + + The SSLv3 protocol was not explicitly 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 "Transport Layer Security (TLS) Extensions" + [RFC4366]: + + 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 SSLv2 and SSLv3/TLS are not compatible. It is possible to use + SSLv2 protocol messages to initiate an SSLv3/TLS connection, + but it is not possible to communicate with an SSLv2 + implementation using SSLv3/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. + + + + + +Carpenter, et al. Informational [Page 39] + +RFC 6709 Design Considerations for Extensions September 2012 + + + The SSLv2 problem has forced SSLv3 and TLS clients to continue to use + SSLv2 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. + + 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. + + SSLv3 and TLS also permitted extension of the Client Hello and Server + Hello handshake messages. This functionality was fully defined by + the introduction of TLS extensions, which make 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, and + indicate Certificate Authority support, maximum record length, etc. + Several of these extensions also introduce new handshake messages. + + It has turned out that many SSLv3 and TLS implementations that do not + support TLS extensions did not ignore the unknown extensions, as + required by the protocol specifications, but instead failed to + establish connections. Since several of the implementations behaving + in this manner are used by high-profile Internet sites, such as + online banking sites, 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 TLS is + weakening. 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). + + To address this issue, TLS 1.2 [RFC5246] makes use of a newer + cryptographic hash algorithm (SHA-256) during the TLS handshake by + default. Legacy ciphersuites can still be used to protect + application data, but new ciphersuites are specified for data + protection as well as for authentication within the TLS handshake. + The hashing method can also be negotiated via a Hello extension. + Implementations are encouraged to implement new ciphersuites and to + enable the negotiation of the ciphersuite used during a TLS session + to be governed by policy, thus enabling a more rapid transition away + from weakened ciphersuites. + + + +Carpenter, et al. Informational [Page 40] + +RFC 6709 Design Considerations for Extensions September 2012 + + + 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. Test + suites and certification programs can help provide incentives for + implementers to pay attention to implementing extensibility + mechanisms correctly. + +A.4. L2TP Extensions + + The Layer Two Tunneling Protocol (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 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 that 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 causes 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 potential problems described + above have yet become a problem in practice. At the time of this + writing, the authors are not aware of the existence of any vendor- + specific AVPs that also set the M-bit. + + + + + + + + + + + +Carpenter, et al. Informational [Page 41] + +RFC 6709 Design Considerations for Extensions September 2012 + + +Authors' Addresses + + Brian Carpenter + Department of Computer Science + University of Auckland + PB 92019 + Auckland, 1142 + New Zealand + + EMail: brian.e.carpenter@gmail.com + + + Bernard Aboba (editor) + PMB 606 + 15600 NE 8th Street, Suite B1 + Bellevue, WA 98008 + USA + + EMail: bernard_aboba@hotmail.com + + + Stuart Cheshire + Apple Inc. + 1 Infinite Loop + Cupertino, CA 95014 + USA + + EMail: cheshire@apple.com + + + + + + + + + + + + + + + + + + + + + + + +Carpenter, et al. Informational [Page 42] + |