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