idnits 2.17.1 draft-iab-extension-recs-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 == Line 391 has weird spacing: '...es used by th...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (18 June 2011) is 4693 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 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2284 (Obsoleted by RFC 3748) -- 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 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft B. Aboba (ed) 4 Intended Status: Informational S. Cheshire 5 Expires: December 23, 2011 Internet Architecture Board 6 18 June 2011 8 Design Considerations for Protocol Extensions 9 draft-iab-extension-recs-06 11 Abstract 13 This document discusses issues related to the extensibility of 14 Internet protocols, with a focus on the architectural design 15 considerations involved. Case study examples are included. It is 16 intended to assist designers of both base protocols and extensions. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on December 23, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1 Requirements Language . . . . . . . . . . . . . . . . . . 4 72 2. Routine and Major Extensions . . . . . . . . . . . . . . . . . 5 73 2.1 When is an Extension Routine? . . . . . . . . . . . . . . 5 74 2.2 What Constitutes a Major Extension? . . . . . . . . . . . 6 75 3. Architectural Principles . . . . . . . . . . . . . . . . . . . 7 76 3.1 Limited Extensibility . . . . . . . . . . . . . . . . . . 7 77 3.2 Design for Global Interoperability . . . . . . . . . . . . 8 78 3.3 Architectural Compatibility . . . . . . . . . . . . . . . 9 79 3.4 Protocol Variations . . . . . . . . . . . . . . . . . . . 10 80 3.5 Testability . . . . . . . . . . . . . . . . . . . . . . . 11 81 3.6 Parameter Parameter Registration . . . . . . . . . . . . . 12 82 3.7 Extensions to Critical Protocols . . . . . . . . . . . . . 14 83 4. Considerations for the Base Protocol . . . . . . . . . . . . . 14 84 4.1 Version Numbers . . . . . . . . . . . . . . . . . . . . . 15 85 4.2 Reserved Fields . . . . . . . . . . . . . . . . . . . . . 18 86 4.3 Encoding Formats . . . . . . . . . . . . . . . . . . . . . 18 87 4.4 Parameter Space Design . . . . . . . . . . . . . . . . . . 18 88 4.5 Cryptographic Agility . . . . . . . . . . . . . . . . . . 21 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 7.1 Normative References . . . . . . . . . . . . . . . . . . . 22 93 7.2 Informative References . . . . . . . . . . . . . . . . . . 22 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 IAB Members . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 96 Appendix A - Examples . . . . . . . . . . . . . . . . . . . . . . 27 97 A.1 Already documented cases . . . . . . . . . . . . . . . . . 27 98 A.2 RADIUS Extensions . . . . . . . . . . . . . . . . . . . . 27 99 A.3 TLS Extensions . . . . . . . . . . . . . . . . . . . . . . 28 100 A.4 L2TP Extensions . . . . . . . . . . . . . . . . . . . . . 30 101 Change log . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 103 1. Introduction 105 When developing protocols, IETF Working Groups (WGs) typically 106 include mechanisms whereby these protocols can be extended in the 107 future. It is a good principle to design extensibility into 108 protocols; as described in "What Makes for a Successful Protocol" 109 [RFC5218], a common definition of a successful protocol is one that 110 becomes widely used in ways not originally anticipated. Well- 111 designed extensibility mechanisms facilitate the evolution of 112 protocols and help make it easier to roll out incremental changes in 113 an interoperable fashion. 115 When an initial protocol design is extended, there is always a risk 116 of unintended consequences, such as interoperability problems or 117 security vulnerabilities. This risk is especially high if the 118 extension is performed by a different team than the original 119 designers, who may stray outside implicit design constraints or 120 assumptions. As a result, extensions should be done carefully and 121 with a full understanding of the base protocol, existing 122 implementations, and current operational practice. 124 This is hardly a recent concern. "TCP Extensions Considered Harmful" 125 [RFC1263] was published in 1991. "Extend" or "extension" occurs in 126 the title of more than 400 existing Request For Comment (RFC) 127 documents. Yet generic extension considerations have not been 128 documented previously. 130 The purpose of this document is to describe the architectural 131 principles of sound extensibility design, in order to minimize such 132 risks. Formal procedures for extending IETF protocols are discussed 133 in "Procedures for Protocol Extensions and Variations" BCP 125 134 [RFC4775]. 136 The rest of this document is organized as follows: Section 2 137 discusses routine and major extensions. Section 3 describes 138 architectural principles for protocol extensibility. Section 4 139 explains how designers of base protocols can take steps to anticipate 140 and facilitate the creation of such subsequent extensions in a safe 141 and reliable manner. 143 Readers are advised to study the whole document, since the 144 considerations are closely linked. 146 1.1. Requirements Language 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in BCP 14, RFC 2119 152 [RFC2119]. 154 2. Routine and Major Extensions 156 Protocol components that are designed with the specific intention of 157 allowing extensibility should be clearly identified, with specific 158 and complete instructions on how to extend them. This includes the 159 process for adequate review of extension proposals: do they need 160 community review and if so how much and by whom? 162 The level of review required for protocol extensions will typically 163 vary based on the nature of the extension. Routine extensions may 164 require minimal review, while major extensions may require wide 165 review. Guidance on which extensions may be considered 'routine' and 166 which ones are 'major' are provided in the sections that follow. 168 2.1. When is an Extension Routine? 170 An extension may be considered 'routine' if its handling is opaque to 171 the protocol itself (e.g. does not substantially change the pattern 172 of messages and responses). For this to apply, no changes to the 173 base protocol can be required, nor can changes be required to 174 existing and currently deployed implementations, unless they make use 175 of the extension. Furthermore, existing implementations should not 176 be impacted. This typically requires that implementations be able to 177 ignore 'routine' extensions without ill-effects. 179 Examples of routine extensions include the Dynamic Host Configuration 180 Protocol (DHCP) vendor-specific option [RFC2132], Vendor-Specific 181 Attributes [RFC2865], the enterprise Object IDentifier (OID) tree for 182 Management Information Base (MIB) modules, vendor Multipurpose 183 Internet Mail Extension (MIME) types, and some classes of (non- 184 critical) certification extensions. Such extensions can safely be 185 made with minimal discussion. 187 In order to increase the likelihood that routine extensions are truly 188 routine, protocol documents should provide guidelines explaining how 189 extensions should be performed. For example, even though DHCP 190 carries opaque data, defining a new option using completely 191 unstructured data may lead to an option that is unnecessarily hard 192 for clients and servers to process. 194 Processes that allow routine extensions with minimal or no review 195 should be used sparingly (such as the "First Come First Served" 196 allocation policy described in "Guidelines for Writing an IANA 197 Considerations Section in RFCs" [RFC5226]). In particular, they 198 should be limited to cases that are unlikely to cause protocol 199 failures. 201 2.2. What Constitutes a Major Extension? 203 Major extensions may have characteristics leading to a risk of 204 interoperability failure. Where these characteristics are present, 205 it is necessary to pay extremely close attention to backward 206 compatibility with implementations and deployments of the unextended 207 protocol, and to the risk of inadvertent introduction of security or 208 operational exposures. 210 Extension designers should examine their design for the following 211 issues: 213 1. Modifications or extensions to the underlying protocol. This 214 can include changing protocol semantics or defining new message 215 types that may require implementation changes in existing and 216 deployed implementations of the protocol, even if they do not want 217 to make use of the new functions. A base protocol without a 218 "silent discard" rule for unknown extensions may automatically 219 enter this category, even for apparently minor extensions. 221 2. Changes to the transport model. While there are circumstances 222 where specification of additional transport protocols may be 223 useful, removal of a widely implemented transport protocol is 224 likely to result in interoperability problems and thus should be 225 avoided wherever possible. 227 Where additional transports are specified, one way to avoid issues 228 is to mandate support for a single transport protocol, while 229 designating other transport protocols as optional. However, if 230 optional transport protocols are introduced due to the unique 231 advantages they afford in certain scenarios, in those situations 232 implementations not supporting optional transport protocols may 233 exhibit degraded performance or may even fail. 235 While requiring support for multiple transport protocols may 236 appear attractive, authors need to realistically evaluate the 237 likelihood that implementers will conform to the requirements. 238 For example, where resources are limited (such as in embedded 239 systems), implementers may choose to only support a subset of the 240 mandated transport protocols, resulting in non-interoperable 241 protocol variants. 243 3. Changes to the basic architectural assumptions. This may 244 include architectural assumptions that are explicitly stated or 245 those that have been assumed by implementers. For example, this 246 would include adding a requirement for session state to a 247 previously stateless protocol. 249 4. New usage scenarios not originally intended or investigated. 250 This can potentially lead to operational difficulties when 251 deployed, even in cases where the "on-the-wire" format has not 252 changed. For example, the level of traffic carried by the 253 protocol may increase substantially, packet sizes may increase, 254 and implementation algorithms that are widely deployed may not 255 scale sufficiently or otherwise be up to the new task at hand. 256 For example, a new DNS Resource Record (RR) type that is too big 257 to fit into a single UDP packet could cause interoperability 258 problems with existing DNS clients and servers. 260 5. Changes to the extension model. Adverse impacts are very 261 likely if the base protocol contains an extension mechanism and 262 that proposed extension does not fit into the model used to create 263 and define that mechanism. Extensions that have the same 264 properties as those that were anticipated when an extension 265 mechanism was devised are much less likely to be disruptive than 266 extensions that don't fit the model. 268 3. Architectural Principles 270 This section describes basic principles of protocol extensibility: 272 1. Extensibility features should be limited to what is reasonably 273 anticipated when the protocol is developed. 275 2. Protocol extensions should be designed for global 276 interoperability. 278 3. Protocol extensions should be architecturally compatible with 279 the base protocol. 281 4. Protocol extension mechanisms should not be used to create 282 incompatible protocol variations. 284 5. Extension mechanisms need to be testable. 286 6. Protocol parameter assignments need to be coordinated to avoid 287 potential conflicts. 289 7. Extensions to critical protocols require special care. 291 3.1. Limited Extensibility 293 Designing a protocol for extensibility may have the perverse side 294 effect of making it easy to construct incompatible extensions. 295 Consequently, protocols should not be made more extensible than 296 clearly necessary at inception, and the process for defining new 297 extensibility mechanisms should ensure that adequate review of 298 proposed extensions will take place before widespread adoption. 300 3.2. Design for Global Interoperability 302 The IETF mission [RFC3935] is to create interoperable protocols for 303 the global Internet, not a collection of different incompatible 304 protocols (or "profiles") for use in separate private networks. 305 Experience shows that separate private networks often end up using 306 equipment from the same vendors, or end up having portable equipment 307 like laptop computers move between them, and networks that were 308 originally envisaged as being separate can end up being connected 309 later. 311 As a result, extensions cannot be designed for an isolated 312 environment; instead, extension designers must assume that systems 313 using the extension will need to interoperate with systems on the 314 global Internet. 316 A key requirement for interoperable extension design is that the base 317 protocol must be well designed for interoperability, and that 318 extensions must have unambiguous semantics. Ideally, the protocol 319 mechanisms for extension and versioning should be sufficiently well 320 described that compatibility can be assessed on paper. Otherwise, 321 when two "private" extensions encounter each other on a public 322 network, unexpected interoperability problems may occur. 324 Consider a "private" extension installed on a work computer which, 325 being portable, is sometimes connected to a home network or a hotel 326 network. If the "private" extension is incompatible with an 327 unextended version of the same protocol, problems will occur. 329 Similarly, problems can occur if "private" extensions conflict with 330 each other. For example, imagine the situation where one site chose 331 to use DHCP [RFC2132] option code 62 for one meaning, and a different 332 site chose to use DHCP option code 62 for a completely different, 333 incompatible, meaning. It may be impossible for a vendor of portable 334 computing devices to make a device that works correctly in both 335 environments. 337 One approach to solving this problem has been to reserve parts of an 338 identifier namespace for "site-specific" use, such as "X-" headers in 339 email messages [RFC0822]. This problem with this approach is that 340 when a site-specific use turns out to have applicability elsewhere, 341 other vendors will then implement that "X-" header for 342 interoperability, and the "X-" header becomes a de facto standard, 343 meaning that it is no longer true that any header beginning "X-" is 344 site-specific. The notion of "X-" headers was removed from the 345 Internet Message Format standard when it was updated in 2001 346 [RFC2822]. 348 3.3. Architectural Compatibility 350 Since protocol extension mechanisms may impact interoperability, it 351 is important that they be architecturally compatible with the base 352 protocol. 354 As part of the definition of new extension mechanisms, it is 355 important to address whether the mechanisms make use of features as 356 envisaged by the original protocol designers, or whether a new 357 extension mechanism is being invented. If a new extension mechanism 358 is being invented, then architectural compatibility issues need to be 359 addressed. 361 Documents relying on extension mechanisms need to explicitly identify 362 the mechanisms being relied upon. For example, a document defining 363 new data elements should not implicitly define new data types or 364 protocol operations without explicitly describing those dependencies 365 and discussing their impact. 367 To help future extension writers to use extension mechanisms 368 properly, there may be a need for explicit guidance relating to 369 extensions beyond what is encapsulated in the base specification. 370 This role may be filled by the development of an extension guidelines 371 document. Where extension guidelines are available, mechanisms need 372 to indicate whether they are compliant with those guidelines and if 373 not, why not. 375 Examples of extension guidelines documents include: 377 1. "Guidelines for Extending the Extensible Provisioning Protocol 378 (EPP)" [RFC3735], which provides guidelines for use of EPP's 379 extension mechanisms to define new features and object management 380 capabilities. 382 2. "Guidelines for Authors and Reviewers of MIB Documents" BCP 111 383 [RFC4181], which provides guidance to protocol designers creating 384 new MIB modules. 386 3. "Guidelines for Authors of Extensions to the Session Initiation 387 Protocol (SIP)" [RFC4485], which outlines guidelines for authors 388 of SIP extensions. 390 4. "RADIUS Design Guidelines" BCP 158 [RFC6158], which provides 391 guidelines for the design of attributes used by the Remote 392 Authentication Dial In User Service (RADIUS) protocol. 394 3.4. Protocol Variations 396 Protocol variations - specifications that look very similar to the 397 original but don't interoperate with each other or with the original 398 - are even more harmful to interoperability than extensions. In 399 general, such variations should be avoided. Causes of protocol 400 variations include incompatible protocol extensions, uncoordinated 401 protocol development, and poorly designed "profiles". 403 Protocol extension mechanisms should not be used to create 404 incompatible forks in development. An extension may lead to 405 interoperability failures unless the extended protocol correctly 406 supports all mandatory and optional features of the unextended base 407 protocol, and implementations of the base protocol operate correctly 408 in the presence of the extensions. In addition, it is necessary for 409 an extension to interoperate with other extensions. 411 As noted in "Uncoordinated Protocol Development Considered Harmful" 412 [RFC5704] Section 1, incompatible forks in development can result 413 from the uncoordinated adaptation of a protocol, parameter or code- 414 point: 416 In particular, the IAB considers it an essential principle of the 417 protocol development process that only one SDO maintains design 418 authority for a given protocol, with that SDO having ultimate 419 authority over the allocation of protocol parameter code-points 420 and over defining the intended semantics, interpretation, and 421 actions associated with those code-points. 423 3.4.1. Profiles 425 Profiling is a common technique for improving interoperability within 426 a target environment or set of scenarios. Generally speaking, there 427 are two approaches to profiling: 429 a) Removal or downgrading of normative requirements (thereby creating 430 potential interoperability problems); 432 b) Elevaton of normative requirement levels (such as from a 433 MAY/SHOULD to a MUST) in order to improve interoperability by 434 narrowing potential implementation choices. 436 While approach a) is potentially harmful, approach b) may be 437 beneficial, but is typically only necessary when the underlying 438 protocol is ill-defined enough to permit non-interoperable yet 439 compliant implementations. 441 In order to avoid creating interoperability problems when profiled 442 implementations interact with others over the Global Internet, 443 profilers need to remain cognizant of the implications of normative 444 requirements. 446 As noted in "Key words for use in RFCs to Indicate Requirement 447 Levels" [RFC2119] Section 6, imperatives are to be used with care, 448 and as a result, their removal within a profile is likely to result 449 in serious consequences: 451 Imperatives of the type defined in this memo must be used with 452 care and sparingly. In particular, they MUST only be used where 453 it is actually required for interoperation or to limit behavior 454 which has potential for causing harm (e.g., limiting 455 retransmissions) For example, they must not be used to try to 456 impose a particular method on implementors where the method is not 457 required for interoperability. 459 As noted in [RFC2119] Sections 3 and 4, recommendations cannot be 460 removed from profiles without serious consideration: 462 there may exist valid reasons in particular circumstances to 463 ignore a particular item, but the full implications must be 464 understood and carefully weighed before choosing a different 465 course. 467 Even the removal of optional features and requirements can have 468 consequences. As noted in [RFC2119] Section 5, implementations which 469 do not support optional features still retain the obligation to 470 ensure interoperation with implementations that do: 472 An implementation which does not include a particular option MUST 473 be prepared to interoperate with another implementation which does 474 include the option, though perhaps with reduced functionality. In 475 the same vein an implementation which does include a particular 476 option MUST be prepared to interoperate with another 477 implementation which does not include the option (except, of 478 course, for the feature the option provides.) 480 3.5. Testability 482 Experience has shown that it is insufficient merely to correctly 483 specify extensibility and backwards compatibility in an RFC. It is 484 also important that implementations respect the compatibility 485 mechanisms; if not, non-interoperable pairs of implementations may 486 arise. The TLS case study (Appendix A.3) shows how important this 487 can be. 489 In order to determine whether protocol extension mechanisms have been 490 properly implemented, testing is required. However, for this to be 491 possible, test cases need to be developed. If a base protocol 492 document specifies extension mechanisms but does not utilize them or 493 provide examples, it may not be possible to develop effective test 494 cases based on the base protocol specification alone. As a result, 495 base protocol implementations may not be properly tested and non- 496 compliant extension behavior may not be detected until these 497 implementations are widely deployed. 499 To encourage correct implementation of extension mechanisms, base 500 protocol specifications should clearly articulate the expected 501 behavior of extension mechanisms and should include examples of 502 correct and incorrect extension behavior. 504 3.6. Protocol Parameter Registration 506 An extension is often likely to make use of additional values added 507 to an existing IANA registry. To avoid conflicting usage of the same 508 value, as well as to prevent potential difficulties in determining 509 and transferring parameter ownership, it is essential that all new 510 values are properly registered by the applicable procedures. If this 511 is not done, there is nothing to prevent two different extensions 512 picking the same value. When these two extensions "meet" each other 513 on the Internet, failure is inevitable. 515 A surprisingly common case of this is misappropriation of assigned 516 Transmission Control Protocol (TCP) (or User Datagram Protocol (UDP)) 517 registered port numbers. This can lead to a client for one service 518 attempting to communicate with a server for another service. 519 Numerous cases could be cited, but not without embarrassing specific 520 implementers. 522 For general rules see [RFC5226], and for specific rules and 523 registries see the individual protocol specification RFCs and the 524 IANA web site. Note that while in theory a "standards track" or 525 "IETF consensus" parameter allocation policy may be instituted to 526 encourage protocol parameter registration or to improve 527 interoperability, in practice these policies, if administered 528 clumsily, can have the opposite effect, discouraging protocol 529 parameter registration and encouraging rampant self-allocation. 530 These effects have also been observed in a number of instances. 532 3.6.1. Experimental and Local Use 534 In some cases, it may be appropriate to use values designated as 535 "experimental" or "local use" in early implementations of an 536 extension. For example, "Experimental Values in IPv4, IPv6, ICMPv4, 537 ICMPv6, UDP and TCP Headers" [RFC4727] discusses experimental values 538 for IP and transport headers, and "Definition of the Differentiated 539 Services Field (DS Field) in the IPv4 and IPv6 Headers" [RFC2474] 540 defines experimental/local use ranges for differentiated services 541 code points. 543 Such values should be used with care and only for their stated 544 purpose: experiments and local use. They are unsuitable for 545 Internet-wide use, since they may be used for conflicting purposes 546 and thereby cause interoperability failures. Packets containing 547 experimental or local use values must not be allowed out of the 548 domain in which they are meaningful. 550 As noted in [RFC5226] Section 4.1: 552 For private or local use... No attempt is made to prevent multiple 553 sites from using the same value in different (and incompatible) 554 ways... assignments are not generally useful for broad 555 interoperability. It is the responsibility of the sites making 556 use of the Private Use range to ensure that no conflicts occur 557 (within the intended scope of use). 559 "Assigning Experimental and Testing Numbers Considered Useful" BCP 82 560 [RFC3692] Section 1 provides additional guidance on the use of 561 experimental code points: 563 Numbers in the experimentation range.... are not intended to be 564 used in general deployments or be enabled by default in products 565 or other general releases. In those cases where a product or 566 release makes use of an experimental number, the end user must be 567 required to explicitly enable the experimental feature and 568 likewise have the ability to chose and assign which number from 569 the experimental range will be used for a specific purpose (i.e., 570 so the end user can ensure that use of a particular number doesn't 571 conflict with other on-going uses). Shipping a product with a 572 specific value pre-enabled would be inappropriate and can lead to 573 interoperability problems when the chosen value collides with a 574 different usage, as it someday surely will. 576 From the above, it follows that it would be inappropriate for a 577 group of vendors, a consortia, or another Standards Development 578 Organization to agree among themselves to use a particular value 579 for a specific purpose and then agree to deploy devices using 580 those values. By definition, experimental numbers are not 581 guaranteed to be unique in any environment other than one where 582 the local system administrator has chosen to use a particular 583 number for a particular purpose and can ensure that a particular 584 value is not already in use for some other purpose. 586 3.7. Extensions to Critical Protocols 588 Some protocols (such as Domain Name Service (DNS) and Border Gateway 589 Protocol (BGP)) have become critical components of the Internet 590 infrastructure. When such protocols are extended, the potential 591 exists for negatively impacting the reliability and security of the 592 global Internet. 594 As a result, special care needs to be taken with these extensions, 595 such as taking explicit steps to isolate existing uses from new ones. 596 For example, this can be accomplished by requiring the extension to 597 utilize a different port or multicast address, or by implementing the 598 extension within a separate process, without access to the data and 599 control structures of the base protocol. 601 4. Considerations for the Base Protocol 603 Good extension design depends on a well designed base protocol. 604 Interoperability stems from a number of factors, including: 606 1. A well-written base protocol specification. Does the base 607 protocol specification make clear what an implementor needs to 608 support and does it define the impact that individual operations 609 (e.g. a message sent to a peer) will have when invoked? 611 2. Design for deployability. This includes understanding what 612 current implementations do and how a proposed extension will 613 interact with deployed systems. Is it clear when a proposed 614 extension (or its proposed usage) will operationally stress 615 existing implementations or the underlying protocol itself if 616 widely deployed? If this is not explained in the base protocol 617 specification, is this covered in an extension design guidelines 618 document? 620 3. Design for backward compatibility. Does the base protocol 621 specification describe how to determine the capabilities of a 622 peer, and negotiate the use of extensions? Does it indicate how 623 implementations handle extensions that they do not understand? Is 624 it possible for an extended implementation to negotiate with an 625 unextended peer to find a common subset of useful functions? 627 4. Respecting underlying architectural or security assumptions. 628 Is there a document describing the underlying architectural 629 assumptions, as well as considerations that have arisen in 630 operational experience? Or are there undocumented considerations 631 that have arisen as the result of operational experience, after 632 the original protocol was published? 633 For example, will backward compatibility issues arise if 634 extensions reverse the flow of data, allow formerly static 635 parameters to be changed on the fly, or change assumptions 636 relating to the frequency of reads/writes? 638 5. Minimizing impact on critical infrastructure. For a protocol 639 that represents a critical element of Internet infractructure, it 640 is important to explain when it is appropriate to isolate new uses 641 of the protocol from existing ones. 643 For example, is it explained when a proposed extension (or usage) 644 has the potential for negatively impacting critical infrastructure 645 to the point where explicit steps would be appropriate to isolate 646 existing uses from new ones? 648 6. Data model extensions. Is there a document that explains when 649 a protocol extension is routine and when it represents a major 650 change? 652 For example, is it clear when a data model extension represents a 653 major versus a routine change? Are there guidelines describing 654 when an extension (such as a new data type) is likely to require a 655 code change within existing implementations? 657 4.1. Version Numbers 659 Any mechanism for extension by versioning must include provisions to 660 ensure interoperability, or at least clean failure modes. Imagine 661 someone creating a protocol and using a "version" field and 662 populating it with a value (1, let's say), but giving no information 663 about what would happen when a new version number appears in it. 664 That's bad protocol design and description; it should be clear what 665 the expectation is and how you test it. For example, stating that 666 1.X must be compatible with any version 1 code, but version 2 or 667 greater is not expected to be compatible, has different implications 668 than stating that version 1 must be a proper subset of version 2. 670 An example is ROHC (Robust Header Compression). ROHCv1 [RFC3095] 671 supports a certain set of profiles for compression algorithms. But 672 experience had shown that these profiles had limitations, so the ROHC 673 WG developed ROHCv2 [RFC5225]. A ROHCv1 implementation does not 674 contain code for the ROHCv2 profiles. As the ROHC WG charter said 675 during the development of ROHCv2: 677 It should be noted that the v2 profiles will thus not be 678 compatible with the original (ROHCv1) profiles, which means less 679 complex ROHC implementations can be realized by not providing 680 support for ROHCv1 (over links not yet supporting ROHC, or by 681 shifting out support for ROHCv1 in the long run). Profile support 682 is agreed through the ROHC channel negotiation, which is part of 683 the ROHC framework and thus not changed by ROHCv2. 685 Thus in this case both backwards-compatible and backwards- 686 incompatible deployments are possible. The important point is a 687 clearly thought out approach to the question of operational 688 compatibility. In the past, protocols have utilized a variety of 689 strategies for versioning, many of which have proven problematic. 690 These include: 692 1. No versioning support. This approach is exemplified by 693 Extensible Authentication Protocol (EAP) [RFC3748] as well as 694 Remote Authentication Dial In User Service (RADIUS) [RFC2865], 695 both of which provide no support for versioning. While lack of 696 versioning support protects against the proliferation of 697 incompatible dialects, the need for extensibility is likely to 698 assert itself in other ways, so that ignoring versioning entirely 699 may not be the most forward thinking approach. 701 2. Highest mutually supported version (HMSV). In this approach, 702 implementations exchange the version numbers of the highest 703 version each supports, with the negotiation agreeing on the 704 highest mutually supported protocol version. This approach 705 implicitly assumes that later versions provide improved 706 functionality, and that advertisement of a particular version 707 number implies support for all lower version numbers. Where these 708 assumptions are invalid, this approach breaks down, potentially 709 resulting in interoperability problems. An example of this issue 710 occurs in Protected Extensible Authentication Protocol [PEAP] 711 where implementations of higher versions may not necessarily 712 provide support for lower versions. 714 3. Assumed backward compatibility. In this approach, 715 implementations may send packets with higher version numbers to 716 legacy implementations supporting lower versions, but with the 717 assumption that the legacy implementations will interpret packets 718 with higher version numbers using the semantics and syntax defined 719 for lower versions. This is the approach taken by Port-Based 720 Access Control [IEEE-802.1X]. For this approach to work, legacy 721 implementations need to be able to accept packets of known types 722 with higher protocol versions without discarding them; protocol 723 enhancements need to permit silent discard of unsupported 724 extensions; implementations supporting higher versions need to 725 refrain from mandating new features when encountering legacy 726 implementations. 728 4. Major/minor versioning. In this approach, implementations with 729 the same major version but a different minor version are assumed 730 to be backward compatible, but implementations are assumed to be 731 required to negotiate a mutually supported major version number. 732 This approach assumes that implementations with a lower minor 733 version number but the same major version can safely ignore 734 unsupported protocol messages. 736 5. Min/max versioning. This approach is similar to HMSV, but 737 without the implied obligation for clients and servers to support 738 all versions back to version 1, in perpetuity. It allows clients 739 and servers to cleanly drop support for early versions when those 740 versions become so old that they are no longer relevant and no 741 longer required. In this approach, the client initiating the 742 connection reports the highest and lowest protocol versions it 743 understands. The server reports back the chosen protocol version: 745 a. If the server understands one or more versions in the client's 746 range, it reports back the highest mutually understood version. 748 b. If there is no mutual version, then the server reports back 749 some version that it does understand (selected as described 750 below). The connection is then typically dropped by client or 751 server, but reporting this version number first helps facilitate 752 useful error messages at the client end: 754 * If there is no mutual version, and the server speaks any 755 version higher than client max, it reports the lowest version it 756 speaks which is greater than the client max. The client can 757 then report to the user, "You need to upgrade to at least 758 version ." 760 * Else, the server reports the highest version it speaks. The 761 client can then report to the user, "You need to request the 762 server operator to upgrade to at least version ." 764 Protocols generally do not need any version-negotiation mechanism 765 more complicated than the mechanisms described here. The nature of 766 protocol version-negotiation mechanisms is that, by definition, they 767 don't get widespread real-world testing until *after* the base 768 protocol has been deployed for a while, and its deficiencies have 769 become evident. This means that, to be useful, a protocol version 770 negotiation mechanism should be simple enough that it can reasonably 771 be assumed that all the implementers of the first protocol version at 772 least managed to implement the version-negotiation mechanism 773 correctly. 775 4.2. Reserved Fields 777 Protocols commonly include one or more "reserved" fields, clearly 778 intended for future extensions. It is good practice to specify the 779 value to be inserted in such a field by the sender (typically zero) 780 and the action to be taken by the receiver when seeing some other 781 value (typically no action). In packet format diagrams, such fields 782 are typically labeled "MBZ", to be read as, "Must Be Zero on 783 transmission, Must Be Ignored on reception." 785 A common mistake of inexperienced protocol implementers is to think 786 that "MBZ" means that it's their software's job to verify that the 787 value of the field is zero on reception, and reject the packet if 788 not. This is a mistake, and such software will fail when it 789 encounters future versions of the protocol where these previously 790 reserved fields are given new defined meanings. Similarly, protocols 791 should carefully specify how receivers should react to unknown 792 extensions (headers, TLVs etc.), such that failures occur only when 793 that is truly the intended outcome. 795 4.3. Encoding Formats 797 Using widely-supported encoding formats leads to better 798 interoperability and easier extensibility. 800 As described in "IAB Thoughts on Encodings for International Domain 801 Names" [RFC6055] Section Y, the number of encodings should be 802 minimized and tricky encodings are generally a bad idea. As soon as 803 one moves outside the ASCII/NVT repertoire, all sorts of interesting 804 issues about collation and/or comparison arise that extensions must 805 deal with and do so with extreme care and considerable knowledge. 807 An example is the Simple Network Management Protocol (SNMP) Structure 808 of Managed Information (SMI). Guidelines exist for defining the 809 Management Information Base (MIB) objects that SNMP carries 810 [RFC4181]. Also, multiple textual conventions have been published, 811 so that MIB designers do not have to reinvent the wheel when they 812 need a commonly encountered construct. For example, the "Textual 813 Conventions for Internet Network Addresses" [RFC4001] can be used by 814 any MIB designer needing to define objects containing IP addresses, 815 thus ensuring consistency as the body of MIBs is extended. 817 4.4. Parameter Space Design 819 In some protocols the parameter space is either infinite (e.g. Header 820 field names) or sufficiently large that it is unlikely to be 821 exhausted. In other protocols, the parameter space is finite, and in 822 some cases, has proven inadequate to accommodate demand. Common 823 mistakes include: 825 a. A version field that is too small (e.g. two bits or less). When 826 designing a version field, existing as well as potential versions of 827 a protocol need to be taken into account. For example, if a protocol 828 is being standardized for which there are existing implementations 829 with known interoperability issues, more than one version for "pre- 830 standard" implementations may be required. If two "pre-standard" 831 versions are required in addition to a version for an IETF standard, 832 then a two-bit version field would only leave one additional version 833 code-point for a future update, which could be insufficient. This 834 problem was encountered during the development of the PEAPv2 protocol 835 [PEAP]. 837 b. A small parameter space (e.g. 8-bits or less) along with a First 838 Come, First Served (FCFS) allocation policy. In general, an FCFS 839 allocation policy is only appropriate in situations where parameter 840 exhaustion is highly unlikely. In situations where substantial 841 demand is anticipated within a parameter space, the space should 842 either be designed to be sufficient to handle that demand, or vendor 843 extensibility should be provided to enable vendors to self-allocate. 844 The combination of a small parameter space, an FCFS allocation 845 policy, and no support for vendor extensibility is particularly 846 likely to prove ill-advised. An example of such a combination was 847 the design of the original 8-bit EAP Method Type space [RFC2284]. 849 Once the potential for parameter exhaustion becomes apparent, it is 850 important that it be addressed as quickly as possible. Protocol 851 changes can take years to appear in implementations and by then the 852 exhaustion problem could become acute. 854 Options for addressing a protocol parameter exhaustion problem 855 include: 857 Rethinking the allocation regime 858 Where it becomes apparent that the size of a parameter space is 859 insufficient to meet demand, it may be necessary to rethink the 860 allocation mechanism, in order to prevent rapid parameter space 861 exhaustion. For example, a few years after approval of RFC 2284 862 [RFC2284], it became clear that the combination of a FCFS 863 allocation policy and lack of support for vendor-extensions had 864 created the potential for exhaustion of the EAP Method Type space 865 within a few years. To address the issue, [RFC3748] Section 6.2 866 changed the allocation policy for EAP Method Types from FCFS to 867 Expert Review, with Specification Required. 869 Support for vendor-specific parameters 870 If the demand that cannot be accommodated is being generated by 871 vendors, merely making allocation harder could make things worse if 872 this encourages vendors to self-allocate, creating interoperability 873 problems. In such a situation, support for vendor-specific 874 parameters should be considered, allowing each vendor to self- 875 allocate within their own vendor-specific space based on a vendor's 876 Private Enterprise Code (PEC). For example, in the case of the EAP 877 Method Type space, [RFC3748] Section 6.2 also provided for an 878 Expanded Type space for "functions specific only to one vendor's 879 implementation". 881 Extensions to the parameter space 882 If the goal is to stave off exhaustion in the face of high demand, 883 a larger parameter space may be helpful. Where vendor-specific 884 parameter support is available, this may be achieved by allocating 885 an PEC for IETF use. Otherwise it may be necessary to try to extend 886 the size of the parameter fields, which could require a new 887 protocol version or other substantial protocol changes. 889 Parameter reclamation 890 In order to gain time, it may be necessary to reclaim unused 891 parameters. However, it may not be easy to determine whether a 892 parameter that has been allocated is in use or not, particularly if 893 the entity that obtained the allocation no longer exists or has 894 been acquired (possibly multiple times). 896 Parameter Transfer 897 When all the above mechanisms have proved infeasible and parameter 898 exhaustion looms in the near future, enabling the transfer of 899 ownership of protocol parameters can be considered as a means for 900 improving allocation efficiency. However, enabling transfer of 901 parameter ownership can be far from simple if the parameter 902 allocation process was not originally designed to enable title 903 searches and ownership transfers. 905 A parameter allocation process designed to uniquely allocate code- 906 points is fundamentally different from one designed to enable title 907 search and transfer. If the only goal is to ensure that a 908 parameter is not allocated more than once, the parameter registry 909 will only need to record the initial allocation. On the other 910 hand, if the goal is to enable transfer of ownership of a protocol 911 parameter, then it is important not only to record the initial 912 allocation, but also to track subsequent ownership changes, so as 913 to make it possible to determine and transfer title. Given the 914 difficulty of converting from a unique allocation regime to one 915 requiring support for title search and ownership transfer, it is 916 best for the desired capabilities to be carefully thought through 917 at the time of registry establishment. 919 4.5. Cryptographic Agility 921 Extensibility with respect to cryptographic algorithms is desirable 922 in order to provide resilience against the compromise of any 923 particular algorithm. "Guidance for Authentication, Authorization, 924 and Accounting (AAA) Key Management" BCP 132 [RFC4962] Section 3 925 provides some basic advice: 927 The ability to negotiate the use of a particular cryptographic 928 algorithm provides resilience against compromise of a particular 929 cryptographic algorithm... This is usually accomplished by 930 including an algorithm identifier and parameters in the protocol, 931 and by specifying the algorithm requirements in the protocol 932 specification. While highly desirable, the ability to negotiate 933 key derivation functions (KDFs) is not required. For 934 interoperability, at least one suite of mandatory-to-implement 935 algorithms MUST be selected... 937 This requirement does not mean that a protocol must support both 938 public-key and symmetric-key cryptographic algorithms. It means 939 that the protocol needs to be structured in such a way that 940 multiple public-key algorithms can be used whenever a public-key 941 algorithm is employed. Likewise, it means that the protocol needs 942 to be structured in such a way that multiple symmetric-key 943 algorithms can be used whenever a symmetric-key algorithm is 944 employed. 946 In practice, the most difficult challenge in providing cryptographic 947 agility is providing for a smooth transition in the event that a 948 mandatory-to-implement algorithm is compromised. Since it may take 949 significant time to provide for widespread implementation of a 950 previously undeployed alternative, it is often advisable to recommend 951 implementation of alternative algorithms of distinct lineage in 952 addition to those made mandatory-to-implement, so that an alternative 953 algorithm is readily available. If such a recommended alternative is 954 not in place, then it would be wise to issue such a recommendation as 955 soon as indications of a potential weakness surface. This is 956 particularly important in the case of potential weakness in 957 algorithms used to authenticate and integrity-protect the 958 cryptographic negotiation itself, such as KDFs or message integrity 959 checks (MICs). Without secure alternatives to compromised KDF or MIC 960 algorithms, it may not be possible to secure the cryptographic 961 negotiation while retaining backward compatibility. 963 5. Security Considerations 965 An extension must not introduce new security risks without also 966 providing adequate counter-measures, and in particular it must not 967 inadvertently defeat security measures in the unextended protocol. 968 Thus, the security analysis for an extension needs to be as thorough 969 as for the original protocol - effectively it needs to be a 970 regression analysis to check that the extension doesn't inadvertently 971 invalidate the original security model. 973 This analysis may be simple (e.g. adding an extra opaque data element 974 is unlikely to create a new risk) or quite complex (e.g. adding a 975 handshake to a previously stateless protocol may create a completely 976 new opportunity for an attacker). 978 When the extensibility of a design includes allowing for new and 979 presumably more powerful cryptographic algorithms to be added, 980 particular care is needed to ensure that the result is in fact 981 increased security. For example, it may be undesirable from a 982 security viewpoint to allow negotiation down to an older, less secure 983 algorithm. 985 6. IANA Considerations 987 [RFC Editor: please remove this section prior to publication.] 989 This document has no IANA Actions. 991 7. References 993 7.1. Normative References 995 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 996 Requirement Levels", BCP 14, RFC 2119, March 1997. 998 [RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures for 999 Protocol Extensions and Variations", BCP 125, RFC 4775, 1000 December 2006. 1002 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1003 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 1005 7.2. Informative References 1007 [IEEE-802.1X] 1008 Institute of Electrical and Electronics Engineers, "Local and 1009 Metropolitan Area Networks: Port-Based Network Access 1010 Control", IEEE Standard 802.1X-2004, December 2004. 1012 [PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G. and 1013 S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", 1014 draft-josefsson-pppext-eap-tls-eap-10.txt, Expired Internet 1015 draft (work in progress), October 2004. 1017 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet text 1018 messages", STD 11, RFC 822, August 1982. 1020 [RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered 1021 Harmful", RFC 1263, October 1991. 1023 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1024 Extensions", RFC 2132, March 1997. 1026 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1027 2246, January 1999. 1029 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication 1030 Protocol (EAP)", RFC 2284, March 1998. 1032 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition 1033 of the Differentiated Services Field (DS Field) in the IPv4 1034 and IPv6 Headers", RFC 2474, December 1998. 1036 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., 1037 and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 1038 2661, August 1999. 1040 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",RFC 2671, 1041 August 1999. 1043 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 1045 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 1046 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1047 2000. 1049 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1050 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., 1051 Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, 1052 T., Yoshimura, T., and H. Zheng, "RObust Header Compression 1053 (ROHC): Framework and four profiles: RTP, UDP, ESP, and 1054 uncompressed", RFC 3095, July 2001. 1056 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and 1057 B. Rosen, "Change Process for the Session Initiation Protocol 1058 (SIP)", BCP 67, RFC 3427, December 2002. 1060 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1061 Authentication Dial In User Service)", RFC 3575, July 2003. 1063 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) 1064 Types", RFC 3597, September 2003. 1066 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1067 Considered Useful", BCP 82, RFC 3692, January 2004. 1069 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 1070 Provisioning Protocol (EPP)", RFC 3735, March 2004. 1072 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 1073 Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC 1074 3748, June 2004. 1076 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", RFC 3935, 1077 October 2004. 1079 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 1080 Schoenwaelder, "Textual Conventions for Internet Network 1081 Addresses", RFC 4001, February 2005. 1083 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 1084 Documents", BCP 111, RFC 4181, September 2005. 1086 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1087 and T. Wright, "Transport Layer Security (TLS) Extensions", 1088 RFC 4366, April 2006. 1090 [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of 1091 Extensions to the Session Initiation Protocol (SIP)", RFC 1092 4485, May 2006. 1094 [RFC4521] Zeilenga, K., "Considerations for Lightweight Directory 1095 Access Protocol (LDAP) Extensions", BCP 118, RFC 4521, June 1096 2006. 1098 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1099 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 1101 [RFC4929] Andersson, L. and A. Farrel, "Change Process for 1102 Multiprotocol Label Switching (MPLS) and Generalized MPLS 1103 (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, June 1104 2007. 1106 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 1107 Authorization, and Accounting (AAA) Key Management", BCP 132, 1108 RFC 4962, July 2007. 1110 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial 1111 In User Service (RADIUS) Implementation Issues and Suggested 1112 Fixes", RFC 5080, December 2007. 1114 [RFC5218] Thaler, D., and B. Aboba, "What Makes for a Successful 1115 Protocol?", RFC 5218, July 2008. 1117 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 1118 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP- 1119 Lite", RFC 5225, April 2008. 1121 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1122 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1124 [RFC5704] Bryant, S. and M. Morrow, "Uncoordinated Protocol Development 1125 Considered Harmful", RFC 5704, November 2009. 1127 [RFC5727] Peterson, J., Jennings, C. and R. Sparks, "Change Process for 1128 the Session Initiation Protocol (SIP) and the Real-time 1129 Applications and Infrastructure Area", BCP 67, RFC 5727, 1130 March 2010. 1132 [RFC6055] Thaler, D., Klensin, J. and S. Cheshire, "IAB Thoughts on 1133 Encodings for Internationalized Domain Names", RFC 6055, 1134 February 2011. 1136 [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", BCP 158, 1137 RFC 6158, March 2011. 1139 Acknowledgments 1141 This document is heavily based on an earlier draft under a different 1142 title by Scott Bradner and Thomas Narten. 1144 That draft stated: The initial version of this document was put 1145 together by the IESG in 2002. Since then, it has been reworked in 1146 response to feedback from John Loughney, Henrik Levkowetz, Mark 1147 Townsley, Randy Bush and others. 1149 Valuable comments and suggestions on the current form of the document 1150 were made by Jari Arkko, Ted Hardie, John Klensin, Loa Andersson, 1151 Eric Rescorla, Pekka Savola, Leslie Daigle, Alfred Hoenes, Adam Roach 1152 and Phillip Hallam-Baker. 1154 The text on TLS experience was contributed by Yngve Pettersen. 1156 IAB Members at the Time of Approval 1158 Bernard Aboba 1159 Ross Callon 1160 Alissa Cooper 1161 Spencer Dawkins 1162 Joel Halpern 1163 Russ Housley 1164 David Kessens 1165 Olaf Kolkman 1166 Danny McPherson 1167 Jon Peterson 1168 Andrei Robachevsky 1169 Dave Thaler 1170 Hannes Tschofenig 1172 Appendix A. Examples 1174 This section discusses some specific examples, as case studies. 1176 A.1. Already documented cases 1178 There are certain documents that specify a change process or describe 1179 extension considerations for specific IETF protocols: 1181 The SIP change process [RFC3427], [RFC4485], [RFC5727] 1182 The (G)MPLS change process (mainly procedural) [RFC4929] 1183 LDAP extensions [RFC4521] 1184 EPP extensions [RFC3735] 1185 DNS extensions [RFC2671][RFC3597] 1187 It is relatively common for MIBs, which are all in effect extensions 1188 of the SMI data model, to be defined or extended outside the IETF. 1189 BCP 111 [RFC4181] offers detailed guidance for authors and reviewers. 1191 A.2. RADIUS Extensions 1193 The RADIUS [RFC2865] protocol was designed to be extensible via 1194 addition of Attributes to a Data Dictionary on the server, without 1195 requiring code changes. However, this extensibility model assumed 1196 that Attributes would conform to a limited set of data types and that 1197 vendor extensions would be limited to use by vendors, in situations 1198 in which interoperability was not required. Subsequent developments 1199 have stretched those assumptions. 1201 Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism 1202 for Vendor-Specific extensions (Attribute 26), and states that use of 1203 Vendor-Specific extensions: 1205 should be encouraged instead of allocation of global attribute 1206 types, for functions specific only to one vendor's implementation 1207 of RADIUS, where no interoperability is deemed useful. 1209 However, in practice usage of Vendor-Specific Attributes (VSAs) has 1210 been considerably broader than this. In particular, VSAs have been 1211 used by Standards Development Organizations (SDOs) to define their 1212 own extensions to the RADIUS protocol. 1214 This has caused a number of problems. Since the VSA mechanism was 1215 not designed for interoperability, VSAs do not contain a "mandatory" 1216 bit. As a result, RADIUS clients and servers may not know whether it 1217 is safe to ignore unknown attributes. For example, Section 5 of the 1218 RADIUS specification [RFC2865] states: 1220 A RADIUS server MAY ignore Attributes with an unknown Type. A 1221 RADIUS client MAY ignore Attributes with an unknown Type. 1223 However, in the case where the VSAs pertain to security (e.g. 1224 Filters) it may not be safe to ignore them, since the RADIUS 1225 specification [RFC2865] also states: 1227 A NAS that does not implement a given service MUST NOT implement 1228 the RADIUS attributes for that service. For example, a NAS that 1229 is unable to offer ARAP service MUST NOT implement the RADIUS 1230 attributes for ARAP. A NAS MUST treat a RADIUS access-accept 1231 authorizing an unavailable service as an access-reject instead." 1233 Detailed discussion of the issues arising from this can be found in 1234 "Common Remote Authentication Dial In User Service (RADIUS) 1235 Implementation Issues and Suggested Fixes" [RFC5080] Section 2.5. 1237 Since it was not envisaged that multi-vendor VSA implementations 1238 would need to interoperate, the RADIUS specification [RFC2865] does 1239 not define the data model for VSAs, and allows multiple sub- 1240 attributes to be included within a single Attribute of type 26. 1241 However, this enables VSAs to be defined which would not be 1242 supportable by current implementations if placed within the standard 1243 RADIUS attribute space. This has caused problems in standardizing 1244 widely deployed VSAs, as discussed in "RADIUS Design Guidelines" 1245 BCP 158 [RFC6158]. 1247 In addition to extending RADIUS by use of VSAs, SDOs have also 1248 defined new values of the Service-Type attribute in order to create 1249 new RADIUS commands. Since the RADIUS specification [RFC2865] 1250 defined Service-Type values as being allocated First Come, First 1251 Served (FCFS), this essentially enabled new RADIUS commands to be 1252 allocated without IETF review. This oversight has since been fixed 1253 in "IANA Considerations for RADIUS" [RFC3575]. 1255 A.3. TLS Extensions 1257 The Secure Sockets Layer (SSL) v2 protocol was developed by Netscape 1258 to be used to secure online transactions on the Internet. It was 1259 later replaced by SSL v3, also developed by Netscape. SSL v3 was 1260 then further developed by the IETF as the Transport Layer Security 1261 (TLS) 1.0 [RFC2246]. 1263 The SSL v3 protocol was not explicitly specified to be extended. 1264 Even TLS 1.0 did not define an extension mechanism explicitly. 1265 However, extension "loopholes" were available. Extension mechanisms 1266 were finally defined in "Transport Layer Security (TLS) Extensions" 1267 [RFC4366]: 1269 o New versions 1270 o New cipher suites 1271 o Compression 1272 o Expanded handshake messages 1273 o New record types 1274 o New handshake messages 1276 The protocol also defines how implementations should handle unknown 1277 extensions. 1279 Of the above extension methods, new versions and expanded handshake 1280 messages have caused the most interoperability problems. 1281 Implementations are supposed to ignore unknown record types but to 1282 reject unknown handshake messages. 1284 The new version support in SSL/TLS includes a capability to define 1285 new versions of the protocol, while allowing newer implementations to 1286 communicate with older implementations. As part of this 1287 functionality some Key Exchange methods include functionality to 1288 prevent version rollback attacks. 1290 The experience with this upgrade functionality in SSL and TLS is 1291 decidedly mixed: 1293 o SSL v2 and SSL v3/TLS are not compatible. It is possible to use 1294 SSL v2 protocol messages to initiate a SSL v3/TLS connection, but 1295 it is not possible to communicate with a SSL v2 implementation 1296 using SSL v3/TLS protocol messages. 1297 o There are implementations that refuse to accept handshakes using 1298 newer versions of the protocol than they support. 1299 o There are other implementations that accept newer versions, but 1300 have implemented the version rollback protection clumsily. 1302 The SSL v2 problem has forced SSL v3 and TLS clients to continue to 1303 use SSL v2 Client Hellos for their initial handshake with almost all 1304 servers until 2006, much longer than would have been desirable, in 1305 order to interoperate with old servers. 1307 The problem with incorrect handling of newer versions has also forced 1308 many clients to actually disable the newer protocol versions, either 1309 by default, or by automatically disabling the functionality, to be 1310 able to connect to such servers. Effectively, this means that the 1311 version rollback protection in SSL and TLS is non-existent if talking 1312 to a fatally compromised older version. 1314 SSL v3 and TLS also permitted expansion of the Client Hello and 1315 Server Hello handshake messages. This functionality was fully 1316 defined by the introduction of TLS Extensions, which makes it 1317 possible to add new functionality to the handshake, such as the name 1318 of the server the client is connecting to, request certificate status 1319 information, indicate Certificate Authority support, maximum record 1320 length, etc. Several of these extensions also introduce new 1321 handshake messages. 1323 It has turned out that many SSL v3 and TLS implementations that do 1324 not support TLS Extensions, did not, as required by the protocol 1325 specifications, ignore the unknown extensions, but instead failed to 1326 establish connections. Several of the implementations behaving in 1327 this manner are used by high profile Internet sites, such as online 1328 banking sites, and this has caused a significant delay in the 1329 deployment of clients supporting TLS Extensions, and several of the 1330 clients that have enabled support are using heuristics that allow 1331 them to disable the functionality when they detect a problem. 1333 Looking forward, the protocol version problem, in particular, can 1334 cause future security problems for the TLS protocol. The strength of 1335 the digest algorithms (MD5 and SHA-1) used by SSL and TLS is 1336 weakening. If MD5 and SHA-1 weaken to the point where it is feasible 1337 to mount successful attacks against older SSL and TLS versions, the 1338 current error recovery used by clients would become a security 1339 vulnerability (among many other serious problems for the Internet). 1341 To address this issue, TLS 1.2 [RFC5246] makes use of a newer 1342 cryptographic hash algorithm (SHA-256) during the TLS handshake by 1343 default. Legacy ciphersuites can still be used to protect 1344 application data, but new ciphersuites are specified for data 1345 protection as well as for authentication within the TLS handshake. 1346 The hashing method can also be negotiated via a Hello extension. 1347 Implementations are encouraged to implement new ciphersuites, and to 1348 enable the negotiation of the ciphersuite used during a TLS session 1349 to be governed by policy, thus enabling a more rapid transition away 1350 from weakened ciphersuites. 1352 The lesson to be drawn from this experience is that it isn't 1353 sufficient to design extensibility carefully; it must also be 1354 implemented carefully by every implementer, without exception. Test 1355 suites and certification programs can help provide incentives for 1356 implementers to pay attention to implementing extensibility 1357 mechanisms correctly. 1359 A.4. L2TP Extensions 1361 Layer Two Tunneling Protocol (L2TP) [RFC2661] carries Attribute-Value 1362 Pairs (AVPs), with most AVPs having no semantics to the L2TP protocol 1363 itself. However, it should be noted that L2TP message types are 1364 identified by a Message Type AVP (Attribute Type 0) with specific AVP 1365 values indicating the actual message type. Thus, extensions relating 1366 to Message Type AVPs would likely be considered major extensions. 1368 L2TP also provides for Vendor-Specific AVPs. Because everything in 1369 L2TP is encoded using AVPs, it would be easy to define vendor- 1370 specific AVPs that would be considered major extensions. 1372 L2TP also provides for a "mandatory" bit in AVPs. Recipients of L2TP 1373 messages containing AVPs they do not understand but that have the 1374 mandatory bit set, are expected to reject the message and terminate 1375 the tunnel or session the message refers to. This leads to 1376 interesting interoperability issues, because a sender can include a 1377 vendor-specific AVP with the M-bit set, which then causes the 1378 recipient to not interoperate with the sender. This sort of behavior 1379 is counter to the IETF ideals, as implementations of the IETF 1380 standard should interoperate successfully with other implementations 1381 and not require the implementation of non-IETF extensions in order to 1382 interoperate successfully. Section 4.2 of the L2TP specification 1383 [RFC2661] includes specific wording on this point, though there was 1384 significant debate at the time as to whether such language was by 1385 itself sufficient. 1387 Fortunately, it does not appear that the potential problems described 1388 above have yet become a problem in practice. At the time of this 1389 writing, the authors are not aware of the existence of any vendor- 1390 specific AVPs that also set the M-bit. 1392 Change log [RFC Editor: please remove this section] 1394 draft-iab-extension-recs-06: 2011-3-1. Incorporated additional 1395 corrections and organizational improvements. 1397 draft-iab-extension-recs-05: 2011-2-4. Added to the security 1398 considerations section. 1400 draft-iab-extension-recs-04: 2011-2-1. Added a section on 1401 cryptographic agility. Additional reorganization. 1403 draft-iab-extension-recs-03: 2011-1-25. Updates and reorganization 1404 to reflect comments from the IETF community. 1406 draft-iab-extension-recs-02: 2010-7-12. Updates by Bernard Aboba 1408 draft-iab-extension-recs-01: 2010-4-7. Updates by Stuart 1409 Cheshire. 1411 draft-iab-extension-recs-00: 2009-4-24. Updated boilerplate, 1412 author list. 1414 draft-carpenter-extension-recs-04: 2008-10-24. Updated author 1415 addresses, fixed editorial issues. 1417 draft-carpenter-extension-recs-03: 2008-10-17. Updated references, 1418 added material relating to versioning. 1420 draft-carpenter-extension-recs-02: 2007-06-15. Reorganized Sections 1421 2 and 3. 1423 draft-carpenter-extension-recs-01: 2007-03-04. Updated according to 1424 comments, especially the wording about TLS, added various specific 1425 examples. 1427 draft-carpenter-extension-recs-00: original version, 2006-10-12. 1428 Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by 1429 focusing on architectural issues; the more procedural issues in that 1430 draft were moved to RFC 4775. 1432 Authors' Addresses 1434 Brian Carpenter 1435 Department of Computer Science 1436 University of Auckland 1437 PB 92019 1438 Auckland, 1142 1439 New Zealand 1441 Email: brian.e.carpenter@gmail.com 1443 Bernard Aboba 1444 Microsoft Corporation 1445 One Microsoft Way 1446 Redmond, WA 98052 1448 EMail: bernard_aboba@hotmail.com 1450 Stuart Cheshire 1451 Apple Computer, Inc. 1452 1 Infinite Loop 1453 Cupertino, CA 95014 1455 EMail: cheshire@apple.com