idnits 2.17.1 draft-iab-extension-recs-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (26 June 2012) is 4314 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-19) exists of draft-ietf-idr-error-handling-02 -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 1341 (Obsoleted by RFC 1521) -- Obsolete informational reference (is this intentional?): RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) -- Obsolete informational reference (is this intentional?): RFC 2058 (Obsoleted by RFC 2138) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2284 (Obsoleted by RFC 3748) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3427 (Obsoleted by RFC 5727) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board B. Carpenter 3 Internet-Draft B. Aboba (ed) 4 Intended Status: Informational S. Cheshire 5 Expires: December 26, 2012 26 June 2012 7 Design Considerations for Protocol Extensions 8 draft-iab-extension-recs-16 10 Abstract 12 This document discusses architectural issues related to the 13 extensibility of Internet protocols, with a focus on design 14 considerations. It is intended to assist designers of both base 15 protocols and extensions. Case studies are included. A companion 16 document, RFC 4775/BCP 125, discusses procedures relating to the 17 extensibility of IETF protocols. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on December 26, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1 Requirements Language . . . . . . . . . . . . . . . . . . 5 73 2. Routine and Major Extensions . . . . . . . . . . . . . . . . . 5 74 2.1 What Constitutes a Major Extension? . . . . . . . . . . . 5 75 2.2 When is an Extension Routine? . . . . . . . . . . . . . . 7 76 3. Architectural Principles . . . . . . . . . . . . . . . . . . . 8 77 3.1 Limited Extensibility . . . . . . . . . . . . . . . . . . 8 78 3.2 Design for Global Interoperability . . . . . . . . . . . . 9 79 3.3 Architectural Compatibility . . . . . . . . . . . . . . . 13 80 3.4 Protocol Variations . . . . . . . . . . . . . . . . . . . 14 81 3.5 Testability . . . . . . . . . . . . . . . . . . . . . . . 16 82 3.6 Parameter Parameter Registration . . . . . . . . . . . . . 17 83 3.7 Extensions to Critical Protocols . . . . . . . . . . . . . 18 84 4. Considerations for the Base Protocol . . . . . . . . . . . . . 18 85 4.1 Version Numbers . . . . . . . . . . . . . . . . . . . . . 19 86 4.2 Reserved Fields . . . . . . . . . . . . . . . . . . . . . 23 87 4.3 Encoding Formats . . . . . . . . . . . . . . . . . . . . . 23 88 4.4 Parameter Space Design . . . . . . . . . . . . . . . . . . 23 89 4.5 Cryptographic Agility . . . . . . . . . . . . . . . . . . 26 90 4.6 Transport . . . . . . . . . . . . . . . . . . . . . . . . 27 91 4.7 Handling of Unknown Extensions . . . . . . . . . . . . . . 28 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 94 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 95 7.1 Normative References . . . . . . . . . . . . . . . . . . . 30 96 7.2 Informative References . . . . . . . . . . . . . . . . . . 30 97 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34 98 IAB Members . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 99 Appendix A - Examples . . . . . . . . . . . . . . . . . . . . . . 35 100 A.1 Already documented cases . . . . . . . . . . . . . . . . . 35 101 A.2 RADIUS Extensions . . . . . . . . . . . . . . . . . . . . 35 102 A.3 TLS Extensions . . . . . . . . . . . . . . . . . . . . . . 37 103 A.4 L2TP Extensions . . . . . . . . . . . . . . . . . . . . . 40 104 Change log . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 106 1. Introduction 108 When developing protocols, IETF Working Groups (WGs) often include 109 mechanisms whereby these protocols can be extended in the future. It 110 is often a good principle to design extensibility into protocols; as 111 described in "What Makes for a Successful Protocol" [RFC5218], a 112 "wildly successful" protocol is one that becomes widely used in ways 113 not originally anticipated. Well-designed extensibility mechanisms 114 facilitate the evolution of protocols and help make it easier to roll 115 out incremental changes in an interoperable fashion. However, at the 116 same time experience has shown that extensions carry the risk of 117 unintended consequences, such as interoperability issues, operational 118 problems or security vulnerabilities. 120 The proliferation of extensions, even well designed ones, can be 121 costly. As noted in "Simple Mail Transfer Protocol" [RFC5321] 122 Section 2.2.1: 124 Experience with many protocols has shown that protocols with few 125 options tend towards ubiquity, whereas protocols with many options 126 tend towards obscurity. 128 Each and every extension, regardless of its benefits, must be 129 carefully scrutinized with respect to its implementation, 130 deployment, and interoperability costs. 132 This is hardly a recent concern. "TCP Extensions Considered Harmful" 133 [RFC1263] was published in 1991. "Extend" or "extension" occurs in 134 the title of more than 400 existing Request For Comment (RFC) 135 documents. Yet generic extension considerations have not been 136 documented previously. 138 The purpose of this document is to describe the architectural 139 principles of sound extensibility design, in order to minimize such 140 risks. Formal procedures for extending IETF protocols are discussed 141 in "Procedures for Protocol Extensions and Variations" BCP 125 142 [RFC4775]. 144 The rest of this document is organized as follows: Section 2 145 discusses routine and major extensions. Section 3 describes 146 architectural principles for protocol extensibility. Section 4 147 explains how designers of base protocols can take steps to anticipate 148 and facilitate the creation of such subsequent extensions in a safe 149 and reliable manner. 151 Readers are advised to study the whole document, since the 152 considerations are closely linked. 154 1.1. Requirements Language 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in BCP 14, RFC 2119 159 [RFC2119]. 161 2. Routine and Major Extensions 163 The risk of unintended consequences from an extension is especially 164 high if the extension is performed by a different team than the 165 original designers, who may stray outside implicit design constraints 166 or assumptions. As a result, it is highly desirable for the original 167 designers to articulate the design constraints and assumptions, so as 168 to enable extensions to be done carefully and with a full 169 understanding of the base protocol, existing implementations, and 170 current operational practice. 172 To assist extension designers and reviewers, protocol documents 173 should provide guidelines explaining how extensions should be 174 performed, and guidance on the appropriate use of protocol extension 175 mechanisms should be developed. 177 Protocol components that are designed with the specific intention of 178 allowing extensibility should be clearly identified, with specific 179 and complete instructions on how to extend them. This includes the 180 process for adequate review of extension proposals: do they need 181 community review and if so how much and by whom? 183 The level of review required for protocol extensions will typically 184 vary based on the nature of the extension. Routine extensions may 185 require minimal review, while major extensions may require wide 186 review. Guidance on which extensions may be considered 'routine' and 187 which ones are 'major' are provided in the sections that follow. 189 2.1. What Constitutes a Major Extension? 191 Major extensions may have characteristics leading to a risk of 192 interoperability failures, security vulnerabilities or operational 193 problems. Where these characteristics are present, it is necessary 194 to pay close attention to backward compatibility with implementations 195 and deployments of the unextended protocol, and to the potential for 196 inadvertent introduction of security or operational exposures. 198 Extension designers should examine their design for the following 199 issues: 201 1. Modifications or extensions to the underlying protocol. An 202 extension document should be considered to update the underlying 203 protocol specification if an implementation of the underlying 204 protocol would need to be updated to accommodate the extension. This 205 should not be necessary if the underlying protocol was designed with 206 a modular interface. Examples of extensions modifying the underlying 207 protocol include specification of additional transports (see Section 208 4.6), changing protocol semantics or defining new message types that 209 may require implementation changes in existing and deployed 210 implementations of the protocol, even if they do not want to make use 211 of the new functions. A base protocol that does not uniformly permit 212 "silent discard" of unknown extensions may automatically enter this 213 category, even for apparently minor extensions. Handling of 214 "unknown" extensions is discussed in more detail in Section 4.7. 216 2. Changes to the basic architectural assumptions. This may include 217 architectural assumptions that are explicitly stated or those that 218 have been assumed by implementers. For example, this would include 219 adding a requirement for session state to a previously stateless 220 protocol. 222 3. New usage scenarios not originally intended or investigated. 223 This can potentially lead to operational difficulties when deployed, 224 even in cases where the "on-the-wire" format has not changed. For 225 example, the level of traffic carried by the protocol may increase 226 substantially, packet sizes may increase, and implementation 227 algorithms that are widely deployed may not scale sufficiently or 228 otherwise be up to the new task at hand. For example, a new DNS 229 Resource Record (RR) type that is too big to fit into a single UDP 230 packet could cause interoperability problems with existing DNS 231 clients and servers. Similarly, the additional traffic that results 232 from an extension to a routing protocol could have a detrimental 233 impact on the performance or stability of implementations that do not 234 implement the extension. 236 4. Changes to the extension model. Adverse impacts are very likely 237 if the base protocol contains an extension mechanism and the proposed 238 extension does not fit into the model used to create and define that 239 mechanism. Extensions that have the same properties as those that 240 were anticipated when an extension mechanism was devised are much 241 less likely to be disruptive than extensions that don't fit the 242 model. Also, changes to the extension model itself (including 243 changes limiting further extensibility) can create interoperability 244 problems. 246 5. Changes to protocol syntax. Changes to protocol syntax bring with 247 them the potential for backward compatibility issues. If at all 248 possible, extensions should be designed for compatibility with 249 existing syntax, so as to avoid interoperability failures. 251 6. Interrelated extensions to multiple protocols. A set of 252 interrelated extensions to multiple protocols typically carries a 253 greater danger of interoperability issues or incompatibilities than a 254 simple extension. Consequently, it is important that such proposals 255 receive earlier and more in-depth review than unitary extensions. 257 7. Changes to the security model. Changes to the protocol security 258 model (or even addition of new security mechanisms within an existing 259 framework) can introduce security vulnerabilities or adversely impact 260 operations. Consequently, it is important that such proposals 261 undergo security as well as operational review. Security 262 considerations are discussed in Section 5. 264 8. Performance impact. An extension that impacts performance can 265 have adverse consequences, particularly if the performance of 266 existing deployments is affected. 268 2.2. When is an Extension Routine? 270 An extension may be considered 'routine' if it does not meet the 271 criteria for being considered a 'major' extension and if its handling 272 is opaque to the protocol itself (e.g. does not substantially change 273 the pattern of messages and responses). For this to apply, no 274 changes to the base protocol can be required, nor can changes be 275 required to existing and currently deployed implementations, unless 276 they make use of the extension. Furthermore, existing 277 implementations should not be impacted. This typically requires that 278 implementations be able to ignore 'routine' extensions without ill- 279 effects. 281 Examples of routine extensions include the Dynamic Host Configuration 282 Protocol (DHCP) vendor-specific option [RFC2132], Remote 283 Authentication Dial In User Service (RADIUS) Vendor-Specific 284 Attributes [RFC2865], the enterprise Object IDentifier (OID) tree for 285 Management Information Base (MIB) modules and vendor Multipurpose 286 Internet Mail Extension (MIME) types. Such extensions can safely be 287 made with minimal discussion. 289 Processes that allow routine extensions with minimal or no review 290 (such as the "First Come First Served" (FCFS) allocation policy 291 described in "Guidelines for Writing an IANA Considerations Section 292 in RFCs" [RFC5226]) should be used sparingly. In particular, they 293 should be limited to cases that are unlikely to result in 294 interoperability problems, or security or operational exposures. 296 Experience has shown that even routine extensions may benefit from 297 review by experts. For example, even though DHCP carries opaque 298 data, defining a new option using completely unstructured data may 299 lead to an option that is unnecessarily hard for clients and servers 300 to process. 302 3. Architectural Principles 304 This section describes basic principles of protocol extensibility: 306 1. Extensibility features should be limited to what is reasonably 307 anticipated when the protocol is developed. 309 2. Protocol extensions should be designed for global 310 interoperability. 312 3. Protocol extensions should be architecturally compatible with the 313 base protocol. 315 4. Protocol extension mechanisms should not be used to create 316 incompatible protocol variations. 318 5. Extension mechanisms need to be testable. 320 6. Protocol parameter assignments need to be coordinated to avoid 321 potential conflicts. 323 7. Extensions to critical components require special care. A 324 critical component is one whose failure can lead to Internet-wide 325 reliability and security issues or performance degradation. 327 3.1. Limited Extensibility 329 Protocols should not be made more extensible than clearly necessary 330 at inception, in order to enable optimization along dimensions (e.g., 331 bandwidth, state, memory requirements, deployment time, latency, 332 etc.) important to the most common use cases. 334 The process for defining new extensibility mechanisms should ensure 335 that adequate review of proposed extensions will take place before 336 widespread adoption. 338 As noted in "What Makes for a Successful Protocol" [RFC5218], "wildly 339 successful" protocols far exceed their original goals, in terms of 340 scale, purpose (being used in scenarios far beyond the initial 341 design), or both. This implies that all potential uses may not be 342 known at inception. As a result, extensibility mechanisms may need 343 to be revisited as additional use cases reveal themselves. However, 344 this does not imply that an initial design needs to take all 345 potential needs into account at inception. 347 3.2. Design for Global Interoperability 349 As noted in [RFC4775] Section 3.1: 351 According to its Mission Statement [RFC3935], the IETF produces 352 high quality, relevant technical and engineering documents, 353 including protocol standards. The mission statement goes on to 354 say that the benefit of these standards to the Internet "is in 355 interoperability - that multiple products implementing a standard 356 are able to work together in order to deliver valuable functions 357 to the Internet's users". 359 One consequence of this mission is that the IETF designs protocols 360 for the single Internet. The IETF expects its protocols to work 361 the same everywhere. Protocol extensions designed for limited 362 environments may be reasonable provided that products with these 363 extensions interoperate with products without the extensions. 364 Extensions that break interoperability are unacceptable when 365 products with and without the extension are mixed. It is the 366 IETF's experience that this tends to happen on the Internet even 367 when the original designers of the extension did not expect this 368 to happen. 370 Another consequence of this definition of interoperability is that 371 the IETF values the ability to exchange one product implementing a 372 protocol with another. The IETF often specifies mandatory-to- 373 implement functionality as part of its protocols so that there is 374 a core set of functionality sufficient for interoperability that 375 all products implement. The IETF tries to avoid situations where 376 protocols need to be profiled to specify which optional features 377 are required for a given environment, because doing so harms 378 interoperability on the Internet as a whole. 380 Since the global Internet is more than a collection of incompatible 381 protocols (or "profiles") for use in separate private networks, 382 implementers supporting extensions in shipping products or multi-site 383 experimental usage must assume that systems will need to interoperate 384 on the global Internet. 386 A key requirement for interoperable extension design is that the base 387 protocol must be well designed for interoperability, and that 388 extensions must have unambiguous semantics. Ideally, the protocol 389 mechanisms for extension and versioning should be sufficiently well 390 described that compatibility can be assessed on paper. Otherwise, 391 when two "private" or "experimental" extensions encounter each other 392 on a public network, unexpected interoperability problems may occur. 393 However, as noted in the TLS case study (see Appendix A.3), it is not 394 sufficient to design extensibility carefully; it also must be 395 implemented carefully. 397 3.2.1. Private Extensions 399 Experience shows that separate private networks often end up using 400 equipment from the same vendors, or end up having portable equipment 401 like laptop computers move between them, and networks that were 402 originally envisaged as being separate can end up being connected 403 later. 405 Consider a "private" extension installed on a work computer which, 406 being portable, is sometimes connected to a home network or a hotel 407 network. If the "private" extension is incompatible with an 408 unextended version of the same protocol, problems will occur. 410 Similarly, problems can occur if "private" extensions conflict with 411 each other. For example, imagine the situation where one site chose 412 to use DHCP [RFC2132] option code 62 for one meaning, and a different 413 site chose to use DHCP option code 62 for a completely different, 414 incompatible, meaning. It may be impossible for a vendor of portable 415 computing devices to make a device that works correctly in both 416 environments. 418 One approach to solving this problem has been to reserve parts of an 419 identifier namespace for "limited applicability" or "site-specific" 420 use, such as "X-" headers in email messages [RFC822] or "P-" headers 421 in SIP [RFC3427]. However, as noted in "Deprecating the X- Prefix 422 and Similar Constructs in Application Protocols" Appendix B 423 [RFC6648]: 425 The primary problem with the "X-" convention is that 426 unstandardized parameters have a tendency to leak into the 427 protected space of standardized parameters, thus introducing the 428 need for migration from the "X-" name to a standardized name. 429 Migration, in turn, introduces interoperability issues (and 430 sometimes security issues) because older implementations will 431 support only the "X-" name and newer implementations might support 432 only the standardized name. To preserve interoperability, newer 433 implementations simply support the "X-" name forever, which means 434 that the unstandardized name has become a de facto standard (thus 435 obviating the need for segregation of the name space into 436 standardized and unstandardized areas in the first place). 438 As a result, the notion of "X-" headers was removed from the Internet 439 Message Format standard when it was updated in 2001 [RFC2822] and 440 within SIP, [RFC5727] Section 4 deprecated the guidance provided in 441 [RFC3427] on the creation of "P-" headers. More generally, as noted 442 in [RFC6648] Section 1: 444 This document generalizes from the experience of the email and SIP 445 communities by doing the following: 447 1. Deprecates the "X-" convention for newly-defined parameters in 448 application protocols, even where that convention was only 449 implicit instead of being codified in a protocol specification (as 450 was done for email in [RFC822]). 452 3.2.2. Local Use 454 Values designated as "experimental" or "local use" are only 455 appropriate for use in a limited set of circumstances such as for use 456 in early implementations of an extension restricted to a single site. 458 For example, "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP 459 and TCP Headers" [RFC4727] discusses experimental values for IP and 460 transport headers, and "Definition of the Differentiated Services 461 Field (DS Field) in the IPv4 and IPv6 Headers" [RFC2474] defines 462 experimental/local use ranges for differentiated services code 463 points. 465 Such values should be used with care and only for their stated 466 purpose: experiments and local use. They are unsuitable for 467 Internet-wide use, since they may be used for conflicting purposes 468 and thereby cause interoperability failures. Packets containing 469 experimental or local use values must not be allowed out of the 470 domain in which they are meaningful. 472 "Assigning Experimental and Testing Numbers Considered Useful" BCP 82 473 [RFC3692] Section 1 provides guidance on the use of experimental code 474 points: 476 Numbers in the experimentation range ... are not intended to be 477 used in general deployments or be enabled by default in products 478 or other general releases. In those cases where a product or 479 release makes use of an experimental number, the end user must be 480 required to explicitly enable the experimental feature and 481 likewise have the ability to chose and assign which number from 482 the experimental range will be used for a specific purpose (i.e., 483 so the end user can ensure that use of a particular number doesn't 484 conflict with other on-going uses). Shipping a product with a 485 specific value pre-enabled would be inappropriate and can lead to 486 interoperability problems when the chosen value collides with a 487 different usage, as it someday surely will. 489 From the above, it follows that it would be inappropriate for a 490 group of vendors, a consortia, or another Standards Development 491 Organization to agree among themselves to use a particular value 492 for a specific purpose and then agree to deploy devices using 493 those values. By definition, experimental numbers are not 494 guaranteed to be unique in any environment other than one where 495 the local system administrator has chosen to use a particular 496 number for a particular purpose and can ensure that a particular 497 value is not already in use for some other purpose. 499 Once an extension has been tested and shown to be useful, a 500 permanent number could be obtained through the normal assignment 501 procedures. 503 However, as noted in [RFC6648] Appendix B, assigning a parameter 504 block for experimental use is only necessary when the parameter pool 505 is limited: 507 "Assigning Experimental and Testing Numbers Considered Useful" ... 508 implies that the "X-" prefix is also useful for experimental 509 parameters. However, BCP 82 addresses the need for protocol 510 numbers when the pool of such numbers is strictly limited (e.g., 511 DHCP options) or when a number is absolutely required even for 512 purely experimental purposes (e.g., the Protocol field of the IP 513 header). In almost all application protocols that make use of 514 protocol parameters (including email headers, media types, HTTP 515 headers, vCard parameters and properties, URNs, and LDAP field 516 names), the name space is not limited or constrained in any way, 517 so there is no need to assign a block of names for private use or 518 experimental purposes ... 520 Therefore it appears that segregating the parameter space into a 521 standardized area and a unstandardized area has few if any 522 benefits, and has at least one significant cost in terms of 523 interoperability. 525 3.2.3. Multi-site Experiments 527 Where an experiment is undertaken among a diverse set of experimental 528 sites connected via the global Internet, the use of "experimental" or 529 "local use" code points is inadvisable. This might include, for 530 example, sites that take a prototype implementation of some protocol 531 and use that both within their site but, importantly, among the full 532 set of other sites interested in that protocol. In such a situation 533 it is impractical and probably impossible to coordinate the de- 534 confliction of "experimental" code points. As noted in [RFC5226] 535 Section 4.1: 537 For private or local use ... No attempt is made to prevent 538 multiple sites from using the same value in different (and 539 incompatible) ways ... assignments are not generally useful for 540 broad interoperability. It is the responsibility of the sites 541 making use of the Private Use range to ensure that no conflicts 542 occur (within the intended scope of use). 544 HIP and LISP are examples where a set of experimental sites are 545 collaborating among themselves, but not necessarily in a tightly 546 coordinated way. Both HIP and LISP have dealt with this by having 547 unique non-experimental code points allocated to HIP and LISP, 548 respectively, at time of publication of their respective Experimental 549 RFCs. 551 3.3. Architectural Compatibility 553 Since protocol extension mechanisms may impact interoperability, it 554 is important that they be architecturally compatible with the base 555 protocol. 557 This includes understanding what current implementations do and how a 558 proposed extension will interact with deployed systems. Is it clear 559 when a proposed extension (or its proposed usage) will operationally 560 stress existing implementations or the underlying protocol itself if 561 widely deployed? If this is not explained in the base protocol 562 specification, is this covered in an extension design guidelines 563 document? 565 As part of the definition of new extension mechanisms, it is 566 important to address whether the mechanisms make use of features as 567 envisaged by the original protocol designers, or whether a new 568 extension mechanism is being invented. If a new extension mechanism 569 is being invented, then architectural compatibility issues need to be 570 addressed. 572 To assist in the assessment of architectural compatibility, protocol 573 documents should provide guidelines explaining how extensions should 574 be performed, and guidance on the appropriate use of protocol 575 extension mechanisms should be developed. 577 Protocol components that are designed with the specific intention of 578 allowing extensibility should be clearly identified, with specific 579 and complete instructions on how to extend them. This includes the 580 process for adequate review of extension proposals: do they need 581 community review and if so how much and by whom? 583 Documents relying on extension mechanisms need to explicitly identify 584 the mechanisms being relied upon. For example, a document defining 585 new data elements should not implicitly define new data types or 586 protocol operations without explicitly describing those dependencies 587 and discussing their impact. Where extension guidelines are 588 available, mechanisms need to indicate whether they are compliant 589 with those guidelines and if not, why not. 591 Examples of extension guidelines documents include: 593 1. "Guidelines for Extending the Extensible Provisioning Protocol 594 (EPP)" [RFC3735], which provides guidelines for use of EPP's 595 extension mechanisms to define new features and object management 596 capabilities. 598 2. "Guidelines for Authors and Reviewers of MIB Documents" BCP 111 599 [RFC4181], which provides guidance to protocol designers creating new 600 MIB modules. 602 3. "Guidelines for Authors of Extensions to the Session Initiation 603 Protocol (SIP)" [RFC4485], which outlines guidelines for authors of 604 SIP extensions. 606 4. "Considerations for Lightweight Directory Access Protocol (LDAP) 607 Extensions" BCP 118 [RFC4521], which discusses considerations for 608 designers of LDAP extensions. 610 5. "RADIUS Design Guidelines" BCP 158 [RFC6158], which provides 611 guidelines for the design of attributes used by the Remote 612 Authentication Dial In User Service (RADIUS) protocol. 614 3.4. Protocol Variations 616 Protocol variations - specifications that look very similar to the 617 original but don't interoperate with each other or with the original 618 - are even more harmful to interoperability than extensions. In 619 general, such variations should be avoided. Causes of protocol 620 variations include incompatible protocol extensions, uncoordinated 621 protocol development, and poorly designed "profiles". 623 Designing a protocol for extensibility may have the perverse side 624 effect of making it easy to construct incompatible extensions. 625 Protocol extension mechanisms should not be used to create 626 incompatible forks in development. An extension may lead to 627 interoperability failures unless the extended protocol correctly 628 supports all mandatory and optional features of the unextended base 629 protocol, and implementations of the base protocol operate correctly 630 in the presence of the extensions. In addition, it is necessary for 631 an extension to interoperate with other extensions. 633 As noted in "Uncoordinated Protocol Development Considered Harmful" 634 [RFC5704] Section 1, incompatible forks in development can result 635 from the uncoordinated adaptation of a protocol, parameter or code- 636 point: 638 In particular, the IAB considers it an essential principle of the 639 protocol development process that only one SDO maintains design 640 authority for a given protocol, with that SDO having ultimate 641 authority over the allocation of protocol parameter code-points 642 and over defining the intended semantics, interpretation, and 643 actions associated with those code-points. 645 Note that problems can occur even when one SDO maintains design 646 authority, if protocol parameter code-points are reused. As an 647 example, both RFC 5421 [RFC5421] and RFC 5422 [RFC5422] reused 648 previously assigned EAP type codes. As described in the IESG note in 649 [RFC5421]: 651 The reuse of previously assigned EAP Type Codes is incompatible 652 with EAP method negotiation as defined in RFC 3748. 654 3.4.1. Profiles 656 Profiling is a common technique for improving interoperability within 657 a target environment or set of scenarios. Generally speaking, there 658 are two approaches to profiling: 660 a) Removal or downgrading of normative requirements (thereby creating 661 potential interoperability problems); 663 b) Elevation of normative requirement levels (such as from a 664 MAY/SHOULD to a MUST). This can be done in order to improve 665 interoperability by narrowing potential implementation choices (such 666 as when the underlying protocol is ill-defined enough to permit non- 667 interoperable yet compliant implementations), or to meet specific 668 operational requirements (such as enabling use of stronger 669 cryptographic mechanisms than those mandated in the specification). 671 While approach a) is potentially harmful, approach b) may be 672 beneficial. 674 In order to avoid creating interoperability problems when profiled 675 implementations interact with others over the Global Internet, 676 profilers need to remain cognizant of the implications of removing 677 normative requirements. As noted in "Key words for use in RFCs to 678 Indicate Requirement Levels" [RFC2119] Section 6, imperatives are to 679 be used with care, and as a result, their removal within a profile is 680 likely to result in serious consequences: 682 Imperatives of the type defined in this memo must be used with 683 care and sparingly. In particular, they MUST only be used where 684 it is actually required for interoperation or to limit behavior 685 which has potential for causing harm (e.g., limiting 686 retransmissions) For example, they must not be used to try to 687 impose a particular method on implementors where the method is not 688 required for interoperability. 690 As noted in [RFC2119] Sections 3 and 4, recommendations cannot be 691 removed from profiles without serious consideration: 693 there may exist valid reasons in particular circumstances to 694 ignore a particular item, but the full implications must be 695 understood and carefully weighed before choosing a different 696 course. 698 Even the removal of optional features and requirements can have 699 consequences. As noted in [RFC2119] Section 5, implementations which 700 do not support optional features still retain the obligation to 701 ensure interoperation with implementations that do: 703 An implementation which does not include a particular option MUST 704 be prepared to interoperate with another implementation which does 705 include the option, though perhaps with reduced functionality. In 706 the same vein an implementation which does include a particular 707 option MUST be prepared to interoperate with another 708 implementation which does not include the option (except, of 709 course, for the feature the option provides.) 711 3.5. Testability 713 Experience has shown that it is insufficient merely to correctly 714 specify extensibility and backwards compatibility in an RFC. It is 715 also important that implementations respect the compatibility 716 mechanisms; if not, non-interoperable pairs of implementations may 717 arise. The TLS case study (Appendix A.3) shows how important this 718 can be. 720 In order to determine whether protocol extension mechanisms have been 721 properly implemented, testing is required. However, for this to be 722 possible, test cases need to be developed. If a base protocol 723 document specifies extension mechanisms but does not utilize them or 724 provide examples, it may not be possible to develop effective test 725 cases based on the base protocol specification alone. As a result, 726 base protocol implementations may not be properly tested and non- 727 compliant extension behavior may not be detected until these 728 implementations are widely deployed. 730 To encourage correct implementation of extension mechanisms, base 731 protocol specifications should clearly articulate the expected 732 behavior of extension mechanisms and should include examples of 733 correct extension behavior. 735 3.6. Protocol Parameter Registration 737 As noted in [RFC4775] Section 3.2: 739 An extension is often likely to make use of additional values 740 added to an existing IANA registry ... It is essential that such 741 new values are properly registered by the applicable procedures, 742 including expert review where applicable ... Extensions may even 743 need to create new IANA registries in some cases. 745 Experience shows that the importance of this is often 746 underestimated during extension design; designers sometimes assume 747 that a new codepoint is theirs for the asking, or even simply for 748 the taking. 750 Before creating a new protocol parameter registry, existing 751 registries should be examined to determine whether one of them can be 752 used instead (see http://www.iana.org/protocols/). 754 To avoid conflicting usage of the same registry value, as well as to 755 prevent potential difficulties in determining and transferring 756 parameter ownership, it is essential that all new values are 757 registered. If this is not done, there is nothing to prevent two 758 different extensions picking the same value. When these two 759 extensions "meet" each other on the Internet, failure is inevitable. 761 A surprisingly common case of this is misappropriation of assigned 762 Transmission Control Protocol (TCP) (or User Datagram Protocol (UDP)) 763 registered port numbers. This can lead to a client for one service 764 attempting to communicate with a server for another service. Another 765 common case is the use of unregistered URI schemes. Numerous cases 766 could be cited, but not without embarrassing specific implementers. 767 For general rules see [RFC5226], and for specific rules and 768 registries see the individual protocol specification RFCs and the 769 IANA web site. 771 While in theory a "standards track" or "IETF consensus" parameter 772 allocation policy may be instituted to encourage protocol parameter 773 registration or to improve interoperability, in practice problems can 774 arise if the procedures result in so much delay that requesters give 775 up and "self-allocate" by picking presumably-unused code points. 776 Where self-allocation is prevalent, the information contained within 777 registries may become inaccurate, particularly when third parties are 778 prohibited from updating entries so as to improve accuracy. In these 779 situations, it is important to consider whether registration 780 processes need to be changed to support the role of a registry as 781 "documentation of how the Internet is operating". 783 3.7. Extensions to Critical Protocols 785 Some protocols (such as Domain Name Service (DNS), Border Gateway 786 Protocol (BGP)) or algorithms (such as congestion control) have 787 become critical components of the Internet infrastructure. A 788 critical component is one whose failure can lead to Internet-wide 789 reliability and security issues or performance degradation. When 790 such protocols or algorithms are extended, the potential exists for 791 negatively impacting the reliability and security of the global 792 Internet. 794 As a result, special care needs to be taken with these extensions, 795 such as taking explicit steps to isolate existing uses from new ones. 796 For example, this can be accomplished by requiring the extension to 797 utilize a different port or multicast address, or by implementing the 798 extension within a separate process, without access to the data and 799 control structures of the base protocol. 801 Experience has shown that even when a mechanism has proven benign in 802 other uses, unforeseen issues may result when adding it to a critical 803 protocol. For example, both ISIS and OSPF support opaque Link State 804 Attributes (LSAs) which are propagated by intermediate nodes that 805 don't understand the LSA. Within Interior Gateway Protocols (IGPs), 806 support for opaque LSAs has proven useful without introducing 807 instability. 809 However, within BGP, 'attribute tunneling' has resulted in large 810 scale routing instabilities, since remote nodes may reset the LOCAL 811 session if the tunneled attributes are malformed or aren't 812 understood. This has required modification to BGP error handling, as 813 noted in "Error Handling for Optional Transitive Attribute BGP 814 Attributes" [I-D.ietf-idr-error-handling]. 816 In general, when extending protocols with local failure conditions, 817 tunneling of attributes that may trigger failures in non-adjacent 818 nodes should be avoided. This is particularly problematic when the 819 originating node receives no indicators of remote failures it may 820 have triggered. 822 4. Considerations for the Base Protocol 824 Good extension design depends on a well-designed base protocol. To 825 promote interoperability, designers should: 827 1. Ensure a well-written base protocol specification. Does the base 828 protocol specification make clear what an implementer needs to 829 support and does it define the impact that individual operations 830 (e.g., a message sent to a peer) will have when invoked? 832 2. Design for backward compatibility. Does the base protocol 833 specification describe how to determine the capabilities of a peer, 834 and negotiate the use of extensions? Does it indicate how 835 implementations handle extensions that they do not understand? Is it 836 possible for an extended implementation to negotiate with an 837 unextended peer to find a common subset of useful functions? 839 3. Respect underlying architectural or security assumptions. Is 840 there a document describing the underlying architectural assumptions, 841 as well as considerations that have arisen in operational experience? 842 Or are there undocumented considerations that have arisen as the 843 result of operational experience, after the original protocol was 844 published? 846 For example, will backward compatibility issues arise if extensions 847 reverse the flow of data, allow formerly static parameters to be 848 changed on the fly, or change assumptions relating to the frequency 849 of reads/writes? 851 4. Minimize impact on critical infrastructure. For a protocol that 852 represents a critical element of Internet infrastructure, it is 853 important to explain when it is appropriate to isolate new uses of 854 the protocol from existing ones. 856 For example, is it explained when a proposed extension (or usage) has 857 the potential for negatively impacting critical infrastructure to the 858 point where explicit steps would be appropriate to isolate existing 859 uses from new ones? 861 5. Provide guidance on data model extensions. Is there a document 862 that explains when a protocol extension is routine and when it 863 represents a major change? 865 For example, is it clear when a data model extension represents a 866 major versus a routine change? Are there guidelines describing when 867 an extension (such as a new data type) is likely to require a code 868 change within existing implementations? 870 4.1. Version Numbers 872 Any mechanism for extension by versioning must include provisions to 873 ensure interoperability, or at least clean failure modes. Imagine 874 someone creating a protocol and using a "version" field and 875 populating it with a value (1, let's say), but giving no information 876 about what would happen when a new version number appears in it. 877 This would be a bad protocol design and description; it should be 878 clear what the expectation is and how it can be tested. For example, 879 stating that 1.X must be compatible with any version 1 code, but 880 version 2 or greater is not expected to be compatible, has different 881 implications than stating that version 1 must be a proper subset of 882 version 2. 884 An example of an under-specified versioning mechanism is provided by 885 the MIME-Version header, originally defined in "MIME (Multipurpose 886 Internet Mail Extensions)" [RFC1341]. As noted in [RFC1341] Section 887 1: 889 A MIME-Version header field ... uses a version number to declare a 890 message to be conformant with this specification and allows mail 891 processing agents to distinguish between such messages and those 892 generated by older or non-conformant software, which is presumed 893 to lack such a field. 895 Beyond this, [RFC1341] provided little guidance on versioning 896 behavior, or even the format of the MIME-Version header, which was 897 specified to contain "text". [RFC1521] which obsoleted [RFC1341], 898 better defined the format of the version field, but still did not 899 clarify the versioning behavior: 901 Thus, future format specifiers, which might replace or extend 902 "1.0", are constrained to be two integer fields, separated by a 903 period. If a message is received with a MIME-version value other 904 than "1.0", it cannot be assumed to conform with this 905 specification ... 907 It is not possible to fully specify how a mail reader that 908 conforms with MIME as defined in this document should treat a 909 message that might arrive in the future with some value of MIME- 910 Version other than "1.0". However, conformant software is 911 encouraged to check the version number and at least warn the user 912 if an unrecognized MIME- version is encountered. 914 Thus, even though [RFC1521] defined a MIME-Version header with a 915 syntax suggestive of a "Major/Minor" versioning scheme, in practice 916 the MIME-Version header was little more than a decoration. 918 A better example is ROHC (Robust Header Compression). ROHCv1 919 [RFC3095] supports a certain set of profiles for compression 920 algorithms. But experience had shown that these profiles had 921 limitations, so the ROHC WG developed ROHCv2 [RFC5225]. A ROHCv1 922 implementation does not contain code for the ROHCv2 profiles. As the 923 ROHC WG charter said during the development of ROHCv2: 925 It should be noted that the v2 profiles will thus not be 926 compatible with the original (ROHCv1) profiles, which means less 927 complex ROHC implementations can be realized by not providing 928 support for ROHCv1 (over links not yet supporting ROHC, or by 929 shifting out support for ROHCv1 in the long run). Profile support 930 is agreed through the ROHC channel negotiation, which is part of 931 the ROHC framework and thus not changed by ROHCv2. 933 Thus in this case both backwards-compatible and backwards- 934 incompatible deployments are possible. The important point is to 935 have a clearly thought out approach to the question of operational 936 compatibility. In the past, protocols have utilized a variety of 937 strategies for versioning, many of which have proven problematic. 938 These include: 940 1. No versioning support. This approach is exemplified by Extensible 941 Authentication Protocol (EAP) [RFC3748] as well as Remote 942 Authentication Dial In User Service (RADIUS) [RFC2865], both of which 943 provide no support for versioning. While lack of versioning support 944 protects against the proliferation of incompatible dialects, the need 945 for extensibility is likely to assert itself in other ways, so that 946 ignoring versioning entirely may not be the most forward thinking 947 approach. 949 2. Highest mutually supported version (HMSV). In this approach, 950 implementations exchange the version numbers of the highest version 951 each supports, with the negotiation agreeing on the highest mutually 952 supported protocol version. This approach implicitly assumes that 953 later versions provide improved functionality, and that advertisement 954 of a particular version number implies support for all lower version 955 numbers. Where these assumptions are invalid, this approach breaks 956 down, potentially resulting in interoperability problems. An example 957 of this issue occurs in Protected Extensible Authentication Protocol 958 [I-D.josefsson-pppext-eap-tls-eap] where implementations of higher 959 versions may not necessarily provide support for lower versions. 961 3. Assumed backward compatibility. In this approach, implementations 962 may send packets with higher version numbers to legacy 963 implementations supporting lower versions, but with the assumption 964 that the legacy implementations will interpret packets with higher 965 version numbers using the semantics and syntax defined for lower 966 versions. This is the approach taken by Port-Based Access Control 967 [IEEE-802.1X]. For this approach to work, legacy implementations 968 need to be able to accept packets of known types with higher protocol 969 versions without discarding them; protocol enhancements need to 970 permit silent discard of unsupported extensions; implementations 971 supporting higher versions need to refrain from mandating new 972 features when encountering legacy implementations. 974 4. Major/minor versioning. In this approach, implementations with 975 the same major version but a different minor version are assumed to 976 be backward compatible, but implementations are required to negotiate 977 a mutually supported major version number. This approach assumes 978 that implementations with a lower minor version number but the same 979 major version can safely ignore unsupported protocol messages. 981 5. Min/max versioning. This approach is similar to HMSV, but without 982 the implied obligation for clients and servers to support all 983 versions back to version 1, in perpetuity. It allows clients and 984 servers to cleanly drop support for early versions when those 985 versions become so old that they are no longer relevant and no longer 986 required. In this approach, the client initiating the connection 987 reports the highest and lowest protocol versions it understands. The 988 server reports back the chosen protocol version: 990 a. If the server understands one or more versions in the client's 991 range, it reports back the highest mutually understood version. 993 b. If there is no mutual version, then the server reports back some 994 version that it does understand (selected as described below). The 995 connection is then typically dropped by client or server, but 996 reporting this version number first helps facilitate useful error 997 messages at the client end: 999 * If there is no mutual version, and the server speaks any version 1000 higher than client max, it reports the lowest version it speaks 1001 which is greater than the client max. The client can then report 1002 to the user, "You need to upgrade to at least version ." 1004 * Else, the server reports the highest version it speaks. The 1005 client can then report to the user, "You need to request the server 1006 operator to upgrade to at least version ." 1008 Protocols generally do not need any version-negotiation mechanism 1009 more complicated than the mechanisms described here. The nature of 1010 protocol version-negotiation mechanisms is that, by definition, they 1011 don't get widespread real-world testing until *after* the base 1012 protocol has been deployed for a while, and its deficiencies have 1013 become evident. This means that, to be useful, a protocol version 1014 negotiation mechanism should be simple enough that it can reasonably 1015 be assumed that all the implementers of the first protocol version at 1016 least managed to implement the version-negotiation mechanism 1017 correctly. 1019 4.2. Reserved Fields 1021 Protocols commonly include one or more "reserved" fields, clearly 1022 intended for future extensions. It is good practice to specify the 1023 value to be inserted in such a field by the sender (typically zero) 1024 and the action to be taken by the receiver when seeing some other 1025 value (typically no action). In packet format diagrams, such fields 1026 are typically labeled "MBZ", to be read as, "Must Be Zero on 1027 transmission, Must Be Ignored on reception." 1029 A common mistake of inexperienced protocol implementers is to think 1030 that "MBZ" means that it's their software's job to verify that the 1031 value of the field is zero on reception, and reject the packet if 1032 not. This is a mistake, and such software will fail when it 1033 encounters future versions of the protocol where these previously 1034 reserved fields are given new defined meanings. Similarly, protocols 1035 should carefully specify how receivers should react to unknown 1036 extensions (headers, TLVs etc.), such that failures occur only when 1037 that is truly the intended outcome. 1039 4.3. Encoding Formats 1041 Using widely-supported encoding formats leads to better 1042 interoperability and easier extensibility. 1044 As described in "IAB Thoughts on Encodings for International Domain 1045 Names" [RFC6055], the number of encodings should be minimized and 1046 complex encodings are generally a bad idea. As soon as one moves 1047 outside the ASCII repertoire, issues relating to collation, string 1048 valid code points, encoding, normalization and comparison arise that 1049 extensions must handle with care. See [draft-iab-identifier- 1050 comparison], [draft-ietf-precis-problem-statement] and [draft-ietf- 1051 precis-framework]. 1053 An example is the Simple Network Management Protocol (SNMP) Structure 1054 of Managed Information (SMI). Guidelines exist for defining the 1055 Management Information Base (MIB) objects that SNMP carries 1056 [RFC4181]. Also, multiple textual conventions have been published, 1057 so that MIB designers do not have to reinvent the wheel when they 1058 need a commonly encountered construct. For example, the "Textual 1059 Conventions for Internet Network Addresses" [RFC4001] can be used by 1060 any MIB designer needing to define objects containing IP addresses, 1061 thus ensuring consistency as the body of MIBs is extended. 1063 4.4. Parameter Space Design 1065 In some protocols the parameter space either has no specified limit 1066 (e.g., Header field names) or is sufficiently large that it is 1067 unlikely to be exhausted. In other protocols, the parameter space is 1068 limited, and in some cases, has proven inadequate to accommodate 1069 demand. Common mistakes include: 1071 a. A version field that is too small (e.g., two bits or less). When 1072 designing a version field, existing as well as potential versions of 1073 a protocol need to be taken into account. For example, if a protocol 1074 is being standardized for which there are existing implementations 1075 with known interoperability issues, more than one version for "pre- 1076 standard" implementations may be required. If two "pre-standard" 1077 versions are required in addition to a version for an IETF standard, 1078 then a two-bit version field would only leave one additional version 1079 code-point for a future update, which could be insufficient. This 1080 problem was encountered during the development of the PEAPv2 protocol 1081 [I-D.josefsson-pppext-eap-tls-eap]. 1083 b. A small parameter space (e.g., 8-bits or less) along with a First 1084 Come, First Served (FCFS) allocation policy. In general, an FCFS 1085 allocation policy is only appropriate in situations where parameter 1086 exhaustion is highly unlikely. In situations where substantial 1087 demand is anticipated within a parameter space, the space should 1088 either be designed to be sufficient to handle that demand, or vendor 1089 extensibility should be provided to enable vendors to self-allocate. 1090 The combination of a small parameter space, an FCFS allocation 1091 policy, and no support for vendor extensibility is particularly 1092 likely to prove ill-advised. An example of such a combination was 1093 the design of the original 8-bit EAP Method Type space [RFC2284]. 1095 Once the potential for parameter exhaustion becomes apparent, it is 1096 important that it be addressed as quickly as possible. Protocol 1097 changes can take years to appear in implementations and by then the 1098 exhaustion problem could become acute. 1100 Options for addressing a protocol parameter exhaustion problem 1101 include: 1103 Rethinking the allocation regime 1104 Where it becomes apparent that the size of a parameter space is 1105 insufficient to meet demand, it may be necessary to rethink the 1106 allocation mechanism, in order to prevent or delay parameter space 1107 exhaustion. In revising parameter allocation mechanisms, it is 1108 important to consider both supply and demand aspects so as to avoid 1109 unintended consequences such as self-allocation or the development 1110 of black markets for the re-sale of protocol parameters. 1112 For example, a few years after approval of RFC 2284 [RFC2284], it 1113 became clear that the combination of a FCFS allocation policy and 1114 lack of support for vendor-extensions had created the potential for 1115 exhaustion of the EAP Method Type space within a few years. To 1116 address the issue, [RFC3748] Section 6.2 changed the allocation 1117 policy for EAP Method Types from FCFS to Expert Review, with 1118 Specification Required. Since this allocation policy revision did 1119 not change the demand for EAP Method Types, it would have been 1120 likely to result in self-allocation within the standards space, had 1121 mechanisms not been provided to expand the method type space 1122 (including support for vendor-specific method types). 1124 Support for vendor-specific parameters 1125 If the demand that cannot be accommodated is being generated by 1126 vendors, merely making allocation harder could make things worse if 1127 this encourages vendors to self-allocate, creating interoperability 1128 problems. In such a situation, support for vendor-specific 1129 parameters should be considered, allowing each vendor to self- 1130 allocate within their own vendor-specific space based on a vendor's 1131 Private Enterprise Code (PEC). For example, in the case of the EAP 1132 Method Type space, [RFC3748] Section 6.2 also provided for an 1133 Expanded Type space for "functions specific only to one vendor's 1134 implementation". 1136 Extensions to the parameter space 1137 If the goal is to stave off exhaustion in the face of high demand, 1138 a larger parameter space may be helpful; this may require a new 1139 version of the protocol (such as was required for IPv6). Where 1140 vendor-specific parameter support is available, this may be 1141 achieved by allocating a PEC for IETF use. Otherwise it may be 1142 necessary to try to extend the size of the parameter fields, which 1143 could require a new protocol version or other substantial protocol 1144 changes. 1146 Parameter reclamation 1147 In order to gain time, it may be necessary to reclaim unused 1148 parameters. However, it may not be easy to determine whether a 1149 parameter that has been allocated is in use or not, particularly if 1150 the entity that obtained the allocation no longer exists or has 1151 been acquired (possibly multiple times). 1153 Parameter Transfer 1154 When all the above mechanisms have proved infeasible and parameter 1155 exhaustion looms in the near future, enabling the transfer of 1156 ownership of protocol parameters can be considered as a means for 1157 improving allocation efficiency. However, enabling transfer of 1158 parameter ownership can be far from simple if the parameter 1159 allocation process was not originally designed to enable title 1160 searches and ownership transfers. 1162 A parameter allocation process designed to uniquely allocate code- 1163 points is fundamentally different from one designed to enable title 1164 search and transfer. If the only goal is to ensure that a parameter 1165 is not allocated more than once, the parameter registry will only 1166 need to record the initial allocation. On the other hand, if the 1167 goal is to enable transfer of ownership of a protocol parameter, then 1168 it is important not only to record the initial allocation, but also 1169 to track subsequent ownership changes, so as to make it possible to 1170 determine and transfer title. Given the difficulty of converting 1171 from a unique allocation regime to one requiring support for title 1172 search and ownership transfer, it is best for the desired 1173 capabilities to be carefully thought through at the time of registry 1174 establishment. 1176 4.5. Cryptographic Agility 1178 Extensibility with respect to cryptographic algorithms is desirable 1179 in order to provide resilience against the compromise of any 1180 particular algorithm. "Guidance for Authentication, Authorization, 1181 and Accounting (AAA) Key Management" BCP 132 [RFC4962] Section 3 1182 provides some basic advice: 1184 The ability to negotiate the use of a particular cryptographic 1185 algorithm provides resilience against compromise of a particular 1186 cryptographic algorithm ... This is usually accomplished by 1187 including an algorithm identifier and parameters in the protocol, 1188 and by specifying the algorithm requirements in the protocol 1189 specification. While highly desirable, the ability to negotiate 1190 key derivation functions (KDFs) is not required. For 1191 interoperability, at least one suite of mandatory-to-implement 1192 algorithms MUST be selected ... 1194 This requirement does not mean that a protocol must support both 1195 public-key and symmetric-key cryptographic algorithms. It means 1196 that the protocol needs to be structured in such a way that 1197 multiple public-key algorithms can be used whenever a public-key 1198 algorithm is employed. Likewise, it means that the protocol needs 1199 to be structured in such a way that multiple symmetric-key 1200 algorithms can be used whenever a symmetric-key algorithm is 1201 employed. 1203 In practice, the most difficult challenge in providing cryptographic 1204 agility is providing for a smooth transition in the event that a 1205 mandatory-to-implement algorithm is compromised. Since it may take 1206 significant time to provide for widespread implementation of a 1207 previously undeployed alternative, it is often advisable to recommend 1208 implementation of alternative algorithms of distinct lineage in 1209 addition to those made mandatory-to-implement, so that an alternative 1210 algorithm is readily available. If such a recommended alternative is 1211 not in place, then it would be wise to issue such a recommendation as 1212 soon as indications of a potential weakness surface. This is 1213 particularly important in the case of potential weakness in 1214 algorithms used to authenticate and integrity-protect the 1215 cryptographic negotiation itself, such as KDFs or message integrity 1216 checks (MICs). Without secure alternatives to compromised KDF or MIC 1217 algorithms, it may not be possible to secure the cryptographic 1218 negotiation while retaining backward compatibility. 1220 4.6. Transport 1222 In the past, IETF protocols have been specified to operate over 1223 multiple transports. Often the protocol was originally specified to 1224 utilize a single transport, but limitations were discovered in 1225 subsequent deployment, so that additional transports were 1226 subsequently specified. 1228 In a number of cases, the protocol was originally specified to 1229 operate over UDP, but subsequent operation disclosed one or more of 1230 the following issues, leading to the specification of alternative 1231 transports: 1233 a. Payload fragmentation (often due to the introduction of 1234 extensions or additional usage scenarios); 1236 b. Problems with congestion control, transport reliability or 1237 efficiency; 1239 c. Lack of deployment in multicast scenarios, which had been a 1240 motivator for UDP transport. 1242 On the other hand, there are also protocols that were originally 1243 specified to operate over reliable transport that have subsequently 1244 defined transport over UDP, due to one or more of the following 1245 issues: 1247 d. NAT traversal concerns that were more easily addressed with UDP 1248 transport; 1250 e. Scalability problems, which could be improved by UDP transport. 1252 Since specification of a single transport offers the highest 1253 potential for interoperability, protocol designers should carefully 1254 consider not only initial but potential future requirements in the 1255 selection of a transport protocol. Where UDP transport is selected, 1256 the guidance provided in "Unicast UDP Usage Guidelines for 1257 Application Designers" [RFC5405] should be taken into account. 1259 After significant deployment has occurred, there are few satisfactory 1260 options for addressing problems with the originally selected 1261 transport protocol. While specification of additional transport 1262 protocols is possible, removal of a widely implemented transport 1263 protocol is likely to result in interoperability problems and should 1264 be avoided. 1266 Mandating support for the initially selected transport protocol, 1267 while designating additional transport protocols as optional may have 1268 limitations. Since optional transport protocols are typically 1269 introduced due to the advantages they afford in certain scenarios, in 1270 those situations implementations not supporting optional transport 1271 protocols may exhibit degraded performance or may even fail. 1273 While mandating support for multiple transport protocols may appear 1274 attractive, designers need to realistically evaluate the likelihood 1275 that implementers will conform to the requirements. For example, 1276 where resources are limited (such as in embedded systems), 1277 implementers may choose to only support a subset of the mandated 1278 transport protocols, resulting in non-interoperable protocol 1279 variants. 1281 4.7. Handling of Unknown Extensions 1283 IETF protocols have utilized several techniques for handling of 1284 unknown extensions. One technique (often used for vendor-specific 1285 extensions) is to specify that unknown extensions be "silently 1286 discarded". 1288 While this approach can deliver a high level of interoperability, 1289 there are situations in which it is problematic. For example, where 1290 security functionality is involved, "silent discard" may not be 1291 satisfactory, particularly if the recipient does not provide feedback 1292 as to whether it supports the extension or not. This can lead to 1293 operational security issues that are difficult to detect and correct, 1294 as noted in Appendix A.2 and "common RADIUS Implementation Issues and 1295 Suggested Fixes" [RFC5080] Section 2.5. 1297 In order to ensure that a recipient supports an extension, a 1298 recipient encountering an unknown extension may be required to 1299 explicitly reject it and to return an error, rather than proceeding. 1300 This can be accomplished via a "Mandatory" bit in a TLV-based 1301 protocol such as L2TP [RFC2661], or a "Require" or "Proxy-Require" 1302 header in a text-based protocol such as SIP [RFC3261] or HTTP 1303 [RFC2616]. 1305 Since a mandatory extension can result in an interoperability failure 1306 when communicating with a party that does not support the extension, 1307 this designation may not be permitted for vendor-specific extensions, 1308 and may only be allowed for standards-track extensions. To enable 1309 fallback operation with degraded functionality, it is good practice 1310 for the recipient to indicate the reason for the failure, including a 1311 list of unsupported extensions. The initiator can then retry without 1312 the offending extensions. 1314 Typically only the recipient will find itself in the position of 1315 rejecting a mandatory extension, since the initiator can explicitly 1316 indicate which extensions are supported, with the recipient choosing 1317 from among the supported extensions. This can be accomplished via an 1318 exchange of TLVs, such as in IKEv2 [RFC5996] or Diameter [RFC3588], 1319 or via use of "Accept", "Accept-Encoding", "Accept-Language", "Allow" 1320 and "Supported" headers in a text-based protocol such as SIP 1321 [RFC3261] or HTTP [RFC2616]. 1323 5. Security Considerations 1325 An extension must not introduce new security risks without also 1326 providing adequate counter-measures, and in particular it must not 1327 inadvertently defeat security measures in the unextended protocol. 1328 Thus, the security analysis for an extension needs to be as thorough 1329 as for the original protocol - effectively it needs to be a 1330 regression analysis to check that the extension doesn't inadvertently 1331 invalidate the original security model. 1333 This analysis may be simple (e.g., adding an extra opaque data 1334 element is unlikely to create a new risk) or quite complex (e.g., 1335 adding a handshake to a previously stateless protocol may create a 1336 completely new opportunity for an attacker). 1338 When the extensibility of a design includes allowing for new and 1339 presumably more powerful cryptographic algorithms to be added, 1340 particular care is needed to ensure that the result is in fact 1341 increased security. For example, it may be undesirable from a 1342 security viewpoint to allow negotiation down to an older, less secure 1343 algorithm. 1345 6. IANA Considerations 1347 [RFC Editor: please remove this section prior to publication.] 1349 This document has no IANA Actions. 1351 7. References 1353 7.1. Normative References 1355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1356 Requirement Levels", BCP 14, RFC 2119, March 1997. 1358 [RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures for 1359 Protocol Extensions and Variations", BCP 125, RFC 4775, 1360 December 2006. 1362 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1363 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 1365 7.2. Informative References 1367 [I-D.ietf-idr-error-handling] 1368 Scudder, J., Chen, E., Mohapatra, P. and K. Patel, "Revised 1369 Error Handling for BGP UPDATE Messages", Internet draft (work 1370 in progress), draft-ietf-idr-error-handling-02, June, 2012. 1372 [I-D.josefsson-pppext-eap-tls-eap] 1373 Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G. and S. 1374 Josefsson, "Protected EAP Protocol (PEAP) Version 2", draft- 1375 josefsson-pppext-eap-tls-eap-10.txt, Expired Internet draft 1376 (work in progress), October 2004. 1378 [IEEE-802.1X] 1379 Institute of Electrical and Electronics Engineers, "Local and 1380 Metropolitan Area Networks: Port-Based Network Access 1381 Control", IEEE Standard 802.1X-2004, December 2004. 1383 [RFC822] Crocker, D., "Standard for the format of ARPA Internet text 1384 messages", STD 11, RFC 822, August 1982. 1386 [RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered 1387 Harmful", RFC 1263, October 1991. 1389 [RFC1341] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail 1390 Extensions): Mechanisms for Specifying and Describing the 1391 Format of Internet Message Bodies", RFC 1341, June 1992. 1393 [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail 1394 Extensions) Part One: Mechanisms for Specifying and Describing 1395 the Format of Internet Message Bodies", RFC 1521, September 1396 1993. 1398 [RFC2058] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 1399 Authentication Dial In User Service (RADIUS)", RFC 2058, 1400 January 1997. 1402 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1403 Extensions", RFC 2132, March 1997. 1405 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1406 2246, January 1999. 1408 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication 1409 Protocol (EAP)", RFC 2284, March 1998. 1411 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition 1412 of the Differentiated Services Field (DS Field) in the IPv4 1413 and IPv6 Headers", RFC 2474, December 1998. 1415 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 1416 L., Leach, P., and T. Berners-Lee, "Hypertext Transfer 1417 Protocol -- HTTP/1.1", RFC 2616, June 1999. 1419 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., 1420 and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 1421 2661, August 1999. 1423 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",RFC 2671, 1424 August 1999. 1426 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 1428 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1429 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1430 2000. 1432 [RFC2882] Mitton, D., "Network Access Servers Requirements: Extended 1433 RADIUS Practices", RFC 2882, July 2000. 1435 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1436 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., 1437 Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, 1438 T., Yoshimura, T., and H. Zheng, "RObust Header Compression 1439 (ROHC): Framework and four profiles: RTP, UDP, ESP, and 1440 uncompressed", RFC 3095, July 2001. 1442 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1443 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1444 Session Initiation Protocol", RFC 3261, June 2002. 1446 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. 1447 Rosen, "Change Process for the Session Initiation Protocol 1448 (SIP)", BCP 67, RFC 3427, December 2002. 1450 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1451 Authentication Dial In User Service)", RFC 3575, July 2003. 1453 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, 1454 "Diameter Base Protocol", RFC 3588, September 2003. 1456 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) 1457 Types", RFC 3597, September 2003. 1459 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1460 Considered Useful", BCP 82, RFC 3692, January 2004. 1462 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 1463 Provisioning Protocol (EPP)", RFC 3735, March 2004. 1465 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 1466 Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC 1467 3748, June 2004. 1469 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", RFC 3935, 1470 October 2004. 1472 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 1473 Schoenwaelder, "Textual Conventions for Internet Network 1474 Addresses", RFC 4001, February 2005. 1476 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1477 Documents", BCP 111, RFC 4181, September 2005. 1479 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 1480 T. Wright, "Transport Layer Security (TLS) Extensions", RFC 1481 4366, April 2006. 1483 [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of 1484 Extensions to the Session Initiation Protocol (SIP)", RFC 1485 4485, May 2006. 1487 [RFC4521] Zeilenga, K., "Considerations for Lightweight Directory Access 1488 Protocol (LDAP) Extensions", BCP 118, RFC 4521, June 2006. 1490 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1491 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 1493 [RFC4929] Andersson, L. and A. Farrel, "Change Process for Multiprotocol 1494 Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols 1495 and Procedures", BCP 129, RFC 4929, June 2007. 1497 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 1498 Authorization, and Accounting (AAA) Key Management", BCP 132, 1499 RFC 4962, July 2007. 1501 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In 1502 User Service (RADIUS) Implementation Issues and Suggested 1503 Fixes", RFC 5080, December 2007. 1505 [RFC5218] Thaler, D., and B. Aboba, "What Makes for a Successful 1506 Protocol?", RFC 5218, July 2008. 1508 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 1509 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP- 1510 Lite", RFC 5225, April 2008. 1512 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1513 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1515 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1516 October 2008. 1518 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for 1519 Application Designers", RFC 5405 (BCP 145), November 2008. 1521 [RFC5421] Cam-Winget, N. and H. Zhou, "Basic Password Exchange within 1522 the Flexible Authentication via Secure Tunneling Extensible 1523 Authentication Protocol (EAP-FAST)", RFC 5421, March 2009. 1525 [RFC5422] Cam-Winget, N., McGrew, D., Salowey, J. and H. Zhou, "Dynamic 1526 Provisioning Using Flexible Authentication via Secure 1527 Tunneling Extensible Authentication Protocol (EAP-FAST)", RFC 1528 5422, March 2009. 1530 [RFC5704] Bryant, S. and M. Morrow, "Uncoordinated Protocol Development 1531 Considered Harmful", RFC 5704, November 2009. 1533 [RFC5727] Peterson, J., Jennings, C. and R. Sparks, "Change Process for 1534 the Session Initiation Protocol (SIP) and the Real-time 1535 Applications and Infrastructure Area", BCP 67, RFC 5727, March 1536 2010. 1538 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet Key 1539 Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 1540 2010. 1542 [RFC6055] Thaler, D., Klensin, J. and S. Cheshire, "IAB Thoughts on 1543 Encodings for Internationalized Domain Names", RFC 6055, 1544 February 2011. 1546 [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", BCP 158, 1547 RFC 6158, March 2011. 1549 [RFC6648] Saint-Andre, P., Crocker, D. and M. Nottingham, "Deprecating 1550 the 'X-' Prefix and Similar Constructs in Application 1551 Protocols", RFC 6648, June 2012. 1553 Acknowledgments 1555 This document is heavily based on an earlier draft by Scott Bradner 1556 and Thomas Narten, other parts of which were eventually published as 1557 RFC 4775. 1559 That draft stated: The initial version of this document was put 1560 together by the IESG in 2002. Since then, it has been reworked in 1561 response to feedback from John Loughney, Henrik Levkowetz, Mark 1562 Townsley, Randy Bush and others. 1564 Valuable comments and suggestions on the current form of the document 1565 were made by Loa Andersson, Ran Atkinson, Stewart Bryant, Leslie 1566 Daigle, Alan DeKok, Roy Fielding, Phillip Hallam-Baker, Ted Hardie, 1567 Alfred Hoenes, John Klensin, Barry Leiba, Eric Rescorla, Adam Roach 1568 and Pekka Savola. The text on TLS experience was contributed by 1569 Yngve Pettersen. 1571 IAB Members at the Time of Approval 1573 Bernard Aboba 1574 Jari Arkko 1575 Marc Blanchet 1576 Ross Callon 1577 Alissa Cooper 1578 Spencer Dawkins 1579 Joel Halpern 1580 Russ Housley 1581 David Kessens 1582 Danny McPherson 1583 Jon Peterson 1584 Dave Thaler 1585 Hannes Tschofenig 1587 Appendix A. Examples 1589 This section discusses some specific examples, as case studies. 1591 A.1. Already documented cases 1593 There are certain documents that specify a change process or describe 1594 extension considerations for specific IETF protocols: 1596 The SIP change process [RFC3427], [RFC4485], [RFC5727] 1597 The (G)MPLS change process (mainly procedural) [RFC4929] 1598 LDAP extensions [RFC4521] 1599 EPP extensions [RFC3735] 1600 DNS extensions [RFC2671][RFC3597] 1601 SMTP extensions [RFC5321] 1603 It is relatively common for MIBs, which are all in effect extensions 1604 of the SMI data model, to be defined or extended outside the IETF. 1605 BCP 111 [RFC4181] offers detailed guidance for authors and reviewers. 1607 A.2. RADIUS Extensions 1609 The RADIUS [RFC2865] protocol was designed to be extensible via 1610 addition of Attributes. This extensibility model assumed that 1611 Attributes would conform to a limited set of data types and that 1612 vendor extensions would be limited to use by vendors, in situations 1613 in which interoperability was not required. Subsequent developments 1614 have stretched those assumptions. 1616 From the beginning, uses of the RADIUS protocol extended beyond the 1617 scope of the original protocol definition (and beyond the scope of 1618 the RADIUS Working Group charter). In addition to rampant self- 1619 allocation within the limited RADIUS standard attribute space, 1620 vendors defined their own RADIUS commands. This lead to the rapid 1621 proliferation of vendor-specific protocol variants. To this day, 1622 many common implementation practices have not been documented. For 1623 example, authentication server implementations are often typically 1624 based on a Data Dictionary, enabling addition of Attributes without 1625 requiring code changes. Yet the concept of a Data Dictionary is not 1626 mentioned in [RFC2865]. 1628 As noted in "Extended RADIUS Practices" [RFC2882] Section 1: 1630 The RADIUS Working Group was formed in 1995 to document the 1631 protocol of the same name, and was chartered to stay within a set 1632 of bounds for dial-in terminal servers. Unfortunately the real 1633 world of Network Access Servers (NASes) hasn't stayed that small 1634 and simple, and continues to evolve at an amazing rate. 1636 This document shows some of the current implementations on the 1637 market have already outstripped the capabilities of the RADIUS 1638 protocol. A quite a few features have been developed completely 1639 outside the protocol. These features use the RADIUS protocol 1640 structure and format, but employ operations and semantics well 1641 beyond the RFC documents. 1643 The limited set of data types defined in [RFC2865] has lead to 1644 subsequent documents defining new data types. Since new data types 1645 are typically defined implicitly as part of defining a new attribute, 1646 and because RADIUS client and server implementations differ in their 1647 support of these additional specifications, there is no definitive 1648 registry of RADIUS data types and data type support has been 1649 inconsistent. To catalog commonly implemented data types as well as 1650 to provide guidance for implementers as well as attribute designers, 1651 "RADIUS Design Guidelines" [RFC6158] Section 2.1 includes advice on 1652 basic and complex data types. Unfortunately, these guidelines were 1653 published 14 years after the RADIUS protocol was first documented in 1654 [RFC2058]. 1656 Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism 1657 for Vendor-Specific extensions (Attribute 26), and states that use of 1658 Vendor-Specific extensions: 1660 should be encouraged instead of allocation of global attribute 1661 types, for functions specific only to one vendor's implementation 1662 of RADIUS, where no interoperability is deemed useful. 1664 However, in practice usage of Vendor-Specific Attributes (VSAs) has 1665 been considerably broader than this. In particular, VSAs have been 1666 used by Standards Development Organizations (SDOs) to define their 1667 own extensions to the RADIUS protocol. This has caused a number of 1668 problems. 1670 One issue concerns the data model for VSAs. Since it was not 1671 envisaged that multi-vendor VSA implementations would need to 1672 interoperate, the RADIUS specification [RFC2865] does not define the 1673 data model for VSAs, and allows multiple sub-attributes to be 1674 included within a single Attribute of type 26. Since this enables 1675 VSAs to be defined which would not be supportable by current 1676 implementations if placed within the standard RADIUS attribute space, 1677 this has caused problems in standardizing widely deployed VSAs, as 1678 discussed in "RADIUS Design Guidelines" BCP 158 [RFC6158] Section 1679 2.4: 1681 RADIUS attributes can often be developed within the vendor space 1682 without loss (and possibly even with gain) in functionality. As a 1683 result, translation of RADIUS attributes developed within the 1684 vendor space into the standard space may provide only modest 1685 benefits, while accelerating the exhaustion of the standard space. 1686 We do not expect that all RADIUS attribute specifications 1687 requiring interoperability will be developed within the IETF, and 1688 allocated from the standard space. A more scalable approach is to 1689 recognize the flexibility of the vendor space, while working 1690 toward improvements in the quality and availability of RADIUS 1691 attribute specifications, regardless of where they are developed. 1693 It is therefore NOT RECOMMENDED that specifications intended 1694 solely for use by a vendor or SDO be translated into the standard 1695 space. 1697 Another issue is how implementations should handle unknown VSAs. 1698 [RFC2865] Section 5.26 states: 1700 Servers not equipped to interpret the vendor-specific information 1701 sent by a client MUST ignore it (although it may be reported). 1702 Clients which do not receive desired vendor-specific information 1703 SHOULD make an attempt to operate without it, although they may do 1704 so (and report they are doing so) in a degraded mode. 1706 However, since VSAs do not contain a "mandatory" bit, RADIUS clients 1707 and servers may not know whether it is safe to ignore unknown VSAs. 1708 For example, in the case where VSAs pertain to security (e.g., 1709 Filters), it may not be safe to ignore them. As a result, "Common 1710 Remote Authentication Dial In User Service (RADIUS) Implementation 1711 Issues and Suggested Fixes" [RFC5080] Section 2.5 includes the 1712 following caution: 1714 To avoid misinterpretation of service requests encoded within 1715 VSAs, RADIUS servers SHOULD NOT send VSAs containing service 1716 requests to RADIUS clients that are not known to understand them. 1717 For example, a RADIUS server should not send a VSA encoding a 1718 filter without knowledge that the RADIUS client supports the VSA. 1720 In addition to extending RADIUS by use of VSAs, SDOs have also 1721 defined new values of the Service-Type attribute in order to create 1722 new RADIUS commands. Since the RADIUS specification [RFC2865] 1723 defined Service-Type values as being allocated First Come, First 1724 Served (FCFS), this permitted new RADIUS commands to be allocated 1725 without IETF review. This oversight has since been fixed in "IANA 1726 Considerations for RADIUS" [RFC3575]. 1728 A.3. TLS Extensions 1730 The Secure Sockets Layer (SSL) v2 protocol was developed by Netscape 1731 to be used to secure online transactions on the Internet. It was 1732 later replaced by SSL v3, also developed by Netscape. SSL v3 was 1733 then further developed by the IETF as the Transport Layer Security 1734 (TLS) 1.0 [RFC2246]. 1736 The SSL v3 protocol was not explicitly specified to be extended. 1737 Even TLS 1.0 did not define an extension mechanism explicitly. 1738 However, extension "loopholes" were available. Extension mechanisms 1739 were finally defined in "Transport Layer Security (TLS) Extensions" 1740 [RFC4366]: 1742 o New versions 1743 o New cipher suites 1744 o Compression 1745 o Expanded handshake messages 1746 o New record types 1747 o New handshake messages 1749 The protocol also defines how implementations should handle unknown 1750 extensions. 1752 Of the above extension methods, new versions and expanded handshake 1753 messages have caused the most interoperability problems. 1754 Implementations are supposed to ignore unknown record types but to 1755 reject unknown handshake messages. 1757 The new version support in SSL/TLS includes a capability to define 1758 new versions of the protocol, while allowing newer implementations to 1759 communicate with older implementations. As part of this 1760 functionality, some Key Exchange methods include functionality to 1761 prevent version rollback attacks. 1763 The experience with this upgrade functionality in SSL and TLS is 1764 decidedly mixed: 1766 o SSL v2 and SSL v3/TLS are not compatible. It is possible to use 1767 SSL v2 protocol messages to initiate a SSL v3/TLS connection, but 1768 it is not possible to communicate with a SSL v2 implementation 1769 using SSL v3/TLS protocol messages. 1770 o There are implementations that refuse to accept handshakes using 1771 newer versions of the protocol than they support. 1772 o There are other implementations that accept newer versions, but 1773 have implemented the version rollback protection clumsily. 1775 The SSL v2 problem has forced SSL v3 and TLS clients to continue to 1776 use SSL v2 Client Hellos for their initial handshake with almost all 1777 servers until 2006, much longer than would have been desirable, in 1778 order to interoperate with old servers. 1780 The problem with incorrect handling of newer versions has also forced 1781 many clients to actually disable the newer protocol versions, either 1782 by default, or by automatically disabling the functionality, to be 1783 able to connect to such servers. Effectively, this means that the 1784 version rollback protection in SSL and TLS is non-existent if talking 1785 to a fatally compromised older version. 1787 SSL v3 and TLS also permitted expansion of the Client Hello and 1788 Server Hello handshake messages. This functionality was fully 1789 defined by the introduction of TLS Extensions, which makes it 1790 possible to add new functionality to the handshake, such as the name 1791 of the server the client is connecting to, request certificate status 1792 information, indicate Certificate Authority support, maximum record 1793 length, etc. Several of these extensions also introduce new 1794 handshake messages. 1796 It has turned out that many SSL v3 and TLS implementations that do 1797 not support TLS Extensions, did not, as required by the protocol 1798 specifications, ignore the unknown extensions, but instead failed to 1799 establish connections. Several of the implementations behaving in 1800 this manner are used by high profile Internet sites, such as online 1801 banking sites, and this has caused a significant delay in the 1802 deployment of clients supporting TLS Extensions, and several of the 1803 clients that have enabled support are using heuristics that allow 1804 them to disable the functionality when they detect a problem. 1806 Looking forward, the protocol version problem, in particular, can 1807 cause future security problems for the TLS protocol. The strength of 1808 the digest algorithms (MD5 and SHA-1) used by SSL and TLS is 1809 weakening. If MD5 and SHA-1 weaken to the point where it is feasible 1810 to mount successful attacks against older SSL and TLS versions, the 1811 current error recovery used by clients would become a security 1812 vulnerability (among many other serious problems for the Internet). 1814 To address this issue, TLS 1.2 [RFC5246] makes use of a newer 1815 cryptographic hash algorithm (SHA-256) during the TLS handshake by 1816 default. Legacy ciphersuites can still be used to protect 1817 application data, but new ciphersuites are specified for data 1818 protection as well as for authentication within the TLS handshake. 1819 The hashing method can also be negotiated via a Hello extension. 1820 Implementations are encouraged to implement new ciphersuites, and to 1821 enable the negotiation of the ciphersuite used during a TLS session 1822 to be governed by policy, thus enabling a more rapid transition away 1823 from weakened ciphersuites. 1825 The lesson to be drawn from this experience is that it isn't 1826 sufficient to design extensibility carefully; it must also be 1827 implemented carefully by every implementer, without exception. Test 1828 suites and certification programs can help provide incentives for 1829 implementers to pay attention to implementing extensibility 1830 mechanisms correctly. 1832 A.4. L2TP Extensions 1834 Layer Two Tunneling Protocol (L2TP) [RFC2661] carries Attribute-Value 1835 Pairs (AVPs), with most AVPs having no semantics to the L2TP protocol 1836 itself. However, it should be noted that L2TP message types are 1837 identified by a Message Type AVP (Attribute Type 0) with specific AVP 1838 values indicating the actual message type. Thus, extensions relating 1839 to Message Type AVPs would likely be considered major extensions. 1841 L2TP also provides for Vendor-Specific AVPs. Because everything in 1842 L2TP is encoded using AVPs, it would be easy to define vendor- 1843 specific AVPs that would be considered major extensions. 1845 L2TP also provides for a "mandatory" bit in AVPs. Recipients of L2TP 1846 messages containing AVPs they do not understand but that have the 1847 mandatory bit set, are expected to reject the message and terminate 1848 the tunnel or session the message refers to. This leads to 1849 interesting interoperability issues, because a sender can include a 1850 vendor-specific AVP with the M-bit set, which then causes the 1851 recipient to not interoperate with the sender. This sort of behavior 1852 is counter to the IETF ideals, as implementations of the IETF 1853 standard should interoperate successfully with other implementations 1854 and not require the implementation of non-IETF extensions in order to 1855 interoperate successfully. Section 4.2 of the L2TP specification 1856 [RFC2661] includes specific wording on this point, though there was 1857 significant debate at the time as to whether such language was by 1858 itself sufficient. 1860 Fortunately, it does not appear that the potential problems described 1861 above have yet become a problem in practice. At the time of this 1862 writing, the authors are not aware of the existence of any vendor- 1863 specific AVPs that also set the M-bit. 1865 Change log [RFC Editor: please remove this section] 1867 -16: 2012-6-26. Resolved issue 176. 1868 -15: 2012-6-25. Resolved issues 174 and 175. 1869 -14: 2012-6-09. Resolved issue 169. 1870 -13: 2012-6-03. Resolved issue 166. 1871 -12: 2012-5-27. Resolved issues 127, 128, 129, 133 and 161. 1872 -11: 2012-2-22. Resolved issue 126. 1873 -10: 2012-2-12. Resolved issues 106 and 108. 1874 -09: 2011-10-30. Resolved additional issues. 1875 -08: 2011-10-22. Resolved additional issues. 1877 -07: 2011-7-24. Resolved issues raised in Call for Comment. 1878 -06: 2011-3-01. Incorporated corrections and organizational updates. 1879 -05: 2011-2-04. Added to the Security Considerations section. 1880 -04: 2011-2-01. Added material on cryptographic agility. 1881 -03: 2011-1-25. Updates and reorganization. 1882 -02: 2010-7-12. Updates by Bernard Aboba. 1883 -01: 2010-4-07. Updates by Stuart Cheshire. 1884 -00: 2009-4-24. Updated boilerplate, author list. 1886 -04: 2008-10-24. Updated author addresses, editorial fixes. 1888 -03: 2008-10-17. Updated references, added material relating to 1889 versioning. 1891 -02: 2007-06-15. Reorganized Sections 2 and 3. 1893 -01: 2007-03-04. Updated according to comments, especially the 1894 wording about TLS, added various specific examples. 1896 draft-carpenter-extension-recs-00: original version, 2006-10-12. 1897 Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by 1898 focusing on architectural issues; the procedural issues were moved to 1899 RFC 4775. 1901 Authors' Addresses 1903 Brian Carpenter 1904 Department of Computer Science 1905 University of Auckland 1906 PB 92019 1907 Auckland, 1142 1908 New Zealand 1910 Email: brian.e.carpenter@gmail.com 1912 Bernard Aboba 1913 Microsoft Corporation 1914 One Microsoft Way 1915 Redmond, WA 98052 1917 EMail: bernard_aboba@hotmail.com 1919 Stuart Cheshire 1920 Apple Computer, Inc. 1921 1 Infinite Loop 1922 Cupertino, CA 95014 1924 EMail: cheshire@apple.com