RFC 9413

Maintaining Robust Protocols

📅 published June 2023, from ietf

RFC 9413: Maintaining Robust Protocols 💖

okay bestie, here's the title block tea ☕

  • Who wrote it: M. Thomson and D. Schinazi 🫶
  • Published by: the Internet Architecture Board (IAB) 👑
  • Category: Informational, so it's for the permanent record and not a Standards Track spec 📚
  • ISSN: 2070-1721
  • Date: June 2023 🗓️
  • Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates ✨

Abstract ✨

okay so the big goal of the networking standards process is making sure protocols stay interoperable for the long haul 🦋 this doc is all about active protocol maintenance, which is literally the way to get there. when you keep evolving the specs and the implementations together, you cut down on ambiguity over time and the whole ecosystem stays healthy 🌸

now, the robustness principle (you know the one: "be conservative in what you send, and liberal in what you accept") has been guiding Internet protocol design forever 💅 but people have read it a bunch of different ways. some readings keep the Internet healthy, and others quietly wreck interoperability as time goes on 😭 when a protocol is actively maintained, designers and implementers can dodge those traps. no cap, it's the move 🔥

Status of This Memo 🎀

this doc is not an Internet Standards Track specification. it's published for informational purposes 📖

it's a product of the Internet Architecture Board (IAB) and it's basically a record of stuff the IAB decided was worth keeping forever. it represents the consensus of the IAB 🤝 documents the IAB approves for publication are not candidates for any level of Internet Standard, see Section 2 of RFC 7841 🙈

to find the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9413 🍓

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please read those carefully, bestie, because they spell out your rights and restrictions for this doc 📜⭐

Table of Contents 🧚

1.  Introduction
2.  Protocol Robustness
  2.1.  Fallibility of Specifications
  2.2.  Extensibility
  2.3.  Flexible Protocols
3.  Applicability
4.  Harmful Consequences of Tolerating the Unexpected
  4.1.  Protocol Decay
  4.2.  Ecosystem Effects
5.  Active Protocol Maintenance
  5.1.  Virtuous Intolerance
  5.2.  Exclusion
6.  Security Considerations
7.  IANA Considerations
8.  Informative References
IAB Members at the Time of Approval
Acknowledgments
Authors' Addresses

1. Introduction 🦋

there's good evidence that lots of important protocols get maintained way past their launch day 🫶 honestly, a big chunk of IETF work is just taking care of protocols that already exist 🧹

this doc first talks through the hazards of applying the robustness principle too broadly (see Section 2), then offers a different strategy for dealing with interoperability problems in real deployments (see Section 5) 💅

ideally, protocol implementations get actively maintained so unexpected conditions are spotted and fixed before they bite anyone ✨ some deployments might still need short-term mitigations when they can't be easily updated, but those don't have to last forever 🌸 Section 5 has more on this 💖

2. Protocol Robustness 👑

the robustness principle has been hugely influential in shaping the Internet, no debate 🔥 the IAB doc "Architectural Principles of the Internet" [RFC1958] puts it like this:

Be strict when sending and tolerant when receiving. Implementations must follow specifications precisely when sending to the network, and tolerate faulty input from the network. When in doubt, discard faulty input silently, without returning an error message unless this is required by the specification.

that's a seriously simple line, but it captures a big idea for building interoperable systems 🧚 a lot of people think applying the robustness principle is a big reason the Internet succeeded, and that it's key to designing interoperable protocols in general 💜

there are three main parts to the robustness principle 👀

  • Robustness to software defects: no software is perfect, so failures can lead to weird behavior 😭 good software is resilient to this stuff, whether it happens in the local software or in the software it talks to. the big thing is that software has to recover gracefully from these issues without aborting unrelated processing 🎀
  • Robustness to attacks: not everyone on the Internet is nice, so networking software needs to be resilient to input that's been deliberately crafted to cause unexpected results 💀 for example, software must make sure invalid input doesn't let the sender access data, change data, or do actions they wouldn't otherwise be allowed to do 🙅‍♀️
  • Robustness to the unexpected: an implementation can receive inputs the specification never prepared it for 🌈 this doesn't include cases where the specification explicitly defines how a faulty message gets handled. it's about cases where handling isn't defined, or where the spec is a little ambiguous. in that situation, some readings of the robustness principle say the implementation should tolerate the faulty input and quietly discard it. some even suggest a faulty or ambiguous message should be processed according to the sender's inferred intent 🤔

the parts of the robustness principle that protect against defects or attacks are totally necessary guiding principles for building networked systems 🫶 but tolerating unexpected inputs is no longer considered best practice in every scenario 🙃

time and experience show that the negative effects on interoperability pile up over time if implementations silently accept faulty input 📉 this problem comes from an assumption that it's impossible to change a system the size of the Internet 🌍 if you assume changing existing implementations isn't realistic right now, tolerating flaws starts to feel inevitable 😩

a lot of the problems the third part of the robustness principle was meant to solve can be handled better by active maintenance ✨ that's where designers, implementers, and deployers work together to keep improving and evolving protocol specs alongside the implementations and deployments 🔧 a community that actively maintains its protocols won't need to lean on the robustness principle to dodge interoperability issues 🦋

2.1. Fallibility of Specifications 🧠

the context the robustness principle came from tells you a lot about what it was for 👀 the earliest version in the RFC Series (the Internet Protocol spec [RFC0760]) comes right after a sentence that shows why the principle exists:

While the goal of this specification is to be explicit about the protocol there is the possibility of differing interpretations. In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior.

this wording openly admits the spec might be imperfect, and that totally changes how you should read the principle 💅

imperfect specs are basically unavoidable, mostly because getting to implementation and deployment matters more than making a spec perfect 🚀 a protocol gets way better from real-world use, and a deployed protocol is wayyy more useful than a perfect spec sitting on a shelf 📦 this is especially true early in system design, which is where the robustness principle fits best 🎀

the IAB doc "What Makes for a Successful Protocol?" [RFC5218] shows that whether a protocol succeeds or fails depends way more on stuff like usefulness than on technical excellence 🏆 getting specs published on time, even with possible flaws, probably helped the Internet succeed a ton 🌈

so yes, specs will be imperfect, and that's true 💯 but ignoring faulty or ambiguous input is almost always the wrong fix 🙅‍♀️

2.2. Extensibility 🧩

good extensibility [EXT] makes it way easier to respond to new use cases or to changes in the environment where the protocol gets deployed ✨

people sometimes mix up extensibility with the robustness principle, and I get why 🤷‍♀️ if one party wants to start using a new feature before the other party is ready to receive it, you might assume the receiver is being tolerant of new kinds of input 🙈

a well-designed extensibility mechanism sets clear rules for handling things like new messages or parameters 📏 that depends on specifying how malformed or illegal inputs get handled, so implementations act consistently in every case that could affect interoperation 🦋 new messages or parameters then become totally expected 💖 if extension mechanisms and error handling are designed and implemented correctly, you can roll out new protocol features with confidence, because you understand the effect they have on existing implementations 🫶

on the flip side, counting on implementations to consistently handle unexpected input is not a good extensibility strategy 💀 using undocumented or accidental features of a protocol as the basis for an extensibility mechanism can be extremely difficult, as the case study in Appendix A.3 of [EXT] shows 😭 it's way better and easier to design a protocol for extensibility from the start than to retrofit that capability later (see also [EDNS0]) 🌸

2.3. Flexible Protocols ✨

okay so a protocol can be designed to only let in a narrow set of valid inputs 🎀, or it can treat a wide range of inputs as valid 🌈.

ngl, the more flexible a protocol is, the more complicated it is to write down and build 😭. Weird little variations, especially the rarely used ones, can cause interoperability hazards 💀. So unless there's a really strong reason to be flexible, a simpler protocol is more likely to actually interoperate ✨.

When real humans are the ones typing the input 🧚, flexibility can make a protocol way more accessible, especially for non-expert users. HTML authoring [HTML] is a good example of this sort of design 🌸.

Now, in protocols with lots of participants who generate messages based on data from other participants, a bit of flexibility might help the whole system be more resilient 🫶. Routing protocols are a great example of where this might be needed.

Let's look at BGP [BGP] 👑. A peer makes UPDATE messages based on the messages it gets from its other peers. Peers can copy attributes without validating them, which means invalid values can get passed along 💀. RFC 4271 [BGP] mandated a session reset for invalid UPDATE messages 🙈, but that requirement wasn't widely implemented. In lots of deployments, peers handled a malformed UPDATE in less strict ways, like treating the affected route as withdrawn. Eventually RFC 7606 [BGP-REH] wrote that practice down and gave precise rules, including mandatory actions for different error conditions 🎀.

A protocol can explicitly allow a bunch of valid ways to express the same meaning, with precise definitions for error handling 💅. That's different from a protocol that just leans on the robustness principle. With the first kind, interoperation depends on specs that capture every relevant detail 📜. With the second kind, interoperation depends way more on implementations making compatible decisions, as noted in Section 4.2 🦋.

3. Applicability

The guidance in this document is intended for protocols that are deployed to the Internet 🌐. There are some situations where this guidance might not apply to a protocol, due to conditions on its implementation or deployment.

In particular, this guidance depends on being able to update and deploy implementations. Being able to rapidly update implementations that are deployed to the Internet helps manage security risks 🔐, but in reality, some software deployments have lifecycles that make software updates either rare or altogether impossible 😩.

Where implementations are not updated, there's no opportunity to apply the practices that this document recommends. In particular, some practices -- such as those described in Section 5.1 -- only exist to support the development of protocol maintenance and evolution 🛠️. So employing this guidance is only applicable where there's the possibility of improving deployments through timely updates of their implementations ✨.

4. Harmful Consequences of Tolerating the Unexpected

Problems in other implementations can create an unavoidable need to temporarily tolerate unexpected inputs 🫠. However, this course of action carries risks ⚠️.

4.1. Protocol Decay

Tolerating unexpected input might be an expedient tool for systems in early phases of deployment, which was the case for the early Internet 🕰️. Being lenient like this defers the effort of dealing with interoperability problems and prioritizes progress 🏃‍♀️. However, this deferral can amplify the ultimate cost of handling interoperability problems 💸.

Divergent implementations of a specification emerge over time 🌿. When variations occur in the interpretation or expression of semantic components, implementations stop being perfectly interoperable 💔.

Implementation bugs are often blamed for the variation, though it's usually a combination of factors 🕵️‍♀️. Using a protocol in ways that weren't anticipated in the original design, or ambiguities and errors in the specification, are often contributing factors. Disagreements on the interpretation of specifications should be expected over the lifetime of a protocol 🙃.

Even with the best intentions to keep protocol correctness intact, the pressure to interoperate can be significant 😤. No implementation can hope to avoid having to trade correctness for interoperability indefinitely 🥲.

An implementation that reacts to variations in the manner recommended in the robustness principle enters a pathological feedback cycle 🌀. Over time:

  • Implementations progressively add logic to constrain how data is transmitted, or to permit variations in what is received.
  • Errors in implementations, or confusion about semantics, are permitted or ignored.
  • These errors can become entrenched, forcing other implementations to be tolerant of those errors.

A flaw can become entrenched as a de facto standard 🧱. Any implementation of the protocol is required to replicate the aberrant behavior, or it's not interoperable. This is both a consequence of tolerating the unexpected and a product of a natural reluctance to avoid fatal error conditions 😬. Ensuring interoperability in this environment is often referred to as aiming to be "bug-for-bug compatible" 🐛💅.

For example, in TLS [TLS], extensions use a tag-length-value format and can be added to messages in any order 🧩. However, some server implementations terminated connections if they encountered a TLS ClientHello message that ends with an empty extension 💀. To maintain interoperability with these servers, which were widely deployed, client implementations were required to be aware of this bug and make sure that a ClientHello message ends in a non-empty extension 🫣.

Overapplying the robustness principle therefore encourages a chain reaction that can create interoperability problems over time ⛓️. In particular, tolerating unexpected behavior is especially harmful for early implementations of new protocols, since quirks in early implementations can affect all subsequent deployments 🌪️.

4.2. Ecosystem Effects

From observing widely deployed protocols, it appears there are two stable points on the spectrum between being strict and being permissive in the presence of protocol errors 🎭:

  • If implementations predominantly enforce strict compliance with specifications, newer implementations will experience failures if they don't comply with protocol requirements. Newer implementations need to fix compliance issues in order to be successfully deployed. This keeps most deployments compliant over time 🏆.
  • Conversely, if non-compliance is tolerated by existing implementations, non-compliant implementations can be deployed successfully. Newer implementations then have a strong incentive to tolerate any existing non-compliance in order to be successfully deployed. This keeps most deployments tolerant of the same non-compliant behavior 🙄.

This happens because interoperability requirements for protocol implementations are set by other deployments 📡. Specifications and test suites -- where they exist -- can guide the initial development of implementations 🗺️. Ultimately, the need to interoperate with deployed implementations is a de facto conformance test suite that can supersede any formal protocol definition 👑.

For widely used protocols, the massive scale of the Internet makes large-scale interoperability testing infeasible for all but a privileged few 🌍. The cost of building a new implementation using reverse engineering goes up as the number of implementations and bugs increases 📈. Worse, the set of tweaks needed for wide interoperability can be really hard to discover 🔍. In the worst case, a new implementer might have to choose between deployments that have diverged so far they're no longer interoperable 😵.

So new implementations might get forced into niche uses, where the problems from interoperability issues can be more closely managed 🪤. However, restricting new implementations to limited deployments risks causing forks in the protocol 🍴. If implementations don't interoperate, little prevents them from diverging even more over time 🫥.

This has a negative impact on the ecosystem of a protocol 🌱. New implementations are key to the continued viability of a protocol 🔑. New protocol implementations are also more likely to be developed for new and diverse use cases, and they're often where features and capabilities that benefit existing users first show up 🎁.

The need to work around interoperability problems also reduces the ability of established implementations to change 🧶. An accumulation of mitigations for interoperability issues makes implementations harder to maintain, and can constrain extensibility (see also the IAB document "Long-Term Viability of Protocol Extension Mechanisms" [RFC9170]) 🧱.

Sometimes, what look like interoperability problems are symptoms of issues in protocol design 🔬. A community that's willing to make changes to the protocol, by revising or extending specifications and then deploying those changes, makes the protocol better 🌟. Tolerating unexpected input instead hides the problems, making them harder, if not impossible, to fix later 🙈💜.

5. Active Protocol Maintenance ✨

okay so the robustness principle is honestly iconic at protecting you from your peers' bugs 💅 But the longer a spec just sits there unchanged, the more everyone feels like being tolerant of errors is the move. Like, if the spec never changes and two implementations read it differently, the only way they keep talking is by tolerating each other's differences and mistakes 🙈 And when the official spec stops getting updates, the deployed implementations (quirks and all) quietly become the real standard 💀

Being tolerant of weird input from another implementation might feel logical, even necessary 🫶 BUT that conclusion assumes existing specs and implementations can never change. Using the robustness principle like this puts short-term wins way above the negative effects on future implementations and the whole protocol. Not it 😭

For a protocol to stay viable for the long haul, both specs and implementations need to be responsive to change, and they need to handle new and old problems as they show up over time 🦋 For example, say an implementer finds a case where the spec calls some input faulty but never says how to handle it. That implementer can add so much value to the ecosystem by reporting the issue and helping the spec evolve 👑

When there's a mismatch between a spec and its implementation, a maintenance discussion inside the standards process lets everyone reach consensus on how to evolve the spec 🎀 After that, updating implementations to match the evolved spec keeps them consistently interoperable and clears away needless barriers for new implementations 🌸 Maintenance also keeps the protocol improving. New use cases are a sign the protocol could be successful [RFC5218] ✨

Protocol designers are strongly encouraged to keep maintaining and evolving their specs well past the initial inception and definition 💖 That might mean revised specs, extensions, or other supporting material that evolves alongside the implementations. The people who implement and deploy the protocol are a critical part of this, since they bring real experience of how it's actually used 🫶

Most interoperability problems don't need the protocol or its spec to be revised 🙈 Software defects can happen even when the spec is unambiguous. For instance, the most effective way to deal with a defective implementation in a peer could be contacting the developer responsible. Fixing one isolated bug is way more efficient in the long term than dealing with the fallout of workarounds 🍓

Early implementations have a stronger obligation to closely follow the spec, because their behavior is going to affect every implementation that comes after 😭 Later implementations get guided by what existing deployments accept too. Tolerating errors in early deployments is the most likely way to cause problems 💀 Specs might need more frequent revision during early deployments so they can capture feedback from the first rounds of rollout 🌈

Neglect can quickly lead to the negative consequences this document describes 💀 Getting a protocol back to a maintainable state starts with discovering how it's actually deployed, not how it was originally documented. That can be really hard and time-consuming, especially if the protocol has a diverse set of implementations. This was exactly the situation for HTTP [HTTP] after a period of minimal maintenance, and restoring the HTTP specs to relevance took a serious amount of effort 🥲

Maintenance works best when it's responsive, and that depends a lot on how fast protocol changes can get deployed 🧚 For deployments that operate on longer time scales, temporary workarounds that follow the spirit of the robustness principle might be necessary. Better software update mechanisms mean that reacting to changes costs way less than it used to 🦋 Alternatively, if specs can be updated more easily than deployments, the workaround can be documented, including the desired form of the protocol once the workaround isn't needed anymore, plus plans for removing it 💜

5.1. Virtuous Intolerance 💅

A well-specified protocol includes rules for consistently handling aberrant conditions 🎀 That makes it more likely that implementations will handle unusual conditions in consistent, interoperable ways.

Choosing to generate fatal errors for unspecified conditions, instead of trying to recover, can make sure faults get attention 🔥 This kind of intolerance can be harnessed to reduce how often aberrant implementations show up.

Intolerance toward spec violations gives especially good feedback to new implementations 🧚 When a new implementation runs into a peer that's intolerant of an error, it gets strong feedback that helps the problem get found quickly.

To work well, intolerant implementations need to be widely deployed enough that new implementations run into them with high probability 🌸 This could depend on multiple implementations deploying strict checks.

Interoperability problems also need to reach the people who can actually fix them 💖 Systems with human operators, like user-facing clients, are ideally suited for surfacing errors. Other systems might need less direct ways of making errors known ✨

This doesn't mean intolerance of errors in early deployments stops interoperability 🙅‍♀️ Actually, when existing implementations follow clearly specified error handling, new implementations or features can be introduced more easily, because the effect on existing implementations is easy to predict. See also Section 2.2 🫶

Any intolerance also needs to be strongly backed by specs, or else it encourages fracturing of the protocol community or a pile-up of workarounds 💀 See Section 5.2.

Intolerance can be used to motivate compliance with any protocol requirement 👑 For instance, the INADEQUATE_SECURITY error code and its associated requirements in HTTP/2 [HTTP/2] led to real improvements in the security of the deployed base 🔥

A notification for a fatal error is best sent as an explicit error message to the entity that made the error 🎀 Error messages benefit from being able to carry arbitrary information that might help the sender of the faulty input understand and fix the issue in their software. QUIC error frames [QUIC] are an example of a fatal error mechanism that helped implementers improve software quality across the whole protocol lifecycle 🦋 Similarly, Extended DNS Errors [EDE] have been effective at giving clients better descriptions of DNS resolution errors 🌈

Stateless protocol endpoints might cause denial-of-service attacks if they send an error message in response to every message received from an unauthenticated sender 😭 These implementations might need to silently discard those messages 🤫

5.2. Exclusion 🚫

Any protocol participant affected by changes from maintenance might get excluded if they're unwilling or unable to implement or deploy the changes made to the protocol 💅

Deliberately excluding problematic implementations is an important tool for keeping a protocol's interoperability viable 💖 Backward-compatible changes are always preferable to incompatible ones, but it isn't always possible to design something that protects the ability of all current and future participants to interoperate 🥲

Accidentally excluding unexpected participants usually isn't a good outcome 🙈 When developing and deploying changes, it's best to first understand how much the change affects existing deployments. That way, any exclusion that happens is intentional 🎯

Sometimes existing deployments might need to change to avoid being excluded 🧚 Forcing deployments to change is something to avoid if possible, but it might be considered necessary. To avoid unnecessarily excluding deployments that take time to change, a migration plan can be a really smart move 🌸

Exclusion is a direct goal when choosing to be intolerant of errors (see Section 5.1) 👑 Exclusionary actions are taken with the deliberate intent of protecting future interoperability.

Excluding implementations or deployments can fracture the protocol system, and that could be more harmful than any divergence that might come from tolerating the unexpected 😭 The IAB document "Uncoordinated Protocol Development Considered Harmful" [RFC5704] describes how conflict or competition in protocol maintenance can lead to similar problems 🫠

6. Security Considerations 🔐

Careless implementations, lax interpretations of specs, and uncoordinated extrapolation of requirements to cover gaps in a spec can all cause security problems 🚨 Hiding the consequences of protocol variations encourages hiding issues, and that can conceal bugs and make them really hard to find 🕵️‍♀️

The consequences of the problems described in this document are especially acute for any protocol where security depends on agreement about the semantics of protocol elements 💀 For instance, weak primitives [MD5] and obsolete mechanisms [SSL3] are prime examples of unsafe security practices, where forcing exclusion (Section 5.2) can be the desirable move 🔒

7. IANA Considerations 🧚

This document has no IANA actions 🎀

8. Informative References ✨

Okay bestie, here's the reading list 📚 These are the informative references, so they're background material the spec points to for context. Every entry keeps its label, authors, title, RFC number, DOI, date and link exactly as written.

[BGP]      Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
           Border Gateway Protocol 4 (BGP-4)", RFC 4271,
           DOI 10.17487/RFC4271, January 2006,
           <https://www.rfc-editor.org/info/rfc4271>.

[BGP-REH]  Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
           Patel, "Revised Error Handling for BGP UPDATE Messages",
           RFC 7606, DOI 10.17487/RFC7606, August 2015,
           <https://www.rfc-editor.org/info/rfc7606>.

[EDE]      Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
           Lawrence, "Extended DNS Errors", RFC 8914,
           DOI 10.17487/RFC8914, October 2020,
           <https://www.rfc-editor.org/info/rfc8914>.

[EDNS0]    Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
           for DNS (EDNS(0))", STD 75, RFC 6891,
           DOI 10.17487/RFC6891, April 2013,
           <https://www.rfc-editor.org/info/rfc6891>.

[EXT]      Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
           Considerations for Protocol Extensions", RFC 6709,
           DOI 10.17487/RFC6709, September 2012,
           <https://www.rfc-editor.org/info/rfc6709>.

[HTML]     WHATWG, "HTML - Living Standard",
           <https://html.spec.whatwg.org/>.

[HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
           Ed., "HTTP Semantics", STD 97, RFC 9110,
           DOI 10.17487/RFC9110, June 2022,
           <https://www.rfc-editor.org/info/rfc9110>.

[HTTP/2]   Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
           DOI 10.17487/RFC9113, June 2022,
           <https://www.rfc-editor.org/info/rfc9113>.

[MD5]      Turner, S. and L. Chen, "Updated Security Considerations
           for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
           RFC 6151, DOI 10.17487/RFC6151, March 2011,
           <https://www.rfc-editor.org/info/rfc6151>.

[QUIC]     Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
           Multiplexed and Secure Transport", RFC 9000,
           DOI 10.17487/RFC9000, May 2021,
           <https://www.rfc-editor.org/info/rfc9000>.

[RFC0760]  Postel, J., "DoD standard Internet Protocol", RFC 760,
           DOI 10.17487/RFC0760, January 1980,
           <https://www.rfc-editor.org/info/rfc760>.

[RFC1958]  Carpenter, B., Ed., "Architectural Principles of the
           Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,
           <https://www.rfc-editor.org/info/rfc1958>.

[RFC3117]  Rose, M., "On the Design of Application Protocols",
           RFC 3117, DOI 10.17487/RFC3117, November 2001,
           <https://www.rfc-editor.org/info/rfc3117>.

[RFC5218]  Thaler, D. and B. Aboba, "What Makes for a Successful
           Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
           <https://www.rfc-editor.org/info/rfc5218>.

[RFC5704]  Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated
           Protocol Development Considered Harmful", RFC 5704,
           DOI 10.17487/RFC5704, November 2009,
           <https://www.rfc-editor.org/info/rfc5704>.

[RFC9170]  Thomson, M. and T. Pauly, "Long-Term Viability of Protocol
           Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170,
           December 2021, <https://www.rfc-editor.org/info/rfc9170>.

[SSL3]     Barnes, R., Thomson, M., Pironti, A., and A. Langley,
           "Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
           DOI 10.17487/RFC7568, June 2015,
           <https://www.rfc-editor.org/info/rfc7568>.

[TLS]      Rescorla, E., "The Transport Layer Security (TLS) Protocol
           Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
           <https://www.rfc-editor.org/info/rfc8446>.

IAB Members at the Time of Approval 👑

Here's the crew from the Internet Architecture Board when this doc got approved 🌈 These were the Internet Architecture Board members at the time this document was approved for publication:

  • Jari Arkko
  • Deborah Brungard
  • Lars Eggert
  • Wes Hardaker
  • Cullen Jennings
  • Mallory Knodel
  • Mirja Kühlewind
  • Zhenbin Li
  • Tommy Pauly
  • David Schinazi
  • Russ White
  • Qin Wu
  • Jiankang Yao

Approval was broad but not unanimous 👀 The guidance is valid, but some folks in the IETF community had concerns about how broadly it applies in all situations.

Acknowledgments 🫶

Okay, the thank-you list is giving main character energy 💖 Constructive feedback on this document came from a surprisingly huge crew, including, but not limited to, the following people:

  • Bernard Aboba
  • Brian Carpenter
  • Stuart Cheshire
  • Joel Halpern
  • Wes Hardaker
  • Russ Housley
  • Cullen Jennings
  • Mallory Knodel
  • Mirja Kühlewind
  • Mark Nottingham
  • Eric Rescorla
  • Henning Schulzrinne
  • Job Snijders
  • Robert Sparks
  • Dave Thaler
  • Brian Trammell
  • Anne van Kesteren

And a special shoutout 🎀 Some of the properties of protocols described in Section 4.1 were observed by Marshall Rose in Section 4.5 of [RFC3117].

Authors' Addresses ✍️

Here's how to reach the two authors who wrote this one 💜

Martin Thomson
Email: mt@lowentropy.net


David Schinazi
Email: dschinazi.ietf@gmail.com
📦 where this page comes from