idnits 2.17.1 draft-iab-extension-recs-05.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 == 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 (4 February 2011) is 4829 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 (~~), 2 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: August 4, 2011 Internet Architecture Board 6 4 February 2011 8 Design Considerations for Protocol Extensions 9 draft-iab-extension-recs-05 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 August 4, 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. Extension Documentation and Review . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 8 77 3.2 Design for Global Interoperability . . . . . . . . . . . . 8 78 3.3 Architectural Compatibility . . . . . . . . . . . . . . . 9 79 3.4 Protocol Variations . . . . . . . . . . . . . . . . . . . 9 80 3.5 Testability . . . . . . . . . . . . . . . . . . . . . . . 11 81 3.6 Parameter Parameter Registration . . . . . . . . . . . . . 11 82 3.7 Extensions to Critical Infrastructure . . . . . . . . . . 12 83 4. Considerations for the Base Protocol . . . . . . . . . . . . . 13 84 4.1 Version Numbers . . . . . . . . . . . . . . . . . . . . . 13 85 4.2 Reserved Fields . . . . . . . . . . . . . . . . . . . . . 16 86 4.3 Encoding Formats . . . . . . . . . . . . . . . . . . . . . 16 87 4.4 Parameter Space Design . . . . . . . . . . . . . . . . . . 16 88 4.5 Cryptographic Agility . . . . . . . . . . . . . . . . . . 19 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 7.1 Normative References . . . . . . . . . . . . . . . . . . . 20 93 7.2 Informative References . . . . . . . . . . . . . . . . . . 20 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 95 IAB Members . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 Appendix A - Examples . . . . . . . . . . . . . . . . . . . . . . 25 97 A.1 Already documented cases . . . . . . . . . . . . . . . . . 25 98 A.2 RADIUS Extensions . . . . . . . . . . . . . . . . . . . . 25 99 A.3 TLS Extensions . . . . . . . . . . . . . . . . . . . . . . 26 100 A.4 L2TP Extensions . . . . . . . . . . . . . . . . . . . . . 28 101 Change log . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 103 1. Introduction 105 Internet Engineering Task Force (IETF) protocols typically include 106 mechanisms whereby they can be extended in the future. It is of 107 course a good principle to design extensibility into protocols; one 108 common definition of a successful protocol is one that becomes widely 109 used in ways not originally anticipated, as described in "What Makes 110 for a Successful Protocol" [RFC5218]. Well-designed extensibility 111 mechanisms facilitate the evolution of protocols and help make it 112 easier to roll out incremental changes in an interoperable fashion. 114 When an initial protocol design is extended, there is always a risk 115 of unintended consequences, such as interoperability problems or 116 security vulnerabilities. This risk is especially high if the 117 extension is performed by a different team than the original 118 designers, who may stray outside implicit design constraints or 119 assumptions. As a result, extensions should be done carefully and 120 with a full understanding of the base protocol, existing 121 implementations, and current operational practice. 123 This is hardly a recent concern. "TCP Extensions Considered Harmful" 124 [RFC1263] was published in 1991. "Extend" or "extension" occurs in 125 the title of more than 400 existing Request For Comment (RFC) 126 documents. Yet generic extension considerations have not been 127 documented previously. 129 This document describes technical considerations for protocol 130 extensions, in order to minimize such risks. It is intended to 131 assist designers of both base protocols and extensions. Formal 132 procedures for extending IETF protocols are discussed in "Procedures 133 for Protocol Extensions and Variations" BCP 125 [RFC4775]. 135 Section 2 discusses extension documentation and review. Section 3 136 describes architectural principles for protocol extensibility. 137 Section 4 explains how designers of base protocols can take steps to 138 anticipate and facilitate the creation of such subsequent extensions 139 in a safe and reliable manner. Readers are advised to study the 140 whole document, since the considerations are closely linked. 142 1.1. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in BCP 14, RFC 2119 147 [RFC2119]. 149 2. Extension Documentation and Review 151 One of the pre-requisites for interoperable extensibility is proper 152 documentation and review. 154 Protocol components that are designed with the specific intention of 155 allowing extensibility should be clearly identified, with specific 156 and complete instructions on how to extend them. This includes the 157 process for adequate review of extension proposals: do they need 158 community review and if so how much and by whom? 160 The level of review required for protocol extensions will typically 161 vary based on the nature of the extension. Routine extensions may 162 require minimal review, while major extensions may require wide 163 review. Guidance on which extensions may be considered 'routine' and 164 which ones are 'major' are provided in the sections that follow. 166 To help future extension writers to use extension mechanisms 167 properly, there may be a need for explicit guidance relating to 168 extensions beyond what is encapsulated in the IANA considerations 169 section of the base specification. 171 Protocols whose data model is likely to be widely extended 172 (particularly using vendor-specific elements) should have a Design 173 Guidelines document specifically addressing extensions. For example, 174 "Guidelines for Authors and Reviewers of MIB Documents" [RFC4181] 175 provides valuable guidance to protocol designers creating new MIB 176 modules. 178 2.1. When is an Extension Routine? 180 An extension may be considered 'routine' if it amounts to a new data 181 element of a type that is already supported within the data model, 182 and if its handling is opaque to the protocol itself (e.g. does not 183 substantially change the pattern of messages and responses). 185 For this to apply, the protocol must have been designed to carry the 186 proposed data type, so that no changes to the underlying base 187 protocol or existing implementations are needed to carry the new data 188 element. 190 Moreover, no changes should be required to existing and currently 191 deployed implementations of the underlying protocol unless they want 192 to make use of the new data element. Using the existing protocol to 193 carry a new data element should not impact existing implementations 194 or cause operational problems. This typically requires that the 195 protocol silently discard unknown data elements. 197 Examples of routine extensions include the Dynamic Host Configuration 198 Protocol (DHCP) vendor-specific option [RFC2132], RADIUS Vendor- 199 Specific Attributes [RFC2865], the enterprise Object IDentifier (OID) 200 tree for Management Information Base (MIB) modules, vendor 201 Multipurpose Internet Mail Extension (MIME) types, and some classes 202 of (non-critical) certification extensions. Such extensions can 203 safely be made with minimal discussion. 205 In order to increase the likelihood that routine extensions are truly 206 routine, protocol documents should provide guidelines explaining how 207 extensions should be performed. For example, even though DHCP 208 carries opaque data, defining a new option using completely 209 unstructured data may lead to an option that is unnecessarily hard 210 for clients and servers to process. 212 Processes that allow routine extensions with minimal or no review 213 should be used sparingly (such as the "First Come First Served" 214 allocation policy described in "Guidelines for Writing an IANA 215 Considerations Section in RFCs" [RFC5226]). In particular, they 216 should be limited to cases that are unlikely to cause protocol 217 failures, such as allowing new opaque data elements. 219 2.2. What Constitutes a Major Extension? 221 Major extensions may have characteristics leading to a risk of 222 interoperability failure. Where these characteristics are present, 223 it is necessary to pay extremely close attention to backward 224 compatibility with implementations and deployments of the unextended 225 protocol, and to the risk of inadvertent introduction of security or 226 operational exposures. 228 Extension designers should examine their design for the following 229 issues: 231 1. Modifications or extensions to the working of the underlying 232 protocol. This can include changing the semantics of existing 233 Protocol Data Units (PDUs) or defining new message types that may 234 require implementation changes in existing and deployed 235 implementations of the protocol, even if they do not want to make 236 use of the new functions or data types. A base protocol without a 237 "silent discard" rule for unknown data elements may automatically 238 enter this category, even for apparently minor extensions. 240 2. Changes to the transport model. While there are circumstances 241 where specification of additional transport protocols may make 242 sense, removal of a widely implemented transport protocol is 243 highly likely to result in interoperability problems and thus 244 should be avoided wherever possible. 246 Where additional transports are specified, one way to avoid issues 247 is to mandate support for a single transport protocol, while 248 designating other transport protocols as optional. However, if 249 optional transport protocols are introduced due to the unique 250 advantages they afford in certain scenarios, in those situations 251 implementations not supporting optional transport protocols may 252 exhibit degraded performance or may even fail. 254 While requiring support for multiple transport protocols may 255 appear attractive, authors need to realistically evaluate the 256 likelihood that implementers will conform to the requirements. 257 For example, where resources are limited (such as in embedded 258 systems), implementers may choose to only support a subset of the 259 mandated transport protocols, resulting in non-interoperable 260 protocol variants. 262 3. Changes to the basic architectural assumptions. This may 263 include architectural assumptions that are explicitly stated or 264 those that have been assumed by implementers. For example, this 265 would include adding a requirement for session state to a 266 previously stateless protocol. 268 4. New usage scenarios not originally intended or investigated. 269 This can potentially lead to operational difficulties when 270 deployed, even in cases where the "on-the-wire" format has not 271 changed. For example, the level of traffic carried by the 272 protocol may increase substantially, packet sizes may increase, 273 and implementation algorithms that are widely deployed may not 274 scale sufficiently or otherwise be up to the new task at hand. 275 For example, a new DNS Resource Record (RR) type that is too big 276 to fit into a single UDP packet could cause interoperability 277 problems with existing DNS clients and servers. 279 3. Architectural Principles 281 This section describes basic principles of protocol extensibility: 283 1. Extensibility features should be limited to what is reasonably 284 anticipated when the protocol is developed. 286 2. Protocol extensions should be designed for global 287 interoperability. 289 3. Protocol extensions should be architecturally compatible with 290 the base protocol. 292 4. Protocol extension mechanisms should not be used to create 293 incompatible protocol variations. 295 5. Extension mechanisms need to be testable. 297 6. Protocol parameter assignments need to be coordinated to avoid 298 potential conflicts. 300 7. Extensions to critical infrastructure require special care. 302 3.1. Limited Extensibility 304 Designing a protocol for extensibility may have the perverse side 305 effect of making it easy to construct incompatible extensions. 306 Consequently, protocols should not be made more extensible than 307 clearly necessary at inception, and the process for defining new 308 extensibility mechanisms should ensure that adequate review of 309 proposed extensions will take place before widespread adoption. 311 3.2. Design for Global Interoperability 313 The IETF mission [RFC3935] is to create interoperable protocols for 314 the global Internet, not a collection of different incompatible 315 protocols (or "profiles") for use in separate private networks. 316 Experience shows that separate private networks often end up using 317 equipment from the same vendors, or end up having portable equipment 318 like laptop computers move between them, and networks that were 319 originally envisaged as being separate can end up being connected 320 later. 322 As a result, extensions cannot be designed for an isolated 323 environment; instead, extension designers must assume that systems 324 using the extension will need to interoperate with systems on the 325 global Internet. 327 A key requirement for interoperable extension design is that the base 328 protocol must be well designed for interoperability, and that 329 extensions must have unambiguous semantics. Ideally, the protocol 330 mechanisms for extension and versioning should be sufficiently well 331 described that compatibility can be assessed on paper. Otherwise, 332 when two "private" extensions encounter each other on a public 333 network, unexpected interoperability problems may occur. 335 Consider a "private" extension installed on a work computer which, 336 being portable, is sometimes connected to a home network or a hotel 337 network. If the "private" extension is incompatible with an 338 unextended version of the same protocol, problems will occur. 340 Similarly, problems can occur if "private" extensions conflict with 341 each other. For example, imagine the situation where one site chose 342 to use DHCP [RFC2132] option code 62 for one meaning, and a different 343 site chose to use DHCP option code 62 for a completely different, 344 incompatible, meaning. It may be impossible for a vendor of portable 345 computing devices to make a device that works correctly in both 346 environments. 348 One approach to solving this problem has been to reserve parts of an 349 identifier namespace for "site-specific" or "experimental" use, such 350 as "X-" headers in email messages [RFC0822]. This problem with this 351 approach is that when an experiment turns out to be successful, or a 352 site-specific use turns out to have applicability elsewhere, other 353 vendors will then implement that "X-" header for interoperability, 354 and the "X-" header becomes a de facto standard, meaning that it is 355 no longer true that any header beginning "X-" is site-specific or 356 experimental. The notion of "X-" headers was removed from the 357 Internet Message Format standard when it was was updated in 2001 358 [RFC2822]. 360 3.3. Architectural Compatibility 362 Since protocol extension mechanisms may impact interoperability, it 363 is important that they be architecturally compatible with the base 364 protocol. As part of the definition of new extension mechanisms, it 365 is important to address whether the mechanisms make use of features 366 as envisaged by the original protocol designers, or whether a new 367 extension mechanism is being invented. If a new extension mechanism 368 is being invented, then architectural compatibility issues need to be 369 addressed. 371 Documents relying on extension mechanisms need to explicitly identify 372 the mechanisms being relied upon. Where extension guidelines are 373 available, mechanisms need to indicate whether they are compliant 374 with those guidelines and if not, why not. For example, a document 375 defining new data elements should not implicitly define new data 376 types or protocol operations without explicitly describing those 377 dependencies and discussing their impact. 379 3.4. Protocol Variations 381 Protocol variations - specifications that look very similar to the 382 original but don't interoperate with each other or with the original 383 - are even more harmful to interoperability than extensions. In 384 general, such variations should be avoided. Causes of protocol 385 variations include incompatible protocol extensions, uncoordinated 386 protocol development, and poorly designed "profiles". 388 Protocol extension mechanisms should not be used to create 389 incompatible forks in development. An extension may lead to 390 interoperability failures unless the extended protocol correctly 391 supports all mandatory and optional features of the unextended base 392 protocol, and implementations of the base protocol operate correctly 393 in the presence of the extensions. In addition, it is necessary for 394 an extension to interoperate with other extensions. 396 As noted in "Uncoordinated Protocol Development Considered Harmful" 397 [RFC5704], incompatible forks in development can result from the 398 uncoordinated adaptation of a protocol, parameter or code-point. 399 Section 1 of [RFC5704] states: 401 In particular, the IAB considers it an essential principle of the 402 protocol development process that only one SDO maintains design 403 authority for a given protocol, with that SDO having ultimate 404 authority over the allocation of protocol parameter code-points 405 and over defining the intended semantics, interpretation, and 406 actions associated with those code-points. 408 Profiling is a common technique for improving interoperability within 409 a target environment or set of scenarios. Typically, profiles are 410 constructed by narrowing potential implementation choices or by 411 removing protocol features. However, in order to avoid creating 412 interoperability problems when profiled implementations interact with 413 others over the Global Internet, profilers need to remain cognizant 414 of the implications of normative requirements. 416 As noted in "Key words for use in RFCs to Indicate Requirement 417 Levels" [RFC2119] Section 6, imperatives are to be used with care, 418 and as a result, their removal within a profile is likely to result 419 in serious consequences: 421 Imperatives of the type defined in this memo must be used with 422 care and sparingly. In particular, they MUST only be used where 423 it is actually required for interoperation or to limit behavior 424 which has potential for causing harm (e.g., limiting 425 retransmissions) For example, they must not be used to try to 426 impose a particular method on implementors where the method is not 427 required for interoperability. 429 As noted in [RFC2119] Sections 3 and 4, recommendations also cannot 430 be removed from profiles without serious consideration: 432 there may exist valid reasons in particular circumstances to 433 ignore a particular item, but the full implications must be 434 understood and carefully weighed before choosing a different 435 course. 437 As noted in [RFC2119] Section 5, implementations which do not support 438 optional features still retain the obligation to ensure 439 interoperation with implementations that do: 441 An implementation which does not include a particular option MUST 442 be prepared to interoperate with another implementation which does 443 include the option, though perhaps with reduced functionality. In 444 the same vein an implementation which does include a particular 445 option MUST be prepared to interoperate with another 446 implementation which does not include the option (except, of 447 course, for the feature the option provides.) 449 3.5. Testability 451 Experience has shown that it is insufficient merely to correctly 452 specify extensibility and backwards compatibility in an RFC. It is 453 also important that implementations respect the compatibility 454 mechanisms; if not, non-interoperable pairs of implementations may 455 arise. The TLS case study (Appendix A.3) shows how important this 456 can be. 458 In order to determine whether protocol extension mechanisms have been 459 properly implemented, testing is required. However, for this to be 460 possible, test cases need to be developed. If a base protocol 461 document specifies extension mechanisms but does not utilize them or 462 provide examples, it may not be possible to develop effective test 463 cases based on the base protocol specification alone. As a result, 464 base protocol implementations may not be properly tested and non- 465 compliant extension behavior may not be detected until these 466 implementations are widely deployed. 468 To encourage correct implementation of extension mechanisms, base 469 protocol specifications should clearly articulate the expected 470 behavior of extension mechanisms and should include examples of 471 correct and incorrect extension behavior. 473 3.6. Protocol Parameter Registration 475 An extension is often likely to make use of additional values added 476 to an existing IANA registry (in many cases, simply by adding a new 477 Type-Length-Value (TLV) field). To avoid conflicting usage of the 478 same value, as well as to prevent potential difficulties in 479 determining and transferring parameter ownership, it is essential 480 that all new values are properly registered by the applicable 481 procedures. 483 For general rules see "Guidelines for Writing an IANA Considerations 484 Section in RFCs" [RFC5226], and for specific rules and registries see 485 the individual protocol specification RFCs and the IANA web site. If 486 this is not done, there is nothing to prevent two different 487 extensions picking the same value. When these two extensions "meet" 488 each other on the Internet, failure is inevitable. 490 A surprisingly common case of this is misappropriation of assigned 491 Transmission Control Protocol (TCP) (or User Datagram Protocol (UDP)) 492 registered port numbers. This can lead to a client for one service 493 attempting to communicate with a server for another service. 494 Numerous cases could be cited, but not without embarrassing specific 495 implementers. 497 While in theory a "standards track" or "IETF consensus" parameter 498 allocation policy may be instituted to encourage protocol parameter 499 registration or to improve interoperability, in practice these 500 policies, if administered clumsily, can have the opposite effect, 501 discouraging protocol parameter registration and encouraging rampant 502 self-allocation. These effects have also been observed in a number 503 of instances. 505 In some cases, it may be appropriate to use values designated as 506 "experimental" or "local use" in early implementations of an 507 extension. For example, "Experimental Values in IPv4, IPv6, ICMPv4, 508 ICMPv6, UDP and TCP Headers" [RFC4727] discusses experimental values 509 for IP and transport headers, and "Definition of the Differentiated 510 Services Field (DS Field) in the IPv4 and IPv6 Headers" [RFC2474] 511 defines experimental/local use ranges for differentiated services 512 code points. Such values should be used with care and only for their 513 stated purpose: experiments and local use. They are unsuitable for 514 Internet-wide use, since they may be used for conflicting purposes 515 and thereby cause interoperability failures. Packets containing 516 experimental or local use values must not be allowed out of the 517 domain in which they are meaningful. 519 3.7. Extensions to Critical Infrastructure 521 Some protocols (such as Domain Name Service (DNS) and Border Gateway 522 Protocol (BGP)) have become critical components of the Internet 523 infrastructure. When such protocols are extended, the potential 524 exists for negatively impacting the reliability and security of the 525 global Internet. 527 As a result, special care needs to be taken with these extensions, 528 such as taking explicit steps to isolate existing uses from new ones. 529 For example, this can be accomplished by requiring the extension to 530 utilize a different port or multicast address, or by implementing the 531 extension within a separate process, without access to the data and 532 control structures of the base protocol. 534 4. Considerations for the Base Protocol 536 Good extension design depends on a well designed base protocol. 537 Interoperability stems from a number of factors, including: 539 1. A well-written specification. Does the specification make 540 clear what an implementor needs to support and does it define the 541 impact that individual operations (e.g. a message sent to a peer) 542 will have when invoked? 544 2. Design for deployability. This includes understanding what 545 current implementations do and how a proposed extension will 546 interact with deployed systems. Will a proposed extension (or its 547 proposed usage) operationally stress existing implementations or 548 the underlying protocol itself if widely deployed? 550 3. An adequate transition or coexistence story. What impact will 551 the proposed extension have on implementations that do not 552 understand it? Is there a way to negotiate or determine the 553 capabilities of a peer? Can the extended protocol negotiate with 554 an unextended partner to find a common subset of useful functions? 556 4. Respecting underlying architectural or security assumptions. 557 This includes assumptions that may not be well-documented, those 558 that may have arisen as the result of operational experience, or 559 those that only became understood after the original protocol was 560 published. For example, do the extensions reverse the flow of 561 data, allow formerly static parameters to be changed on the fly, 562 or change assumptions relating to the frequency of reads/writes? 564 5. Minimizing impact on critical infrastructure. Does the 565 proposed extension (or its proposed usage) have the potential for 566 negatively impacting critical infrastructure to the point where 567 explicit steps would be appropriate to isolate existing uses from 568 new ones? 570 6. Data model extensions. Does the proposed extension extend the 571 data model in a major way? For example, are new data types 572 defined that may require code changes within existing 573 implementations? 575 4.1. Version Numbers 577 Any mechanism for extension by versioning must include provisions to 578 ensure interoperability, or at least clean failure modes. Imagine 579 someone creating a protocol and using a "version" field and 580 populating it with a value (1, let's say), but giving no information 581 about what would happen when a new version number appears in it. 583 That's bad protocol design and description; it should be clear what 584 the expectation is and how you test it. For example, stating that 585 1.X must be compatible with any version 1 code, but version 2 or 586 greater is not expected to be compatible, has different implications 587 than stating that version 1 must be a proper subset of version 2. 589 An example is ROHC (Robust Header Compression). ROHCv1 [RFC3095] 590 supports a certain set of profiles for compression algorithms. But 591 experience had shown that these profiles had limitations, so the ROHC 592 WG developed ROHCv2 [RFC5225]. A ROHCv1 implementation does not 593 contain code for the ROHCv2 profiles. As the ROHC WG charter said 594 during the development of ROHCv2: 596 It should be noted that the v2 profiles will thus not be 597 compatible with the original (ROHCv1) profiles, which means less 598 complex ROHC implementations can be realized by not providing 599 support for ROHCv1 (over links not yet supporting ROHC, or by 600 shifting out support for ROHCv1 in the long run). Profile support 601 is agreed through the ROHC channel negotiation, which is part of 602 the ROHC framework and thus not changed by ROHCv2. 604 Thus in this case both backwards-compatible and backwards- 605 incompatible deployments are possible. The important point is a 606 clearly thought out approach to the question of operational 607 compatibility. In the past, protocols have utilized a variety of 608 strategies for versioning, many of which have proven problematic. 609 These include: 611 1. No versioning support. This approach is exemplified by 612 Extensible Authentication Protocol (EAP) [RFC3748] as well as 613 Remote Authentication Dial In User Service (RADIUS) [RFC2865], 614 both of which provide no support for versioning. While lack of 615 versioning support protects against the proliferation of 616 incompatible dialects, the need for extensibility is likely to 617 assert itself in other ways, so that ignoring versioning entirely 618 may not be the most forward thinking approach. 620 2. Highest mutually supported version (HMSV). In this approach, 621 implementations exchange the version numbers of the highest 622 version each supports, with the negotiation agreeing on the 623 highest mutually supported protocol version. This approach 624 implicitly assumes that later versions provide improved 625 functionality, and that advertisement of a particular version 626 number implies support for all lower version numbers. Where these 627 assumptions are invalid, this approach breaks down, potentially 628 resulting in interoperability problems. An example of this issue 629 occurs in Protected EAP [PEAP] where implementations of higher 630 versions may not necessarily provide support for lower versions. 632 3. Assumed backward compatibility. In this approach, 633 implementations may send packets with higher version numbers to 634 legacy implementations supporting lower versions, but with the 635 assumption that the legacy implementations will interpret packets 636 with higher version numbers using the semantics and syntax defined 637 for lower versions. This is the approach taken by Port-Based 638 Access Control [IEEE-802.1X]. For this approach to work, legacy 639 implementations need to be able to accept packets of known type 640 with higher protocol versions without discarding them; protocol 641 enhancements need to permit silent discard of unsupported 642 extensions; implementations supporting higher versions need to 643 refrain from mandating new features when encountering legacy 644 implementations. 646 4. Major/minor versioning. In this approach, implementations with 647 the same major version but a different minor version are assumed 648 to be backward compatible, but implementations are assumed to be 649 required to negotiate a mutually supported major version number. 650 This approach assumes that implementations with a lower minor 651 version number but the same major version can safely ignore 652 unsupported protocol messages. 654 5. Min/max versioning. This approach is similar to HMSV, but 655 without the implied obligation for clients and servers to support 656 all versions back to version 1, in perpetuity. It allows clients 657 and servers to cleanly drop support for early versions when those 658 versions become so old that they are no longer relevant and no 659 longer required. In this approach, the client initiating the 660 connection reports the highest and lowest protocol versions it 661 understands. The server reports back the chosen protocol version: 663 a. If the server understands one or more versions in the client's 664 range, it reports back the highest mutually understood version. 666 b. If there is no mutual version, then the server reports back 667 some version that it does understand (selected as described 668 below). The connection is then typically dropped by client or 669 server, but reporting this version number first helps facilitate 670 useful error messages at the client end: 672 * If there is no mutual version, and the server speaks any 673 version higher than client max, it reports the lowest version it 674 speaks which is greater than the client max. The client can 675 then report to the user, "You need to upgrade to at least 676 version ." 678 * Else, the server reports the highest version it speaks. The 679 client can then report to the user, "You need to request the 680 server operator to upgrade to at least version ." 682 Protocols generally do not need any version-negotiation mechanism 683 more complicated than the mechanisms described here. The nature of 684 protocol version-negotiation mechanisms is that, by definition, they 685 don't get widespread real-world testing until *after* the base 686 protocol has been deployed for a while, and its deficiencies have 687 become evident. This means that, to be useful, a protocol version 688 negotiation mechanism should be simple enough that it can reasonably 689 be assumed that all the implementers of the first protocol version at 690 least managed to implement the version-negotiation mechanism 691 correctly. 693 4.2. Reserved Fields 695 Protocols commonly include one or more "reserved" fields, clearly 696 intended for future extensions. It is good practice to specify the 697 value to be inserted in such a field by the sender (typically zero) 698 and the action to be taken by the receiver when seeing some other 699 value (typically no action). In packet format diagrams, such fields 700 are typically labeled "MBZ", to be read as, "Must Be Zero on 701 transmission, Must Be Ignored on reception." A common mistake of 702 inexperienced protocol implementers is to think that "MBZ" means that 703 it's their software's job to verify that the value of the field is 704 zero on reception, and reject the packet if not. This is a mistake, 705 and such software will fail when it encounters future versions of the 706 protocol where these previously reserved fields are given new defined 707 meanings. Similarly, protocols should carefully specify how 708 receivers should react to unknown TLVs etc., such that failures occur 709 only when that is truly the intended outcome. 711 4.3. Encoding Formats 713 Using widely-supported encoding formats leads to better 714 interoperability and easier extensibility. An excellent example is 715 the Simple Network Management Protocol (SNMP) SMI. Guidelines exist 716 for defining the MIB objects that SNMP carries [RFC4181]. Also, 717 multiple textual conventions have been published, so that MIB 718 designers do not have to reinvent the wheel when they need a commonly 719 encountered construct. For example, the "Textual Conventions for 720 Internet Network Addresses" [RFC4001] can be used by any MIB designer 721 needing to define objects containing IP addresses, thus ensuring 722 consistency as the body of MIBs is extended. 724 4.4. Parameter Space Design 726 In some protocols the parameter space is either infinite (e.g. Header 727 field names) or sufficiently large that it is unlikely to be 728 exhausted. In other protocols, the parameter space is finite, and in 729 some cases, has proven inadequate to accommodate demand. Common 730 mistakes include: 732 a. A version field that is too small (e.g. two bits or less). When 733 designing a version field, existing as well as potential versions of 734 a protocol need to be taken into account. For example, if a protocol 735 is being standardized for which there are existing implementations 736 with known interoperability issues, more than one version for "pre- 737 standard" implementations may be required. If two "pre-standard" 738 versions are required in addition to a version for an IETF standard, 739 then a two-bit version field would only leave one additional version 740 code-point for a future update, which could be insufficient. This 741 problem was encountered during the development of the PEAPv2 protocol 742 [PEAP]. 744 b. A small parameter space (e.g. 8-bits or less) along with a First 745 Come, First Served (FCFS) allocation policy. In general, an FCFS 746 allocation policy is only appropriate in situations where parameter 747 exhaustion is highly unlikely. In situations where substantial 748 demand is anticipated within a parameter space, the space should 749 either be designed to be sufficient to handle that demand, or vendor 750 extensibility should be provided to enable vendors to self-allocate. 751 The combination of a small parameter space, an FCFS allocation 752 policy, and no support for vendor extensibility is particularly 753 likely to prove ill-advised. An example of such a combination was 754 the design of the original 8-bit EAP Method Type space [RFC2284]. 756 Once the potential for parameter exhaustion becomes apparent, it is 757 important that it be addressed as quickly as possible. Protocol 758 changes can take years to appear in implementations and by then the 759 exhaustion problem could become acute. 761 Options for addressing a protocol parameter exhaustion problem 762 include: 764 Rethinking the allocation regime 765 Where it becomes apparent that the size of a parameter space is 766 insufficient to meet demand, it may be necessary to rethink the 767 allocation mechanism, in order to prevent rapid parameter space 768 exhaustion. For example, a few years after approval of RFC 2284 769 [RFC2284], it became clear that the combination of a FCFS 770 allocation policy and lack of support for vendor-extensions had 771 created the potential for exhaustion of the EAP Method Type space 772 within a few years. To address the issue, [RFC3748] Section 6.2 773 changed the allocation policy for EAP Method Types from FCFS to 774 Expert Review, with Specification Required. 776 Support for vendor-specific parameters 777 If the demand that cannot be accommodated is being generated by 778 vendors, merely making allocation harder could make things worse if 779 this encourages vendors to self-allocate, creating interoperability 780 problems. In such a situation, support for vendor-specific 781 parameters should be considered, allowing each vendor to self- 782 allocate within their own vendor-specific space based on a vendor's 783 Private Enterprise Code (PEC). For example, in the case of the EAP 784 Method Type space, [RFC3748] Section 6.2 also provided for an 785 Expanded Type space for "functions specific only to one vendor's 786 implementation". 788 Extensions to the parameter space 789 If the goal is to stave off exhaustion in the face of high demand, 790 a larger parameter space may be helpful. Where vendor-specific 791 parameter support is available, this may be achieved by allocating 792 an PEC for IETF use. Otherwise it may be necessary to try to extend 793 the size of the parameter fields, which could require a new 794 protocol version or other substantial protocol changes. 796 Parameter reclamation 797 In order to gain time, it may be necessary to reclaim unused 798 parameters. However, it may not be easy to determine whether a 799 parameter that has been allocated is in use or not, particularly if 800 the entity that obtained the allocation no longer exists or has 801 been acquired (possibly multiple times). 803 Parameter Transfer 804 When all the above mechanisms have proved infeasible and parameter 805 exhaustion looms in the near future, enabling the transfer of 806 ownership of protocol parameters can be considered as a means for 807 improving allocation efficiency. However, enabling transfer of 808 parameter ownership can be far from simple if the parameter 809 allocation process was not originally designed to enable title 810 searches and ownership transfers. 812 A parameter allocation process designed to uniquely allocate code- 813 points is fundamentally different from one designed to enable title 814 search and transfer. If the only goal is to ensure that a 815 parameter is not allocated more than once, the parameter registry 816 will only need to record the initial allocation. On the other 817 hand, if the goal is to enable transfer of ownership of a protocol 818 parameter, then it is important not only to record the initial 819 allocation, but also to track subsequent ownership changes, so as 820 to make it possible to determine and transfer title. Given the 821 difficulty of converting from a unique allocation regime to one 822 requiring support for title search and ownership transfer, it is 823 best for the desired capabilities to be carefully thought through 824 at the time of registry establishment. 826 4.5. Cryptographic Agility 828 Extensibility with respect to cryptographic algorithms is desirable 829 in order to provide resilience against the compromise of any 830 particular algorithm. "Guidance for Authentication, Authorization, 831 and Accounting (AAA) Key Management" BCP 132 [RFC4962] Section 3 832 provides some basic advice: 834 The ability to negotiate the use of a particular cryptographic 835 algorithm provides resilience against compromise of a particular 836 cryptographic algorithm... This is usually accomplished by 837 including an algorithm identifier and parameters in the protocol, 838 and by specifying the algorithm requirements in the protocol 839 specification. While highly desirable, the ability to negotiate 840 key derivation functions (KDFs) is not required. For 841 interoperability, at least one suite of mandatory-to-implement 842 algorithms MUST be selected... 844 This requirement does not mean that a protocol must support both 845 public-key and symmetric-key cryptographic algorithms. It means 846 that the protocol needs to be structured in such a way that 847 multiple public-key algorithms can be used whenever a public-key 848 algorithm is employed. Likewise, it means that the protocol needs 849 to be structured in such a way that multiple symmetric-key 850 algorithms can be used whenever a symmetric-key algorithm is 851 employed. 853 In practice, the most difficult challenge in providing cryptographic 854 agility is providing for a smooth transition in the event that a 855 mandatory-to-implement algorithm is compromised. Since it may take 856 significant time to provide for widespread implementation of a 857 previously undeployed alternative, it is often advisable to recommend 858 implementation of alternative algorithms of distinct lineage in 859 addition to those made mandatory-to-implement, so that an alternative 860 algorithm is readily available. If such a recommended alternative is 861 not in place, then it would be wise to issue such a recommendation as 862 soon as indications of a potential weakness surface. This is 863 particularly important in the case of potential weakness in 864 algorithms used to authenticate and integrity-protect the 865 cryptographic negotiation itself, such as KDFs or message integrity 866 checks (MICs). Without secure alternatives to compromised KDF or MIC 867 algorithms, it may not be possible to secure the cryptographic 868 negotiation against a bidding-down attack while retaining backward 869 compatibility. 871 5. Security Considerations 873 An extension must not introduce new security risks without also 874 providing adequate counter-measures, and in particular it must not 875 inadvertently defeat security measures in the unextended protocol. 876 Thus, the security analysis for an extension needs to be as thorough 877 as for the original protocol - effectively it needs to be a 878 regression analysis to check that the extension doesn't inadvertently 879 invalidate the original security model. 881 This analysis may be simple (e.g. adding an extra opaque data element 882 is unlikely to create a new risk) or quite complex (e.g. adding a 883 handshake to a previously stateless protocol may create a completely 884 new opportunity for an attacker). 886 When the extensibility of a design includes allowing for new and 887 presumably more powerful cryptographic algorithms to be added, 888 particular care is needed to ensure that the result is in fact 889 increased security. For example, it may be undesirable from a 890 security viewpoint to allow negotiation down to an older, less secure 891 algorithm. 893 6. IANA Considerations 895 [RFC Editor: please remove this section prior to publication.] 897 This document has no IANA Actions. 899 7. References 901 7.1. Normative References 903 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 904 Requirement Levels", BCP 14, RFC 2119, March 1997. 906 [RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures 907 for Protocol Extensions and Variations", BCP 125, RFC 908 4775, December 2006. 910 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 911 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 912 May 2008. 914 7.2. Informative References 916 [I-D.ietf-radext-design] 917 DeKok, A. and G. Weber, "RADIUS Design Guidelines", 918 draft-ietf-radext-design-19.txt, Internet draft (work in 919 progress), November 2010. 921 [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local 922 and Metropolitan Area Networks: Port-Based Network Access 923 Control", IEEE Standard 802.1X-2004, December 2004. 925 [PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G. 926 and S. Josefsson, "Protected EAP Protocol (PEAP) Version 927 2", draft-josefsson-pppext-eap-tls-eap-10.txt, Expired 928 Internet draft (work in progress), October 2004. 930 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 931 text messages", STD 11, RFC 822, August 1982. 933 [RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered 934 Harmful", RFC 1263, October 1991. 936 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP 937 Vendor Extensions", RFC 2132, March 1997. 939 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 940 RFC 2246, January 1999. 942 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 943 Authentication Protocol (EAP)", RFC 2284, March 1998. 945 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 946 "Definition of the Differentiated Services Field (DS 947 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 948 1998. 950 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 951 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 952 RFC 2661, August 1999. 954 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",RFC 955 2671, August 1999. 957 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 958 2001. 960 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 961 "Remote Authentication Dial In User Service (RADIUS)", 962 RFC 2865, June 2000. 964 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, 965 H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., 966 Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, 967 K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust 968 Header Compression (ROHC): Framework and four profiles: 969 RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. 971 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 972 and B. Rosen, "Change Process for the Session Initiation 973 Protocol (SIP)", BCP 67, RFC 3427, December 2002. 975 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 976 Authentication Dial In User Service)", RFC 3575, July 977 2003. 979 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 980 (RR) Types", RFC 3597, September 2003. 982 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 983 Provisioning Protocol (EPP)", RFC 3735, March 2004. 985 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 986 Lefkowetz, "Extensible Authentication Protocol (EAP)", 987 RFC 3748, June 2004. 989 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", RFC 990 3935, October 2004. 992 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 993 Schoenwaelder, "Textual Conventions for Internet Network 994 Addresses", RFC 4001, February 2005. 996 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 997 Documents", BCP 111, RFC 4181, September 2005. 999 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, 1000 J., and T. Wright, "Transport Layer Security (TLS) 1001 Extensions", RFC 4366, April 2006. 1003 [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors 1004 of Extensions to the Session Initiation Protocol (SIP)", 1005 RFC 4485, May 2006. 1007 [RFC4521] Zeilenga, K., "Considerations for Lightweight Directory 1008 Access Protocol (LDAP) Extensions", BCP 118, RFC 4521, 1009 June 2006. 1011 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1012 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 1014 [RFC4929] Andersson, L. and A. Farrel, "Change Process for 1015 Multiprotocol Label Switching (MPLS) and Generalized MPLS 1016 (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, 1017 June 2007. 1019 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 1020 Authorization, and Accounting (AAA) Key Management", BCP 1021 132, RFC 4962, July 2007. 1023 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 1024 Dial In User Service (RADIUS) Implementation Issues and 1025 Suggested Fixes", RFC 5080, December 2007. 1027 [RFC5218] Thaler, D., and B. Aboba, "What Makes for a Successful 1028 Protocol?", RFC 5218, July 2008. 1030 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 1031 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 1032 UDP-Lite", RFC 5225, April 2008. 1034 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1035 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1037 [RFC5704] Bryant, S. and M. Morrow, "Uncoordinated Protocol 1038 Development Considered Harmful", RFC 5704, November 2009. 1040 [RFC5727] Peterson, J., Jennings, C. and R. Sparks, "Change Process 1041 for the Session Initiation Protocol (SIP) and the Real- 1042 time Applications and Infrastructure Area", RFC 5727, 1043 March 2010. 1045 Acknowledgments 1047 This document is heavily based on an earlier draft under a different 1048 title by Scott Bradner and Thomas Narten. 1050 That draft stated: The initial version of this document was put 1051 together by the IESG in 2002. Since then, it has been reworked in 1052 response to feedback from John Loughney, Henrik Levkowetz, Mark 1053 Townsley, Randy Bush and others. 1055 Valuable comments and suggestions on the current form of the document 1056 were made by Jari Arkko, Ted Hardie, Loa Andersson, Eric Rescorla, 1057 Pekka Savola, Leslie Daigle, Alfred Hoenes, Adam Roach and Phillip 1058 Hallam-Baker. 1060 The text on TLS experience was contributed by Yngve Pettersen. 1062 IAB Members at the Time of this Writing 1064 Bernard Aboba 1065 Marcelo Bagnulo 1066 Ross Callon 1067 Spencer Dawkins 1068 Vijay Gill 1069 Russ Housley 1070 John Klensin 1071 Olaf Kolkman 1072 Danny McPherson 1073 Jon Peterson 1074 Andrei Robachevsky 1075 Dave Thaler 1076 Hannes Tschofenig 1078 Appendix A. Examples 1080 This section discusses some specific examples, as case studies. 1082 A.1. Already documented cases 1084 There are certain documents that specify a change process or describe 1085 extension considerations for specific IETF protocols: 1087 The SIP change process [RFC3427], [RFC4485], [RFC5727] 1088 The (G)MPLS change process (mainly procedural) [RFC4929] 1089 LDAP extensions [RFC4521] 1090 EPP extensions [RFC3735] 1091 DNS extensions [RFC2671][RFC3597] 1093 It is relatively common for MIBs, which are all in effect extensions 1094 of the SMI data model, to be defined or extended outside the IETF. 1095 BCP 111 [RFC4181] offers detailed guidance for authors and reviewers. 1097 A.2. RADIUS Extensions 1099 The RADIUS [RFC2865] protocol was designed to be extensible via 1100 addition of Attributes to a Data Dictionary on the server, without 1101 requiring code changes. However, this extensibility model assumed 1102 that Attributes would conform to a limited set of data types and that 1103 vendor extensions would be limited to use by vendors, in situations 1104 in which interoperability was not required. Subsequent developments 1105 have stretched those assumptions. 1107 Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism 1108 for Vendor-Specific extensions (Attribute 26), and states that use of 1109 Vendor-Specific extensions: 1111 should be encouraged instead of allocation of global attribute 1112 types, for functions specific only to one vendor's implementation 1113 of RADIUS, where no interoperability is deemed useful. 1115 However, in practice usage of Vendor-Specific Attributes (VSAs) has 1116 been considerably broader than this. In particular, VSAs have been 1117 used by Standards Development Organizations (SDOs) to define their 1118 own extensions to the RADIUS protocol. 1120 This has caused a number of problems. Since the VSA mechanism was 1121 not designed for interoperability, VSAs do not contain a "mandatory" 1122 bit. As a result, RADIUS clients and servers may not know whether it 1123 is safe to ignore unknown attributes. For example, Section 5 of the 1124 RADIUS specification [RFC2865] states: 1126 A RADIUS server MAY ignore Attributes with an unknown Type. A 1127 RADIUS client MAY ignore Attributes with an unknown Type. 1129 However, in the case where the VSAs pertain to security (e.g. 1130 Filters) it may not be safe to ignore them, since the RADIUS 1131 specification [RFC2865] also states: 1133 A NAS that does not implement a given service MUST NOT implement 1134 the RADIUS attributes for that service. For example, a NAS that 1135 is unable to offer ARAP service MUST NOT implement the RADIUS 1136 attributes for ARAP. A NAS MUST treat a RADIUS access-accept 1137 authorizing an unavailable service as an access-reject instead." 1139 Detailed discussion of the issues arising from this can be found in 1140 "Common Remote Authentication Dial In User Service (RADIUS) 1141 Implementation Issues and Suggested Fixes" [RFC5080] Section 2.5. 1143 Since it was not envisaged that multi-vendor VSA implementations 1144 would need to interoperate, the RADIUS specification [RFC2865] does 1145 not define the data model for VSAs, and allows multiple sub- 1146 attributes to be included within a single Attribute of type 26. 1147 However, this enables VSAs to be defined which would not be 1148 supportable by current implementations if placed within the standard 1149 RADIUS attribute space. This has caused problems in standardizing 1150 widely deployed VSAs, as discussed in "RADIUS Design Guidelines" 1151 [I-D.ietf-radext-design]. 1153 In addition to extending RADIUS by use of VSAs, SDOs have also 1154 defined new values of the Service-Type attribute in order to create 1155 new RADIUS commands. Since the RADIUS specification [RFC2865] 1156 defined Service-Type values as being allocated First Come, First 1157 Served (FCFS), this essentially enabled new RADIUS commands to be 1158 allocated without IETF review. This oversight has since been fixed 1159 in "IANA Considerations for RADIUS" [RFC3575]. 1161 A.3. TLS Extensions 1163 The Secure Sockets Layer (SSL) v2 protocol was developed by Netscape 1164 to be used to secure online transactions on the Internet. It was 1165 later replaced by SSL v3, also developed by Netscape. SSL v3 was 1166 then further developed by the IETF as the Transport Layer Security 1167 (TLS) 1.0 [RFC2246]. 1169 The SSL v3 protocol was not explicitly specified to be extended. 1170 Even TLS 1.0 did not define an extension mechanism explicitly. 1171 However, extension "loopholes" were available. Extension mechanisms 1172 were finally defined in "Transport Layer Security (TLS) Extensions" 1173 [RFC4366]: 1175 o New versions 1176 o New cipher suites 1177 o Compression 1178 o Expanded handshake messages 1179 o New record types 1180 o New handshake messages 1182 The protocol also defines how implementations should handle unknown 1183 extensions. 1185 Of the above extension methods, new versions and expanded handshake 1186 messages have caused the most interoperability problems. 1187 Implementations are supposed to ignore unknown record types but to 1188 reject unknown handshake messages. 1190 The new version support in SSL/TLS includes a capability to define 1191 new versions of the protocol, while allowing newer implementations to 1192 communicate with older implementations. As part of this 1193 functionality some Key Exchange methods include functionality to 1194 prevent version rollback attacks. 1196 The experience with this upgrade functionality in SSL and TLS is 1197 decidedly mixed: 1199 o SSL v2 and SSL v3/TLS are not compatible. It is possible to use 1200 SSL v2 protocol messages to initiate a SSL v3/TLS connection, but 1201 it is not possible to communicate with a SSL v2 implementation 1202 using SSL v3/TLS protocol messages. 1203 o There are implementations that refuse to accept handshakes using 1204 newer versions of the protocol than they support. 1205 o There are other implementations that accept newer versions, but 1206 have implemented the version rollback protection clumsily. 1208 The SSL v2 problem has forced SSL v3 and TLS clients to continue to 1209 use SSL v2 Client Hellos for their initial handshake with almost all 1210 servers until 2006, much longer than would have been desirable, in 1211 order to interoperate with old servers. 1213 The problem with incorrect handling of newer versions has also forced 1214 many clients to actually disable the newer protocol versions, either 1215 by default, or by automatically disabling the functionality, to be 1216 able to connect to such servers. Effectively, this means that the 1217 version rollback protection in SSL and TLS is non-existent if talking 1218 to a fatally compromised older version. 1220 SSL v3 and TLS also permitted expansion of the Client Hello and 1221 Server Hello handshake messages. This functionality was fully 1222 defined by the introduction of TLS Extensions, which makes it 1223 possible to add new functionality to the handshake, such as the name 1224 of the server the client is connecting to, request certificate status 1225 information, indicate Certificate Authority support, maximum record 1226 length, etc. Several of these extensions also introduce new 1227 handshake messages. 1229 It has turned out that many SSL v3 and TLS implementations that do 1230 not support TLS Extensions, did not, as required by the protocol 1231 specifications, ignore the unknown extensions, but instead failed to 1232 establish connections. Several of the implementations behaving in 1233 this manner are used by high profile Internet sites, such as online 1234 banking sites, and this has caused a significant delay in the 1235 deployment of clients supporting TLS Extensions, and several of the 1236 clients that have enabled support are using heuristics that allow 1237 them to disable the functionality when they detect a problem. 1239 Looking forward, the protocol version problem, in particular, can 1240 cause future security problems for the TLS protocol. The strength of 1241 the digest algorithms (MD5 and SHA-1) used by SSL and TLS is 1242 weakening. If MD5 and SHA-1 weaken to the point where it is feasible 1243 to mount successful attacks against older SSL and TLS versions, the 1244 current error recovery used by clients would become a security 1245 vulnerability (among many other serious problems for the Internet). 1247 To address this issue, TLS 1.2 [RFC5246] makes use of a newer 1248 cryptographic hash algorithm (SHA-256) during the TLS handshake by 1249 default. Legacy ciphersuites can still be used to protect 1250 application data, but new ciphersuites are specified for data 1251 protection as well as for authentication within the TLS handshake. 1252 The hashing method can also be negotiated via a Hello extension. 1253 Implementations are encouraged to implement new ciphersuites, and to 1254 enable the negotiation of the ciphersuite used during a TLS session 1255 to be governed by policy, thus enabling a more rapid transition away 1256 from weakened ciphersuites. 1258 The lesson to be drawn from this experience is that it isn't 1259 sufficient to design extensibility carefully; it must also be 1260 implemented carefully by every implementer, without exception. Test 1261 suites and certification programs can help provide incentives for 1262 implementers to pay attention to implementing extensibility 1263 mechanisms correctly. 1265 A.4. L2TP Extensions 1267 Layer Two Tunneling Protocol (L2TP) [RFC2661] carries Attribute-Value 1268 Pairs (AVPs), with most AVPs having no semantics to the L2TP protocol 1269 itself. However, it should be noted that L2TP message types are 1270 identified by a Message Type AVP (Attribute Type 0) with specific AVP 1271 values indicating the actual message type. Thus, extensions relating 1272 to Message Type AVPs would likely be considered major extensions. 1274 L2TP also provides for Vendor-Specific AVPs. Because everything in 1275 L2TP is encoded using AVPs, it would be easy to define vendor- 1276 specific AVPs that would be considered major extensions. 1278 L2TP also provides for a "mandatory" bit in AVPs. Recipients of L2TP 1279 messages containing AVPs they do not understand but that have the 1280 mandatory bit set, are expected to reject the message and terminate 1281 the tunnel or session the message refers to. This leads to 1282 interesting interoperability issues, because a sender can include a 1283 vendor-specific AVP with the M-bit set, which then causes the 1284 recipient to not interoperate with the sender. This sort of behavior 1285 is counter to the IETF ideals, as implementations of the IETF 1286 standard should interoperate successfully with other implementations 1287 and not require the implementation of non-IETF extensions in order to 1288 interoperate successfully. Section 4.2 of the L2TP specification 1289 [RFC2661] includes specific wording on this point, though there was 1290 significant debate at the time as to whether such language was by 1291 itself sufficient. 1293 Fortunately, it does not appear that the potential problems described 1294 above have yet become a problem in practice. At the time of this 1295 writing, the authors are not aware of the existence of any vendor- 1296 specific AVPs that also set the M-bit. 1298 Change log [RFC Editor: please remove this section] 1300 draft-iab-extension-recs-04: 2011-2-3. Added a section on 1301 cryptographic agility. Additional reorganization. 1303 draft-iab-extension-recs-03: 2011-1-25. Updates and reorganization 1304 to reflect comments from the IETF community. 1306 draft-iab-extension-recs-02: 2010-7-12. Updates by Bernard Aboba 1308 draft-iab-extension-recs-01: 2010-4-7. Updates by Stuart 1309 Cheshire. 1311 draft-iab-extension-recs-00: 2009-4-24. Updated boilerplate, 1312 author list. 1314 draft-carpenter-extension-recs-04: 2008-10-24. Updated author 1315 addresses, fixed editorial issues. 1317 draft-carpenter-extension-recs-03: 2008-10-17. Updated references, 1318 added material relating to versioning. 1320 draft-carpenter-extension-recs-02: 2007-06-15. Reorganized Sections 1321 2 and 3. 1323 draft-carpenter-extension-recs-01: 2007-03-04. Updated according to 1324 comments, especially the wording about TLS, added various specific 1325 examples. 1327 draft-carpenter-extension-recs-00: original version, 2006-10-12. 1328 Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by 1329 focusing on architectural issues; the more procedural issues in that 1330 draft were moved to RFC 4775. 1332 Authors' Addresses 1334 Brian Carpenter 1335 Department of Computer Science 1336 University of Auckland 1337 PB 92019 1338 Auckland, 1142 1339 New Zealand 1341 Email: brian.e.carpenter@gmail.com 1343 Bernard Aboba 1344 Microsoft Corporation 1345 One Microsoft Way 1346 Redmond, WA 98052 1348 EMail: bernard_aboba@hotmail.com 1350 Stuart Cheshire 1351 Apple Computer, Inc. 1352 1 Infinite Loop 1353 Cupertino, CA 95014 1355 EMail: cheshire@apple.com