idnits 2.17.1 draft-iab-extension-recs-02.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 (11 July 2010) is 5030 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-19) exists of draft-ietf-radext-design-16 -- 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 (~~), 3 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: January 11, 2011 Internet Architecture Board 6 11 July 2010 8 Design Considerations for Protocol Extensions 9 draft-iab-extension-recs-02 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 January 11, 2011. 41 Copyright Notice 43 Copyright (c) 2010 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. Architectural Principles . . . . . . . . . . . . . . . . . . . 5 73 2.1 Limited Extensibility . . . . . . . . . . . . . . . . . . 5 74 2.2 Design for Global Interoperability . . . . . . . . . . . . 6 75 2.3 Protocol Variations . . . . . . . . . . . . . . . . . . . 7 76 2.4 Extension Documentation . . . . . . . . . . . . . . . . . 8 77 2.5 Testability . . . . . . . . . . . . . . . . . . . . . . . 8 78 2.6 Parameter Registration . . . . . . . . . . . . . . . . . . 9 79 2.7 Extensions to Critical Infrastructure . . . . . . . . . . 12 80 2.8 Architectural Compatibility . . . . . . . . . . . . . . . 12 81 3. Specific Considerations for Robust Extensions . . . . . . . . 12 82 3.1. Interoperability Checklist . . . . . . . . . . . . . . . . 13 83 3.2. When is an Extension Routine? . . . . . . . . . . . . . . 13 84 3.3. What Constitutes a Major Extension? . . . . . . . . . . . 14 85 4. Considerations for the Base Protocol . . . . . . . . . . . . . 15 86 4.1. Version Numbers . . . . . . . . . . . . . . . . . . . . . 15 87 4.2. Reserved Fields . . . . . . . . . . . . . . . . . . . . . 17 88 4.3. Encoding Formats . . . . . . . . . . . . . . . . . . . . . 18 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 93 7.2. Informative References . . . . . . . . . . . . . . . . . . 19 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 95 IAB Members . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 Appendix A - Examples . . . . . . . . . . . . . . . . . . . . . . 23 97 A.1. Already documented cases . . . . . . . . . . . . . . . . . 23 98 A.2. RADIUS Extensions . . . . . . . . . . . . . . . . . . . . 23 99 A.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . . 24 100 A.4. L2TP Extensions . . . . . . . . . . . . . . . . . . . . . 26 101 Change log . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 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 300 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 describes architectural principles for protocol 136 extensibility. Section 3 gives specific guidance for authors of 137 protocol extensions, and Section 4 explains how designers of base 138 protocols can take steps to anticipate and facilitate the creation of 139 such subsequent extensions in a safe and reliable manner. Readers 140 are advised to study the whole document, since the considerations are 141 closely linked. 143 1.1. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in BCP 14, RFC 2119 148 [RFC2119]. 150 2. Architectural Principles 152 This section describes basic principles of protocol extensibility: 154 1. Extensibility features should be limited to what is reasonably 155 anticipated when the protocol is developed. 157 2. Protocol extensions should be designed for global 158 interoperability. 160 3. Protocol extension mechanisms should not be used to create 161 incompatible protocol variations. 163 4. Extension mechanisms need to be fully documented. 165 5. Extension mechanisms need to be testable. 167 6. Protocol parameters should be registered and used for their 168 intended purpose. 170 7. Extensions to critical infrastructure should not impact the 171 security or reliability of the global Internet. 173 8. Extension mechanisms should be explicitly identified and should be 174 architecturally compatible with the base protocol design. 176 2.1. Limited Extensibility 178 Designing a protocol to permit easy extensions may have the perverse 179 side effect of making it easy to construct incompatible extensions. 180 Consequently, protocols should not be made more extensible than 181 clearly necessary at inception, and the process for defining new 182 extensibility mechanisms should ensure that adequate review of 183 proposed extensions will take place before widespread adoption. In 184 practice, this means that processes that allow routine extensions 185 should be used sparingly (such as the "First Come First Served" 186 allocation policy described in "Guidelines for Writing an IANA 187 Considerations Section in RFCs" [RFC5226]), as they imply minimal or 188 no review. In particular, they should be limited to cases that are 189 unlikely to cause protocol failures, such as allowing new opaque data 190 elements. 192 In order to increase the likelihood that routine extensions are truly 193 routine, protocol documents should provide guidelines explaining how 194 extensions should be performed. For example, even though DHCP 195 carries opaque data, defining a new option using completely 196 unstructured data may lead to an option that is unnecessarily hard 197 for clients and servers to process. 199 2.2. Design for Global Interoperability 201 The IETF mission [RFC3935] is to create interoperable protocols for 202 the global Internet, not a collection of different incompatible 203 protocols (or "profiles") for use in separate private networks. 204 Experience shows that separate private networks often end up using 205 equipment from the same vendors, or end up having portable equipment 206 like laptop computers move between them, and networks that were 207 originally envisaged as being separate can end up being connected 208 later. 210 As a result, extensions cannot be designed for an isolated 211 environment; instead, extension designers must assume that systems 212 using the extension will need to interoperate with systems on the 213 global Internet. 215 A key requirement for interoperable extension design is that the base 216 protocol must be well designed for interoperability, and that 217 extensions must have unambiguous semantics. Ideally, the protocol 218 mechanisms for extension and versioning should be sufficiently well 219 described that compatibility can be assessed on paper. Otherwise, 220 when two "private" extensions encounter each other on a public 221 network, unexpected interoperability problems may occur. 223 Consider a "private" extension installed on a work computer which, 224 being portable, is sometimes connected to a home network or a hotel 225 network. If the "private" extension is incompatible with an 226 unextended version of the same protocol, problems will occur. 228 Similarly, problems can occur if "private" extensions conflict with 229 each other. For example, imagine the situation where one site chose 230 to use DHCP [RFC2132] option code 62 for one meaning, and a different 231 site chose to use DHCP option code 62 for a completely different, 232 incompatible, meaning. It may be impossible for a vendor of portable 233 computing devices to make a device that works correctly in both 234 environments. 236 One approach to solving this problem has been to reserve parts of an 237 identifier namespace for "site-specific" or "experimental" use, such 238 as "X-" headers in email messages [RFC0822]. This problem with this 239 approach is that when an experiment turns out to be successful, or a 240 site-specific use turns out to have applicability elsewhere, other 241 vendors will then implement that "X-" header for interoperability, 242 and the "X-" header becomes a de facto standard, meaning that it is 243 no longer true that any header beginning "X-" is site-specific or 244 experimental. The notion of "X-" headers was removed from the 245 Internet Message Format standard when it was was updated in 2001 246 [RFC2822]. 248 2.3. Protocol Variations 250 Protocol variations - specifications that look very similar to the 251 original but don't interoperate with each other or with the original 252 - are even more harmful to interoperability than extensions. In 253 general, such variations should be avoided. Causes of protocol 254 variations include incompatible protocol extensions, uncoordinated 255 protocol development, and poorly designed "profiles". 257 Protocol extension mechanisms should not be used to create 258 incompatible forks in development. An extension may lead to 259 interoperability failures unless the extended protocol correctly 260 supports all mandatory and optional features of the unextended base 261 protocol, and implementations of the base protocol operate correctly 262 in the presence of the extensions. In addition, it is necessary for 263 an extension to interoperate with other extensions. 265 As noted in "Uncoordinated Protocol Development Considered Harmful" 266 [RFC5704], incompatible forks in development can result from the 267 uncoordinated adaptation of a protocol, parameter or code-point. 268 Section 1 of [RFC5704] states: 270 In particular, the IAB considers it an essential principle of the 271 protocol development process that only one SDO maintains design 272 authority for a given protocol, with that SDO having ultimate 273 authority over the allocation of protocol parameter code-points 274 and over defining the intended semantics, interpretation, and 275 actions associated with those code-points. 277 Profiling is a common technique for improving interoperability within 278 a target environment or set of scenarios. Typically, profiles are 279 constructed by narrowing potential implementation choices or by 280 removing protocol features. However, in order to avoid creating 281 interoperability problems when profiled implementations interact with 282 others over the Global Internet, profilers need to remain cognizant 283 of the implications of normative requirements. 285 As noted in "Key words for use in RFCs to Indicate Requirement 286 Levels" [RFC2119] Section 6, imperatives are to be used with care, 287 and as a result, their removal within a profile is likely to result 288 in serious consequences: 290 Imperatives of the type defined in this memo must be used with 291 care and sparingly. In particular, they MUST only be used where 292 it is actually required for interoperation or to limit behavior 293 which has potential for causing harm (e.g., limiting 294 retransmissions) For example, they must not be used to try to 295 impose a particular method on implementors where the method is not 296 required for interoperability. 298 As noted in [RFC2119] Sections 3 and 4, recommendations also cannot 299 be removed from profiles without serious consideration: 301 there may exist valid reasons in particular circumstances to 302 ignore a particular item, but the full implications must be 303 understood and carefully weighed before choosing a different 304 course. 306 As noted in [RFC2119] Section 5, implementations which do not support 307 optional features still retain the obligation to ensure 308 interoperation with implementations that do: 310 An implementation which does not include a particular option MUST 311 be prepared to interoperate with another implementation which does 312 include the option, though perhaps with reduced functionality. In 313 the same vein an implementation which does include a particular 314 option MUST be prepared to interoperate with another 315 implementation which does not include the option (except, of 316 course, for the feature the option provides.) 318 2.4. Extension Documentation 320 Some protocol components are designed with the specific intention of 321 allowing extensibility. These should be clearly identified, with 322 specific and complete instructions on how to extend them, including 323 the process for adequate review of extension proposals: do they need 324 community review and if so how much and by whom? For example, the 325 definition of additional data elements that can be carried opaquely 326 may require no review, while the addition of new data types or new 327 protocol messages might require a Standards Track action. For 328 additional information, see "Guidelines for Writing an IANA 329 Considerations Section in RFCs" [RFC5226]. 331 In a number of cases, there is a need for explicit guidance relating 332 to extensions beyond what is encapsulated in the IANA considerations 333 section of the base specification. Protocols whose data model is 334 likely to be widely extended (particularly using vendor-specific 335 elements) should have a Design Guidelines document specifically 336 addressing extensions. For example, "Guidelines for Authors and 337 Reviewers of MIB Documents" [RFC4181] provides valuable guidance to 338 protocol designers creating new MIB modules. 340 2.5. Testability 342 Experience has shown that it is insufficient merely to correctly 343 specify extensibility and backwards compatibility in an RFC. It is 344 also important that implementations respect the compatibility 345 mechanisms; if not, non-interoperable pairs of implementations may 346 arise. The TLS case study (Appendix A.3) shows how important this 347 can be. 349 In order to determine whether protocol extension mechanisms have been 350 properly implemented, testing is required. However, for this to be 351 possible, test cases need to be developed. If a base protocol 352 document specifies extension mechanisms but does not utilize them or 353 provide examples, it may not be possible to develop effective test 354 cases based on the base protocol specification alone. As a result, 355 base protocol implementations may not be properly tested and non- 356 compliant extension behavior may not be detected until these 357 implementations are widely deployed. 359 To encourage correct implementation of extension mechanisms, base 360 protocol specifications should clearly articulate the expected 361 behavior of extension mechanisms and should include examples of 362 correct and incorrect extension behavior. 364 2.6. Parameter Registration 366 An extension is often likely to make use of additional values added 367 to an existing IANA registry (in many cases, simply by adding a new 368 Type-Length-Value (TLV) field). To avoid conflicting usage of the 369 same value, it is essential that all new values are properly 370 registered by the applicable procedures. For general rules see 371 "Guidelines for Writing an IANA Considerations Section in RFCs" 372 [RFC5226], and for specific rules and registries see the individual 373 protocol specification RFCs and the IANA web site. If this is not 374 done, there is nothing to prevent two different extensions picking 375 the same value. When these two extensions "meet" each other on the 376 Internet, failure is inevitable. 378 A surprisingly common case of this is misappropriation of assigned 379 Transmission Control Protocol (TCP) (or User Datagram Protocol (UDP)) 380 registered port numbers. This can lead to a client for one service 381 attempting to communicate with a server for another service. 382 Numerous cases could be cited, but not without embarrassing specific 383 implementors. 385 In some cases, it may be appropriate to use values designated as 386 "experimental" or "local use" in early implementations of an 387 extension. For example, "Experimental Values in IPv4, IPv6, ICMPv4, 388 ICMPv6, UDP and TCP Headers" [RFC4727] discusses experimental values 389 for IP and transport headers, and "Definition of the Differentiated 390 Services Field (DS Field) in the IPv4 and IPv6 Headers" [RFC2474] 391 defines experimental/local use ranges for differentiated services 392 code points. Such values should be used with care and only for their 393 stated purpose: experiments and local use. They are unsuitable for 394 Internet-wide use, since they may be used for conflicting purposes 395 and thereby cause interoperability failures. Packets containing 396 experimental or local use values must not be allowed out of the 397 domain in which they are meaningful. 399 2.6.1. Parameter Exhaustion 401 In some protocols the parameter space is either infinite (e.g. Header 402 field names) or sufficiently large that it is unlikely to be 403 exhausted. In these protocols, the primary role of parameter 404 registration is to ensure uniqueness in order to prevent conflicts 405 between uses. 407 However, in other protocols the parameter space has proven inadequate 408 to accommodate demand. Some common mistakes include: 410 a. A version field that is too small (e.g. two bits or less). When 411 designing a version field, existing as well as potential versions of 412 a protocol need to be taken into account. For example, if a protocol 413 is being standardized for which there are existing implementations 414 with known interoperability issues, more than one version for "pre- 415 standard" implementations may be required. If two "pre-standard" 416 versions are required in addition to a version for an IETF standard, 417 then a two-bit version field would only leave one additional version 418 code-point for a future update, which could be insufficient. This 419 problem was encountered during the development of the PEAPv2 protocol 420 [PEAP]. 422 b. Creating a small parameter space (e.g. 8-bits or less) along with 423 a First Come, First Served (FCFS) allocation policy. In general, an 424 FCFS allocation policy is only appropriate in situations where 425 parameter exhaustion is highly unlikely. In situations where 426 substantial demand is anticipated within a parameter space, the space 427 should either be designed to be sufficient to handle that demand, or 428 vendor extensibility should be provided to enable vendors to self- 429 allocate. The combination of a small parameter space, an FCFS 430 allocation policy, and no support for vendor extensibility is 431 particularly likely to prove ill-advised. An example of such a 432 combination was the design of the original 8-bit EAP Method Type 433 space [RFC2284]. 435 Once the potential for parameter exhaustion becomes apparent, it is 436 important that it be addressed as quickly as possible. Protocol 437 changes can take years to appear in implementations and by then the 438 exhaustion problem could become acute. Options for addressing a 439 protocol parameter exhaustion problem include: 441 Rethinking the allocation regime 442 Where it becomes apparent that the size of a parameter space is 443 insufficient to meet demand, it may be necessary to rethink the 444 allocation mechanism, in order to prevent rapid parameter space 445 exhaustion. For example, a few years after approval of RFC 2284 446 [RFC2284], it became clear that the combination of a FCFS 447 allocation policy and lack of support for vendor-extensions had 448 created the potential for exhaustion of the EAP Method Type space 449 within a few years. To address the issue, [RFC3748] Section 6.2 450 changed the allocation policy for EAP Method Types from FCFS to 451 Expert Review, with Specification Required. 453 Support for vendor-specific parameters 454 If the demand that cannot be accommodated is being generated by 455 vendors, merely making allocation harder could make things worse if 456 this encourages vendors to self-allocate, creating interoperability 457 problems. In such a situation, support for vendor-specific 458 parameters should be considered, allowing each vendor to self- 459 allocate within their own vendor-specific space based on a vendor's 460 Private Enterprise Code (PEC). For example, in the case of the EAP 461 Method Type space, [RFC3748] Section 6.2 also provided for an 462 Expanded Type space for "functions specific only to one vendor's 463 implementation". 465 Extensions to the parameter space 466 If the goal is to stave off exhaustion in the face of high demand, 467 a larger parameter space may be helpful. Where vendor-specific 468 parameter support is available, this may be achieved by allocating 469 an PEC for IETF use. Otherwise it may be necessary to try to extend 470 the size of the parameter fields, which could require a new 471 protocol version or other substantial protocol changes. 473 Parameter reclamation 474 In order to gain time, it may be necessary to reclaim unused 475 parameters. However, it may not be easy to determine whether a 476 parameter that has been allocated is in use or not, particularly if 477 the entity that obtained the allocation no longer exists or has 478 been acquired (possibly multiple times). 480 Enabling Parameter Transfers 481 When all the above mechanisms have proved infeasible and parameter 482 exhaustion looms in the near future, enabling the transfer of 483 ownership of protocol parameters can be considered as a mechanism 484 for improving allocation efficiency. However, enabling transfer of 485 parameter ownership can be far from simple if the parameter 486 allocation process was not originally designed to enable ownership 487 transfers. 489 A parameter allocation process designed to uniquely allocate code- 490 points is fundamentally different from one designed to enable 491 transfer of parameter ownership. If the only goal is to ensure 492 that a parameter is not allocated more than once, parameter 493 ownership is irrelevant, and there is no reason to create a process 494 to enable ownership determination or title transfer. If the goal 495 is to enable transfer of ownership of a protocol parameter, then a 496 pre-requisite for a secure transfer is to be able determine who the 497 rightful owner is. 499 2.7. Extensions to Critical Infrastructure 501 Some protocols (such as Domain Name Service (DNS) and Border Gateway 502 Protocol (BGP)) have become critical components of the Internet 503 infrastructure. When such protocols are extended, the potential 504 exists for negatively impacting the reliability and security of the 505 global Internet. 507 As a result, special care needs to be taken with these extensions, 508 such as taking explicit steps to isolate existing uses from new ones. 509 For example, this can be accomplished by requiring the extension to 510 utilize a different port or multicast address, or by implementing the 511 extension within a separate process, without access to the data and 512 control structures of the base protocol. 514 2.8. Architectural Compatibility 516 Since protocol extension mechanisms may impact interoperability, it 517 is important that these mechanisms be architecturally compatible with 518 the base protocol. This implies that documents relying on extension 519 mechanisms need to explicitly identify them, rather than burying them 520 in the text in the hope that they will escape notice. 522 As part of the definition of new extension mechanisms, the authors 523 need to address whether the mechanisms make use of features as 524 envisaged by the original protocol designers, or whether a new 525 extension mechanism is being invented. If a new extension mechanism 526 is being invented, then architectural compatibility issues need to be 527 addressed. 529 For example, a document defining new data elements should not 530 implicitly define new data types or protocol operations without 531 explicitly describing those dependencies and discussing their impact. 533 3. Specific Considerations for Robust Extensions 535 This section makes explicit some design considerations based on the 536 community's experience with extensibility mechanisms. 538 3.1. Interoperability Checklist 540 Good interoperability stems from a number of factors, including: 542 1. Having a well-written specification. Does the specification 543 make clear what an implementor needs to support and does it define 544 the impact that individual operations (e.g. a message sent to a 545 peer) will have when invoked? 547 2. Learning lessons from deployment. This includes understanding 548 what current implementations do and how a proposed extension will 549 interact with deployed systems. Will a proposed extension (or its 550 proposed usage) operationally stress existing implementations or 551 the underlying protocol itself if widely deployed? 553 3. Having an adequate transition or coexistence story. What 554 impact will the proposed extension have on implementations that do 555 not understand it? Is there a way to negotiate or determine the 556 capabilities of a peer? Can the extended protocol negotiate with 557 an unextended partner to find a common subset of useful functions? 559 4. Respecting underlying architectural or security assumptions. 560 This includes assumptions that may not be well-documented, those 561 that may have arisen as the result of operational experience, or 562 those that only became understood after the original protocol was 563 published. For example, do the extensions reverse the flow of 564 data, allow formerly static parameters to be changed on the fly, 565 or change assumptions relating to the frequency of reads/writes? 567 5. Minimizing impact on critical infrastructure. Does the 568 proposed extension (or its proposed usage) have the potential for 569 negatively impacting critical infrastructure to the point where 570 explicit steps would be appropriate to isolate existing uses from 571 new ones? 573 6. Data model extensions. Does the proposed extension extend the 574 data model in a major way? For example, are new data types 575 defined that may require code changes within existing 576 implementations? 578 3.2. When is an Extension Routine? 580 An extension may be considered 'routine' if it amounts to a new data 581 element of a type that is already supported within the data model, 582 and if its handling is opaque to the protocol itself (e.g. does not 583 substantially change the pattern of messages and responses). 585 For this to apply, the protocol must have been designed to carry the 586 proposed data type, so that no changes to the underlying base 587 protocol or existing implementations are needed to carry the new data 588 element. 590 Moreover, no changes should be required to existing and currently 591 deployed implementations of the underlying protocol unless they want 592 to make use of the new data element. Using the existing protocol to 593 carry a new data element should not impact existing implementations 594 or cause operational problems. This typically requires that the 595 protocol silently discard unknown data elements. 597 Examples of routine extensions include the Dynamic Host Configuration 598 Protocol (DHCP) vendor-specific option [RFC2132], RADIUS Vendor- 599 Specific Attributes [RFC2865], the enterprise Object IDentifier (OID) 600 tree for Management Information Base (MIB) modules, vendor 601 Multipurpose Internet Mail Extension (MIME) types, and some classes 602 of (non-critical) certification extensions. Such extensions can 603 safely be made with minimal discussion. 605 3.3. What Constitutes a Major Extension? 607 Major extensions may have characteristics leading to a risk of 608 interoperability failure. Where these characteristics are present, 609 it is necessary to pay extremely close attention to backward 610 compatibility with implementations and deployments of the unextended 611 protocol, and to the risk of inadvertent introduction of security or 612 operational exposures. Extension designers should examine their 613 design for the following issues: 615 1. Modifications or extensions to the working of the underlying 616 protocol. This can include changing the semantics of existing 617 Protocol Data Units (PDUs) or defining new message types that may 618 require implementation changes in existing and deployed 619 implementations of the protocol, even if they do not want to make 620 use of the new functions or data types. A base protocol without a 621 "silent discard" rule for unknown data elements may automatically 622 enter this category, even for apparently minor extensions. 624 2. Changes to the basic architectural assumptions. This includes 625 architectural assumptions that are explicitly stated or those that 626 have been assumed by implementers. For example, this would 627 include adding a requirement for session state to a previously 628 stateless protocol. 630 3. New usage scenarios not originally intended or investigated. 631 This can potentially lead to operational difficulties when 632 deployed, even in cases where the "on-the-wire" format has not 633 changed. For example, the level of traffic carried by the 634 protocol may increase substantially, packet sizes may increase, 635 and implementation algorithms that are widely deployed may not 636 scale sufficiently or otherwise be up to the new task at hand. 637 For example, a new DNS Resource Record (RR) type that is too big 638 to fit into a single UDP packet could cause interoperability 639 problems with existing DNS clients and servers. 641 4. Considerations for the Base Protocol 643 A good extension design depends on a good base protocol. Ideally, 644 the document that defines a base protocol's extension mechanisms will 645 include guidance to future extension writers that help them use 646 extension mechanisms properly. It may also be possible to define 647 classes of extensions that need little or no review, while other 648 classes need wide review. The details will necessarily be 649 technology-specific. 651 4.1. Version Numbers 653 Any mechanism for extension by versioning must include provisions to 654 ensure interoperability, or at least clean failure modes. Imagine 655 someone creating a protocol and using a "version" field and 656 populating it with a value (1, let's say), but giving no information 657 about what would happen when a new version number appears in it. 658 That's bad protocol design and description; it should be clear what 659 the expectation is and how you test it. For example, stating that 660 1.X must be compatible with any version 1 code, but version 2 or 661 greater is not expected to be compatible, has different implications 662 than stating that version 1 must be a proper subset of version 2. 664 An example is ROHC (Robust Header Compression). ROHCv1 [RFC3095] 665 supports a certain set of profiles for compression algorithms. But 666 experience had shown that these profiles had limitations, so the ROHC 667 WG developed ROHCv2 [RFC5225]. A ROHCv1 implementation does not 668 contain code for the ROHCv2 profiles. As the ROHC WG charter said 669 during the development of ROHCv2: 671 It should be noted that the v2 profiles will thus not be 672 compatible with the original (ROHCv1) profiles, which means less 673 complex ROHC implementations can be realized by not providing 674 support for ROHCv1 (over links not yet supporting ROHC, or by 675 shifting out support for ROHCv1 in the long run). Profile support 676 is agreed through the ROHC channel negotiation, which is part of 677 the ROHC framework and thus not changed by ROHCv2. 679 Thus in this case both backwards-compatible and backwards- 680 incompatible deployments are possible. The important point is a 681 clearly thought out approach to the question of operational 682 compatibility. In the past, protocols have utilized a variety of 683 strategies for versioning, many of which have proven problematic. 684 These include: 686 1. No versioning support. This approach is exemplified by 687 Extensible Authentication Protocol (EAP) [RFC3748] as well as 688 Remote Authentication Dial In User Service (RADIUS) [RFC2865], 689 both of which provide no support for versioning. While lack of 690 versioning support protects against the proliferation of 691 incompatible dialects, the need for extensibility is likely to 692 assert itself in other ways, so that ignoring versioning entirely 693 may not be the most forward thinking approach. 695 2. Highest mutually supported version (HMSV). In this approach, 696 implementations exchange the version numbers of the highest 697 version each supports, with the negotiation agreeing on the 698 highest mutually supported protocol version. This approach 699 implicitly assumes that later versions provide improved 700 functionality, and that advertisement of a particular version 701 number implies support for all lower version numbers. Where these 702 assumptions are invalid, this approach breaks down, potentially 703 resulting in interoperability problems. An example of this issue 704 occurs in Protected EAP [PEAP] where implementations of higher 705 versions may not necessarily provide support for lower versions. 707 3. Assumed backward compatibility. In this approach, 708 implementations may send packets with higher version numbers to 709 legacy implementations supporting lower versions, but with the 710 assumption that the legacy implementations will interpret packets 711 with higher version numbers using the semantics and syntax defined 712 for lower versions. This is the approach taken by Port-Based 713 Access Control [IEEE-802.1X]. For this approach to work, legacy 714 implementations need to be able to accept packets of known type 715 with higher protocol versions without discarding them; protocol 716 enhancements need to permit silent discard of unsupported 717 extensions; implementations supporting higher versions need to 718 refrain from mandating new features when encountering legacy 719 implementations. 721 4. Major/minor versioning. In this approach, implementations with 722 the same major version but a different minor version are assumed 723 to be backward compatible, but implementations are assumed to be 724 required to negotiate a mutually supported major version number. 725 This approach assumes that implementations with a lower minor 726 version number but the same major version can safely ignore 727 unsupported protocol messages. 729 5. Min/max versioning. This approach is similar to HMSV, but 730 without the implied obligation for clients and servers to support 731 all versions back to version 1, in perpetuity. It allows clients 732 and servers to cleanly drop support for early versions when those 733 versions become so old that they are no longer relevant and no 734 longer required. In this approach, the client initiating the 735 connection reports the highest and lowest protocol versions it 736 understands. The server reports back the chosen protocol version: 738 a. If the server understands one or more versions in the client's 739 range, it reports back the highest mutually understood version. 741 b. If there is no mutual version, then the server reports back 742 some version that it does understand (selected as described 743 below). The connection is then typically dropped by client or 744 server, but reporting this version number first helps facilitate 745 useful error messages at the client end: 747 * If there is no mutual version, and the server speaks any 748 version higher than client max, it reports the lowest version it 749 speaks which is greater than the client max. The client can 750 then report to the user, "You need to upgrade to at least 751 version ." 753 * Else, the server reports the highest version it speaks. The 754 client can then report to the user, "You need to request the 755 server operator to upgrade to at least version ." 757 Protocols generally do not need any version-negotiation mechanism 758 more complicated than the mechanisms described here. The nature of 759 protocol version-negotiation mechanisms is that, by definition, they 760 don't get widespread real-world testing until *after* the base 761 protocol has been deployed for a while, and its deficiencies have 762 become evident. This means that, to be useful, a protocol version 763 negotiation mechanism should be simple enough that it can reasonably 764 be assumed that all the implementers of the first protocol version at 765 least managed to implement the version-negotiation mechanism 766 correctly. 768 4.2. Reserved Fields 770 Protocols commonly include one or more "reserved" fields, clearly 771 intended for future extensions. It is good practice to specify the 772 value to be inserted in such a field by the sender (typically zero) 773 and the action to be taken by the receiver when seeing some other 774 value (typically no action). In packet format diagrams, such fields 775 are typically labeled "MBZ", to be read as, "Must Be Zero on 776 transmission, Must Be Ignored on reception." A common mistake of 777 inexperienced protocol implementers is to think that "MBZ" means that 778 it's their software's job to verify that the value of the field is 779 zero on reception, and reject the packet if not. This is a mistake, 780 and such software will fail when it encounters future versions of the 781 protocol where these previously reserved fields are given new defined 782 meanings. Similarly, protocols should carefully specify how 783 receivers should react to unknown TLVs etc., such that failures occur 784 only when that is truly the intended outcome. 786 4.3. Encoding Formats 788 Using widely-supported encoding formats leads to better 789 interoperability and easier extensibility. An excellent example is 790 the Simple Network Management Protocol (SNMP) SMI. Guidelines exist 791 for defining the MIB objects that SNMP carries [RFC4181]. Also, 792 multiple textual conventions have been published, so that MIB 793 designers do not have to reinvent the wheel when they need a commonly 794 encountered construct. For example, the "Textual Conventions for 795 Internet Network Addresses" [RFC4001] can be used by any MIB designer 796 needing to define objects containing IP addresses, thus ensuring 797 consistency as the body of MIBs is extended. 799 5. Security Considerations 801 An extension must not introduce new security risks without also 802 providing adequate counter-measures, and in particular it must not 803 inadvertently defeat security measures in the unextended protocol. 804 Thus, the security analysis for an extension needs to be as thorough 805 as for the original protocol - effectively it needs to be a 806 regression analysis to check that the extension doesn't inadvertently 807 invalidate the original security model. 809 This analysis may be simple (e.g. adding an extra opaque data element 810 is unlikely to create a new risk) or quite complex (e.g. adding a 811 handshake to a previously stateless protocol may create a completely 812 new opportunity for an attacker). 814 6. IANA Considerations 816 [RFC Editor: please remove this section prior to publication.] 818 This document has no IANA Actions. 820 7. References 822 7.1. Normative References 824 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 825 Requirement Levels", BCP 14, RFC 2119, March 1997. 827 [RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures 828 for Protocol Extensions and Variations", BCP 125, RFC 829 4775, December 2006. 831 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 832 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 833 May 2008. 835 7.2. Informative References 837 [I-D.ietf-radext-design] 838 Weber, G. and A. DeKok, "RADIUS Design Guidelines", 839 draft-ietf-radext-design-16.txt, Internet draft (work in 840 progress), July 2010. 842 [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local 843 and Metropolitan Area Networks: Port-Based Network Access 844 Control", IEEE Standard 802.1X-2004, December 2004. 846 [PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G. 847 and S. Josefsson, "Protected EAP Protocol (PEAP) Version 848 2", draft-josefsson-pppext-eap-tls-eap-10.txt, Expired 849 Internet draft (work in progress), October 2004. 851 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 852 text messages", STD 11, RFC 822, August 1982. 854 [RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered 855 Harmful", RFC 1263, October 1991. 857 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP 858 Vendor Extensions", RFC 2132, March 1997. 860 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 861 RFC 2246, January 1999. 863 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 864 Authentication Protocol (EAP)", RFC 2284, March 1998. 866 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 867 "Definition of the Differentiated Services Field (DS 868 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 869 1998. 871 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 872 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 873 RFC 2661, August 1999. 875 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",RFC 876 2671, August 1999. 878 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 879 2001. 881 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 882 "Remote Authentication Dial In User Service (RADIUS)", 883 RFC 2865, June 2000. 885 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, 886 H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., 887 Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, 888 K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust 889 Header Compression (ROHC): Framework and four profiles: 890 RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. 892 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 893 and B. Rosen, "Change Process for the Session Initiation 894 Protocol (SIP)", BCP 67, RFC 3427, December 2002. 896 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 897 Authentication Dial In User Service)", RFC 3575, July 898 2003. 900 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 901 (RR) Types", RFC 3597, September 2003. 903 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 904 Provisioning Protocol (EPP)", RFC 3735, March 2004. 906 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 907 Lefkowetz, "Extensible Authentication Protocol (EAP)", 908 RFC 3748, June 2004. 910 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", RFC 911 3935, October 2004. 913 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 914 Schoenwaelder, "Textual Conventions for Internet Network 915 Addresses", RFC 4001, February 2005. 917 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 918 Documents", BCP 111, RFC 4181, September 2005. 920 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, 921 J., and T. Wright, "Transport Layer Security (TLS) 922 Extensions", RFC 4366, April 2006. 924 [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors 925 of Extensions to the Session Initiation Protocol (SIP)", 926 RFC 4485, May 2006. 928 [RFC4521] Zeilenga, K., "Considerations for Lightweight Directory 929 Access Protocol (LDAP) Extensions", BCP 118, RFC 4521, 930 June 2006. 932 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 933 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 935 [RFC4929] Andersson, L. and A. Farrel, "Change Process for 936 Multiprotocol Label Switching (MPLS) and Generalized MPLS 937 (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, 938 June 2007. 940 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 941 Dial In User Service (RADIUS) Implementation Issues and 942 Suggested Fixes", RFC 5080, December 2007. 944 [RFC5218] Thaler, D., and B. Aboba, "What Makes for a Successful 945 Protocol?", RFC 5218, July 2008. 947 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 948 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 949 UDP-Lite", RFC 5225, April 2008. 951 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 952 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 954 [RFC5704] Bryant, S. and M. Morrow, "Uncoordinated Protocol 955 Development Considered Harmful", RFC 5704, November 2009. 957 [RFC5727] Peterson, J., Jennings, C. and R. Sparks, "Change Process 958 for the Session Initiation Protocol (SIP) and the Real- 959 time Applications and Infrastructure Area", RFC 5727, 960 March 2010. 962 Acknowledgements 964 This document is heavily based on an earlier draft under a different 965 title by Scott Bradner and Thomas Narten. 967 That draft stated: The initial version of this document was put 968 together by the IESG in 2002. Since then, it has been reworked in 969 response to feedback from John Loughney, Henrik Levkowetz, Mark 970 Townsley, Randy Bush and others. 972 Valuable comments and suggestions on the current form of the document 973 were made by Jari Arkko, Ted Hardie, Loa Andersson, Eric Rescorla, 974 Pekka Savola, Leslie Daigle and Alfred Hoenes. 976 The text on TLS experience was contributed by Yngve Pettersen. 978 IAB Members at the Time of this Writing 980 Bernard Aboba 981 Marcelo Bagnulo 982 Ross Callon 983 Spencer Dawkins 984 Vijay Gill 985 Russ Housley 986 John Klensin 987 Olaf Kolkman 988 Danny McPherson 989 Jon Peterson 990 Andrei Robachevsky 991 Dave Thaler 992 Hannes Tschofenig 994 Appendix A. Examples 996 This section discusses some specific examples, as case studies. 998 A.1. Already documented cases 1000 There are certain documents that specify a change process or describe 1001 extension considerations for specific IETF protocols: 1003 The SIP change process [RFC3427], [RFC4485], [RFC5727] 1004 The (G)MPLS change process (mainly procedural) [RFC4929] 1005 LDAP extensions [RFC4521] 1006 EPP extensions [RFC3735] 1007 DNS extensions [RFC2671][RFC3597] 1009 It is relatively common for MIBs, which are all in effect extensions 1010 of the SMI data model, to be defined or extended outside the IETF. 1011 BCP 111 [RFC4181] offers detailed guidance for authors and reviewers. 1013 A.2. RADIUS Extensions 1015 The RADIUS [RFC2865] protocol was designed to be extensible via 1016 addition of Attributes to a Data Dictionary on the server, without 1017 requiring code changes. However, this extensibility model assumed 1018 that Attributes would conform to a limited set of data types and that 1019 vendor extensions would be limited to use by vendors, in situations 1020 in which interoperability was not required. Subsequent developments 1021 have stretched those assumptions. 1023 Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism 1024 for Vendor-Specific extensions (Attribute 26), and states that use of 1025 Vendor-Specific extensions: 1027 should be encouraged instead of allocation of global attribute 1028 types, for functions specific only to one vendor's implementation 1029 of RADIUS, where no interoperability is deemed useful. 1031 However, in practice usage of Vendor-Specific Attributes (VSAs) has 1032 been considerably broader than this. In particular, VSAs have been 1033 used by Standards Development Organizations (SDOs) to define their 1034 own extensions to the RADIUS protocol. 1036 This has caused a number of problems. Since the VSA mechanism was 1037 not designed for interoperability, VSAs do not contain a "mandatory" 1038 bit. As a result, RADIUS clients and servers may not know whether it 1039 is safe to ignore unknown attributes. For example, Section 5 of the 1040 RADIUS specification [RFC2865] states: 1042 A RADIUS server MAY ignore Attributes with an unknown Type. A 1043 RADIUS client MAY ignore Attributes with an unknown Type. 1045 However, in the case where the VSAs pertain to security (e.g. 1046 Filters) it may not be safe to ignore them, since the RADIUS 1047 specification [RFC2865] also states: 1049 A NAS that does not implement a given service MUST NOT implement 1050 the RADIUS attributes for that service. For example, a NAS that 1051 is unable to offer ARAP service MUST NOT implement the RADIUS 1052 attributes for ARAP. A NAS MUST treat a RADIUS access-accept 1053 authorizing an unavailable service as an access-reject instead." 1055 Detailed discussion of the issues arising from this can be found in 1056 "Common Remote Authentication Dial In User Service (RADIUS) 1057 Implementation Issues and Suggested Fixes" [RFC5080] Section 2.5. 1059 Since it was not envisaged that multi-vendor VSA implementations 1060 would need to interoperate, the RADIUS specification [RFC2865] does 1061 not define the data model for VSAs, and allows multiple sub- 1062 attributes to be included within a single Attribute of type 26. 1063 However, this enables VSAs to be defined which would not be 1064 supportable by current implementations if placed within the standard 1065 RADIUS attribute space. This has caused problems in standardizing 1066 widely deployed VSAs, as discussed in "RADIUS Design Guidelines" 1067 [I-D.ietf-radext-design]. 1069 In addition to extending RADIUS by use of VSAs, SDOs have also 1070 defined new values of the Service-Type attribute in order to create 1071 new RADIUS commands. Since the RADIUS specification [RFC2865] 1072 defined Service-Type values as being allocated First Come, First 1073 Served (FCFS), this essentially enabled new RADIUS commands to be 1074 allocated without IETF review. This oversight has since been fixed 1075 in "IANA Considerations for RADIUS" [RFC3575]. 1077 A.3. TLS Extensions 1079 The Secure Sockets Layer (SSL) v2 protocol was developed by Netscape 1080 to be used to secure online transactions on the Internet. It was 1081 later replaced by SSL v3, also developed by Netscape. SSL v3 was 1082 then further developed by the IETF as the Transport Layer Security 1083 (TLS) 1.0 [RFC2246]. 1085 The SSL v3 protocol was not explicitly specified to be extended. 1086 Even TLS 1.0 did not define an extension mechanism explicitly. 1087 However, extension "loopholes" were available. Extension mechanisms 1088 were finally defined in "Transport Layer Security (TLS) Extensions" 1089 [RFC4366]: 1091 o New versions 1092 o New cipher suites 1093 o Compression 1094 o Expanded handshake messages 1095 o New record types 1096 o New handshake messages 1098 The protocol also defines how implementations should handle unknown 1099 extensions. 1101 Of the above extension methods, new versions and expanded handshake 1102 messages have caused the most interoperability problems. 1103 Implementations are supposed to ignore unknown record types but to 1104 reject unknown handshake messages. 1106 The new version support in SSL/TLS includes a capability to define 1107 new versions of the protocol, while allowing newer implementations to 1108 communicate with older implementations. As part of this 1109 functionality some Key Exchange methods include functionality to 1110 prevent version rollback attacks. 1112 The experience with this upgrade functionality in SSL and TLS is 1113 decidedly mixed: 1115 o SSL v2 and SSL v3/TLS are not compatible. It is possible to use 1116 SSL v2 protocol messages to initiate a SSL v3/TLS connection, but 1117 it is not possible to communicate with a SSL v2 implementation 1118 using SSL v3/TLS protocol messages. 1119 o There are implementations that refuse to accept handshakes using 1120 newer versions of the protocol than they support. 1121 o There are other implementations that accept newer versions, but 1122 have implemented the version rollback protection clumsily. 1124 The SSL v2 problem has forced SSL v3 and TLS clients to continue to 1125 use SSL v2 Client Hellos for their initial handshake with almost all 1126 servers until 2006, much longer than would have been desirable, in 1127 order to interoperate with old servers. 1129 The problem with incorrect handling of newer versions has also forced 1130 many clients to actually disable the newer protocol versions, either 1131 by default, or by automatically disabling the functionality, to be 1132 able to connect to such servers. Effectively, this means that the 1133 version rollback protection in SSL and TLS is non-existent if talking 1134 to a fatally compromised older version. 1136 SSL v3 and TLS also permitted expansion of the Client Hello and 1137 Server Hello handshake messages. This functionality was fully 1138 defined by the introduction of TLS Extensions, which makes it 1139 possible to add new functionality to the handshake, such as the name 1140 of the server the client is connecting to, request certificate status 1141 information, indicate Certificate Authority support, maximum record 1142 length, etc. Several of these extensions also introduce new 1143 handshake messages. 1145 It has turned out that many SSL v3 and TLS implementations that do 1146 not support TLS Extensions, did not, as required by the protocol 1147 specifications, ignore the unknown extensions, but instead failed to 1148 establish connections. Several of the implementations behaving in 1149 this manner are used by high profile Internet sites, such as online 1150 banking sites, and this has caused a significant delay in the 1151 deployment of clients supporting TLS Extensions, and several of the 1152 clients that have enabled support are using heuristics that allow 1153 them to disable the functionality when they detect a problem. 1155 Looking forward, the protocol version problem, in particular, can 1156 cause future security problems for the TLS protocol. The strength of 1157 the digest algorithms (MD5 and SHA-1) used by SSL and TLS is 1158 weakening. If MD5 and SHA-1 weaken to the point where it is feasible 1159 to mount successful attacks against older SSL and TLS versions, the 1160 current error recovery used by clients would become a security 1161 vulnerability (among many other serious problems for the Internet). 1163 To address this issue, TLS 1.2 [RFC5246] makes use of a newer 1164 cryptographic hash algorithm (SHA-256) during the TLS handshake by 1165 default. Legacy ciphersuites can still be used to protect 1166 application data, but new ciphersuites are specified for data 1167 protection as well as for authentication within the TLS handshake. 1168 The hashing method can also be negotiated via a Hello extension. 1169 Implementations are encouraged to implement new ciphersuites, and to 1170 enable the negotiation of the ciphersuite used during a TLS session 1171 to be governed by policy, thus enabling a more rapid transition away 1172 from weakened ciphersuites. 1174 The lesson to be drawn from this experience is that it isn't 1175 sufficient to design extensibility carefully; it must also be 1176 implemented carefully by every implementer, without exception. Test 1177 suites and certification programs can help provide incentives for 1178 implementers to pay attention to implementing extensibility 1179 mechanisms correctly. 1181 A.4. L2TP Extensions 1183 Layer Two Tunneling Protocol (L2TP) [RFC2661] carries Attribute-Value 1184 Pairs (AVPs), with most AVPs having no semantics to the L2TP protocol 1185 itself. However, it should be noted that L2TP message types are 1186 identified by a Message Type AVP (Attribute Type 0) with specific AVP 1187 values indicating the actual message type. Thus, extensions relating 1188 to Message Type AVPs would likely be considered major extensions. 1190 L2TP also provides for Vendor-Specific AVPs. Because everything in 1191 L2TP is encoded using AVPs, it would be easy to define vendor- 1192 specific AVPs that would be considered major extensions. 1194 L2TP also provides for a "mandatory" bit in AVPs. Recipients of L2TP 1195 messages containing AVPs they do not understand but that have the 1196 mandatory bit set, are expected to reject the message and terminate 1197 the tunnel or session the message refers to. This leads to 1198 interesting interoperability issues, because a sender can include a 1199 vendor-specific AVP with the M-bit set, which then causes the 1200 recipient to not interoperate with the sender. This sort of behavior 1201 is counter to the IETF ideals, as implementations of the IETF 1202 standard should interoperate successfully with other implementations 1203 and not require the implementation of non-IETF extensions in order to 1204 interoperate successfully. Section 4.2 of the L2TP specification 1205 [RFC2661] includes specific wording on this point, though there was 1206 significant debate at the time as to whether such language was by 1207 itself sufficient. 1209 Fortunately, it does not appear that the potential problems described 1210 above have yet become a problem in practice. At the time of this 1211 writing, the authors are not aware of the existence of any vendor- 1212 specific AVPs that also set the M-bit. 1214 Change log [RFC Editor: please remove this section] 1216 draft-iab-extension-recs-02: 2010-7-12. Updates by Bernard Aboba 1218 draft-iab-extension-recs-01: 2010-4-7. Updates by Stuart 1219 Cheshire. 1221 draft-iab-extension-recs-00: 2009-4-24. Updated boilerplate, 1222 author list. 1224 draft-carpenter-extension-recs-04: 2008-10-24. Updated author 1225 addresses, fixed editorial issues. 1227 draft-carpenter-extension-recs-03: 2008-10-17. Updated references, 1228 added material relating to versioning. 1230 draft-carpenter-extension-recs-02: 2007-06-15. Reorganized Sections 1231 2 and 3. 1233 draft-carpenter-extension-recs-01: 2007-03-04. Updated according to 1234 comments, especially the wording about TLS, added various specific 1235 examples. 1237 draft-carpenter-extension-recs-00: original version, 2006-10-12. 1238 Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by 1239 focusing on architectural issues; the more procedural issues in that 1240 draft were moved to RFC 4775. 1242 Authors' Addresses 1244 Brian Carpenter 1245 Department of Computer Science 1246 University of Auckland 1247 PB 92019 1248 Auckland, 1142 1249 New Zealand 1251 Email: brian.e.carpenter@gmail.com 1253 Bernard Aboba 1254 Microsoft Corporation 1255 One Microsoft Way 1256 Redmond, WA 98052 1258 EMail: bernarda@microsoft.com 1259 Phone: +1 425 706 6605 1260 Fax: +1 425 936 7329 1262 Stuart Cheshire 1263 Apple Computer, Inc. 1264 1 Infinite Loop 1265 Cupertino, CA 95014 1267 EMail: cheshire@apple.com