idnits 2.17.00 (12 Aug 2021) /tmp/idnits43557/draft-carpenter-extension-recs-02.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 929. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 940. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 947. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 953. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (12 June 2007) is 5456 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 583, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3427 (Obsoleted by RFC 5727) ** Obsolete normative reference: RFC 3546 (Obsoleted by RFC 4366) == Outdated reference: draft-andersson-rtg-gmpls-change has been published as RFC 4929 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter (ed) 3 Internet-Draft IBM 4 Intended Status: Informational B. Aboba 5 Expires: December 25, 2007 Microsoft Corporation 6 12 June 2007 8 Design Considerations for Protocol Extensions 9 draft-carpenter-extension-recs-02 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 December 25, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 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 2. Architectural Principles . . . . . . . . . . . . . . . . . . . 3 50 2.1 Limited Extensibility . . . . . . . . . . . . . . . . . . 4 51 2.2 Global Interoperability . . . . . . . . . . . . . . . . . 4 52 2.3 Protocol Variations . . . . . . . . . . . . . . . . . . . 5 53 2.4 Extension Documentation . . . . . . . . . . . . . . . . . 5 54 2.5 Testability . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.6 Parameter Registration . . . . . . . . . . . . . . . . . . 6 56 2.7 Extensions to Critical Infrastructure . . . . . . . . . . 7 57 2.8 Architectural Compatibility . . . . . . . . . . . . . . . 7 58 3. Specific Considerations for Robust Extensions . . . . . . . . 8 59 3.1. Checklist for Interoperability of Extensions . . . . . . . 8 60 3.2. When is an Extension Routine? . . . . . . . . . . . . . . 9 61 3.3. What Constitutes a Major Extension? . . . . . . . . . . . 9 62 4. Considerations for the Base Protocol . . . . . . . . . . . . . 10 63 4.1. Version Numbers . . . . . . . . . . . . . . . . . . . . . 10 64 4.2. Reserved Fields . . . . . . . . . . . . . . . . . . . . . 12 65 4.3. Encoding Formats . . . . . . . . . . . . . . . . . . . . . 12 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 72 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 16 73 A.1. Already documented cases . . . . . . . . . . . . . . . . . 16 74 A.2. RADIUS Extensions . . . . . . . . . . . . . . . . . . . . 16 75 A.3. TLS Extensions . . . . . . . . . . . . . . . . . . . . . . 17 76 A.4. L2TP Extensions . . . . . . . . . . . . . . . . . . . . . 19 77 Change log . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 79 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 21 80 Intellectual Property . . . . . . . . . . . . . . . . . . . . . . 21 81 1. Introduction 83 IETF protocols typically include mechanisms whereby they can be 84 extended in the future. It is of course a good principle to design 85 extensibility into protocols; one common definition of a successful 86 protocol is one that becomes widely used in ways not originally 87 anticipated. Well-designed extensibility mechanisms facilitate the 88 evolution of protocols and help make it easier to roll out 89 incremental changes in an interoperable fashion. 91 When an initial protocol design is extended, there is always a risk 92 of unintended consequences, such as interoperability problems or 93 security vulnerabilities. This risk is especially high if the 94 extension is performed by a different team than the original 95 designers, who may stray outside implicit design constraints or 96 assumptions. As a result, extensions should be done carefully and 97 with a full understanding of the base protocol, existing 98 implementations, and current operational practice. 100 This is hardly a recent concern. "TCP Extensions Considered Harmful" 101 [RFC1263] was published in 1991. "Extend" or "extension" occurs in 102 the title of more than 300 existing RFCs. Yet generic extension 103 considerations have not been documented previously. 105 This document describes technical considerations for protocol 106 extensions, in order to minimize such risks. It is intended to 107 assist designers of both base protocols and extensions. Formal 108 procedures for extending IETF protocols are discussed in BCP 125 109 [RFC4775]. 111 Section 2 describes architectural principles for protocol 112 extensibility. Section 3 is aimed principally at extension 113 designers, and Section 4 at base protocol designers. Nevertheless, 114 readers are advised to study the whole document, since the 115 considerations are closely linked. 117 2. Architectural Principles 119 This Section describes basic principles of protocol extensibility: 121 1. Extensibility features should be limited to what is clearly 122 necessary when the protocol is developed. 124 2. Protocol extensions should be designed for global 125 interoperability. 127 3. Protocol extension mechanisms should not be used to create 128 incompatible protocol variations. 130 4. Extension mechanisms need to be fully documented. 132 5. Extension mechanisms need to be testable. 134 6. Protocol parameters should be registered and used for their 135 intended purpose. 137 7. Extensions to critical infrastructure should not impact the 138 security or reliability of the global Internet. 140 8. Extension mechanisms should be explicitly identified and should be 141 architecturally compatible with the base protocol design. 143 2.1. Limited Extensibility 145 Protocols that permit easy extensions may have the perverse side 146 effect of making it easy to construct incompatible extensions. 147 Consequently, protocols should not be made more extensible than 148 clearly necessary at inception, and the process for defining new 149 extensibility mechanisms should ensure that adequate review of 150 proposed extensions will take place before widespread adoption. In 151 practice, this means First Come First Served [RFC2434] and similar 152 policies that allow routine extensions should be used sparingly, as 153 they imply minimal or no review. In particular, they should be 154 limited to cases, such as allowing new opaque data elements, that are 155 unlikely to cause protocol failures. 157 In order to increase the likelihood that routine extensions are truly 158 routine, protocol documents should provide guidelines explaining how 159 they should be performed. For example, even though DHCP carries 160 opaque data, defining a new option using completely unstructured data 161 may lead to an option that is (unnecessarily) hard for clients and 162 servers to process. 164 2.2. Global Interoperability 166 Global interoperability is a primary goal of IETF protocol design. 167 Experience shows that software is often used outside the particular 168 special environment it was originally intended for, so extensions 169 cannot be designed for an isolated environment. Designers of 170 extensions must assume the high likelihood of a system using the 171 extension having to interoperate with systems on the global Internet. 173 For this reason, an extension may lead to interoperability failures 174 unless the extended protocol correctly supports all mandatory and 175 optional features of the unextended base protocol, and 176 implementations of the base protocol operate correctly in the 177 presence of the extensions. 179 Consider for example a "private" extension installed on a work 180 computer which, being portable, is sometimes installed on a home 181 network or in a hotel. If the "private" extension is incompatible 182 with an unextended version of the same protocol, problems will occur. 184 2.3. Protocol Variations 186 Protocol extension mechanisms should not be used to create 187 incompatible forks in development instead. Ideally, the protocol 188 mechanisms for extension and versioning should be sufficiently well 189 described that compatibility can be assessed on paper. Otherwise, 190 when two "private" extensions encounter each other on a public 191 network, unexpected interoperability problems may occur. 193 An example of what might go wrong is misuse of the X- mail headers 194 originally defined in SMTP [RFC0822]. X-anything was a valid mail 195 header; but it had no defined meaning in the standard. Suppose a 196 mail implementation assigns specific semantics to X-anything that 197 causes it to take specific action, such as discarding a message as 198 spam. If it encounters a message from a different implementation 199 that assigns different semantics, it may take quite inappropriate 200 action, such as discarding a valid message. Thus, relying on the 201 implied semantics of an X- header automatically creates a risk of 202 operational failures. X- headers were removed from [RFC2822]. Even 203 when they are assigned semantics, as in [RFC4356], great care must be 204 taken that implementations do not rely on such semantics in messages 205 that have crossed the open Internet. 207 Thus we observe that a key requirement for interoperable extension 208 design is that the base protocol must be well designed for 209 interoperability, and that extensions must have unambiguous 210 semantics. 212 Protocol variations - specifications that look very similar to the 213 original but are actually different - are even more harmful to 214 interoperability than extensions. In general, such variations should 215 be avoided. If they cannot be avoided, as many of the following 216 considerations as possible should be applied, to minimize the damage 217 to interoperability. 219 2.4. Extension Documentation 221 Some protocol components are designed with the specific intention of 222 allowing extensibility. These should be clearly identified, with 223 specific and complete instructions on how to extend them, including 224 the process for adequate review of extension proposals: do they need 225 community review and if so how much and by whom? For example, the 226 definition of additional data elements that can be carried opaquely 227 may require no review, while the addition of new data types or new 228 protocol messages might require a Standards Track action. Guidance 229 on writing appropriate IANA Considerations text may be found in 230 [RFC2434]. 232 In a number of cases, there is a need for explicit guidance relating 233 to extensions beyond what is encapsulated in the IANA considerations 234 section of the base specification. The usefulness of [RFC4181] would 235 appear to suggest that protocols whose data model is likely to be 236 widely extended (particularly using vendor-specific elements) need a 237 Design Guidelines document specifically addressing extensions. 239 2.5. Testability 241 Experience shows that it is insufficient to correctly specify 242 extensibility and backwards compatibility in an RFC. It is also 243 important that implementations respect the compatibility mechanisms; 244 if not, non-interoperable pairs of implementations may arise. The 245 TLS case study shows how important this can be. 247 In order to determine whether protocol extension mechanisms have been 248 properly implemented, testing is required. However, for this to be 249 possible, test cases need to be developed. If a base protocol 250 document specifies extension mechanisms but does not utilize them or 251 provide examples, it may not be possible to develop test cases based 252 on the base protocol specification alone. As a result, base protocol 253 implementations may not be properly tested and non-compliant 254 extension behavior may not be detected until these implementations 255 are widely deployed. 257 To encourage correct implementation of extension mechanisms, base 258 protocol specifications should clearly articulate the expected 259 behavior of extension mechanisms and should include examples of 260 correct and incorrect extension behavior. 262 2.6. Parameter Registration 264 An extension is often likely to make use of additional values added 265 to an existing IANA registry (in many cases, simply by adding a new 266 "TLV" (type-length-value) field). To avoid conflicting usage of the 267 same value, it is essential that all new values are properly 268 registered by the applicable procedures. See BCP 26, [RFC2434] for 269 the general rules, and individual protocol RFCs, and the IANA web 270 site, for specific rules and registries. If this is not done, there 271 is nothing to prevent two different extensions picking the same 272 value. When these two extensions "meet" each other on the Internet, 273 failure is inevitable. 275 A surprisingly common case of this is misappropriation of assigned 276 TCP (or UDP) registered port numbers. This can lead to a client for 277 one service attempting to communicate with a server for another 278 service. Numerous cases could be cited, but not without embarrassing 279 specific implementors. 281 In some cases, it may be appropriate to use values designated as 282 "experimental" or "local use" in early implementations of an 283 extension. For example, [RFC4727] discusses experimental values for 284 IP and transport headers, and [RFC2474] defines experimental/local 285 use ranges for differentiated services code points. Such values 286 should be used with care and only for their stated purpose: 287 experiments and local use. They are unsuitable for Internet-wide 288 use, since they may be used for conflicting purposes and thereby 289 cause interoperability failures. Packets containing experimental or 290 local use values must not be allowed out of the domain in which they 291 are meaningful. 293 2.7. Extensions to Critical Infrastructure 295 Some protocols (such as DNS and BGP) have become critical components 296 of the Internet infrastructure. When such protocols are extended, 297 the potential exists for negatively impacting the reliability and 298 security of the global Internet. 300 As a result, special care needs to be taken with these extensions, 301 such as taking explicit steps to isolate existing uses from new ones. 302 For example, this can be accomplished by requiring the extension to 303 utilize a different port or multicast address, or by implementing the 304 extension within a separate process, without access to the data and 305 control structures of the base protocol. 307 2.8. Architectural Compatibility 309 Since protocol extension mechanisms may impact interoperability, it 310 is important that these mechanisms be architecturally compatible with 311 the base protocol. This implies that documents relying on extension 312 mechanisms need to explicitly identify them, rather than burying them 313 in the text in the hope that they will escape notice. 315 As part of the definition of new extension mechanisms, the authors 316 need to address whether the mechanisms make use of features as 317 envisaged by the original protocol designers, or whether a new 318 extension mechanism is being invented. If a new extension mechanism 319 is being invented, then architectural compatibility issues need to be 320 addressed. 322 For example, a document defining new data elements should not 323 implicitly define new data types or protocol operations without 324 explicitly describing those dependencies and discussing their impact. 326 3. Specific Considerations for Robust Extensions 328 This section makes explicit some design considerations based on the 329 community's experience with extensibility mechanisms. 331 3.1. Interoperability Checklist 333 Good interoperability stems from a number of factors, including: 335 1. Having a well-written specification. Does the specification 336 make clear what an implementor needs to support and does it define 337 the impact that individual operations (e.g. a message sent to a 338 peer) will have when invoked? 340 2. Learning lessons from deployment. This includes understanding 341 what current implementations do and how a proposed extension will 342 interact with deployed systems. Will a proposed extension (or its 343 proposed usage) operationally stress existing implementations or 344 the underlying protocol itself if widely deployed? 346 3. Having an adequate transition or coexistence story. What 347 impact will the proposed extension have on implementations that do 348 not understand it? Is there a way to negotiate or determine the 349 capabilities of a peer? Can the extended protocol negotiate with 350 an unextended partner to find a common subset of useful functions? 352 4. Respecting underlying architectural or security assumptions. 353 This includes assumptions that may not be well-documented, those 354 that may have arisen as the result of operational experience, or 355 those that only became understood after the original protocol was 356 published. For example, do the extensions reverse the flow of 357 data, allow formerly static parameters to be changed on the fly, 358 or change assumptions relating to the frequency of reads/writes? 360 5. Minimizing impact on critical infrastructure. Does the 361 proposed extension (or its proposed usage) have the potential for 362 negatively impacting critical infrastructure to the point where 363 explicit steps would be appropriate to isolate existing uses from 364 new ones? 366 6. Data model extensions. Does the proposed extension extend the 367 data model in a major way? For example, are new data types 368 defined that may require code changes within existing 369 implementations? 371 3.2. When is an Extension Routine? 373 An extension may be considered routine if it amounts to a new data 374 element of a type that is already supported within the data model, 375 and if its handling is opaque to the protocol itself (e.g. does not 376 substantially change the pattern of messages and responses). 378 For this to apply, the protocol must have been designed to carry the 379 proposed data type, so that no changes to the underlying base 380 protocol or existing implementations are needed to carry the new data 381 element. 383 Moreover, no changes are required to existing and currently deployed 384 implementations of the underlying protocol unless they want to make 385 use of the new data element. Using the existing protocol to carry a 386 new data element should not impact existing implementations or cause 387 operational problems. This typically requires that the protocol 388 silently discard unknown data elements. 390 Examples of routine extensions include the DHC vendor-specific 391 option, RADIUS Vendor-Specific Attributes compliant with [RFC2865], 392 the enterprise OID tree for MIB modules, vendor MIME types, and some 393 classes of (non-critical) certification extensions. Such extensions 394 can safely be made with minimal discussion. 396 3.3. What Constitutes a Major Extension? 398 Major extensions may have characteristics leading to a risk of 399 interoperability failure. Where these characteristics are present, 400 it is necessary to pay extremely close attention to backward 401 compatibility with implementations and deployments of the unextended 402 protocol, and to the risk of inadvertent introduction of security or 403 operational exposures. Extension designers should examine their 404 design for the following issues: 406 1. Modifications or extensions to the working of the underlying 407 protocol. This can include changing the semantics of existing 408 PDUs or defining new message types that may require implementation 409 changes in existing and deployed implementations of the protocol, 410 even if they do not want to make use of the new functions or data 411 types. A base protocol without a "silent discard" rule for 412 unknown data elements may automatically enter this category, even 413 for apparently minor extensions. 415 2. Changes to the basic architectural assumptions. This includes 416 architectural assumptions that are explicitly stated or those that 417 have been assumed by implementers. For example, this would 418 include adding a requirement for session state to a previously 419 stateless protocol. 421 3. New usage scenarios not originally intended or investigated. 422 This can potentially lead to operational difficulties when 423 deployed, even in cases where the "on-the-wire" format has not 424 changed. For example, the level of traffic carried by the 425 protocol may increase substantially, packet sizes may increase, 426 and implementation algorithms that are widely deployed may not 427 scale sufficiently or otherwise be up to the new task at hand. 428 For example, a new DNS Resource Record (RR) type that is too big 429 to fit into a single UDP packet could cause interoperability 430 problems with existing DNS clients and servers. 432 4. Considerations for the Base Protocol 434 A good extension design depends on a good base protocol. Ideally, 435 the document that defines a base protocol's extension mechanisms will 436 include guidance to future extension writers that help them use 437 extension mechanisms properly. It may also be possible to define 438 classes of extensions that need little or no review, while other 439 classes need wide review. The details will necessarily be 440 technology-specific. 442 4.1. Version Numbers 444 Any mechanism for extension by versioning must include provisions to 445 ensure interoperability, or at least clean failure modes. Imagine 446 someone creating a protocol and using a "version" field and 447 populating it with a value (1, let's say), but giving no information 448 about what would happen when a new version number appears in it. 449 That's bad protocol design and description; it should be clear what 450 the expectation is and how you test it. For example, stating that 451 1.X must be compatible with any version 1 code, but version 2 or 452 greater is not expected to be compatible, has different implications 453 than stating that version 1 must be a proper subset of version 2. 455 An example is ROHC (Robust Header Compression). ROHCv1 [RFC3095] 456 supports a certain set of profiles for compression algorithms. But 457 experience has shown that these profiles have limitations, so the 458 ROHC WG is developing ROHCv2. A ROHCv1 implementation will not 459 contain code for the ROHCv2 profiles. As the ROHC WG charter said at 460 the time of writing: 462 It should be noted that the v2 profiles will thus not be 463 compatible with the original (ROHCv1) profiles, which means less 464 complex ROHC implementations can be realized by not providing 465 support for ROHCv1 (over links not yet supporting ROHC, or by 466 shifting out support for ROHCv1 in the long run). Profile support 467 is agreed through the ROHC channel negotiation, which is part of 468 the ROHC framework and thus not changed by ROHCv2. 470 Thus in this case both backwards-compatible and backwards- 471 incompatible deployments are possible. The important point is a 472 clearly thought out approach to the question of operational 473 compatibility. In the past, protocols have utilized a variety of 474 strategies for versioning, many of which have proven problematic. 475 These include: 477 1. No versioning support. This approach is exemplified by EAP 478 [RFC3748] as well as RADIUS [RFC2865], both of which provide no 479 support for versioning. While lack of versioning support protects 480 against the proliferation of incompatible dialects, the need for 481 extensibility is likely to assert itself in other ways, so that 482 ignoring versioning entirely may not be the most forward thinking 483 approach. 485 2. Highest mutually supported version. In this approach, 486 implementations exchange the highest supported version, with the 487 negotiation agreeing on the highest mutually supported protocol 488 version. This approach implicitly assumes that later versions 489 provide improved functionality, and that advertisement of a higher 490 version number implies support for lower versions. Where these 491 assumptions are invalid, this approach breaks down, potentially 492 resulting in interoperability problems. An example of this issue 493 occurs in [PEAP] where implementations of higher versions may not 494 necessarily provide support for lower versions. 496 3. Assumed backward compatibility. In this approach, 497 implementations may send packets with higher version numbers to 498 legacy implementations supporting lower versions, but with the 499 assumption that the legacy implementations will interpret packets 500 with higher version numbers using the semantics and syntax defined 501 for lower versions. This is the approach taken by [IEEE-802.1X]. 502 For this approach to work, legacy implementations need to be able 503 to accept packets of known type with higher protocol versions 504 without discarding them; protocol enhancements need to permit 505 silent discard of unsupported extensions; implementations 506 supporting higher versions need to refrain from mandating new 507 features when encountering legacy implementations. 509 4. Major/minor versioning. In this approach, implementations with 510 the same major version but a different minor version are assumed 511 to be backward compatible, but implementations are assumed to be 512 required to negotiate a mutually supported major version number. 513 This approach assumes that implementations with a lower minor 514 version number but the same major version can safely ignore 515 unsupported protocol messages. 517 4.2. Reserved Fields 519 Protocols commonly include one or more "reserved" fields, clearly 520 intended for future extensions. It is good practice to specify the 521 value to be inserted in such a field by the sender (typically zero) 522 and the action to be taken by the receiver when seeing some other 523 value (typically no action). If this is not done, future 524 implementation of new values in the reserved field may break old 525 software. Similarly, protocols should carefully specify how 526 receivers should react to unknown TLVs etc., such that failures occur 527 only when that is truly the desired result. 529 4.3. Encoding Formats 531 Using widely-supported encoding formats leads to better 532 interoperability and easier extensibility. An excellent example is 533 the SNMP SMI. Guidelines exist for defining the MIB objects that 534 SNMP carries [RFC4181]. Also, multiple textual conventions have been 535 published, so that MIB designers do not have to reinvent the wheel 536 when they need a commonly encountered construct. For example, the 537 "Textual Conventions for Internet Network Addresses" [RFC4001] can be 538 used by any MIB designer needing to define objects containing IP 539 addresses, thus ensuring consistency as the body of MIBs is extended. 541 5. Security Considerations 543 An extension must not introduce new security risks without also 544 providing adequate counter-measures, and in particular it must not 545 inadvertently defeat security measures in the unextended protocol. 546 Thus, the security analysis for an extension needs to be as thorough 547 as for the original protocol - effectively it needs to be a 548 regression analysis to check that the extension doesn't inadvertently 549 invalidate the original security model. 551 This analysis may be simple (e.g. adding an extra opaque data element 552 is unlikely to create a new risk) or quite complex (e.g. adding a 553 handshake to a previously stateless protocol may create a completely 554 new opportunity for an attacker). 556 6. IANA Considerations 558 This draft requires no action by IANA. 560 7. Acknowledgments 562 This document is heavily based on an earlier draft under a different 563 title by Scott Bradner and Thomas Narten. 565 That draft stated: The initial version of this document was put 566 together by the IESG in 2002. Since then, it has been reworked in 567 response to feedback from John Loughney, Henrik Levkowetz, Mark 568 Townsley, Randy Bush, Bernard Aboba and others. 570 Valuable comments and suggestions on the current form of the document 571 were made by Jari Arkko, Ted Hardie, Loa Andersson, Eric Rescorla, 572 Pekka Savola, and Leslie Daigle. 574 The text on TLS experience was contributed by Yngve Pettersen. 576 8. References 578 8.1. Normative References 580 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 581 text messages", STD 11, RFC 822, August 1982. 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, March 1997. 586 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 587 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 588 October 1998. 590 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 591 "Definition of the Differentiated Services Field (DS 592 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 593 1998. 595 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",RFC 596 2671, August 1999. 598 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 599 2001. 601 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, 602 H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., 603 Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, 604 K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust 605 Header Compression (ROHC): Framework and four profiles: 606 RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. 608 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 609 and B. Rosen, "Change Process for the Session Initiation 610 Protocol (SIP)", BCP 67, RFC 3427, December 2002. 612 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, 613 J., and T. Wright, "Transport Layer Security (TLS) 614 Extensions", RFC 3546, June 2003. 616 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 617 Schoenwaelder, "Textual Conventions for Internet Network 618 Addresses", RFC 4001, February 2005. 620 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 621 Documents", BCP 111, RFC 4181, September 2005. 623 [RFC4356] Gellens, R., "Mapping Between the Multimedia Messaging 624 Service (MMS) and Internet Mail", RFC 4356, January 2006. 626 [RFC4521] Zeilenga, K., "Considerations for Lightweight Directory 627 Access Protocol (LDAP) Extensions", BCP 118, RFC 4521, 628 June 2006. 630 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 631 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 633 [RFC4775] Bradner, S., Carpenter, B., and T. Narten, "Procedures 634 for Protocol Extensions and Variations", BCP 125, RFC 635 4775, December 2006. 637 8.2. Informative References 639 [I-D.andersson-rtg-gmpls-change] 640 Andersson, L. and A. Farrel, "Change Process for 641 Multiprotocol Label Switching (MPLS) and Generalized MPLS 642 (GMPLS) Protocols and Procedures", draft-andersson-rtg- 643 gmpls-change-08 (work in progress), March 2007. 645 [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local 646 and Metropolitan Area Networks: Port-Based Network Access 647 Control", IEEE Standard 802.1X-2004, December 2004. 649 [PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G. 650 and S. Josefsson, "Protected EAP Protocol (PEAP) Version 651 2", draft-josefsson-pppext-eap-tls-eap-10.txt, Internet 652 draft (work in progress), October 2004. 654 [RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered 655 Harmful", RFC 1263, October 1991. 657 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 658 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 659 RFC 2661, August 1999. 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 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 666 Authentication Dial In User Service)", RFC 3575, July 667 2003. 669 [RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible 670 Provisioning Protocol (EPP)", RFC 3735, March 2004. 672 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 673 Lefkowetz, "Extensible Authentication Protocol (EAP)", 674 RFC 3748, June 2004. 676 [RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors 677 of Extensions to the Session Initiation Protocol (SIP)", 678 RFC 4485, May 2006. 680 Appendix A. Examples 682 This section discusses some specific examples, as case studies. 684 A.1. Already documented cases 686 There are certain documents that specify a change process or describe 687 extension considerations for specific IETF protocols: 689 The SIP change process [RFC3427], [RFC4485] 690 The (G)MPLS change process (mainly procedural) 691 [I-D.andersson-rtg-gmpls-change] 692 LDAP extensions[RFC4521] 693 EPP extensions[RFC3735] 694 DNS extensions[RFC2671] 696 It is relatively common for MIBs, which are all in effect extensions 697 of the SMI data model, to be defined or extended outside the IETF. 698 BCP 111 [RFC4181] offers detailed guidance for authors and reviewers. 700 A.2. RADIUS Extensions 702 The RADIUS [RFC2865] protocol was designed to be extensible via 703 addition of Attributes to a Data Dictionary on the server, without 704 requiring code changes. However, this extensibility model assumed 705 that Attributes would conform to a limited set of data types and that 706 vendor extensions would be limited to use by vendors, in situations 707 in which interoperability was not required. Subsequent developments 708 have stretched those assumptions. 710 [RFC2865] Section 6.2 defines a mechanism for Vendor-Specific 711 extensions (Attribute 26), and states that use: 713 should be encouraged instead of allocation of global attribute 714 types, for functions specific only to one vendor's implementation 715 of RADIUS, where no interoperability is deemed useful. 717 However, in practice usage of Vendor-Specific Attributes (VSAs) has 718 been considerably broader than this; in particular, VSAs have been 719 used by SDOs to define their extensions to the RADIUS protocol. 721 This has caused a number of problems. Since the VSA mechanism was 722 not designed for interoperability, VSAs do not contain a "mandatory" 723 bit. As a result, RADIUS clients and servers may not know whether it 724 is safe to ignore unknown attributes. For example, [RFC2865] Section 725 5 states: 727 A RADIUS server MAY ignore Attributes with an unknown Type. A 728 RADIUS client MAY ignore Attributes with an unknown Type. 730 However, in the case where the VSAs pertain to security (e.g. 731 Filters) it may not be safe to ignore them, since [RFC2865] also 732 states: 734 A NAS that does not implement a given service MUST NOT implement 735 the RADIUS attributes for that service. For example, a NAS that 736 is unable to offer ARAP service MUST NOT implement the RADIUS 737 attributes for ARAP. A NAS MUST treat a RADIUS access-accept 738 authorizing an unavailable service as an access-reject instead." 740 Since it was not envisaged that multi-vendor VSA implementations 741 would need to interoperate, [RFC2865] does not define the data model 742 for VSAs, and allows multiple sub-attributes to be included within a 743 single Attribute of type 26. However, this enables VSAs to be 744 defined which would not be supportable by current implementations if 745 placed within the standard RADIUS attribute space. This has caused 746 problems in standardizing widely deployed VSAs. 748 In addition to extending RADIUS by use of VSAs, SDOs have also 749 defined new values of the Service-Type attribute in order to create 750 new RADIUS commands. Since [RFC2865] defined Service-Type values as 751 being allocated First Come, First Served (FCFS), this essentially 752 enabled new RADIUS commands to be allocated without IETF review. 753 This oversight has since been fixed in [RFC3575]. 755 A.3. TLS Extensions 757 The Secure Sockets Layer (SSL) v2 protocol was developed by Netscape 758 to be used to secure online transactions on the Internet. It was 759 later replaced by SSL v3, also developed by Netscape. SSL v3 was 760 then further developed by the IETF as the Transport Layer Security 761 (TLS) protocol. 763 The SSL v3 protocol was not explicitly specified to be extended. 764 Even TLS 1.0 did not define an extension mechanism explicitly. 765 However, extension "loopholes" were available. Extension mechanisms 766 were finally defined in [RFC3546]: 768 o New versions 769 o New cipher suites 770 o Compression 771 o Expanded handshake messages 772 o New record types 773 o New handshake messages 775 The protocol also defines how implementations should handle unknown 776 extensions. 778 Of the above extension methods, new versions and expanded handshake 779 messages have caused the most interoperability problems. 780 Implementations are supposed to ignore unknown record types but to 781 reject unknown handshake messages. 783 The new version support in SSL/TLS includes a capability to define 784 new versions of the protocol, while allowing newer implementations to 785 communicate with older implementations. As part of this 786 functionality some Key Exchange methods include functionality to 787 prevent version rollback attacks. 789 The experience with this upgrade functionality in SSL and TLS is 790 decidedly mixed. 792 o SSL v2 and SSL v3/TLS are not compatible. It is possible to use 793 SSL v2 protocol messages to initiate a SSL v3/TLS connection, but 794 it is not possible to communicate with a SSL v2 implementation 795 using SSL v3/TLS protocol messages. 796 o There are implementations that refuse to accept handshakes using 797 newer versions of the protocol than they support. 798 o There are other implementations that accept newer versions, but 799 have implemented the version rollback protection clumsily. 801 The SSL v2 problem has forced SSL v3 and TLS clients to continue to 802 use SSL v2 Client Hellos for their initial handshake with almost all 803 servers until 2006, much longer than would have been desirable, in 804 order to interoperate with old servers. 806 The problem with incorrect handling of newer versions has also forced 807 many clients to actually disable the newer protocol versions, either 808 by default, or by automatically disabling the functionality, to be 809 able to connect to such servers. Effectively, this means that the 810 version rollback protection in SSL and TLS is non-existent if talking 811 to a fatally compromised older version. 813 SSL v3 and TLS also permitted expansion of the Client Hello and 814 Server Hello handshake messages. This functionality was fully 815 defined by the introduction of TLS Extensions, which makes it 816 possible to add new functionality to the handshake, such as the name 817 of the server the client is connecting to, request certificate status 818 information, indicate Certificate Authority support, maximum record 819 length, etc. Several of these extensions also introduces new 820 handshake messages. 822 It has turned out that many SSL v3 and TLS implementations that do 823 not support TLS Extensions, did not, as specified in the protocols, 824 ignore the unknown extensions, but instead failed to establish 825 connections. 827 Several of the implementations behaving in this manner are used by 828 high profile Internet sites, such as online banking sites, and this 829 has caused a significant delay in the deployment of clients 830 supporting TLS Extensions, and several of the clients that have 831 enabled support are using heuristics that allow them to disable the 832 functionality when they detect a problem. 834 Looking forward, the protocol version problem, in particular, can 835 cause future security problems for the TLS protocol. The strength of 836 the Digest algorithms (MD5 and SHA-1) used by SSL and and TLS is 837 weakening, and work is underway to define TLS 1.2 which will permit 838 new methods to be used in the protocol instead of the currently used 839 methods. If MD5 and SHA-1 weaken to the point where it is feasible 840 to mount successful attacks against older SSL and TLS versions, the 841 current error recovery used by clients would become a security 842 vulnerability (among many other serious problems for the Internet). 844 The lesson to be drawn from this experience is that it isn't 845 sufficient to design extensibility carefully; it must also be 846 implemented carefully by every implementer, without exception. 848 A.4. L2TP Extensions 850 L2TP [RFC2661] carries Attribute-Value Pairs (AVPs), with most AVPs 851 having no semantics to the L2TP protocol itself. However, it should 852 be noted that L2TP message types are identified by a Message Type AVP 853 (Attribute Type 0) with specific AVP values indicating the actual 854 message type. Thus, extensions relating to Message Type AVPs would 855 likely be considered major extensions. 857 L2TP also provides for Vendor-Specific AVPs. Because everything in 858 L2TP is encoded using AVPs, it would be easy to define vendor- 859 specific AVPs that would be considered major extensions. 861 L2TP also provides for a "mandatory" bit in AVPs. Recipients of L2TP 862 messages containing AVPs they do not understand but that have the 863 mandatory bit set, are expected to reject the message and terminate 864 the tunnel or session the message refers to. This leads to 865 interesting interoperability issues, because a sender can include a 866 vendor-specific AVP with the M-bit set, which then cause the 867 recipient to not interoperate with the sender. This sort of behavior 868 is counter to the IETF ideals, as implementations of the IETF 869 standard should interoperate successfully with other implementations 870 and not require the implementation of non-IETF extensions in order to 871 interoperate successfully. Section 4.2 of the L2TP specification 873 [RFC2661] includes specific wording on this point, though there was 874 significant debate at the time as to whether such language was by 875 itself sufficient. 877 Fortunately, it does not appear that the above concerns have been a 878 problem in practice. At the time of this writing, the authors are 879 unaware of the existence of vendor-specific AVPs that also set the M- 880 bit. 882 Change log [RFC Editor: please remove this section] 884 draft-carpenter-extension-rec-02: 2007-06-15. Reorganized Sections 885 2 and 3. 887 draft-carpenter-extension-recs-01: 2007-03-04. Updated according to 888 comments, especially the wording about TLS, added various specific 889 examples. 891 draft-carpenter-extension-recs-00: original version, 2006-10-12. 892 Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by 893 focusing on architectural issues; the more procedural issues in that 894 draft were moved to RFC 4775. 896 Authors' Addresses 898 Brian Carpenter 899 IBM 900 8 Chemin de Blandonnet 901 1214 Vernier, 902 Switzerland 904 Email: brian.e.carpenter@gmail.com 906 Bernard Aboba 907 Microsoft Corporation 908 One Microsoft Way 909 Redmond, WA 98052 911 EMail: bernarda@microsoft.com 912 Phone: +1 425 706 6605 913 Fax: +1 425 936 7329 915 Full Copyright Statement 917 Copyright (C) The IETF Trust (2007). 919 This document is subject to the rights, licenses and restrictions 920 contained in BCP 78, and except as set forth therein, the authors 921 retain all their rights. 923 This document and the information contained herein are provided on an 924 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 925 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 926 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 927 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 928 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 929 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 931 Intellectual Property 933 The IETF takes no position regarding the validity or scope of any 934 Intellectual Property Rights or other rights that might be claimed to 935 pertain to the implementation or use of the technology described in 936 this document or the extent to which any license under such rights 937 might or might not be available; nor does it represent that it has 938 made any independent effort to identify any such rights. Information 939 on the procedures with respect to rights in RFC documents can be 940 found in BCP 78 and BCP 79. 942 Copies of IPR disclosures made to the IETF Secretariat and any 943 assurances of licenses to be made available, or the result of an 944 attempt made to obtain a general license or permission for the use of 945 such proprietary rights by implementers or users of this 946 specification can be obtained from the IETF on-line IPR repository at 947 http://www.ietf.org/ipr. 949 The IETF invites any interested party to bring to its attention any 950 copyrights, patents or patent applications, or other proprietary 951 rights that may cover technology that may be required to implement 952 this standard. Please address the information to the IETF at ietf- 953 ipr@ietf.org. 955 Acknowledgment 957 Funding for the RFC Editor function is provided by the IETF 958 Administrative Support Activity (IASA).