idnits 2.17.1 draft-iab-use-it-or-lose-it-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 August 2021) is 973 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TLS' is mentioned on line 635, but not defined == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-18 == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-messaging-18 -- Obsolete informational reference (is this intentional?): RFC 6824 (ref. 'MPTCP') (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 988 (Obsoleted by RFC 1054, RFC 1112) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS12') (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Informational T. Pauly 5 Expires: 25 February 2022 Apple 6 24 August 2021 8 Long-term Viability of Protocol Extension Mechanisms 9 draft-iab-use-it-or-lose-it-02 11 Abstract 13 The ability to change protocols depends on exercising the extension 14 and version negotiation mechanisms that support change. This 15 document explores how regular use of new protocol features can ensure 16 that it remains possible to deploy changes to a protocol. Examples 17 are given where lack of use caused changes to be more difficult or 18 costly. 20 Discussion Venues 22 This note is to be removed before publishing as an RFC. 24 Discussion of this document takes place on the EDM Program mailing 25 list (edm@iab.org), which is archived at 26 https://mailarchive.ietf.org/arch/browse/edm/. 28 Source for this draft and an issue tracker can be found at 29 https://github.com/intarchboard/use-it-or-lose-it. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 25 February 2022. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Imperfect Implementations Limit Protocol Evolution . . . . . 3 66 2.1. Good Protocol Design is Not Itself Sufficient . . . . . . 4 67 2.2. Disuse Can Hide Problems . . . . . . . . . . . . . . . . 5 68 2.3. Multi-Party Interactions and Middleboxes . . . . . . . . 5 69 3. Active Use . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1. Dependency is Better . . . . . . . . . . . . . . . . . . 6 71 3.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 7 72 3.3. Falsifying Active Use . . . . . . . . . . . . . . . . . . 8 73 3.4. Examples of Active Use . . . . . . . . . . . . . . . . . 9 74 3.5. Restoring Active Use . . . . . . . . . . . . . . . . . . 10 75 4. Complementary Techniques . . . . . . . . . . . . . . . . . . 10 76 4.1. Fewer Extension Points . . . . . . . . . . . . . . . . . 10 77 4.2. Invariants . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.3. Limiting Participation . . . . . . . . . . . . . . . . . 11 79 4.4. Effective Feedback . . . . . . . . . . . . . . . . . . . 12 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 7. Informative References . . . . . . . . . . . . . . . . . . . 13 83 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17 84 A.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 A.2. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 A.3. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 A.4. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 A.5. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 A.6. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 A successful protocol [SUCCESS] needs to change in ways that allow it 96 to continue to fulfill the changing needs of its users. New use 97 cases, conditions and constraints on the deployment of a protocol can 98 render a protocol that does not change obsolete. 100 Usage patterns and requirements for a protocol shift over time. In 101 response, implementations might adjust usage patterns within the 102 constraints of the protocol, the protocol could be extended, or a 103 replacement protocol might be developed. Experience with Internet- 104 scale protocol deployment shows that each option comes with different 105 costs. [TRANSITIONS] examines the problem of protocol evolution more 106 broadly. 108 An extension point is a mechanism that allows a protocol to be 109 changed or enhanced. This document examines the specific conditions 110 that determine whether protocol maintainers have the ability to 111 design and deploy new or modified protocols via their specified 112 extension points. Section 2 highlights some historical examples of 113 difficulties in transitions to new protocol features. Section 3 114 argues that ossified protocols are more difficult to update and 115 describes how successful protocols make frequent use of new 116 extensions and code-points. Section 4 outlines several additional 117 strategies that might aid in ensuring that protocol changes remain 118 possible over time. 120 The experience that informs this document is predominantly at 121 "higher" layers of the network stack, in protocols that operate at 122 very large scale and Internet-scale applications. It is possible 123 that these conclusions are less applicable to protocol deployments 124 that have less scale and diversity, or operate under different 125 constraints. 127 2. Imperfect Implementations Limit Protocol Evolution 129 It can be extremely difficult to deploy a change to a protocol if 130 implementations with which the new deployment needs to interoperate 131 do not operate predictably. Variation in how new codepoints or 132 extensions are handled can be the result of bugs in implementation or 133 specifications. Unpredictability can manifest as abrupt termination 134 of sessions, errors, crashes, or disappearances of endpoints and 135 timeouts. 137 The risk of interoperability problems can in turn make it infeasible 138 to deploy certain protocol changes. If deploying a new codepoint or 139 extension makes an implementation less reliable than others, even if 140 only in rare cases, it is far less likely that implementations will 141 adopt the change. 143 Deploying a change to a protocol could require implementations to fix 144 a substantial proportion of the bugs that the change exposes. This 145 can involve a difficult process that includes identifying the cause 146 of these errors, finding the responsible implementation(s), 147 coordinating a bug fix and release plan, contacting users and/or the 148 operator of affected services, and waiting for the fix to be 149 deployed. 151 Given the effort involved in fixing problems, the existence of these 152 sorts of bugs can outright prevent the deployment of some types of 153 protocol changes, especially for protocols involving multiple parties 154 or that are considered critical infrastructure (e.g., IP, BGP, DNS, 155 or TLS). It could even be necessary to come up with a new protocol 156 design that uses a different method to achieve the same result. 158 This document largely assumes that extensions are not deliberately 159 blocked. Some deployments or implementations apply policies that 160 explicitly prohibit the use of unknown capabilities. This is 161 especially true of functions that seek to make security guarantees, 162 like firewalls. 164 The set of interoperable features in a protocol is often the subset 165 of its features that have some value to those implementing and 166 deploying the protocol. It is not always the case that future 167 extensibility is in that set. 169 2.1. Good Protocol Design is Not Itself Sufficient 171 It is often argued that the careful design of a protocol extension 172 point or version negotiation capability is critical to the freedom 173 that it ultimately offers. 175 RFC 6709 [EXTENSIBILITY] contains a great deal of well-considered 176 advice on designing for extension. It includes the following advice: 178 This means that, to be useful, a protocol version-negotiation 179 mechanism should be simple enough that it can reasonably be 180 assumed that all the implementers of the first protocol version at 181 least managed to implement the version-negotiation mechanism 182 correctly. 184 There are a number of protocols for which this has proven to be 185 insufficient in practice. These protocols have imperfect 186 implementations of these mechanisms. Mechanisms that aren't used are 187 the ones that fail most often. The same paragraph from RFC 6709 188 acknowledges the existence of this problem, but does not offer any 189 remedy: 191 The nature of protocol version-negotiation mechanisms is that, by 192 definition, they don't get widespread real-world testing until 193 _after_ the base protocol has been deployed for a while, and its 194 deficiencies have become evident. 196 Indeed, basic interoperability is considered critical early in the 197 deployment of a protocol. A desire to deploy can result in early 198 focus on a reduced feature set, which could result in deferring 199 implementation of version negotiation and extension mechanisms. This 200 leads to these mechanisms being particularly affected by this 201 problem. 203 2.2. Disuse Can Hide Problems 205 There are many examples of extension points in protocols that have 206 been either completely unused, or their use was so infrequent that 207 they could no longer be relied upon to function correctly. 209 Appendix A includes examples of disuse in a number of widely deployed 210 Internet protocols. 212 Even where extension points have multiple valid values, if the set of 213 permitted values does not change over time, there is still a risk 214 that new values are not tolerated by existing implementations. If 215 the set of values for a particular field or the order in which these 216 values appear of a protocol remains fixed over a long period, some 217 implementations might not correctly handle a new value when it is 218 introduced. For example, implementations of TLS broke when new 219 values of the signature_algorithms extension were introduced. 221 2.3. Multi-Party Interactions and Middleboxes 223 One of the key challenges in deploying new features is ensuring 224 compatibility with all actors that could be involved in the protocol. 225 Even the most superficially simple protocols can often involve more 226 actors than is immediately apparent. Even for a two-party protocol, 227 protocol elements can be passed on to other entities in ways that can 228 affect protocol operation. 230 Protocols that are intermediated need to consider the effect that 231 deploying an extension might have on a middlebox. 233 3. Active Use 235 The design of a protocol for extensibility and eventual replacement 236 [EXTENSIBILITY] does not guarantee the ability to exercise those 237 options. The set of features that enable future evolution need to be 238 interoperable in the first implementations and deployments of the 239 protocol. Implementation of mechanisms that support evolution is 240 necessary to ensure that they remain available for new uses, and 241 history has shown this occurs almost exclusively through active 242 mechanism use. 244 Only by using the extension capabilities of a protocol is the 245 availability of that capability assured. "Using" here includes 246 specifying, implementing, and deploying capabilities that rely on the 247 extension capability. Protocols that fail to use a mechanism, or a 248 protocol that only rarely uses a mechanism, could lead to that 249 mechanism being unreliable. 251 Implementations that routinely see new values are more likely to 252 correctly handle new values. More frequent changes will improve the 253 likelihood that incorrect handling or intolerance is discovered and 254 rectified. The longer an intolerant implementation is deployed, the 255 more difficult it is to correct. 257 Protocols that routinely add new extensions and code points rarely 258 have trouble adding additional ones, especially when the handling of 259 new versions or extensions are well defined. The definition of 260 mechanisms alone is insufficient; it is the assured implementation 261 and active use of those mechanisms that determines their 262 availability. 264 What constitutes "active use" can depend greatly on the environment 265 in which a protocol is deployed. The frequency of changes necessary 266 to safeguard some mechanisms might be slow enough to attract 267 ossification in another protocol deployment, while being excessive in 268 others. 270 3.1. Dependency is Better 272 The easiest way to guarantee that a protocol mechanism is used is to 273 make the handling of it critical to an endpoint participating in that 274 protocol. This means that implementations must rely on both the 275 existence of extension mechanisms and their continued, repeated 276 expansion over time. 278 For example, the message format in SMTP relies on header fields for 279 most of its functions, including the most basic delivery functions. 280 A deployment of SMTP cannot avoid including an implementation of 281 header field handling. In addition to this, the regularity with 282 which new header fields are defined and used ensures that deployments 283 frequently encounter header fields that they do not yet (and may 284 never) understand. An SMTP implementation therefore needs to be able 285 to both process header fields that it understands and ignore those 286 that it does not. 288 In this way, implementing the extensibility mechanism is not merely 289 mandated by the specification, it is crucial to the functioning of a 290 protocol deployment. Should an implementation fail to correctly 291 implement the mechanism, that failure would quickly become apparent. 293 Caution is advised to avoid assuming that building a dependency on an 294 extension mechanism is sufficient to ensure availability of that 295 mechanism in the long term. If the set of possible uses is narrowly 296 constrained and deployments do not change over time, implementations 297 might not see new variations or assume a narrower interpretation of 298 what is possible. Those implementations might still exhibit errors 299 when presented with new variations. 301 3.2. Version Negotiation 303 As noted in Section 2.1, protocols that provide version negotiation 304 mechanisms might not be able to test that feature until a new version 305 is deployed. One relatively successful design approach has been to 306 use the protocol selection mechanisms built into a lower-layer 307 protocol to select the protocol. This could allow a version 308 negotiation mechanism to benefit from active use of the extension 309 point by other protocols. 311 For instance, all published versions of IP contain a version number 312 as the four high bits of the first header byte. However, version 313 selection using this field proved to be unsuccessful. Ultimately, 314 successful deployment of IPv6 over Ethernet [RFC2464] required a 315 different EtherType from IPv4. This change took advantage of the 316 already-diverse usage of EtherType. 318 Other examples of this style of design include Application-Layer 319 Protocol Negotiation ([ALPN]) and HTTP content negotiation 320 (Section 12 of [HTTP]). 322 This technique relies on the codepoint being usable. For instance, 323 the IP protocol number is known to be unreliable and therefore not 324 suitable [NEW-PROTOCOLS]. 326 3.3. Falsifying Active Use 328 "Grease" was originally defined for TLS [GREASE], but has been 329 adopted by other protocols, such as QUIC [QUIC]. Grease identifies 330 lack of use as an issue (protocol mechanisms "rusting" shut) and 331 proposes reserving values for extensions that have no semantic value 332 attached. 334 The design in [GREASE] is aimed at the style of negotiation most used 335 in TLS, where one endpoint offers a set of options and the other 336 chooses the one that it most prefers from those that it supports. An 337 endpoint that uses grease randomly offers options - usually just one 338 - from a set of reserved values. These values are guaranteed to 339 never be assigned real meaning, so its peer will never have cause to 340 genuinely select one of these values. 342 More generally, greasing is used to refer to any attempt to exercise 343 extension points without changing endpoint behavior, other than to 344 encourage participants to tolerate new or varying values of protocol 345 elements. 347 The principle that grease operates on is that an implementation that 348 is regularly exposed to unknown values is less likely to be 349 intolerant of new values when they appear. This depends largely on 350 the assumption that the difficulty of implementing the extension 351 mechanism correctly is as easy or easier than implementing code to 352 identify and filter out reserved values. Reserving random or 353 unevenly distributed values for this purpose is thought to further 354 discourage special treatment. 356 Without reserved greasing codepoints, an implementation can use code 357 points from spaces used for private or experimental use if such a 358 range exists. In addition to the risk of triggering participation in 359 an unwanted experiment, this can be less effective. Incorrect 360 implementations might still be able to identify these code points and 361 ignore them. 363 In addition to advertising bogus capabilities, an endpoint might also 364 selectively disable non-critical protocol elements to test the 365 ability of peers to handle the absence of certain capabilities. 367 This style of defensive design is limited because it is only 368 superficial. As greasing only mimics active use of an extension 369 point, it only exercises a small part of the mechanisms that support 370 extensibility. More critically, it does not easily translate to all 371 forms of extension points. For instance, HMSV negotiation cannot be 372 greased in this fashion. Other techniques might be necessary for 373 protocols that don't rely on the particular style of exchange that is 374 predominant in TLS. 376 Grease is deployed with the intent of quickly revealing errors in 377 implementing the mechanisms it safeguards. Though it has been 378 effective at revealing problems in some cases with TLS, the efficacy 379 of greasing isn't proven more generally. Where implementations are 380 able to tolerate a non-zero error rate in their operation, greasing 381 offers a potential option for safeguarding future extensibility. 382 However, this relies on there being a sufficient proportion of 383 participants that are willing to invest the effort and tolerate the 384 risk of interoperability failures. 386 3.4. Examples of Active Use 388 Header fields in email [SMTP], HTTP [HTTP] and SIP [SIP] all derive 389 from the same basic design, which amounts to a list name/value pairs. 390 There is no evidence of significant barriers to deploying header 391 fields with new names and semantics in email and HTTP as clients and 392 servers generally ignore headers they do not understand or need. The 393 widespread deployment of SIP B2BUAs, which generally do not ignore 394 unknown fields, means that new SIP header fields do not reliably 395 reach peers. This does not necessarily cause interoperability issues 396 in SIP but rather causes features to remain unavailable until the 397 B2BUA is updated. All three protocols are still able to deploy new 398 features reliably, but SIP features are deployed more slowly due to 399 the larger number of active participants that need to support new 400 features. 402 As another example, the attribute-value pairs (AVPs) in Diameter 403 [DIAMETER] are fundamental to the design of the protocol. Any use of 404 Diameter requires exercising the ability to add new AVPs. This is 405 routinely done without fear that the new feature might not be 406 successfully deployed. 408 These examples show extension points that are heavily used are also 409 being relatively unaffected by deployment issues preventing addition 410 of new values for new use cases. 412 These examples show that a good design is not required for success. 413 On the contrary, success is often despite shortcomings in the design. 414 For instance, the shortcomings of HTTP header fields are significant 415 enough that there are ongoing efforts to improve the syntax 416 [HTTP-HEADERS]. 418 3.5. Restoring Active Use 420 With enough effort, active use can be used to restore capabililities. 422 EDNS [EDNS] was defined to provide extensibility in DNS. Intolerance 423 of the extension in DNS servers resulted in a fallback method being 424 widely deployed (see Section 6.2.2 of [EDNS]). This fallback 425 resulted in EDNS being disabled for affected servers. Over time, 426 greater support for EDNS and increased reliance on it for different 427 features motivated a flag day [DNSFLAGDAY] where the workaround was 428 removed. 430 The EDNS example shows that effort can be used to restore 431 capabilities. This is in part because EDNS was actively used with 432 most resolvers and servers. It was therefore possible to force a 433 change to ensure that extension capabilities would always be 434 available. However, this required an enormous coordination effort. 435 A small number of incompatible servers and the names they serve also 436 became inaccessible to most clients. 438 4. Complementary Techniques 440 The protections to protocol evolution that come from active use 441 (Section 3) can be improved through the use of other defensive 442 techniques. The techniques listed here might not prevent 443 ossification on their own, but can make active use more effective. 445 4.1. Fewer Extension Points 447 A successful protocol will include many potential types of extension. 448 Designing multiple types of extension mechanism, each suited to a 449 specific purpose, might leave some extension points less heavily used 450 than others. 452 Disuse of a specialized extension point might render it unusable. In 453 contrast, having a smaller number of extension points with wide 454 applicability could improve the use of those extension points. Use 455 of a shared extension point for any purpose can protect rarer or more 456 specialized uses. 458 Both extensions and core protocol elements use the same extension 459 points in protocols like HTTP [HTTP] and DIAMETER [DIAMETER]; see 460 Section 3.4. 462 4.2. Invariants 464 Documenting aspects of the protocol that cannot or will not change as 465 extensions or new versions are added can be a useful exercise. 466 Section 2.2 of [RFC5704] defines invariants as: 468 Invariants are core properties that are consistent across the 469 network and do not change over extremely long time-scales. 471 Understanding what aspects of a protocol are invariant can help guide 472 the process of identifying those parts of the protocol that might 473 change. [QUIC-INVARIANTS] and Section 9.3 of [TLS13] are both 474 examples of documented invariants. 476 As a means of protecting extensibility, a declaration of protocol 477 invariants is useful only to the extent that protocol participants 478 are willing to allow new uses for the protocol. A protocol that 479 declares protocol invariants relies on implementations understanding 480 and respecting those invariants. If active use is not possible for 481 all non-invariant parts of the protocol, greasing (Section 3.3) might 482 be used to improve the chance that invariants are respected. 484 Protocol invariants need to be clearly and concisely documented. 485 Including examples of aspects of the protocol that are not invariant, 486 such as Appendix A of [QUIC-INVARIANTS], can be used to clarify 487 intent. 489 4.3. Limiting Participation 491 Reducing the number of entities that can participate in a protocol or 492 limiting the extent of participation can reduce the number of 493 entities that might affect extensibility. Using TLS or other 494 cryptographic tools can therefore reduce the number of entities that 495 can influence whether new features are usable. 497 [PATH-SIGNALS] also recommends the use of encryption and integrity 498 protection to limit participation. For example, encryption is used 499 by the QUIC protocol [QUIC] to limit the information that is 500 available to middleboxes and integrity protection prevents 501 modification. 503 4.4. Effective Feedback 505 While not a direct means of protecting extensibility mechanisms, 506 feedback systems can be important to discovering problems. 508 Visibility of errors is critical to the success of techniques like 509 grease (see Section 3.3). The grease design is most effective if a 510 deployment has a means of detecting and reporting errors. Ignoring 511 errors could allow problems to become entrenched. 513 Feedback on errors is more important during the development and early 514 deployment of a change. It might also be helpful to disable 515 automatic error recovery methods during development. 517 Automated feedback systems are important for automated systems, or 518 where error recovery is also automated. For instance, connection 519 failures with HTTP alternative services [ALT-SVC] are not permitted 520 to affect the outcome of transactions. An automated feedback system 521 for capturing failures in alternative services is therefore necessary 522 for failures to be detected. 524 How errors are gathered and reported will depend greatly on the 525 nature of the protocol deployment and the entity that receives the 526 report. For instance, end users, developers, and network operations 527 each have different requirements for how error reports are created, 528 managed, and acted upon. 530 Automated delivery of error reports can be critical for rectifying 531 deployment errors as early as possible, such as seen in [DMARC] and 532 [SMTP-TLS-Reporting]. 534 5. Security Considerations 536 Many of the problems identified in this document are not the result 537 of deliberate actions by an adversary, but more the result of 538 mistakes, decisions made without sufficient context, or simple 539 neglect. Problems therefore not the result of opposition by an 540 adversary. In response, the recommended measures generally assume 541 that other protocol participants will not take deliberate action to 542 prevent protocol evolution. 544 The use of cryptographic techniques to exclude potential participants 545 is the only strong measure that the document recommends. However, 546 authorized protocol peers are most often responsible for the 547 identified problems, which can mean that cryptography is insufficient 548 to exclude them. 550 The ability to design, implement, and deploy new protocol mechanisms 551 can be critical to security. In particular, it is important to be 552 able to replace cryptographic algorithms over time [AGILITY]. For 553 example, preparing for replacement of weak hash algorithms was made 554 more difficult through misuse [HASH]. 556 6. IANA Considerations 558 This document makes no request of IANA. 560 7. Informative References 562 [AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm 563 Agility and Selecting Mandatory-to-Implement Algorithms", 564 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 565 . 567 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 568 "Transport Layer Security (TLS) Application-Layer Protocol 569 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 570 July 2014, . 572 [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 573 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 574 April 2016, . 576 [DIAMETER] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 577 Ed., "Diameter Base Protocol", RFC 6733, 578 DOI 10.17487/RFC6733, October 2012, 579 . 581 [DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 582 Message Authentication, Reporting, and Conformance 583 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 584 . 586 [DNSFLAGDAY] 587 "DNS Flag Day 2019", May 2019, 588 . 590 [EDNS] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 591 for DNS (EDNS(0))", STD 75, RFC 6891, 592 DOI 10.17487/RFC6891, April 2013, 593 . 595 [EXT-TCP] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., 596 Handley, M., and H. Tokuda, "Is it still possible to 597 extend TCP?", Proceedings of the 2011 ACM SIGCOMM 598 conference on Internet measurement conference - IMC '11, 599 DOI 10.1145/2068816.2068834, 2011, 600 . 602 [EXTENSIBILITY] 603 Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 604 Considerations for Protocol Extensions", RFC 6709, 605 DOI 10.17487/RFC6709, September 2012, 606 . 608 [GREASE] Benjamin, D., "Applying Generate Random Extensions And 609 Sustain Extensibility (GREASE) to TLS Extensibility", 610 RFC 8701, DOI 10.17487/RFC8701, January 2020, 611 . 613 [HASH] Bellovin, S. and E. Rescorla, "Deploying a New Hash 614 Algorithm", Proceedings of NDSS '06 , 2006, 615 . 617 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 618 Semantics", Work in Progress, Internet-Draft, draft-ietf- 619 httpbis-semantics-18, 18 August 2021, 620 . 623 [HTTP-HEADERS] 624 Nottingham, M. and P-H. Kamp, "Structured Field Values for 625 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, 626 . 628 [HTTP11] Fielding, R. T., Nottingham, M., and J. Reschke, 629 "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- 630 httpbis-messaging-18, 18 August 2021, 631 . 634 [INTOLERANCE] 635 Kario, H., "Re: [TLS] Thoughts on Version Intolerance", 20 636 July 2016, . 639 [MPTCP] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 640 "TCP Extensions for Multipath Operation with Multiple 641 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 642 . 644 [MPTCP-HOW-HARD] 645 Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M., 646 Duchene, F., Bonaventure, O., and M. Handley, "How Hard 647 Can It Be? Designing and Implementing a Deployable 648 Multipath TCP", April 2012, 649 . 652 [NEW-PROTOCOLS] 653 Barik, R., Welzl, M., Fairhurst, G., Elmokashfi, A., 654 Dreibholz, T., and S. Gjessing, "On the usability of 655 transport protocols other than TCP: A home gateway and 656 internet path traversal study", Computer Networks Vol. 657 173, pp. 107211, DOI 10.1016/j.comnet.2020.107211, May 658 2020, . 660 [PATH-SIGNALS] 661 Hardie, T., Ed., "Transport Protocol Path Signals", 662 RFC 8558, DOI 10.17487/RFC8558, April 2019, 663 . 665 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 666 Multiplexed and Secure Transport", RFC 9000, 667 DOI 10.17487/RFC9000, May 2021, 668 . 670 [QUIC-INVARIANTS] 671 Thomson, M., "Version-Independent Properties of QUIC", 672 RFC 8999, DOI 10.17487/RFC8999, May 2021, 673 . 675 [RAv4] Katz, D., "IP Router Alert Option", RFC 2113, 676 DOI 10.17487/RFC2113, February 1997, 677 . 679 [RAv6] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 680 RFC 2711, DOI 10.17487/RFC2711, October 1999, 681 . 683 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 684 DOI 10.17487/RFC0791, September 1981, 685 . 687 [RFC0988] Deering, S., "Host extensions for IP multicasting", 688 RFC 988, DOI 10.17487/RFC0988, July 1986, 689 . 691 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 692 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 693 . 695 [RFC5704] Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated 696 Protocol Development Considered Harmful", RFC 5704, 697 DOI 10.17487/RFC5704, November 2009, 698 . 700 [RRTYPE] Gustafsson, A., "Handling of Unknown DNS Resource Record 701 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 702 2003, . 704 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 705 A., Peterson, J., Sparks, R., Handley, M., and E. 706 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 707 DOI 10.17487/RFC3261, June 2002, 708 . 710 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 711 DOI 10.17487/RFC5321, October 2008, 712 . 714 [SMTP-TLS-Reporting] 715 Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J., 716 and M. Risher, "SMTP TLS Reporting", RFC 8460, 717 DOI 10.17487/RFC8460, September 2018, 718 . 720 [SNI] Langley, A., "Accepting that other SNI name types will 721 never work", 3 March 2016, 722 . 725 [SNMPv1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 726 "Simple Network Management Protocol (SNMP)", RFC 1157, 727 DOI 10.17487/RFC1157, May 1990, 728 . 730 [SPF] Kitterman, S., "Sender Policy Framework (SPF) for 731 Authorizing Use of Domains in Email, Version 1", RFC 7208, 732 DOI 10.17487/RFC7208, April 2014, 733 . 735 [SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful 736 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 737 . 739 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 740 RFC 793, DOI 10.17487/RFC0793, September 1981, 741 . 743 [TFO] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 744 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 745 . 747 [TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS) 748 Extensions: Extension Definitions", RFC 6066, 749 DOI 10.17487/RFC6066, January 2011, 750 . 752 [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security 753 (TLS) Protocol Version 1.2", RFC 5246, 754 DOI 10.17487/RFC5246, August 2008, 755 . 757 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 758 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 759 . 761 [TRANSITIONS] 762 Thaler, D., Ed., "Planning for Protocol Adoption and 763 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 764 May 2017, . 766 Appendix A. Examples 768 This appendix contains a brief study of problems in a range of 769 Internet protocols at different layers of the stack. 771 A.1. DNS 773 Ossified DNS code bases and systems resulted in new Resource Record 774 Codes (RRCodes) being unusable. A new codepoint would take years of 775 coordination between implementations and deployments before it could 776 be relied upon. Consequently, overloading use of the TXT record was 777 used to avoid effort and delays involved, a method used in the Sender 778 Policy Framework [SPF] and other protocols. 780 It was not until after the standard mechanism for dealing with new 781 RRCodes [RRTYPE] was considered widely deployed that new RRCodes can 782 be safely created and used. 784 A.2. HTTP 786 HTTP has a number of very effective extension points in addition to 787 the aforementioned header fields. It also has some examples of 788 extension points that are so rarely used that it is possible that 789 they are not at all usable. 791 Extension points in HTTP that might be unwise to use include the 792 extension point on each chunk in the chunked transfer coding 793 Section 7.1 of [HTTP11], the ability to use transfer codings other 794 than the chunked coding, and the range unit in a range request 795 Section 14 of [HTTP]. 797 A.3. IP 799 The version field in IP was rendered useless when encapsulated over 800 Ethernet, requring a new ethertype with IPv6 [RFC2464], due in part 801 to layer 2 devices making version-independent assumptions about the 802 structure of the IPv4 header. 804 Protocol identifiers or codepoints that are reserved for future use 805 can be especially problematic. Reserving values without attributing 806 semantics to their use can result in diverse or conflicting semantics 807 being attributed without any hope of interoperability. An example of 808 this is the 224/3 "class E" address space in IPv4 [RFC0988]. This 809 space was originally reserved in [RFC0791] without assigning any 810 semantics and has since been partially reclaimed for use in multicast 811 (224/4), but otherwise has not been successfully reclaimed for any 812 purpose (240/4) [RFC0988]. 814 For protocols that can use negotiation to attribute semantics to 815 values, it is possible that unused codepoints can be reclaimed for 816 active use, though this requires that the negotiation include all 817 protocol participants. For something as fundamental as addressing, 818 negotiation is difficult or even impossible, as all nodes on the 819 network path plus potential alternative paths would need to be 820 involved. 822 IP Router Alerts [RAv4][RAv6] use IP options or extension headers to 823 indicate that data is intended for consumption by the next hop router 824 rather than the addressed destination. In part, the deployment of 825 router alerts was unsuccessful due to the realities of processing IP 826 packets at line rates, combined with bad assumptions in the protocol 827 design about these performance constraints. However, this was not 828 exclusively down to design problems or bugs as the capability was 829 also deliberately blocked at some routers. 831 A.4. SNMP 833 As a counter example, the first version of the Simple Network 834 Management Protocol (SNMP) [SNMPv1] defines that unparseable or 835 unauthenticated messages are simply discarded without response: 837 It then verifies the version number of the SNMP message. If there 838 is a mismatch, it discards the datagram and performs no further 839 actions. 841 When SNMP versions 2, 2c and 3 came along, older agents did exactly 842 what the protocol specifies. Deployment of new versions was likely 843 successful because the handling of newer versions was both clear and 844 simple. 846 A.5. TCP 848 Extension points in TCP [TCP] have been rendered difficult to use, 849 largely due to middlebox interactions; see [EXT-TCP]. 851 For instance, multipath TCP [MPTCP] can only be deployed 852 opportunistically; see [MPTCP-HOW-HARD]. As multipath TCP enables 853 progressive enhancement of the protocol, this largely only causes the 854 feature to not be available if the path is intolerant of the 855 extension. 857 In comparison, the deployment of Fast Open [TFO] critically depends 858 on extension capability being widely available. Though very few 859 network paths were intolerant of the extension in absolute terms, TCP 860 Fast Open could not be deployed as a result. 862 A.6. TLS 864 Transport Layer Security (TLS) [TLS12] provides examples of where a 865 design that is objectively sound fails when incorrectly implemented. 866 TLS provides examples of failures in protocol version negotiation and 867 extensibility. 869 Version negotiation in TLS 1.2 and earlier uses the "Highest mutually 870 supported version (HMSV)" scheme exactly as it is described in 871 [EXTENSIBILITY]. However, clients are unable to advertise a new 872 version without causing a non-trivial proportion of sessions to fail 873 due to bugs in server and middlebox implementations. 875 Intolerance to new TLS versions is so severe [INTOLERANCE] that TLS 876 1.3 [TLS13] abandoned HMSV version negotiation for a new mechanism. 878 The server name indication (SNI) [TLS-EXT] in TLS is another 879 excellent example of the failure of a well-designed extensibility 880 point. SNI uses the same technique for extension that is used 881 successfully in other parts of the TLS protocol. The original design 882 of SNI anticipated the ability to include multiple names of different 883 types. 885 SNI was originally defined with just one type of name: a domain name. 886 No other type has ever been standardized, though several have been 887 proposed. Despite an otherwise exemplary design, SNI is so 888 inconsistently implemented that any hope for using the extension 889 point it defines has been abandoned [SNI]. 891 Acknowledgments 893 Toerless Eckert, Wes Hardaker, Mirja Kuehlewind, Eliot Lear, Mark 894 Nottingham, and Brian Trammell made significant contributions to this 895 document. 897 Authors' Addresses 899 Martin Thomson 900 Mozilla 902 Email: mt@lowentropy.net 904 Tommy Pauly 905 Apple 907 Email: tpauly@apple.com