idnits 2.17.1 draft-iab-protocol-maintenance-01.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 (October 22, 2018) is 2013 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7230 (ref. 'HTTP') (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7540 (ref. 'HTTP2') (Obsoleted by RFC 9113) -- Obsolete informational reference (is this intentional?): RFC 760 (ref. 'IP') (Obsoleted by RFC 791) -- Obsolete informational reference (is this intentional?): RFC 4627 (ref. 'JSON') (Obsoleted by RFC 7158, RFC 7159) -- Obsolete informational reference (is this intentional?): RFC 7159 (ref. 'JSON-BIS') (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 7 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 October 22, 2018 5 Expires: April 25, 2019 7 The Harmful Consequences of the Robustness Principle 8 draft-iab-protocol-maintenance-01 10 Abstract 12 Jon Postel's famous statement of "Be liberal in what you accept, and 13 conservative in what you send" is a principle that has long guided 14 the design and implementation of Internet protocols. The posture 15 this statement advocates promotes interoperability in the short term, 16 but can negatively affect the protocol ecosystem. For a protocol 17 that is actively maintained, the Postel's robustness principle can, 18 and should, be avoided. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 25, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Fallibility of Specifications . . . . . . . . . . . . . . . . 3 56 3. Protocol Decay . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Ecosystem Effects . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Active Protocol Maintenance . . . . . . . . . . . . . . . . . 6 59 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 7 60 7. The Role of Feedback . . . . . . . . . . . . . . . . . . . . 8 61 7.1. Feedback from Implementations . . . . . . . . . . . . . . 8 62 7.2. Virtuous Intolerance . . . . . . . . . . . . . . . . . . 8 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 10. Informative References . . . . . . . . . . . . . . . . . . . 9 66 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 Of the great many contributions Jon Postel made to the Internet, his 72 remarkable technical achievements are often shadowed by his 73 contribution of a design and implementation philosophy known as the 74 robustness principle: 76 Be strict when sending and tolerant when receiving. 77 Implementations must follow specifications precisely when sending 78 to the network, and tolerate faulty input from the network. When 79 in doubt, discard faulty input silently, without returning an 80 error message unless this is required by the specification. 82 This being the version of the text that appears in IAB RFC 1958 83 [PRINCIPLES]. 85 Postel's robustness principle has been hugely influential in shaping 86 the Internet and the systems that use Internet protocols. Many 87 consider the application of the robustness principle to be 88 instrumental in the success of the Internet as well as the design of 89 interoperable protocols in general. 91 Over time, considerable experience has been accumulated with 92 protocols that were designed by the application of Postel's maxim. 93 That experience shows that there are negative long-term consequences 94 to interoperability if an implementation applies Postel's advice. 96 The flaw in Postel's logic originates from the presumption of an 97 inability to affect change in a system the size of the Internet. 98 That is, once a protocol specification is published, changes that 99 might be different to the practice of existing implementations are 100 not feasible. 102 Many of the shortcomings that lead to applications of the robustness 103 principle are avoided for protocols under active maintenance. Active 104 protocol maintenance is where a community of protocol designers, 105 implementers, and deployers continuously improve and evolve 106 protocols. A community that takes an active role in the maintenance 107 of protocols can greatly reduce and even eliminate opportunities to 108 apply Postel's guidance. 110 There is good evidence to suggest that many important protocols are 111 routinely maintained beyond their inception. This document serves 112 primarily as a record of the hazards inherent in applying the 113 robustness principle and to offer an alternative strategy for 114 handling interoperability problems in deployments. 116 Ideally, protocol implementations never have to apply the robustness 117 principle. Or, where it is unavoidable, any application can be 118 quickly reverted. 120 2. Fallibility of Specifications 122 The context from which the robustness principle was developed 123 provides valuable insights into its intent and purpose. The earliest 124 form of the principle in the RFC series (in RFC 760 [IP]) is preceded 125 by a sentence that reveals the motivation for the principle: 127 While the goal of this specification is to be explicit about the 128 protocol there is the possibility of differing interpretations. 129 In general, an implementation should be conservative in its 130 sending behavior, and liberal in its receiving behavior. 132 Here Postel recognizes the possibility that the specification could 133 be imperfect. As a frank admission of fallibility it is a 134 significant statement. However, the same statement is inexplicably 135 absent from the later versions in [HOSTS] and [PRINCIPLES]. 137 An imperfect specification is natural, largely because it is more 138 important to proceed to implementation and deployment than it is to 139 perfect a specification. A protocol, like any complex system, 140 benefits greatly from experience with its use. A deployed protocol 141 is immeasurably more useful than a perfect protocol. 143 As [SUCCESS] demonstrates, success or failure of a protocol depends 144 far more on factors like usefulness than on on technical excellence. 145 Postel's timely publication of protocol specifications, even with the 146 potential for flaws, likely had a significant effect in the eventual 147 success of the Internet. 149 The problem is therefore not with the premise, but with its 150 conclusion: the robustness principle itself. 152 3. Protocol Decay 154 Divergent implementations of a specification emerge over time. When 155 variations occur in the interpretation or expression of semantic 156 components, implementations cease to be perfectly interoperable. 158 Implementation bugs are often identified as the cause of variation, 159 though it is often a combination of factors. Application of a 160 protocol to new and unanticipated uses, and ambiguities or errors in 161 the specification are often confounding factors. Situations where 162 two peers disagree on interpretation should be expected over the 163 lifetime of a protocol. 165 Even with the best intentions, the pressure to interoperate can be 166 significant. No implementation can hope to avoid having to trade 167 correctness for interoperability indefinitely. 169 An implementation that reacts to variations in the manner advised by 170 Postel sets up a feedback cycle: 172 o Over time, implementations progressively add new code to constrain 173 how data is transmitted, or to permit variations in what is 174 received. 176 o Errors in implementations, or confusion about semantics can 177 thereby be masked. 179 o These errors can become entrenched, forcing other implementations 180 to be tolerant of those errors. 182 A flaw can become entrenched as a de facto standard. Any 183 implementation of the protocol is required to replicate the aberrant 184 behavior, or it is not interoperable. This is both a consequence of 185 applying Postel's advice, and a product of a natural reluctance to 186 avoid fatal error conditions. Ensuring interoperability in this 187 environment is often colloquially referred to as aiming to be "bug 188 for bug compatible". 190 For example, TLS demonstrates the effect of bugs. In TLS [TLS] 191 extensions use a tag-length-value format, and they can be added to 192 messages in any order. However, some server implementations 193 terminate connections if they encounter a TLS ClientHello message 194 that ends with an empty extension. To maintain interoperability, 195 client implementations are required to be aware of this bug and 196 ensure that a ClientHello message ends in a non-empty extension. 198 The original JSON specification [JSON] demonstrates the effect of 199 specification shortcomings. RFC 4627 omitted critical details on a 200 range of key details including Unicode handling, ordering and 201 duplication of object members, and number encoding. Consequently, a 202 range of interpretations were used by implementations. An updated 203 specification [JSON-BIS] did not correct these errors, concentrating 204 instead on identifying the interoperable subset of JSON. I-JSON 205 [I-JSON] takes that subset and defines a new format that prohibits 206 the problematic parts of JSON. Of course, that means that I-JSON is 207 not fully interoperable with JSON. Consequently, I-JSON is not 208 widely implemented in parsers. Many JSON parsers now implement the 209 more precise algorithm specified in [ECMA262]. 211 The robustness principle therefore encourages a reaction that 212 compounds and entrenches interoperability problems. 214 4. Ecosystem Effects 216 Once deviations become entrenched, it can be extremely difficult - if 217 not impossible - to rectify the situation. 219 For widely used protocols, the massive scale of the Internet makes 220 large-scale interoperability testing infeasible for all but a 221 privileged few. The cost of building a new implementation increases 222 as the number of implementations and bugs increases. Worse, the set 223 of tweaks necessary for interoperability can be difficult to learn. 225 Consequently, new implementations can be restricted to niche uses, 226 where the problems arising from interoperability issues can be more 227 closely managed. Restricting new implementations to narrow contexts 228 also risks causing forks in the protocol. If implementations do not 229 interoperate, little prevents those implementations from diverging 230 more over time. 232 This has a negative impact on the ecosystem of a protocol. New 233 implementations are important in ensuring the continued viability of 234 a protocol. New protocol implementations are also more likely to be 235 developed for new and diverse use cases and often are the origin of 236 features and capabilities that can be of benefit to existing users. 238 The need to work around interoperability problems also reduces the 239 ability of established implementations to change. For instance, an 240 accumulation of mitigations for interoperability issues makes 241 implementations more difficult to maintain. 243 Sometimes what appear to be interoperability problems are symptomatic 244 of issues in protocol design. A community that is willing to make 245 changes to the protocol, by revising or extending it, makes the 246 protocol better in the process. Applying the robustness principle 247 might conceal the problem. That can make it harder, or even 248 impossible, to fix later. 250 A similar class of problems is described in RFC 5704 [UNCOORDINATED], 251 which addresses conflict or competition in the maintenance of 252 protocols. This document concerns itself primarily with the absence 253 of maintenance, though the problems are similar. 255 5. Active Protocol Maintenance 257 The robustness principle can be highly effective in safeguarding 258 against flaws in the implementation of a protocol by peers. 259 Especially when a specification remains unchanged for an extended 260 period of time, the inclination to be tolerant accumulates over time. 261 Indeed, when faced with divergent interpretations of an immutable 262 specification, the best way for an implementation to remain 263 interoperable is to be tolerant of differences in interpretation and 264 an occasional outright implementation error. 266 From this perspective, application of Postel's advice to the 267 implementation of a protocol specification that does not change is 268 logical, even necessary. But that suggests that the problem is with 269 the assumption that the situation - existing specifications and 270 implementations - are unable to change. 272 As already established, this is not a sustainable. For a protocol to 273 be viable, it is necessary for both specifications and 274 implementations to be responsive to changes, in addition to handling 275 new and old problems that might arise over time. 277 Active maintenance of a protocol is critical in ensuring that 278 specifications correctly reflect the requirements for 279 interoperability with existing implementations. Maintenance enables 280 both new implementations and the continued improvement of the 281 protocol. New use cases are an indicator that the protocol could be 282 successful [SUCCESS]. 284 Protocol designers are strongly encouraged to continue to maintain 285 and evolve protocols beyond their initial inception and definition. 287 Involvement of protocol implementers is a critical part of this 288 process, as they provide input on their experience with 289 implementation and deployment of the protocol. 291 Maintenance does not necessarily involve the development of new 292 versions of protocols or protocol specifications. For instance, the 293 most effective means of dealing with a defective implementation in a 294 peer is often to email the developer of the stack. It is far more 295 efficient in the long term to fix one isolated bug than it is to deal 296 with the consequences of workarounds. 298 Neglect can quickly produce the negative consequences this document 299 describes. Restoring the protocol to a state where it can be 300 maintained involves first discovering the properties of the protocol 301 as it is deployed, rather than the protocol as it was originally 302 documented. This can be difficult and time-consuming, particularly 303 if the protocol has a diverse set of implementations. Such a process 304 was undertaken for HTTP [HTTP] after a period of minimal maintenance. 305 Restoring HTTP specifications to currency took significant effort. 307 6. Extensibility 309 Good extensibility [EXT] can make it easier to respond to new use 310 cases or changes in the environment in which the protocol is 311 deployed. 313 Extensibility is sometimes mistaken for an application of the 314 robustness principle. After all, if one party wants to start using a 315 new feature before another party is prepared to receive it, it might 316 be assumed that the receiving party is being tolerant of unexpected 317 inputs. 319 A well-designed extensibility mechanism establishes clear rules for 320 the handling of things like new messages or parameters. If an 321 extension mechanism is designed and implemented correctly, the user 322 of a new protocol feature can confidently predict the effect that 323 feature will have on existing implementations. 325 Relying on implementations consistently applying the robustness 326 principle is not a good strategy for extensibility. Using 327 undocumented or accidental features of a protocol as the basis of an 328 extensibility mechanism can be extremely difficult, as is 329 demonstrated by the case study in Appendix A.3 of [EXT]. 331 A protocol could be designed to permit a narrow set of valid inputs, 332 or it could allow a wide range of inputs as a core feature (see for 333 example [HTML]). Specifying and implementing a more flexible 334 protocol is more difficult; allowing less variation is preferable in 335 the absence of strong reasons to be flexible. 337 7. The Role of Feedback 339 Protocol maintenance is only possible if there is sufficient 340 information about the deployment of the protocol. Feedback from 341 deployment is critical to effective protocol maintenance. 343 For a protocol specification, the primary and most effective form of 344 feedback comes from people who implement and deploy the protocol. 345 This comes in the form of new requirements, or in experience with the 346 protocol as it is deployed. 348 Managing and deploying changes to implementations can be expensive. 349 However, it is widely recognized that regular updates are a vital 350 part of the deployment of computer systems for security reasons (see 351 for example [IOTSU]). 353 7.1. Feedback from Implementations 355 Automated error reporting mechanisms in protocol implementations 356 allows for better feedback from deployments. Exposing faults through 357 operations and management systems is highly valuable, but it might be 358 necessary to ensure that the information is propagated further. 360 Building telemetry and error logging systems that report faults to 361 the developers of the implementation is superior in many respects. 362 However, this is only possible in deployments that are conducive to 363 the collection of this type of information. Giving due consideration 364 to protection of the privacy of protocol participants is critical 365 prior to deploying any such system. 367 7.2. Virtuous Intolerance 369 A well-specified protocol includes rules for consistent handling of 370 aberrant conditions. This increases the changes that implementations 371 have interoperable handling of unusual conditions. 373 Intolerance of any deviation from specification, where 374 implementations generate fatal errors in response to observing 375 undefined or unusal behaviour, can be harnessed to reduce occurrences 376 of abherrent implementations. Choosing to generate fatal error for 377 unspecified conditions instead of attempting error recovery can 378 ensure that faults receive attention. 380 This improves feedback for new implementations in particular. When a 381 new implementation encounters a virtuously intolerant implementation, 382 it receives strong feedback that allows problems to be discovered 383 quickly. 385 To be effective, virtuously intolerant implementations need to be 386 sufficiently widely deployed that they are encountered by new 387 implementations with high probability. This could depend on multiple 388 implementations of the same strict checks. Any intolerance also 389 needs to be strongly supported by specifications, otherwise they 390 encourage fracturing of the protocol community or proliferation of 391 workarounds. 393 Virtuous intolerance can be used to motivate compliance with any 394 protocol requirement. For instance, the INADEQUATE_SECURITY error 395 code and associated requirements in HTTP/2 [HTTP2] resulted in 396 improvements in the security of the deployed base. 398 8. Security Considerations 400 Sloppy implementations, lax interpretations of specifications, and 401 uncoordinated extrapolation of requirements to cover gaps in 402 specification can result in security problems. Hiding the 403 consequences of protocol variations encourages the hiding of issues, 404 which can conceal bugs and make them difficult to discover. 406 The consequences of the problems described in this document are 407 especially acute for any protocol where security depends on agreement 408 about semantics of protocol elements. 410 9. IANA Considerations 412 This document has no IANA actions. 414 10. Informative References 416 [ECMA262] "ECMAScript(R) 2017 Language Specification", ECMA-262 8th 417 Edition, June 2017, . 420 [EXT] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 421 Considerations for Protocol Extensions", RFC 6709, 422 DOI 10.17487/RFC6709, September 2012, 423 . 425 [HOSTS] Braden, R., Ed., "Requirements for Internet Hosts - 426 Communication Layers", STD 3, RFC 1122, 427 DOI 10.17487/RFC1122, October 1989, 428 . 430 [HTML] "HTML", WHATWG Living Standard, October 2017, 431 . 433 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 434 Protocol (HTTP/1.1): Message Syntax and Routing", 435 RFC 7230, DOI 10.17487/RFC7230, June 2014, 436 . 438 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 439 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 440 DOI 10.17487/RFC7540, May 2015, 441 . 443 [I-JSON] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 444 DOI 10.17487/RFC7493, March 2015, 445 . 447 [IOTSU] Tschofenig, H. and S. Farrell, "Report from the Internet 448 of Things Software Update (IoTSU) Workshop 2016", 449 RFC 8240, DOI 10.17487/RFC8240, September 2017, 450 . 452 [IP] Postel, J., "DoD standard Internet Protocol", RFC 760, 453 DOI 10.17487/RFC0760, January 1980, 454 . 456 [JSON] Crockford, D., "The application/json Media Type for 457 JavaScript Object Notation (JSON)", RFC 4627, 458 DOI 10.17487/RFC4627, July 2006, 459 . 461 [JSON-BIS] 462 Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 463 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 464 2014, . 466 [PRINCIPLES] 467 Carpenter, B., Ed., "Architectural Principles of the 468 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 469 . 471 [SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful 472 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 473 . 475 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 476 (TLS) Protocol Version 1.2", RFC 5246, 477 DOI 10.17487/RFC5246, August 2008, 478 . 480 [UNCOORDINATED] 481 Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated 482 Protocol Development Considered Harmful", RFC 5704, 483 DOI 10.17487/RFC5704, November 2009, 484 . 486 Appendix A. Acknowledgments 488 Constructive feedback on this document has been provided by a 489 surprising number of people including Bernard Aboba, Brian Carpenter, 490 Mark Nottingham, Russ Housley, Henning Schulzrinne, Robert Sparks, 491 Brian Trammell, and Anne Van Kesteren. Please excuse any omission. 493 Author's Address 495 Martin Thomson 496 Mozilla 498 Email: martin.thomson@gmail.com