idnits 2.17.1 draft-iab-extension-recs-01.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 (12 April 2010) is 5120 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-radext-design' is defined on line 677, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-19) exists of draft-ietf-radext-design-12 -- 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 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3427 (Obsoleted by RFC 5727) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 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 4 Intended Status: Informational S. Cheshire (ed) 5 Expires: October 12, 2010 Internet Architecture Board 6 12 April 2010 8 Design Considerations for Protocol Extensions 9 draft-iab-extension-recs-01 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 October 12, 2010. 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 . . . . . . . . . . . . . . . . . . . 4 73 2.1 Limited Extensibility . . . . . . . . . . . . . . . . . . 5 74 2.2 Global Interoperability . . . . . . . . . . . . . . . . . 6 75 2.3 Protocol Variations . . . . . . . . . . . . . . . . . . . 6 76 2.4 Extension Documentation . . . . . . . . . . . . . . . . . 7 77 2.5 Testability . . . . . . . . . . . . . . . . . . . . . . . 7 78 2.6 Parameter Registration . . . . . . . . . . . . . . . . . . 8 79 2.7 Extensions to Critical Infrastructure . . . . . . . . . . 8 80 2.8 Architectural Compatibility . . . . . . . . . . . . . . . 9 81 3. Specific Considerations for Robust Extensions . . . . . . . . 9 82 3.1. Interoperability Checklist . . . . . . . . . . . . . . . . 9 83 3.2. When is an Extension Routine? . . . . . . . . . . . . . . 10 84 3.3. What Constitutes a Major Extension? . . . . . . . . . . . 11 85 4. Considerations for the Base Protocol . . . . . . . . . . . . . 11 86 4.1. Version Numbers . . . . . . . . . . . . . . . . . . . . . 12 87 4.2. Reserved Fields . . . . . . . . . . . . . . . . . . . . . 14 88 4.3. Encoding Formats . . . . . . . . . . . . . . . . . . . . . 14 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 93 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 IAB Members . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 Appendix A - Examples . . . . . . . . . . . . . . . . . . . . . . 19 97 A.1. Already documented cases . . . . . . . . . . . . . . . . . 19 98 A.2. RADIUS Extensions . . . . . . . . . . . . . . . . . . . . 19 99 A.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . . 20 100 A.4. L2TP Extensions . . . . . . . . . . . . . . . . . . . . . 22 101 Change log . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 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 [RFC5218]. Well-designed 110 extensibility mechanisms facilitate the evolution of protocols and 111 help make it easier to roll out incremental changes in an 112 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 relible manner. Readers are 140 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 Protocols that permit easy extensions may have the perverse side 179 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 the "First Come First Served" allocation 185 policy described in "Guidelines for Writing an IANA Considerations 186 Section in RFCs" [RFC5226], as well as similar policies that allow 187 routine extensions should be used sparingly, as they imply minimal or 188 no review. In particular, they should be limited to cases, such as 189 allowing new opaque data elements, that are unlikely to cause 190 protocol failures. 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. Global Interoperability 201 Global interoperability is a primary goal of Internet protocol 202 design. Experience shows that software is often used outside the 203 particular special environment it was originally intended for, so 204 extensions cannot be designed for an isolated environment. Designers 205 of extensions must assume the high likelihood of a system using the 206 extension having to interoperate with systems on the global Internet. 208 For this reason, an extension may lead to interoperability failures 209 unless the extended protocol correctly supports all mandatory and 210 optional features of the unextended base protocol, and 211 implementations of the base protocol operate correctly in the 212 presence of the extensions. 214 Consider for example a "private" extension installed on a work 215 computer which, being portable, is sometimes connected to a home 216 network or a hotel network. If the "private" extension is 217 incompatible with an unextended version of the same protocol, 218 problems will occur. 220 2.3. Protocol Variations 222 Protocol extension mechanisms should not be used to create 223 incompatible forks in development. Ideally, the protocol mechanisms 224 for extension and versioning should be sufficiently well described 225 that compatibility can be assessed on paper. Otherwise, when two 226 "private" extensions encounter each other on a public network, 227 unexpected interoperability problems may occur. 229 An example of what might go wrong is misuse of the "X-" mail header 230 fields originally defined in the Simple Mail Transfer Protocol (SMTP) 231 [RFC0822]. X-anything was a valid mail header field; but it had no 232 defined meaning in the standard. Suppose a mail implementation 233 assigns specific semantics to X-anything that causes it to take 234 specific action, such as discarding a message as spam. If it 235 encounters a message from a different implementation that assigns 236 different semantics, it may take quite inappropriate action, such as 237 discarding a valid message. Thus, relying on the implied semantics 238 of an "X-" header field automatically creates a risk of operational 239 failures. "X-" header fields were removed from "Internet Message 240 Format" [RFC2822]. Even when they are assigned semantics, as in 241 "Mapping Between the Multimedia Message Service (MMS) and Internet 242 Mail" [RFC4356], great care must be taken that implementations do not 243 rely on such semantics in messages that have crossed the open 244 Internet. 246 Thus we observe that a key requirement for interoperable extension 247 design is that the base protocol must be well designed for 248 interoperability, and that extensions must have unambiguous 249 semantics. 251 Protocol variations - specifications that look very similar to the 252 original but don't interoperate with each other or with the original 253 - are even more harmful to interoperability than extensions. In 254 general, such variations should be avoided. If they cannot be 255 avoided, as many of the following considerations as possible should 256 be applied, to minimize the damage to interoperability. 258 2.4. Extension Documentation 260 Some protocol components are designed with the specific intention of 261 allowing extensibility. These should be clearly identified, with 262 specific and complete instructions on how to extend them, including 263 the process for adequate review of extension proposals: do they need 264 community review and if so how much and by whom? For example, the 265 definition of additional data elements that can be carried opaquely 266 may require no review, while the addition of new data types or new 267 protocol messages might require a Standards Track action. For 268 additional information, see "Guidelines for Writing an IANA 269 Considerations Section in RFCs" [RFC5226]. 271 In a number of cases, there is a need for explicit guidance relating 272 to extensions beyond what is encapsulated in the IANA considerations 273 section of the base specification. Protocols whose data model is 274 likely to be widely extended (particularly using vendor-specific 275 elements) should have a Design Guidelines document specifically 276 addressing extensions. For example, "Guidelines for Authors and 277 Reviewers of MIB Documents" [RFC4181] provides valuable guidance to 278 protocol designers creating new MIB modules. 280 2.5. Testability 282 Experience has shown that it is insufficient merely to correctly 283 specify extensibility and backwards compatibility in an RFC. It is 284 also important that implementations respect the compatibility 285 mechanisms; if not, non-interoperable pairs of implementations may 286 arise. The TLS case study (Appendix A.3) shows how important this 287 can be. 289 In order to determine whether protocol extension mechanisms have been 290 properly implemented, testing is required. However, for this to be 291 possible, test cases need to be developed. If a base protocol 292 document specifies extension mechanisms but does not utilize them or 293 provide examples, it may not be possible to develop effective test 294 cases based on the base protocol specification alone. As a result, 295 base protocol implementations may not be properly tested and non- 296 compliant extension behavior may not be detected until these 297 implementations are widely deployed. 299 To encourage correct implementation of extension mechanisms, base 300 protocol specifications should clearly articulate the expected 301 behavior of extension mechanisms and should include examples of 302 correct and incorrect extension behavior. 304 2.6. Parameter Registration 306 An extension is often likely to make use of additional values added 307 to an existing IANA registry (in many cases, simply by adding a new 308 Type-Length-Value (TLV) field). To avoid conflicting usage of the 309 same value, it is essential that all new values are properly 310 registered by the applicable procedures. For general rules see 311 "Guidelines for Writing an IANA Considerations Section in RFCs" 312 [RFC5226], and for specific rules and registries see the individual 313 protocol specification RFCs and the IANA web site. If this is not 314 done, there is nothing to prevent two different extensions picking 315 the same value. When these two extensions "meet" each other on the 316 Internet, failure is inevitable. 318 A surprisingly common case of this is misappropriation of assigned 319 Transmission Control Protocol (TCP) (or User Datagram Protocol (UDP)) 320 registered port numbers. This can lead to a client for one service 321 attempting to communicate with a server for another service. 322 Numerous cases could be cited, but not without embarrassing specific 323 implementors. 325 In some cases, it may be appropriate to use values designated as 326 "experimental" or "local use" in early implementations of an 327 extension. For example, "Experimental Values in IPv4, IPv6, ICMPv4, 328 ICMPv6, UDP and TCP Headers" [RFC4727] discusses experimental values 329 for IP and transport headers, and "Definition of the Differentiated 330 Services Field (DS Field) in the IPv4 and IPv6 Headers" [RFC2474] 331 defines experimental/local use ranges for differentiated services 332 code points. Such values should be used with care and only for their 333 stated purpose: experiments and local use. They are unsuitable for 334 Internet-wide use, since they may be used for conflicting purposes 335 and thereby cause interoperability failures. Packets containing 336 experimental or local use values must not be allowed out of the 337 domain in which they are meaningful. 339 2.7. Extensions to Critical Infrastructure 341 Some protocols (such as Domain Name Service (DNS) and Border Gateway 342 Protocol (BGP)) have become critical components of the Internet 343 infrastructure. When such protocols are extended, the potential 344 exists for negatively impacting the reliability and security of the 345 global Internet. 347 As a result, special care needs to be taken with these extensions, 348 such as taking explicit steps to isolate existing uses from new ones. 349 For example, this can be accomplished by requiring the extension to 350 utilize a different port or multicast address, or by implementing the 351 extension within a separate process, without access to the data and 352 control structures of the base protocol. 354 2.8. Architectural Compatibility 356 Since protocol extension mechanisms may impact interoperability, it 357 is important that these mechanisms be architecturally compatible with 358 the base protocol. This implies that documents relying on extension 359 mechanisms need to explicitly identify them, rather than burying them 360 in the text in the hope that they will escape notice. 362 As part of the definition of new extension mechanisms, the authors 363 need to address whether the mechanisms make use of features as 364 envisaged by the original protocol designers, or whether a new 365 extension mechanism is being invented. If a new extension mechanism 366 is being invented, then architectural compatibility issues need to be 367 addressed. 369 For example, a document defining new data elements should not 370 implicitly define new data types or protocol operations without 371 explicitly describing those dependencies and discussing their impact. 373 3. Specific Considerations for Robust Extensions 375 This section makes explicit some design considerations based on the 376 community's experience with extensibility mechanisms. 378 3.1. Interoperability Checklist 380 Good interoperability stems from a number of factors, including: 382 1. Having a well-written specification. Does the specification 383 make clear what an implementor needs to support and does it define 384 the impact that individual operations (e.g. a message sent to a 385 peer) will have when invoked? 387 2. Learning lessons from deployment. This includes understanding 388 what current implementations do and how a proposed extension will 389 interact with deployed systems. Will a proposed extension (or its 390 proposed usage) operationally stress existing implementations or 391 the underlying protocol itself if widely deployed? 393 3. Having an adequate transition or coexistence story. What 394 impact will the proposed extension have on implementations that do 395 not understand it? Is there a way to negotiate or determine the 396 capabilities of a peer? Can the extended protocol negotiate with 397 an unextended partner to find a common subset of useful functions? 399 4. Respecting underlying architectural or security assumptions. 400 This includes assumptions that may not be well-documented, those 401 that may have arisen as the result of operational experience, or 402 those that only became understood after the original protocol was 403 published. For example, do the extensions reverse the flow of 404 data, allow formerly static parameters to be changed on the fly, 405 or change assumptions relating to the frequency of reads/writes? 407 5. Minimizing impact on critical infrastructure. Does the 408 proposed extension (or its proposed usage) have the potential for 409 negatively impacting critical infrastructure to the point where 410 explicit steps would be appropriate to isolate existing uses from 411 new ones? 413 6. Data model extensions. Does the proposed extension extend the 414 data model in a major way? For example, are new data types 415 defined that may require code changes within existing 416 implementations? 418 3.2. When is an Extension Routine? 420 An extension may be considered 'routine' if it amounts to a new data 421 element of a type that is already supported within the data model, 422 and if its handling is opaque to the protocol itself (e.g. does not 423 substantially change the pattern of messages and responses). 425 For this to apply, the protocol must have been designed to carry the 426 proposed data type, so that no changes to the underlying base 427 protocol or existing implementations are needed to carry the new data 428 element. 430 Moreover, no changes should be required to existing and currently 431 deployed implementations of the underlying protocol unless they want 432 to make use of the new data element. Using the existing protocol to 433 carry a new data element should not impact existing implementations 434 or cause operational problems. This typically requires that the 435 protocol silently discard unknown data elements. 437 Examples of routine extensions include the Dynamic Host Configuration 438 Protocol (DHCP) vendor-specific option [RFC2132], RADIUS Vendor- 439 Specific Attributes [RFC2865], the enterprise Object IDentifier (OID) 440 tree for Management Information Base (MIB) modules, vendor 441 Multipurpose Internet Mail Extension (MIME) types, and some classes 442 of (non-critical) certification extensions. Such extensions can 443 safely be made with minimal discussion. 445 3.3. What Constitutes a Major Extension? 447 Major extensions may have characteristics leading to a risk of 448 interoperability failure. Where these characteristics are present, 449 it is necessary to pay extremely close attention to backward 450 compatibility with implementations and deployments of the unextended 451 protocol, and to the risk of inadvertent introduction of security or 452 operational exposures. Extension designers should examine their 453 design for the following issues: 455 1. Modifications or extensions to the working of the underlying 456 protocol. This can include changing the semantics of existing 457 Protocol Data Units (PDUs) or defining new message types that may 458 require implementation changes in existing and deployed 459 implementations of the protocol, even if they do not want to make 460 use of the new functions or data types. A base protocol without a 461 "silent discard" rule for unknown data elements may automatically 462 enter this category, even for apparently minor extensions. 464 2. Changes to the basic architectural assumptions. This includes 465 architectural assumptions that are explicitly stated or those that 466 have been assumed by implementers. For example, this would 467 include adding a requirement for session state to a previously 468 stateless protocol. 470 3. New usage scenarios not originally intended or investigated. 471 This can potentially lead to operational difficulties when 472 deployed, even in cases where the "on-the-wire" format has not 473 changed. For example, the level of traffic carried by the 474 protocol may increase substantially, packet sizes may increase, 475 and implementation algorithms that are widely deployed may not 476 scale sufficiently or otherwise be up to the new task at hand. 477 For example, a new DNS Resource Record (RR) type that is too big 478 to fit into a single UDP packet could cause interoperability 479 problems with existing DNS clients and servers. 481 4. Considerations for the Base Protocol 483 A good extension design depends on a good base protocol. Ideally, 484 the document that defines a base protocol's extension mechanisms will 485 include guidance to future extension writers that help them use 486 extension mechanisms properly. It may also be possible to define 487 classes of extensions that need little or no review, while other 488 classes need wide review. The details will necessarily be 489 technology-specific. 491 4.1. Version Numbers 493 Any mechanism for extension by versioning must include provisions to 494 ensure interoperability, or at least clean failure modes. Imagine 495 someone creating a protocol and using a "version" field and 496 populating it with a value (1, let's say), but giving no information 497 about what would happen when a new version number appears in it. 498 That's bad protocol design and description; it should be clear what 499 the expectation is and how you test it. For example, stating that 500 1.X must be compatible with any version 1 code, but version 2 or 501 greater is not expected to be compatible, has different implications 502 than stating that version 1 must be a proper subset of version 2. 504 An example is ROHC (Robust Header Compression). ROHCv1 [RFC3095] 505 supports a certain set of profiles for compression algorithms. But 506 experience had shown that these profiles had limitations, so the ROHC 507 WG developed ROHCv2 [RFC5225]. A ROHCv1 implementation does not 508 contain code for the ROHCv2 profiles. As the ROHC WG charter said 509 during the development of ROHCv2: 511 It should be noted that the v2 profiles will thus not be 512 compatible with the original (ROHCv1) profiles, which means less 513 complex ROHC implementations can be realized by not providing 514 support for ROHCv1 (over links not yet supporting ROHC, or by 515 shifting out support for ROHCv1 in the long run). Profile support 516 is agreed through the ROHC channel negotiation, which is part of 517 the ROHC framework and thus not changed by ROHCv2. 519 Thus in this case both backwards-compatible and backwards- 520 incompatible deployments are possible. The important point is a 521 clearly thought out approach to the question of operational 522 compatibility. In the past, protocols have utilized a variety of 523 strategies for versioning, many of which have proven problematic. 524 These include: 526 1. No versioning support. This approach is exemplified by 527 Extensible Authentication Protocol (EAP) [RFC3748] as well as 528 Remote Authentication Dial In User Service (RADIUS) [RFC2865], 529 both of which provide no support for versioning. While lack of 530 versioning support protects against the proliferation of 531 incompatible dialects, the need for extensibility is likely to 532 assert itself in other ways, so that ignoring versioning entirely 533 may not be the most forward thinking approach. 535 2. Highest mutually supported version (HMSV). In this approach, 536 implementations exchange the version numbers of the highest 537 version each supports, with the negotiation agreeing on the 538 highest mutually supported protocol version. This approach 539 implicitly assumes that later versions provide improved 540 functionality, and that advertisement of a particular version 541 number implies support for all lower version numbers. Where these 542 assumptions are invalid, this approach breaks down, potentially 543 resulting in interoperability problems. An example of this issue 544 occurs in Protected EAP [PEAP] where implementations of higher 545 versions may not necessarily provide support for lower versions. 547 3. Assumed backward compatibility. In this approach, 548 implementations may send packets with higher version numbers to 549 legacy implementations supporting lower versions, but with the 550 assumption that the legacy implementations will interpret packets 551 with higher version numbers using the semantics and syntax defined 552 for lower versions. This is the approach taken by Port-Based 553 Access Control [IEEE-802.1X]. For this approach to work, legacy 554 implementations need to be able to accept packets of known type 555 with higher protocol versions without discarding them; protocol 556 enhancements need to permit silent discard of unsupported 557 extensions; implementations supporting higher versions need to 558 refrain from mandating new features when encountering legacy 559 implementations. 561 4. Major/minor versioning. In this approach, implementations with 562 the same major version but a different minor version are assumed 563 to be backward compatible, but implementations are assumed to be 564 required to negotiate a mutually supported major version number. 565 This approach assumes that implementations with a lower minor 566 version number but the same major version can safely ignore 567 unsupported protocol messages. 569 5. Min/max versioning. This approach is similar to HMSV, but 570 without the implied obligation for clients and servers to support 571 all versions back to version 1, in perpetuity. It allows clients 572 and servers to cleanly drop support for early versions when those 573 versions become so old that they are no longer relevant and no 574 longer required. In this approach, the client initiating the 575 connection reports the highest and lowest protocol versions it 576 understands. The server reports back the chosen protocol version: 578 a. If the server understands one or more versions in the client's 579 range, it reports back the highest mutually understood version. 581 b. If there is no mutual version, then the server reports back 582 some version that it does understand (selected as described 583 below). The connection is then typically dropped by client or 584 server, but reporting this version number first helps facilitate 585 useful error messages at the client end: 587 * If there is no mutual version, and the server speaks any 588 version higher than client max, it reports the lowest version it 589 speaks which is greater than the client max. The client can 590 then report to the user, "You need to upgrade to at least 591 version ." 593 * Else, the server reports the highest version it speaks. The 594 client can then report to the user, "You need to request the 595 server operator to upgrade to at least version ." 597 Protocols generally do not need any version-negotiation mechanism 598 more complicated than the mechanisms described here. The nature of 599 protocol version-negotiation mechanisms is that, by definition, they 600 don't get widespread real-world testing until *after* the base 601 protocol has been deployed for a while, and its deficiencies have 602 become evident. This means that, to be useful, a protocol version- 603 negotiation mechanism should be simple enough that it can reasonably 604 be assumed that all the implementers of the first protocol version at 605 least managed to implement the version-negotiation mechanism 606 correctly. 608 4.2. Reserved Fields 610 Protocols commonly include one or more "reserved" fields, clearly 611 intended for future extensions. It is good practice to specify the 612 value to be inserted in such a field by the sender (typically zero) 613 and the action to be taken by the receiver when seeing some other 614 value (typically no action). In packet format diagrams, such fields 615 are typically labelled "MBZ", to be read as, "Must Be Zero on 616 transmission, Must Be Ignored on reception." A common mistake of 617 inexperienced protocol implementers is to think that "MBZ" means that 618 it's their software's job to verify that the value of the field is 619 zero on reception, and reject the packet if not. This is a mistake, 620 and such software will fail when it encouters future versions of the 621 protocol where these previously reserved fields are given new defined 622 meanings. Similarly, protocols should carefully specify how 623 receivers should react to unknown TLVs etc., such that failures occur 624 only when that is truly the intended outcome. 626 4.3. Encoding Formats 628 Using widely-supported encoding formats leads to better 629 interoperability and easier extensibility. An excellent example is 630 the Simple Network Management Protocol (SNMP) SMI. Guidelines exist 631 for defining the MIB objects that SNMP carries [RFC4181]. Also, 632 multiple textual conventions have been published, so that MIB 633 designers do not have to reinvent the wheel when they need a commonly 634 encountered construct. For example, the "Textual Conventions for 635 Internet Network Addresses" [RFC4001] can be used by any MIB designer 636 needing to define objects containing IP addresses, thus ensuring 637 consistency as the body of MIBs is extended. 639 5. Security Considerations 641 An extension must not introduce new security risks without also 642 providing adequate counter-measures, and in particular it must not 643 inadvertently defeat security measures in the unextended protocol. 644 Thus, the security analysis for an extension needs to be as thorough 645 as for the original protocol - effectively it needs to be a 646 regression analysis to check that the extension doesn't inadvertently 647 invalidate the original security model. 649 This analysis may be simple (e.g. adding an extra opaque data element 650 is unlikely to create a new risk) or quite complex (e.g. adding a 651 handshake to a previously stateless protocol may create a completely 652 new opportunity for an attacker). 654 6. IANA Considerations 656 [RFC Editor: please remove this section prior to publication.] 658 This document has no IANA Actions. 660 7. References 662 7.1. Normative References 664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 665 Requirement Levels", BCP 14, RFC 2119, March 1997. 667 [RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures 668 for Protocol Extensions and Variations", BCP 125, RFC 669 4775, December 2006. 671 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 672 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 673 May 2008. 675 7.2. Informative References 677 [I-D.ietf-radext-design] 678 Weber, G. and A. DeKok, "RADIUS Design Guidelines", 679 draft-ietf-radext-design-12.txt, Internet draft (work in 680 progress), March 2010. 682 [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local 683 and Metropolitan Area Networks: Port-Based Network Access 684 Control", IEEE Standard 802.1X-2004, December 2004. 686 [PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G. 687 and S. Josefsson, "Protected EAP Protocol (PEAP) Version 688 2", draft-josefsson-pppext-eap-tls-eap-10.txt, Expired 689 Internet draft (work in progress), October 2004. 691 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 692 text messages", STD 11, RFC 822, August 1982. 694 [RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered 695 Harmful", RFC 1263, October 1991. 697 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP 698 Vendor Extensions", RFC 2132, March 1997. 700 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 701 RFC 2246, January 1999. 703 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 704 "Definition of the Differentiated Services Field (DS 705 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 706 1998. 708 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 709 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 710 RFC 2661, August 1999. 712 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",RFC 713 2671, August 1999. 715 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 716 2001. 718 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 719 "Remote Authentication Dial In User Service (RADIUS)", 720 RFC 2865, June 2000. 722 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, 723 H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., 724 Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, 725 K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust 726 Header Compression (ROHC): Framework and four profiles: 728 RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. 730 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 731 and B. Rosen, "Change Process for the Session Initiation 732 Protocol (SIP)", BCP 67, RFC 3427, December 2002. 734 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 735 Authentication Dial In User Service)", RFC 3575, July 736 2003. 738 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 739 (RR) Types", RFC 3597, September 2003. 741 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 742 Provisioning Protocol (EPP)", RFC 3735, March 2004. 744 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 745 Lefkowetz, "Extensible Authentication Protocol (EAP)", 746 RFC 3748, June 2004. 748 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 749 Schoenwaelder, "Textual Conventions for Internet Network 750 Addresses", RFC 4001, February 2005. 752 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 753 Documents", BCP 111, RFC 4181, September 2005. 755 [RFC4356] Gellens, R., "Mapping Between the Multimedia Messaging 756 Service (MMS) and Internet Mail", RFC 4356, January 2006. 758 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, 759 J., and T. Wright, "Transport Layer Security (TLS) 760 Extensions", RFC 4366, April 2006. 762 [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors 763 of Extensions to the Session Initiation Protocol (SIP)", 764 RFC 4485, May 2006. 766 [RFC4521] Zeilenga, K., "Considerations for Lightweight Directory 767 Access Protocol (LDAP) Extensions", BCP 118, RFC 4521, 768 June 2006. 770 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 771 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 773 [RFC4929] Andersson, L. and A. Farrel, "Change Process for 774 Multiprotocol Label Switching (MPLS) and Generalized MPLS 775 (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, 776 June 2007. 778 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 779 Dial In User Service (RADIUS) Implementation Issues and 780 Suggested Fixes", RFC 5080, December 2007. 782 [RFC5218] Thaler, D., and B. Aboba, "What Makes for a Successful 783 Protocol?", RFC 5218, July 2008. 785 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 786 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 787 UDP-Lite", RFC 5225, April 2008. 789 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 790 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 792 [RFC5727] Peterson, J., Jennings, C. and R. Sparks, "Change Process 793 for the Session Initiation Protocol (SIP) and the REal- 794 time Applications and Infrastructure Area", RFC 5727, 795 March 2010. 797 Acknowledgements 799 This document is heavily based on an earlier draft under a different 800 title by Scott Bradner and Thomas Narten. 802 That draft stated: The initial version of this document was put 803 together by the IESG in 2002. Since then, it has been reworked in 804 response to feedback from John Loughney, Henrik Levkowetz, Mark 805 Townsley, Randy Bush and others. 807 Valuable comments and suggestions on the current form of the document 808 were made by Jari Arkko, Ted Hardie, Loa Andersson, Eric Rescorla, 809 Pekka Savola, Leslie Daigle and Alfred Hoenes. 811 The text on TLS experience was contributed by Yngve Pettersen. 813 IAB Members at the Time of this Writing 815 Marcelo Bagnulo 816 Gonzalo Camarillo 817 Stuart Cheshire 818 Vijay Gill 819 Russ Housley 820 John Klensin 821 Olaf Kolkman 822 Gregory Lebovitz 823 Andrew Malis 824 Danny McPherson 825 David Oran 826 Jon Peterson 827 Dave Thaler 829 Appendix A. Examples 831 This section discusses some specific examples, as case studies. 833 A.1. Already documented cases 835 There are certain documents that specify a change process or describe 836 extension considerations for specific IETF protocols: 838 The SIP change process [RFC3427], [RFC4485], [RFC5727] 839 The (G)MPLS change process (mainly procedural) [RFC4929] 840 LDAP extensions [RFC4521] 841 EPP extensions [RFC3735] 842 DNS extensions [RFC2671][RFC3597] 844 It is relatively common for MIBs, which are all in effect extensions 845 of the SMI data model, to be defined or extended outside the IETF. 846 BCP 111 [RFC4181] offers detailed guidance for authors and reviewers. 848 A.2. RADIUS Extensions 850 The RADIUS [RFC2865] protocol was designed to be extensible via 851 addition of Attributes to a Data Dictionary on the server, without 852 requiring code changes. However, this extensibility model assumed 853 that Attributes would conform to a limited set of data types and that 854 vendor extensions would be limited to use by vendors, in situations 855 in which interoperability was not required. Subsequent developments 856 have stretched those assumptions. 858 Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism 859 for Vendor-Specific extensions (Attribute 26), and states that use of 860 Vendor-Specific extensions: 862 should be encouraged instead of allocation of global attribute 863 types, for functions specific only to one vendor's implementation 864 of RADIUS, where no interoperability is deemed useful. 866 However, in practice usage of Vendor-Specific Attributes (VSAs) has 867 been considerably broader than this. In particular, VSAs have been 868 used by Standards Development Organizations (SDOs) to define their 869 own extensions to the RADIUS protocol. 871 This has caused a number of problems. Since the VSA mechanism was 872 not designed for interoperability, VSAs do not contain a "mandatory" 873 bit. As a result, RADIUS clients and servers may not know whether it 874 is safe to ignore unknown attributes. For example, Section 5 of the 875 RADIUS specification [RFC2865] states: 877 A RADIUS server MAY ignore Attributes with an unknown Type. A 878 RADIUS client MAY ignore Attributes with an unknown Type. 880 However, in the case where the VSAs pertain to security (e.g. 881 Filters) it may not be safe to ignore them, since the RADIUS 882 specification [RFC2865] also states: 884 A NAS that does not implement a given service MUST NOT implement 885 the RADIUS attributes for that service. For example, a NAS that 886 is unable to offer ARAP service MUST NOT implement the RADIUS 887 attributes for ARAP. A NAS MUST treat a RADIUS access-accept 888 authorizing an unavailable service as an access-reject instead." 890 Detailed discussion of the issues arising from this can be found in 891 "Common Remote Authentication Dial In User Service (RADIUS) 892 Implementation Issues and Suggested Fixes" [RFC5080] Section 2.5. 894 Since it was not envisaged that multi-vendor VSA implementations 895 would need to interoperate, the RADIUS specification [RFC2865] does 896 not define the data model for VSAs, and allows multiple sub- 897 attributes to be included within a single Attribute of type 26. 898 However, this enables VSAs to be defined which would not be 899 supportable by current implementations if placed within the standard 900 RADIUS attribute space. This has caused problems in standardizing 901 widely deployed VSAs, as discussed in "RADIUS Design Guidelines" [I- 902 D.ietf-radext-design]. 904 In addition to extending RADIUS by use of VSAs, SDOs have also 905 defined new values of the Service-Type attribute in order to create 906 new RADIUS commands. Since the RADIUS specification [RFC2865] 907 defined Service-Type values as being allocated First Come, First 908 Served (FCFS), this essentially enabled new RADIUS commands to be 909 allocated without IETF review. This oversight has since been fixed 910 in "IANA Considerations for RADIUS" [RFC3575]. 912 A.3. TLS Extensions 914 The Secure Sockets Layer (SSL) v2 protocol was developed by Netscape 915 to be used to secure online transactions on the Internet. It was 916 later replaced by SSL v3, also developed by Netscape. SSL v3 was 917 then further developed by the IETF as the Transport Layer Security 918 (TLS) protocol [RFC2246]. 920 The SSL v3 protocol was not explicitly specified to be extended. 921 Even TLS 1.0 did not define an extension mechanism explicitly. 922 However, extension "loopholes" were available. Extension mechanisms 923 were finally defined in "Transport Layer Security (TLS) Extensions" 924 [RFC4366]: 926 o New versions 927 o New cipher suites 928 o Compression 929 o Expanded handshake messages 930 o New record types 931 o New handshake messages 933 The protocol also defines how implementations should handle unknown 934 extensions. 936 Of the above extension methods, new versions and expanded handshake 937 messages have caused the most interoperability problems. 938 Implementations are supposed to ignore unknown record types but to 939 reject unknown handshake messages. 941 The new version support in SSL/TLS includes a capability to define 942 new versions of the protocol, while allowing newer implementations to 943 communicate with older implementations. As part of this 944 functionality some Key Exchange methods include functionality to 945 prevent version rollback attacks. 947 The experience with this upgrade functionality in SSL and TLS is 948 decidedly mixed: 950 o SSL v2 and SSL v3/TLS are not compatible. It is possible to use 951 SSL v2 protocol messages to initiate a SSL v3/TLS connection, but 952 it is not possible to communicate with a SSL v2 implementation 953 using SSL v3/TLS protocol messages. 954 o There are implementations that refuse to accept handshakes using 955 newer versions of the protocol than they support. 956 o There are other implementations that accept newer versions, but 957 have implemented the version rollback protection clumsily. 959 The SSL v2 problem has forced SSL v3 and TLS clients to continue to 960 use SSL v2 Client Hellos for their initial handshake with almost all 961 servers until 2006, much longer than would have been desirable, in 962 order to interoperate with old servers. 964 The problem with incorrect handling of newer versions has also forced 965 many clients to actually disable the newer protocol versions, either 966 by default, or by automatically disabling the functionality, to be 967 able to connect to such servers. Effectively, this means that the 968 version rollback protection in SSL and TLS is non-existent if talking 969 to a fatally compromised older version. 971 SSL v3 and TLS also permitted expansion of the Client Hello and 972 Server Hello handshake messages. This functionality was fully 973 defined by the introduction of TLS Extensions, which makes it 974 possible to add new functionality to the handshake, such as the name 975 of the server the client is connecting to, request certificate status 976 information, indicate Certificate Authority support, maximum record 977 length, etc. Several of these extensions also introduce new 978 handshake messages. 980 It has turned out that many SSL v3 and TLS implementations that do 981 not support TLS Extensions, did not, as required by the protocol 982 specifications, ignore the unknown extensions, but instead failed to 983 establish connections. Several of the implementations behaving in 984 this manner are used by high profile Internet sites, such as online 985 banking sites, and this has caused a significant delay in the 986 deployment of clients supporting TLS Extensions, and several of the 987 clients that have enabled support are using heuristics that allow 988 them to disable the functionality when they detect a problem. 990 Looking forward, the protocol version problem, in particular, can 991 cause future security problems for the TLS protocol. The strength of 992 the digest algorithms (MD5 and SHA-1) used by SSL and TLS is 993 weakening. If MD5 and SHA-1 weaken to the point where it is feasible 994 to mount successful attacks against older SSL and TLS versions, the 995 current error recovery used by clients would become a security 996 vulnerability (among many other serious problems for the Internet). 998 To address this issue, TLS 1.2 [RFC5246] makes use of a newer 999 cryptographic hash algorithm (SHA-256) during the TLS handshake by 1000 default. Legacy ciphersuites can still be used to protect 1001 application data, but new ciphersuites are specified for data 1002 protection as well as for authentication within the TLS handhshake. 1003 The hashing method can also be negotiated via a Hello extension. 1004 Implementations are encouraged to implement new ciphersuites, and to 1005 enable the negotiation of the ciphersuite used during a TLS session 1006 to be governed by policy, thus enabling a more rapid transition away 1007 from weakened ciphersuites. 1009 The lesson to be drawn from this experience is that it isn't 1010 sufficient to design extensibility carefully; it must also be 1011 implemented carefully by every implementer, without exception. Test 1012 suites and certification programs can help provide incentives for 1013 implementers to pay attention to implementing extensibility 1014 mechanisms correctly. 1016 A.4. L2TP Extensions 1018 Layer Two Tunneling Protocol (L2TP) [RFC2661] carries Attribute-Value 1019 Pairs (AVPs), with most AVPs having no semantics to the L2TP protocol 1020 itself. However, it should be noted that L2TP message types are 1021 identified by a Message Type AVP (Attribute Type 0) with specific AVP 1022 values indicating the actual message type. Thus, extensions relating 1023 to Message Type AVPs would likely be considered major extensions. 1025 L2TP also provides for Vendor-Specific AVPs. Because everything in 1026 L2TP is encoded using AVPs, it would be easy to define vendor- 1027 specific AVPs that would be considered major extensions. 1029 L2TP also provides for a "mandatory" bit in AVPs. Recipients of L2TP 1030 messages containing AVPs they do not understand but that have the 1031 mandatory bit set, are expected to reject the message and terminate 1032 the tunnel or session the message refers to. This leads to 1033 interesting interoperability issues, because a sender can include a 1034 vendor-specific AVP with the M-bit set, which then causes the 1035 recipient to not interoperate with the sender. This sort of behavior 1036 is counter to the IETF ideals, as implementations of the IETF 1037 standard should interoperate successfully with other implementations 1038 and not require the implementation of non-IETF extensions in order to 1039 interoperate successfully. Section 4.2 of the L2TP specification 1040 [RFC2661] includes specific wording on this point, though there was 1041 significant debate at the time as to whether such language was by 1042 itself sufficient. 1044 Fortunately, it does not appear that the potential problems described 1045 above have yet become a problem in practice. At the time of this 1046 writing, the authors are not aware of the existence of any vendor- 1047 specific AVPs that also set the M-bit. 1049 Change log [RFC Editor: please remove this section] 1051 draft-iab-extension-recs-01: 2010-4-7. Updates by Stuart 1052 Cheshire. 1054 draft-iab-extension-recs-00: 2009-4-24. Updated boilerplate, 1055 author list. 1057 draft-carpenter-extension-recs-04: 2008-10-24. Updated author 1058 addresses, fixed editorial issues. 1060 draft-carpenter-extension-recs-03: 2008-10-17. Updated references, 1061 added material relating to versioning. 1063 draft-carpenter-extension-recs-02: 2007-06-15. Reorganized Sections 1064 2 and 3. 1066 draft-carpenter-extension-recs-01: 2007-03-04. Updated according to 1067 comments, especially the wording about TLS, added various specific 1068 examples. 1070 draft-carpenter-extension-recs-00: original version, 2006-10-12. 1071 Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by 1072 focusing on architectural issues; the more procedural issues in that 1073 draft were moved to RFC 4775. 1075 Authors' Addresses 1077 Brian Carpenter 1078 Department of Computer Science 1079 University of Auckland 1080 PB 92019 1081 Auckland, 1142 1082 New Zealand 1084 Email: brian.e.carpenter@gmail.com 1086 Bernard Aboba 1087 Microsoft Corporation 1088 One Microsoft Way 1089 Redmond, WA 98052 1091 EMail: bernarda@microsoft.com 1092 Phone: +1 425 706 6605 1093 Fax: +1 425 936 7329 1095 Stuart Cheshire 1096 Apple Computer, Inc. 1097 1 Infinite Loop 1098 Cupertino, CA 95014 1100 EMail: cheshire@apple.com