idnits 2.17.1 draft-carpenter-extension-recs-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1016. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1027. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1034. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1040. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (27 October 2008) is 5650 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-05 -- 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 (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft University of Auckland 4 Intended Status: Informational B. Aboba (ed) 5 Expires: April 24, 2009 Microsoft Corporation 6 27 October 2008 8 Design Considerations for Protocol Extensions 9 draft-carpenter-extension-recs-04 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 24, 2009. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 38 Abstract 40 This document discusses issues related to the extensibility of 41 Internet protocols, with a focus on the architectural design 42 considerations involved. Concrete case study examples are included. 43 It is intended to assist designers of both base protocols and 44 extensions. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1 Requirements Language . . . . . . . . . . . . . . . . . . 3 50 2. Architectural Principles . . . . . . . . . . . . . . . . . . . 3 51 2.1 Limited Extensibility . . . . . . . . . . . . . . . . . . 4 52 2.2 Global Interoperability . . . . . . . . . . . . . . . . . 5 53 2.3 Protocol Variations . . . . . . . . . . . . . . . . . . . 5 54 2.4 Extension Documentation . . . . . . . . . . . . . . . . . 6 55 2.5 Testability . . . . . . . . . . . . . . . . . . . . . . . 6 56 2.6 Parameter Registration . . . . . . . . . . . . . . . . . . 7 57 2.7 Extensions to Critical Infrastructure . . . . . . . . . . 7 58 2.8 Architectural Compatibility . . . . . . . . . . . . . . . 8 59 3. Specific Considerations for Robust Extensions . . . . . . . . 8 60 3.1. Interoperability Checklist . . . . . . . . . . . . . . . . 8 61 3.2. When is an Extension Routine? . . . . . . . . . . . . . . 9 62 3.3. What Constitutes a Major Extension? . . . . . . . . . . . 10 63 4. Considerations for the Base Protocol . . . . . . . . . . . . . 10 64 4.1. Version Numbers . . . . . . . . . . . . . . . . . . . . . 11 65 4.2. Reserved Fields . . . . . . . . . . . . . . . . . . . . . 13 66 4.3. Encoding Formats . . . . . . . . . . . . . . . . . . . . . 13 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 72 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 Appendix A - Examples . . . . . . . . . . . . . . . . . . . . . . 17 74 A.1. Already documented cases . . . . . . . . . . . . . . . . . 17 75 A.2. RADIUS Extensions . . . . . . . . . . . . . . . . . . . . 17 76 A.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . . 18 77 A.4. L2TP Extensions . . . . . . . . . . . . . . . . . . . . . 20 78 Change log . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 80 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 23 81 Intellectual Property . . . . . . . . . . . . . . . . . . . . . . 23 82 1. Introduction 84 Internet Engineering Task Force (IETF) protocols typically include 85 mechanisms whereby they can be extended in the future. It is of 86 course a good principle to design extensibility into protocols; one 87 common definition of a successful protocol is one that becomes widely 88 used in ways not originally anticipated. Well-designed extensibility 89 mechanisms facilitate the evolution of protocols and help make it 90 easier to roll out incremental changes in an interoperable fashion. 92 When an initial protocol design is extended, there is always a risk 93 of unintended consequences, such as interoperability problems or 94 security vulnerabilities. This risk is especially high if the 95 extension is performed by a different team than the original 96 designers, who may stray outside implicit design constraints or 97 assumptions. As a result, extensions should be done carefully and 98 with a full understanding of the base protocol, existing 99 implementations, and current operational practice. 101 This is hardly a recent concern. "TCP Extensions Considered Harmful" 102 [RFC1263] was published in 1991. "Extend" or "extension" occurs in 103 the title of more than 300 existing Request For Comment (RFC) 104 documents. Yet generic extension considerations have not been 105 documented previously. 107 This document describes technical considerations for protocol 108 extensions, in order to minimize such risks. It is intended to 109 assist designers of both base protocols and extensions. Formal 110 procedures for extending IETF protocols are discussed in "Procedures 111 for Protocol Extensions and Variations" BCP 125 [RFC4775]. 113 Section 2 describes architectural principles for protocol 114 extensibility. Section 3 is aimed principally at extension 115 designers, and Section 4 at base protocol designers. Nevertheless, 116 readers are advised to study the whole document, since the 117 considerations are closely linked. 119 1.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in BCP 14, RFC 2119 124 [RFC2119]. 126 2. Architectural Principles 128 This Section describes basic principles of protocol extensibility: 130 1. Extensibility features should be limited to what is clearly 131 necessary when the protocol is developed. 133 2. Protocol extensions should be designed for global 134 interoperability. 136 3. Protocol extension mechanisms should not be used to create 137 incompatible protocol variations. 139 4. Extension mechanisms need to be fully documented. 141 5. Extension mechanisms need to be testable. 143 6. Protocol parameters should be registered and used for their 144 intended purpose. 146 7. Extensions to critical infrastructure should not impact the 147 security or reliability of the global Internet. 149 8. Extension mechanisms should be explicitly identified and should be 150 architecturally compatible with the base protocol design. 152 2.1. Limited Extensibility 154 Protocols that permit easy extensions may have the perverse side 155 effect of making it easy to construct incompatible extensions. 156 Consequently, protocols should not be made more extensible than 157 clearly necessary at inception, and the process for defining new 158 extensibility mechanisms should ensure that adequate review of 159 proposed extensions will take place before widespread adoption. In 160 practice, this means that the "First Come First Served" allocation 161 policy described in "Guidelines for Writing an IANA Considerations 162 Section in RFCs" [RFC5226], as well as similar policies that allow 163 routine extensions should be used sparingly, as they imply minimal or 164 no review. In particular, they should be limited to cases, such as 165 allowing new opaque data elements, that are unlikely to cause 166 protocol failures. 168 In order to increase the likelihood that routine extensions are truly 169 routine, protocol documents should provide guidelines explaining how 170 they should be performed. For example, even though DHCP carries 171 opaque data, defining a new option using completely unstructured data 172 may lead to an option that is (unnecessarily) hard for clients and 173 servers to process. 175 2.2. Global Interoperability 177 Global interoperability is a primary goal of Internet protocol 178 design. Experience shows that software is often used outside the 179 particular special environment it was originally intended for, so 180 extensions cannot be designed for an isolated environment. Designers 181 of extensions must assume the high likelihood of a system using the 182 extension having to interoperate with systems on the global Internet. 184 For this reason, an extension may lead to interoperability failures 185 unless the extended protocol correctly supports all mandatory and 186 optional features of the unextended base protocol, and 187 implementations of the base protocol operate correctly in the 188 presence of the extensions. 190 Consider for example a "private" extension installed on a work 191 computer which, being portable, is sometimes installed on a home 192 network or in a hotel. If the "private" extension is incompatible 193 with an unextended version of the same protocol, problems will occur. 195 2.3. Protocol Variations 197 Protocol extension mechanisms should not be used to create 198 incompatible forks in development instead. Ideally, the protocol 199 mechanisms for extension and versioning should be sufficiently well 200 described that compatibility can be assessed on paper. Otherwise, 201 when two "private" extensions encounter each other on a public 202 network, unexpected interoperability problems may occur. 204 An example of what might go wrong is misuse of the "X-" mail header 205 fields originally defined in the Simple Mail Transfer Protocol (SMTP) 206 [RFC0822]. X-anything was a valid mail header field; but it had no 207 defined meaning in the standard. Suppose a mail implementation 208 assigns specific semantics to X-anything that causes it to take 209 specific action, such as discarding a message as spam. If it 210 encounters a message from a different implementation that assigns 211 different semantics, it may take quite inappropriate action, such as 212 discarding a valid message. Thus, relying on the implied semantics 213 of an "X-" header field automatically creates a risk of operational 214 failures. "X-" header fields were removed from "Internet Message 215 Format" [RFC2822]. Even when they are assigned semantics, as in 216 "Mapping Between the Multimedia Message Service (MMS) and Internet 217 Mail" [RFC4356], great care must be taken that implementations do not 218 rely on such semantics in messages that have crossed the open 219 Internet. 221 Thus we observe that a key requirement for interoperable extension 222 design is that the base protocol must be well designed for 223 interoperability, and that extensions must have unambiguous 224 semantics. 226 Protocol variations - specifications that look very similar to the 227 original but are actually different - are even more harmful to 228 interoperability than extensions. In general, such variations should 229 be avoided. If they cannot be avoided, as many of the following 230 considerations as possible should be applied, to minimize the damage 231 to interoperability. 233 2.4. Extension Documentation 235 Some protocol components are designed with the specific intention of 236 allowing extensibility. These should be clearly identified, with 237 specific and complete instructions on how to extend them, including 238 the process for adequate review of extension proposals: do they need 239 community review and if so how much and by whom? For example, the 240 definition of additional data elements that can be carried opaquely 241 may require no review, while the addition of new data types or new 242 protocol messages might require a Standards Track action. Guidance 243 on writing appropriate IANA Considerations text may be found in 244 [RFC5226]. 246 In a number of cases, there is a need for explicit guidance relating 247 to extensions beyond what is encapsulated in the IANA considerations 248 section of the base specification. The usefulness of "Guidelines for 249 Authors and Reviewers of MIB Documents" [RFC4181] suggests that 250 protocols whose data model is likely to be widely extended 251 (particularly using vendor-specific elements) need a Design 252 Guidelines document specifically addressing extensions. 254 2.5. Testability 256 Experience shows that it is insufficient to correctly specify 257 extensibility and backwards compatibility in an RFC. It is also 258 important that implementations respect the compatibility mechanisms; 259 if not, non-interoperable pairs of implementations may arise. The 260 TLS case study shows how important this can be. 262 In order to determine whether protocol extension mechanisms have been 263 properly implemented, testing is required. However, for this to be 264 possible, test cases need to be developed. If a base protocol 265 document specifies extension mechanisms but does not utilize them or 266 provide examples, it may not be possible to develop test cases based 267 on the base protocol specification alone. As a result, base protocol 268 implementations may not be properly tested and non-compliant 269 extension behavior may not be detected until these implementations 270 are widely deployed. 272 To encourage correct implementation of extension mechanisms, base 273 protocol specifications should clearly articulate the expected 274 behavior of extension mechanisms and should include examples of 275 correct and incorrect extension behavior. 277 2.6. Parameter Registration 279 An extension is often likely to make use of additional values added 280 to an existing IANA registry (in many cases, simply by adding a new 281 Type-Length-Value (TLV) field). To avoid conflicting usage of the 282 same value, it is essential that all new values are properly 283 registered by the applicable procedures. See BCP 26, [RFC5226] for 284 the general rules, and individual protocol RFCs, and the IANA web 285 site, for specific rules and registries. If this is not done, there 286 is nothing to prevent two different extensions picking the same 287 value. When these two extensions "meet" each other on the Internet, 288 failure is inevitable. 290 A surprisingly common case of this is misappropriation of assigned 291 Transport Control Protocol (TCP) (or User Datagram Protocol (UDP)) 292 registered port numbers. This can lead to a client for one service 293 attempting to communicate with a server for another service. 294 Numerous cases could be cited, but not without embarrassing specific 295 implementors. 297 In some cases, it may be appropriate to use values designated as 298 "experimental" or "local use" in early implementations of an 299 extension. For example, "Experimental Values in IPv4, IPv6, ICMPv4, 300 ICMPv6, UDP and TCP Headers" [RFC4727] discusses experimental values 301 for IP and transport headers, and "Definition of the Differentiated 302 Services Field (DS Field) in the IPv4 and IPv6 Headers" [RFC2474] 303 defines experimental/local use ranges for differentiated services 304 code points. Such values should be used with care and only for their 305 stated purpose: experiments and local use. They are unsuitable for 306 Internet-wide use, since they may be used for conflicting purposes 307 and thereby cause interoperability failures. Packets containing 308 experimental or local use values must not be allowed out of the 309 domain in which they are meaningful. 311 2.7. Extensions to Critical Infrastructure 313 Some protocols (such as Domain Name Service (DNS) and Border Gateway 314 Protocol (BGP) have become critical components of the Internet 315 infrastructure. When such protocols are extended, the potential 316 exists for negatively impacting the reliability and security of the 317 global Internet. 319 As a result, special care needs to be taken with these extensions, 320 such as taking explicit steps to isolate existing uses from new ones. 321 For example, this can be accomplished by requiring the extension to 322 utilize a different port or multicast address, or by implementing the 323 extension within a separate process, without access to the data and 324 control structures of the base protocol. 326 2.8. Architectural Compatibility 328 Since protocol extension mechanisms may impact interoperability, it 329 is important that these mechanisms be architecturally compatible with 330 the base protocol. This implies that documents relying on extension 331 mechanisms need to explicitly identify them, rather than burying them 332 in the text in the hope that they will escape notice. 334 As part of the definition of new extension mechanisms, the authors 335 need to address whether the mechanisms make use of features as 336 envisaged by the original protocol designers, or whether a new 337 extension mechanism is being invented. If a new extension mechanism 338 is being invented, then architectural compatibility issues need to be 339 addressed. 341 For example, a document defining new data elements should not 342 implicitly define new data types or protocol operations without 343 explicitly describing those dependencies and discussing their impact. 345 3. Specific Considerations for Robust Extensions 347 This section makes explicit some design considerations based on the 348 community's experience with extensibility mechanisms. 350 3.1. Interoperability Checklist 352 Good interoperability stems from a number of factors, including: 354 1. Having a well-written specification. Does the specification 355 make clear what an implementor needs to support and does it define 356 the impact that individual operations (e.g. a message sent to a 357 peer) will have when invoked? 359 2. Learning lessons from deployment. This includes understanding 360 what current implementations do and how a proposed extension will 361 interact with deployed systems. Will a proposed extension (or its 362 proposed usage) operationally stress existing implementations or 363 the underlying protocol itself if widely deployed? 365 3. Having an adequate transition or coexistence story. What 366 impact will the proposed extension have on implementations that do 367 not understand it? Is there a way to negotiate or determine the 368 capabilities of a peer? Can the extended protocol negotiate with 369 an unextended partner to find a common subset of useful functions? 371 4. Respecting underlying architectural or security assumptions. 372 This includes assumptions that may not be well-documented, those 373 that may have arisen as the result of operational experience, or 374 those that only became understood after the original protocol was 375 published. For example, do the extensions reverse the flow of 376 data, allow formerly static parameters to be changed on the fly, 377 or change assumptions relating to the frequency of reads/writes? 379 5. Minimizing impact on critical infrastructure. Does the 380 proposed extension (or its proposed usage) have the potential for 381 negatively impacting critical infrastructure to the point where 382 explicit steps would be appropriate to isolate existing uses from 383 new ones? 385 6. Data model extensions. Does the proposed extension extend the 386 data model in a major way? For example, are new data types 387 defined that may require code changes within existing 388 implementations? 390 3.2. When is an Extension Routine? 392 An extension may be considered 'routine' if it amounts to a new data 393 element of a type that is already supported within the data model, 394 and if its handling is opaque to the protocol itself (e.g. does not 395 substantially change the pattern of messages and responses). 397 For this to apply, the protocol must have been designed to carry the 398 proposed data type, so that no changes to the underlying base 399 protocol or existing implementations are needed to carry the new data 400 element. 402 Moreover, no changes should be required to existing and currently 403 deployed implementations of the underlying protocol unless they want 404 to make use of the new data element. Using the existing protocol to 405 carry a new data element should not impact existing implementations 406 or cause operational problems. This typically requires that the 407 protocol silently discard unknown data elements. 409 Examples of routine extensions include the Dynamic Host Configuration 410 Protocol (DHCP) vendor-specific option, RADIUS Vendor-Specific 411 Attributes compliant with [RFC2865], the enterprise Object IDentifier 412 (OID) tree for Management Information Base (MIB) modules, vendor 413 Multipurpose Internet Mail Extension (MIME) types, and some classes 414 of (non-critical) certification extensions. Such extensions can 415 safely be made with minimal discussion. 417 3.3. What Constitutes a Major Extension? 419 Major extensions may have characteristics leading to a risk of 420 interoperability failure. Where these characteristics are present, 421 it is necessary to pay extremely close attention to backward 422 compatibility with implementations and deployments of the unextended 423 protocol, and to the risk of inadvertent introduction of security or 424 operational exposures. Extension designers should examine their 425 design for the following issues: 427 1. Modifications or extensions to the working of the underlying 428 protocol. This can include changing the semantics of existing 429 Protocol Data Units (PDUs) or defining new message types that may 430 require implementation changes in existing and deployed 431 implementations of the protocol, even if they do not want to make 432 use of the new functions or data types. A base protocol without a 433 "silent discard" rule for unknown data elements may automatically 434 enter this category, even for apparently minor extensions. 436 2. Changes to the basic architectural assumptions. This includes 437 architectural assumptions that are explicitly stated or those that 438 have been assumed by implementers. For example, this would 439 include adding a requirement for session state to a previously 440 stateless protocol. 442 3. New usage scenarios not originally intended or investigated. 443 This can potentially lead to operational difficulties when 444 deployed, even in cases where the "on-the-wire" format has not 445 changed. For example, the level of traffic carried by the 446 protocol may increase substantially, packet sizes may increase, 447 and implementation algorithms that are widely deployed may not 448 scale sufficiently or otherwise be up to the new task at hand. 449 For example, a new DNS Resource Record (RR) type that is too big 450 to fit into a single UDP packet could cause interoperability 451 problems with existing DNS clients and servers. 453 4. Considerations for the Base Protocol 455 A good extension design depends on a good base protocol. Ideally, 456 the document that defines a base protocol's extension mechanisms will 457 include guidance to future extension writers that help them use 458 extension mechanisms properly. It may also be possible to define 459 classes of extensions that need little or no review, while other 460 classes need wide review. The details will necessarily be 461 technology-specific. 463 4.1. Version Numbers 465 Any mechanism for extension by versioning must include provisions to 466 ensure interoperability, or at least clean failure modes. Imagine 467 someone creating a protocol and using a "version" field and 468 populating it with a value (1, let's say), but giving no information 469 about what would happen when a new version number appears in it. 470 That's bad protocol design and description; it should be clear what 471 the expectation is and how you test it. For example, stating that 472 1.X must be compatible with any version 1 code, but version 2 or 473 greater is not expected to be compatible, has different implications 474 than stating that version 1 must be a proper subset of version 2. 476 An example is ROHC (Robust Header Compression). ROHCv1 [RFC3095] 477 supports a certain set of profiles for compression algorithms. But 478 experience had shown that these profiles had limitations, so the ROHC 479 WG developed ROHCv2 [RFC5225]. A ROHCv1 implementation does not 480 contain code for the ROHCv2 profiles. As the ROHC WG charter said 481 during the development of ROHCv2: 483 It should be noted that the v2 profiles will thus not be 484 compatible with the original (ROHCv1) profiles, which means less 485 complex ROHC implementations can be realized by not providing 486 support for ROHCv1 (over links not yet supporting ROHC, or by 487 shifting out support for ROHCv1 in the long run). Profile support 488 is agreed through the ROHC channel negotiation, which is part of 489 the ROHC framework and thus not changed by ROHCv2. 491 Thus in this case both backwards-compatible and backwards- 492 incompatible deployments are possible. The important point is a 493 clearly thought out approach to the question of operational 494 compatibility. In the past, protocols have utilized a variety of 495 strategies for versioning, many of which have proven problematic. 496 These include: 498 1. No versioning support. This approach is exemplified by 499 Extensible Authentication Protocol (EAP) [RFC3748] as well as 500 Remote Authentication Dial In User Service (RADIUS) [RFC2865], 501 both of which provide no support for versioning. While lack of 502 versioning support protects against the proliferation of 503 incompatible dialects, the need for extensibility is likely to 504 assert itself in other ways, so that ignoring versioning entirely 505 may not be the most forward thinking approach. 507 2. Highest mutually supported version. In this approach, 508 implementations exchange the highest supported version, with the 509 negotiation agreeing on the highest mutually supported protocol 510 version. This approach implicitly assumes that later versions 511 provide improved functionality, and that advertisement of a higher 512 version number implies support for lower versions. Where these 513 assumptions are invalid, this approach breaks down, potentially 514 resulting in interoperability problems. An example of this issue 515 occurs in [PEAP] where implementations of higher versions may not 516 necessarily provide support for lower versions. 518 3. Assumed backward compatibility. In this approach, 519 implementations may send packets with higher version numbers to 520 legacy implementations supporting lower versions, but with the 521 assumption that the legacy implementations will interpret packets 522 with higher version numbers using the semantics and syntax defined 523 for lower versions. This is the approach taken by IEEE-802.1X 524 [IEEE-802.1X]. For this approach to work, legacy implementations 525 need to be able to accept packets of known type with higher 526 protocol versions without discarding them; protocol enhancements 527 need to permit silent discard of unsupported extensions; 528 implementations supporting higher versions need to refrain from 529 mandating new features when encountering legacy implementations. 531 4. Major/minor versioning. In this approach, implementations with 532 the same major version but a different minor version are assumed 533 to be backward compatible, but implementations are assumed to be 534 required to negotiate a mutually supported major version number. 535 This approach assumes that implementations with a lower minor 536 version number but the same major version can safely ignore 537 unsupported protocol messages. 539 5. Min/max versioning. In this approach, the client initiating 540 the connection reports the highest and lowest protocol versions it 541 understands. The server reports back the chosen protocol version: 543 a. If the server understands one or more versions in the client's 544 range, it reports back the highest mutually understood version. 546 b. If there is no mutual version, then the server reports back 547 some version that it does understand (selected as described 548 below). The connection is then typically dropped by client or 549 server, but reporting this version number first helps facilitate 550 useful error messages at the client end: 552 * If there is no mutual version, and the server speaks any 553 version higher than client max, it reports the lowest version it 554 speaks which is greater than the client max. The client can then 555 report to the user, "You need to upgrade to at least version 556 xx." 558 * Else, the server reports the highest version it speaks. The 559 client can then report to the user, "You need to request the 560 server operator to upgrade to at least version min." 562 4.2. Reserved Fields 564 Protocols commonly include one or more "reserved" fields, clearly 565 intended for future extensions. It is good practice to specify the 566 value to be inserted in such a field by the sender (typically zero) 567 and the action to be taken by the receiver when seeing some other 568 value (typically no action). If this is not done, future 569 implementation of new values in the reserved field may break old 570 software. Similarly, protocols should carefully specify how 571 receivers should react to unknown TLVs etc., such that failures occur 572 only when that is truly the desired result. 574 4.3. Encoding Formats 576 Using widely-supported encoding formats leads to better 577 interoperability and easier extensibility. An excellent example is 578 the Simple Network Management Protocol (SNMP) SMI. Guidelines exist 579 for defining the MIB objects that SNMP carries [RFC4181]. Also, 580 multiple textual conventions have been published, so that MIB 581 designers do not have to reinvent the wheel when they need a commonly 582 encountered construct. For example, the "Textual Conventions for 583 Internet Network Addresses" [RFC4001] can be used by any MIB designer 584 needing to define objects containing IP addresses, thus ensuring 585 consistency as the body of MIBs is extended. 587 5. Security Considerations 589 An extension must not introduce new security risks without also 590 providing adequate counter-measures, and in particular it must not 591 inadvertently defeat security measures in the unextended protocol. 592 Thus, the security analysis for an extension needs to be as thorough 593 as for the original protocol - effectively it needs to be a 594 regression analysis to check that the extension doesn't inadvertently 595 invalidate the original security model. 597 This analysis may be simple (e.g. adding an extra opaque data element 598 is unlikely to create a new risk) or quite complex (e.g. adding a 599 handshake to a previously stateless protocol may create a completely 600 new opportunity for an attacker). 602 6. IANA Considerations 604 This draft requires no action by IANA. 606 7. References 608 7.1. Normative References 610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 611 Requirement Levels", BCP 14, RFC 2119, March 1997. 613 [RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures 614 for Protocol Extensions and Variations", BCP 125, RFC 615 4775, December 2006. 617 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 618 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 619 May 2008. 621 7.2. Informative References 623 [I-D.ietf-radext-design] 624 Weber, G. and A. DeKok, "RADIUS Design Guidelines", 625 draft-ietf-radext-design-05.txt, Internet draft (work in 626 progress), August 2008. 628 [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local 629 and Metropolitan Area Networks: Port-Based Network Access 630 Control", IEEE Standard 802.1X-2004, December 2004. 632 [PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G. 633 and S. Josefsson, "Protected EAP Protocol (PEAP) Version 634 2", draft-josefsson-pppext-eap-tls-eap-10.txt, Expired 635 Internet draft (work in progress), October 2004. 637 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 638 text messages", STD 11, RFC 822, August 1982. 640 [RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered 641 Harmful", RFC 1263, October 1991. 643 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 644 RFC 2246, January 1999. 646 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 647 "Definition of the Differentiated Services Field (DS 648 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 649 1998. 651 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 652 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 653 RFC 2661, August 1999. 655 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",RFC 656 2671, August 1999. 658 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 659 2001. 661 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 662 "Remote Authentication Dial In User Service (RADIUS)", 663 RFC 2865, June 2000. 665 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, 666 H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., 667 Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, 668 K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust 669 Header Compression (ROHC): Framework and four profiles: 670 RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. 672 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 673 and B. Rosen, "Change Process for the Session Initiation 674 Protocol (SIP)", BCP 67, RFC 3427, December 2002. 676 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 677 Authentication Dial In User Service)", RFC 3575, July 678 2003. 680 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 681 (RR) Types", RFC 3597, September 2003. 683 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 684 Provisioning Protocol (EPP)", RFC 3735, March 2004. 686 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 687 Lefkowetz, "Extensible Authentication Protocol (EAP)", 688 RFC 3748, June 2004. 690 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 691 Schoenwaelder, "Textual Conventions for Internet Network 692 Addresses", RFC 4001, February 2005. 694 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 695 Documents", BCP 111, RFC 4181, September 2005. 697 [RFC4356] Gellens, R., "Mapping Between the Multimedia Messaging 698 Service (MMS) and Internet Mail", RFC 4356, January 2006. 700 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, 701 J., and T. Wright, "Transport Layer Security (TLS) 702 Extensions", RFC 4366, April 2006. 704 [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors 705 of Extensions to the Session Initiation Protocol (SIP)", 706 RFC 4485, May 2006. 708 [RFC4521] Zeilenga, K., "Considerations for Lightweight Directory 709 Access Protocol (LDAP) Extensions", BCP 118, RFC 4521, 710 June 2006. 712 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 713 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 715 [RFC4929] Andersson, L. and A. Farrel, "Change Process for 716 Multiprotocol Label Switching (MPLS) and Generalized MPLS 717 (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, 718 June 2007. 720 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 721 Dial In User Service (RADIUS) Implementation Issues and 722 Suggested Fixes", RFC 5080, December 2007. 724 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 725 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 726 UDP-Lite", RFC 5225, April 2008. 728 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 729 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 731 Acknowledgments 733 This document is heavily based on an earlier draft under a different 734 title by Scott Bradner and Thomas Narten. 736 That draft stated: The initial version of this document was put 737 together by the IESG in 2002. Since then, it has been reworked in 738 response to feedback from John Loughney, Henrik Levkowetz, Mark 739 Townsley, Randy Bush and others. 741 Valuable comments and suggestions on the current form of the document 742 were made by Jari Arkko, Ted Hardie, Loa Andersson, Eric Rescorla, 743 Pekka Savola, Stuart Cheshire, Leslie Daigle and Alfred Hoenes. 745 The text on TLS experience was contributed by Yngve Pettersen. 747 Appendix A. Examples 749 This section discusses some specific examples, as case studies. 751 A.1. Already documented cases 753 There are certain documents that specify a change process or describe 754 extension considerations for specific IETF protocols: 756 The SIP change process [RFC3427], [RFC4485] 757 The (G)MPLS change process (mainly procedural) [RFC4929] 758 LDAP extensions [RFC4521] 759 EPP extensions [RFC3735] 760 DNS extensions [RFC2671][RFC3597] 762 It is relatively common for MIBs, which are all in effect extensions 763 of the SMI data model, to be defined or extended outside the IETF. 764 BCP 111 [RFC4181] offers detailed guidance for authors and reviewers. 766 A.2. RADIUS Extensions 768 The RADIUS [RFC2865] protocol was designed to be extensible via 769 addition of Attributes to a Data Dictionary on the server, without 770 requiring code changes. However, this extensibility model assumed 771 that Attributes would conform to a limited set of data types and that 772 vendor extensions would be limited to use by vendors, in situations 773 in which interoperability was not required. Subsequent developments 774 have stretched those assumptions. 776 [RFC2865] Section 6.2 defines a mechanism for Vendor-Specific 777 extensions (Attribute 26), and states that use: 779 should be encouraged instead of allocation of global attribute 780 types, for functions specific only to one vendor's implementation 781 of RADIUS, where no interoperability is deemed useful. 783 However, in practice usage of Vendor-Specific Attributes (VSAs) has 784 been considerably broader than this. In particular, VSAs have been 785 used by Standards Development Organizations (SDOs) to define their 786 own extensions to the RADIUS protocol. 788 This has caused a number of problems. Since the VSA mechanism was 789 not designed for interoperability, VSAs do not contain a "mandatory" 790 bit. As a result, RADIUS clients and servers may not know whether it 791 is safe to ignore unknown attributes. For example, [RFC2865] Section 792 5 states: 794 A RADIUS server MAY ignore Attributes with an unknown Type. A 795 RADIUS client MAY ignore Attributes with an unknown Type. 797 However, in the case where the VSAs pertain to security (e.g. 798 Filters) it may not be safe to ignore them, since [RFC2865] also 799 states: 801 A NAS that does not implement a given service MUST NOT implement 802 the RADIUS attributes for that service. For example, a NAS that 803 is unable to offer ARAP service MUST NOT implement the RADIUS 804 attributes for ARAP. A NAS MUST treat a RADIUS access-accept 805 authorizing an unavailable service as an access-reject instead." 807 Detailed discussion of the issues arising from this can be found in 808 "Common Remote Authentication Dial In User Service (RADIUS) 809 Implementation Issues and Suggested Fixes" [RFC5080] Section 2.5. 811 Since it was not envisaged that multi-vendor VSA implementations 812 would need to interoperate, [RFC2865] does not define the data model 813 for VSAs, and allows multiple sub-attributes to be included within a 814 single Attribute of type 26. However, this enables VSAs to be 815 defined which would not be supportable by current implementations if 816 placed within the standard RADIUS attribute space. This has caused 817 problems in standardizing widely deployed VSAs, as discussed in 818 "RADIUS Design Guidelines" [I-D.ietf-radext-design]. 820 In addition to extending RADIUS by use of VSAs, SDOs have also 821 defined new values of the Service-Type attribute in order to create 822 new RADIUS commands. Since [RFC2865] defined Service-Type values as 823 being allocated First Come, First Served (FCFS), this essentially 824 enabled new RADIUS commands to be allocated without IETF review. 825 This oversight has since been fixed in "IANA Considerations for 826 RADIUS" [RFC3575]. 828 A.3. TLS Extensions 830 The Secure Sockets Layer (SSL) v2 protocol was developed by Netscape 831 to be used to secure online transactions on the Internet. It was 832 later replaced by SSL v3, also developed by Netscape. SSL v3 was 833 then further developed by the IETF as the Transport Layer Security 834 (TLS) protocol. 836 The SSL v3 protocol was not explicitly specified to be extended. 837 Even TLS 1.0 [RFC2246] did not define an extension mechanism 838 explicitly. However, extension "loopholes" were available. 839 Extension mechanisms were finally defined in "Transport Layer 840 Security (TLS) Extensions" [RFC4366]: 842 o New versions 843 o New cipher suites 844 o Compression 845 o Expanded handshake messages 846 o New record types 847 o New handshake messages 849 The protocol also defines how implementations should handle unknown 850 extensions. 852 Of the above extension methods, new versions and expanded handshake 853 messages have caused the most interoperability problems. 854 Implementations are supposed to ignore unknown record types but to 855 reject unknown handshake messages. 857 The new version support in SSL/TLS includes a capability to define 858 new versions of the protocol, while allowing newer implementations to 859 communicate with older implementations. As part of this 860 functionality some Key Exchange methods include functionality to 861 prevent version rollback attacks. 863 The experience with this upgrade functionality in SSL and TLS is 864 decidedly mixed. 866 o SSL v2 and SSL v3/TLS are not compatible. It is possible to use 867 SSL v2 protocol messages to initiate a SSL v3/TLS connection, but 868 it is not possible to communicate with a SSL v2 implementation 869 using SSL v3/TLS protocol messages. 870 o There are implementations that refuse to accept handshakes using 871 newer versions of the protocol than they support. 872 o There are other implementations that accept newer versions, but 873 have implemented the version rollback protection clumsily. 875 The SSL v2 problem has forced SSL v3 and TLS clients to continue to 876 use SSL v2 Client Hellos for their initial handshake with almost all 877 servers until 2006, much longer than would have been desirable, in 878 order to interoperate with old servers. 880 The problem with incorrect handling of newer versions has also forced 881 many clients to actually disable the newer protocol versions, either 882 by default, or by automatically disabling the functionality, to be 883 able to connect to such servers. Effectively, this means that the 884 version rollback protection in SSL and TLS is non-existent if talking 885 to a fatally compromised older version. 887 SSL v3 and TLS also permitted expansion of the Client Hello and 888 Server Hello handshake messages. This functionality was fully 889 defined by the introduction of TLS Extensions, which makes it 890 possible to add new functionality to the handshake, such as the name 891 of the server the client is connecting to, request certificate status 892 information, indicate Certificate Authority support, maximum record 893 length, etc. Several of these extensions also introduce new 894 handshake messages. 896 It has turned out that many SSL v3 and TLS implementations that do 897 not support TLS Extensions, did not, as specified in the protocols, 898 ignore the unknown extensions, but instead failed to establish 899 connections. Several of the implementations behaving in this manner 900 are used by high profile Internet sites, such as online banking 901 sites, and this has caused a significant delay in the deployment of 902 clients supporting TLS Extensions, and several of the clients that 903 have enabled support are using heuristics that allow them to disable 904 the functionality when they detect a problem. 906 Looking forward, the protocol version problem, in particular, can 907 cause future security problems for the TLS protocol. The strength of 908 the Digest algorithms (MD5 and SHA-1) used by SSL and and TLS is 909 weakening. If MD5 and SHA-1 weaken to the point where it is feasible 910 to mount successful attacks against older SSL and TLS versions, the 911 current error recovery used by clients would become a security 912 vulnerability (among many other serious problems for the Internet). 914 To address this issue, TLS 1.2 [RFC5246] makes use of a newer 915 cryptographic hash algorithm (SHA-256) during the TLS handshake by 916 default. Legacy ciphersuites can still be used to protect 917 application data, but new ciphersuites are specified for data 918 protection as well as for authentication within the TLS handhshake. 919 The hashing method can also be negotiated via a Hello extension. 920 Implementations are encouraged to implement new ciphersuites, and to 921 enable the negotiation of the ciphersuite used during a TLS session 922 be governed by policy, thus enabling a more rapid transition away 923 from weakened ciphersuites. 925 The lesson to be drawn from this experience is that it isn't 926 sufficient to design extensibility carefully; it must also be 927 implemented carefully by every implementer, without exception. 929 A.4. L2TP Extensions 931 Layer Two Tunneling Protocol (L2TP) [RFC2661] carries Attribute-Value 932 Pairs (AVPs), with most AVPs having no semantics to the L2TP protocol 933 itself. However, it should be noted that L2TP message types are 934 identified by a Message Type AVP (Attribute Type 0) with specific AVP 935 values indicating the actual message type. Thus, extensions relating 936 to Message Type AVPs would likely be considered major extensions. 938 L2TP also provides for Vendor-Specific AVPs. Because everything in 939 L2TP is encoded using AVPs, it would be easy to define vendor- 940 specific AVPs that would be considered major extensions. 942 L2TP also provides for a "mandatory" bit in AVPs. Recipients of L2TP 943 messages containing AVPs they do not understand but that have the 944 mandatory bit set, are expected to reject the message and terminate 945 the tunnel or session the message refers to. This leads to 946 interesting interoperability issues, because a sender can include a 947 vendor-specific AVP with the M-bit set, which then causes the 948 recipient to not interoperate with the sender. This sort of behavior 949 is counter to the IETF ideals, as implementations of the IETF 950 standard should interoperate successfully with other implementations 951 and not require the implementation of non-IETF extensions in order to 952 interoperate successfully. Section 4.2 of the L2TP specification 953 [RFC2661] includes specific wording on this point, though there was 954 significant debate at the time as to whether such language was by 955 itself sufficient. 957 Fortunately, it does not appear that the above concerns have been a 958 problem in practice. At the time of this writing, the authors are 959 unaware of the existence of vendor-specific AVPs that also set the M- 960 bit. 962 Change log [RFC Editor: please remove this section] 964 draft-carpenter-extension-rec-04: 2008-10-24. Updated author 965 addresses, fixed editorial issues. 967 draft-carpenter-extension-rec-03: 2008-10-17. Updated references, 968 added material relating to versioning. 970 draft-carpenter-extension-rec-02: 2007-06-15. Reorganized Sections 971 2 and 3. 973 draft-carpenter-extension-recs-01: 2007-03-04. Updated according to 974 comments, especially the wording about TLS, added various specific 975 examples. 977 draft-carpenter-extension-recs-00: original version, 2006-10-12. 978 Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by 979 focusing on architectural issues; the more procedural issues in that 980 draft were moved to RFC 4775. 982 Authors' Addresses 984 Brian Carpenter 985 Department of Computer Science 986 University of Auckland 987 PB 92019 988 Auckland, 1142 989 New Zealand 991 Email: brian.e.carpenter@gmail.com 993 Bernard Aboba 994 Microsoft Corporation 995 One Microsoft Way 996 Redmond, WA 98052 998 EMail: bernarda@microsoft.com 999 Phone: +1 425 706 6605 1000 Fax: +1 425 936 7329 1002 Full Copyright Statement 1004 Copyright (C) The IETF Trust (2008). 1006 This document is subject to the rights, licenses and restrictions 1007 contained in BCP 78, and except as set forth therein, the authors 1008 retain all their rights. 1010 This document and the information contained herein are provided on an 1011 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1012 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1013 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1014 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1015 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1016 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1018 Intellectual Property 1020 The IETF takes no position regarding the validity or scope of any 1021 Intellectual Property Rights or other rights that might be claimed to 1022 pertain to the implementation or use of the technology described in 1023 this document or the extent to which any license under such rights 1024 might or might not be available; nor does it represent that it has 1025 made any independent effort to identify any such rights. Information 1026 on the procedures with respect to rights in RFC documents can be 1027 found in BCP 78 and BCP 79. 1029 Copies of IPR disclosures made to the IETF Secretariat and any 1030 assurances of licenses to be made available, or the result of an 1031 attempt made to obtain a general license or permission for the use of 1032 such proprietary rights by implementers or users of this 1033 specification can be obtained from the IETF on-line IPR repository at 1034 http://www.ietf.org/ipr. 1036 The IETF invites any interested party to bring to its attention any 1037 copyrights, patents or patent applications, or other proprietary 1038 rights that may cover technology that may be required to implement 1039 this standard. Please address the information to the IETF at 1040 ietf-ipr@ietf.org. 1042 Acknowledgment 1044 Funding for the RFC Editor function is provided by the IETF 1045 Administrative Support Activity (IASA).