Long-Term Viability of Protocol Extension Mechanismsmt@lowentropy.nettpauly@apple.comExtensionsversionsgreaseThe ability to change protocols depends on exercising the extension
and version-negotiation mechanisms that support change. This document
explores how regular use of new protocol features can ensure that it
remains possible to deploy changes to a protocol. Examples are given
where lack of use caused changes to be more difficult or costly.Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Architecture Board
(IAB) and represents information that the IAB has deemed valuable
to provide for permanent record. It represents the consensus of the Internet
Architecture Board (IAB). Documents approved for publication
by the IAB are not candidates for any level of Internet Standard; see
Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Table of Contents
IntroductionA successful protocol needs
to change in ways that allow it to continue to fulfill the changing
needs of its users. New use cases, conditions, and constraints on the
deployment of a protocol can render a protocol that does not change
obsolete.Usage patterns and requirements for a protocol shift over time. In response,
implementations might adjust usage patterns within the constraints of the
protocol, the protocol could be extended, or a replacement protocol might be
developed. Experience with Internet-scale protocol deployment shows that each
option comes with different costs. examines the
problem of protocol evolution more broadly.An extension point is a mechanism that allows a protocol to be changed or
enhanced. This document examines the specific conditions that determine whether
protocol maintainers have the ability to design and deploy new or modified
protocols via their specified extension points. highlights
some historical examples of difficulties in transitions to new protocol
features. argues that ossified protocols are more difficult to
update and describes how successful protocols make frequent use of new
extensions and code points. outlines several additional strategies
that might aid in ensuring that protocol changes remain possible over time.The experience that informs this document is predominantly at "higher" layers of
the network stack, in protocols with limited numbers of participants. Though
similar issues are present in many protocols that operate at scale, the
trade-offs involved with applying some of the suggested techniques can be more
complex when there are many participants, such as at the network layer or in
routing systems.Imperfect Implementations Limit Protocol EvolutionIt can be extremely difficult to deploy a change to a protocol if
implementations with which the new deployment needs to interoperate do
not operate predictably. Variation in how new code points or extensions
are handled can be the result of bugs in implementation or
specifications.
Unpredictability can manifest as errors, crashes, timeouts, abrupt
termination of sessions, or disappearances of endpoints.
The risk of interoperability problems can in turn make it infeasible
to deploy certain protocol changes. If deploying a new code point or
extension makes an implementation less reliable than others, even if
only in rare cases, it is far less likely that implementations will
adopt the change.Deploying a change to a protocol could require implementations to fix
a substantial proportion of the bugs that the change exposes. This can
involve a difficult process that includes identifying the cause of these
errors, finding the responsible implementation(s), coordinating a bug
fix and release plan, contacting users and/or the operator of affected
services, and waiting for the fix to be deployed.Given the effort involved in fixing problems, the existence of these
sorts of bugs can outright prevent the deployment of some types of
protocol changes, especially for protocols involving multiple parties or
that are considered critical infrastructure (e.g., IP, BGP, DNS, or
TLS). It could even be necessary to come up with a new protocol design
that uses a different method to achieve the same result.This document only addresses cases where extensions are not deliberately
blocked. Some deployments or implementations apply policies that explicitly
prohibit the use of unknown capabilities. This is especially true of functions
that seek to make security guarantees, like firewalls.The set of interoperable features in a protocol is often the subset of its
features that have some value to those implementing and deploying the protocol.
It is not always the case that future extensibility is in that set.Good Protocol Design Is Not Itself SufficientIt is often argued that the careful design of a protocol extension
point or version-negotiation capability is critical to the freedom
that it ultimately offers.RFC 6709 contains a great
deal of well-considered advice on designing for extensions. It
includes the following advice:
This means that, to be useful, a protocol version-negotiation mechanism
should be simple enough that it can reasonably be assumed that all the
implementers of the first protocol version at least managed to implement the
version-negotiation mechanism correctly.
There are a number of protocols for which this has proven to be insufficient in
practice. These protocols have imperfect implementations of these mechanisms.
Mechanisms that aren't used are the ones that fail most often. The same
paragraph from RFC 6709 acknowledges the existence of this problem but does not
offer any remedy:
The nature of protocol version-negotiation mechanisms is that, by
definition, they don't get widespread real-world testing until
after the base protocol has been deployed for a while, and its
deficiencies have become evident.
Indeed, basic interoperability is considered critical early in the deployment of
a protocol. A desire to deploy can result in early focus on a reduced feature
set, which could result in deferring implementation of version-negotiation and
extension mechanisms. This leads to these mechanisms being particularly
affected by this problem.Disuse Can Hide ProblemsThere are many examples of extension points in protocols that have been either
completely unused or their use was so infrequent that they could no longer be
relied upon to function correctly. includes examples of disuse in a number of widely deployed Internet
protocols.Even where extension points have multiple valid values, if the set
of permitted values does not change over time, there is still a risk
that new values are not tolerated by existing implementations. If the
set of values for a particular field of a protocol or the order in which these
values appear remains fixed over a long period, some
implementations might not correctly handle a new value when it is
introduced. For example, implementations of TLS broke when new values
of the signature_algorithms extension were introduced.Multi-party Interactions and MiddleboxesOne of the key challenges in deploying new features is ensuring compatibility
with all actors that could be involved in the protocol. Even the most
superficially simple protocols can often involve more actors than is immediately
apparent.The design of extension points needs to consider what actions middleboxes
might take in response to a protocol change as well as the effect those actions
could have on the operation of the protocol.Deployments of protocol extensions also need to consider the impact
of the changes on entities beyond protocol participants and middleboxes.
Protocol changes can affect the behavior of applications or systems
that don't directly interact with the protocol, such as when a protocol
change modifies the formatting of data delivered to an application.Active UseThe design of a protocol for extensibility and eventual replacement
does not guarantee the ability
to exercise those options. The set of features that enable future
evolution need to be interoperable in the first implementations and
deployments of the protocol. Implementation of mechanisms that support
evolution is necessary to ensure that they remain available for new
uses, and history has shown this occurs almost exclusively through
active mechanism use.Only by using the extension capabilities of a protocol is the
availability of that capability assured. "Using" here includes
specifying, implementing, and deploying capabilities that rely on the
extension capability. Protocols that fail to use a mechanism, or a
protocol that only rarely uses a mechanism, could lead to that mechanism
being unreliable.Implementations that routinely see new values are more likely to
correctly handle new values. More frequent changes will improve the
likelihood that incorrect handling or intolerance is discovered and
rectified. The longer an intolerant implementation is deployed, the
more difficult it is to correct.Protocols that routinely add new extensions and code points rarely
have trouble adding additional ones especially when the handling of new
versions or extensions are well defined. The definition of mechanisms
alone is insufficient; it is the assured implementation and active use
of those mechanisms that determines their availability.What constitutes "active use" can depend greatly on the environment
in which a protocol is deployed. The frequency of changes necessary to
safeguard some mechanisms might be slow enough to attract ossification
in another protocol deployment, while being excessive in others.Dependency Is BetterThe easiest way to guarantee that a protocol mechanism is used is
to make the handling of it critical to an endpoint participating in
that protocol. This means that implementations must rely on both the
existence of extension mechanisms and their continued, repeated
expansion over time.For example, the message format in SMTP relies on header fields for most of its
functions, including the most basic delivery functions. A deployment of SMTP
cannot avoid including an implementation of header field handling. In addition
to this, the regularity with which new header fields are defined and used
ensures that deployments frequently encounter header fields that they do not yet
(and may never) understand. An SMTP implementation therefore needs to be able
to both process header fields that it understands and ignore those that it does
not.In this way, implementing the extensibility mechanism is not merely mandated by
the specification, it is crucial to the functioning of a protocol deployment.
Should an implementation fail to correctly implement the mechanism, that failure
would quickly become apparent.Caution is advised to avoid assuming that building a dependency on an extension
mechanism is sufficient to ensure availability of that mechanism in the long
term. If the set of possible uses is narrowly constrained and deployments do
not change over time, implementations might not see new variations or assume a
narrower interpretation of what is possible. Those implementations might still
exhibit errors when presented with new variations.Version NegotiationAs noted in ,
protocols that provide version-negotiation mechanisms might not be
able to test that feature until a new version is deployed. One
relatively successful design approach has been to use the protocol
selection mechanisms built into a lower-layer protocol to select the
protocol. This could allow a version-negotiation mechanism to benefit
from active use of the extension point by other protocols.For instance, all published versions of IP contain a version number
as the four high bits of the first header byte. However, version
selection using this field proved to be unsuccessful. Ultimately,
successful deployment of IPv6 over Ethernet required a different EtherType from IPv4. This
change took advantage of the already diverse usage of EtherType.Other examples of this style of design include Application-Layer
Protocol Negotiation () and
HTTP content negotiation ().This technique relies on the code point being usable. For instance,
the IP protocol number is known to be unreliable and therefore not
suitable .Falsifying Active Use"Grease" was originally defined for TLS but has been adopted by other protocols such as
QUIC . Grease identifies
lack of use as an issue (protocol mechanisms "rusting" shut) and
proposes reserving values for extensions that have no semantic value
attached.The design in is aimed at
the style of negotiation most used in TLS, where one endpoint offers a
set of options and the other chooses the one that it most prefers from
those that it supports. An endpoint that uses grease randomly offers
options, usually just one, from a set of reserved values. These
values are guaranteed to never be assigned real meaning, so its peer
will never have cause to genuinely select one of these values.More generally, greasing is used to refer to any attempt to
exercise extension points without changing endpoint behavior other
than to encourage participants to tolerate new or varying values of
protocol elements.The principle that grease operates on is that an implementation
that is regularly exposed to unknown values is less likely to be
intolerant of new values when they appear. This depends largely on
the assumption that the difficulty of implementing the extension
mechanism correctly is as easy or easier than implementing code to
identify and filter out reserved values. Reserving random or unevenly
distributed values for this purpose is thought to further discourage
special treatment.Without reserved greasing code points, an implementation can use
code points from spaces used for private or experimental use if such a
range exists. In addition to the risk of triggering participation in
an unwanted experiment, this can be less effective. Incorrect
implementations might still be able to identify these code points and
ignore them.In addition to advertising bogus capabilities, an endpoint might
also selectively disable noncritical protocol elements to test the
ability of peers to handle the absence of certain capabilities.This style of defensive design is limited because it is only
superficial. As greasing only mimics active use of an extension
point, it only exercises a small part of the mechanisms that support
extensibility. More critically, it does not easily translate to all
forms of extension points. For instance, highest mutually supported
version (HMSV) negotiation cannot be greased in this fashion. Other
techniques might be necessary for protocols that don't rely on the
particular style of exchange that is predominant in TLS.Grease is deployed with the intent of quickly revealing errors in implementing
the mechanisms it safeguards. Though it has been effective at revealing
problems in some cases with TLS, the efficacy of greasing isn't proven more
generally. Where implementations are able to tolerate a non-zero error rate in
their operation, greasing offers a potential option for safeguarding future
extensibility. However, this relies on there being a sufficient proportion of
participants that are willing to invest the effort and tolerate the risk of
interoperability failures.Examples of Active UseHeader fields in email ,
HTTP , and SIP all derive from the same basic
design, which amounts to a list of name/value pairs. There is no
evidence of significant barriers to deploying header fields with new
names and semantics in email and HTTP as clients and servers generally
ignore headers they do not understand or need. The widespread
deployment of SIP back-to-back user agents (B2BUAs), which generally
do not ignore unknown fields, means that new SIP header fields do not
reliably reach peers. This does not necessarily cause
interoperability issues in SIP but rather causes features to remain
unavailable until the B2BUA is updated. All three protocols are still
able to deploy new features reliably, but SIP features are deployed
more slowly due to the larger number of active participants that need
to support new features.As another example, the attribute-value pairs (AVPs) in Diameter
are fundamental to the design of the protocol. Any use of
Diameter requires exercising the ability to add new AVPs. This is routinely
done without fear that the new feature might not be successfully deployed.These examples show extension points that are heavily used are also being
relatively unaffected by deployment issues preventing addition of new values
for new use cases.These examples show that a good design is not required for success. On the
contrary, success is often despite shortcomings in the design. For instance,
the shortcomings of HTTP header fields are significant enough that there are
ongoing efforts to improve the syntax .Restoring Active UseWith enough effort, active use can be used to restore capabilities.Extension Mechanisms for DNS () was defined to provide extensibility in DNS.
Intolerance of the extension in DNS servers resulted in a fallback
method being widely deployed (see ). This
fallback resulted in EDNS being disabled for affected servers. Over
time, greater support for EDNS and increased reliance on it for
different features motivated a flag day where the workaround was removed.The EDNS example shows that effort can be used to restore capabilities. This is
in part because EDNS was actively used with most resolvers and servers. It was
therefore possible to force a change to ensure that extension capabilities would
always be available. However, this required an enormous coordination effort. A
small number of incompatible servers and the names they serve also became
inaccessible to most clients.Complementary TechniquesThe protections to protocol evolution that come from active use can
be improved through the use of other defensive techniques. The techniques listed
here might not prevent ossification on their own, but they can make active use more
effective.Fewer Extension PointsA successful protocol will include many potential types of
extensions. Designing multiple types of extension mechanisms, each
suited to a specific purpose, might leave some extension points less
heavily used than others.Disuse of a specialized extension point might render it unusable.
In contrast, having a smaller number of extension points with wide
applicability could improve the use of those extension points. Use of
a shared extension point for any purpose can protect rarer or more
specialized uses.Both extensions and core protocol elements use the same extension
points in protocols like HTTP and DIAMETER ; see .InvariantsDocumenting aspects of the protocol that cannot or will not change as extensions
or new versions are added can be a useful exercise.
defines invariants as:
Invariants are core properties that are consistent across the network and
do not change over extremely long time-scales.
Understanding what aspects of a protocol are invariant can help guide the
process of identifying those parts of the protocol that might change.
and are both examples of
documented invariants.As a means of protecting extensibility, a declaration of protocol
invariants is useful only to the extent that protocol participants are
willing to allow new uses for the protocol. A protocol that declares
protocol invariants relies on implementations understanding and
respecting those invariants. If active use is not possible for all
non-invariant parts of the protocol, greasing () might be used to improve the chance that
invariants are respected.Protocol invariants need to be clearly and concisely documented.
Including examples of aspects of the protocol that are not invariant,
such as , can be
used to clarify intent.Limiting ParticipationReducing the number of entities that can participate in a protocol
or limiting the extent of participation can reduce the number of
entities that might affect extensibility. Using TLS or other
cryptographic tools can therefore reduce the number of entities that
can influence whether new features are usable. also recommends the use
of encryption and integrity protection to limit participation. For
example, encryption is used by the QUIC protocol to limit the information that is
available to middleboxes and integrity protection prevents
modification.Effective FeedbackWhile not a direct means of protecting extensibility mechanisms,
feedback systems can be important to discovering problems.The visibility of errors is critical to the success of techniques like
grease (see ). The grease
design is most effective if a deployment has a means of detecting and
reporting errors. Ignoring errors could allow problems to become
entrenched.Feedback on errors is more important during the development and
early deployment of a change. It might also be helpful to disable
automatic error recovery methods during development.Automated feedback systems are important for automated systems, or
where error recovery is also automated. For instance, connection
failures with HTTP alternative services are not permitted to affect the outcome of
transactions. An automated feedback system for capturing failures in
alternative services is therefore necessary for failures to be
detected.How errors are gathered and reported will depend greatly on the
nature of the protocol deployment and the entity that receives the
report. For instance, end users, developers, and network operations
each have different requirements for how error reports are created,
managed, and acted upon.Automated delivery of error reports can be critical for rectifying
deployment errors as early as possible, as seen in and .Security ConsiderationsMany of the problems identified in this document are not the result
of deliberate actions by an adversary but more the result of mistakes,
decisions made without sufficient context, or simple neglect, i.e.,
problems therefore not the result of opposition by an adversary. In
response, the recommended measures generally assume that other protocol
participants will not take deliberate action to prevent protocol
evolution.The use of cryptographic techniques to exclude potential participants is the
only strong measure that the document recommends. However, authorized protocol
peers are most often responsible for the identified problems, which can mean
that cryptography is insufficient to exclude them.The ability to design, implement, and deploy new protocol mechanisms can be
critical to security. In particular, it is important to be able to replace
cryptographic algorithms over time . For example,
preparing for the replacement of weak hash algorithms was made more difficult
through misuse .IANA ConsiderationsThis document has no IANA actions.Informative ReferencesGuidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement AlgorithmsMany IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time.Transport Layer Security (TLS) Application-Layer Protocol Negotiation ExtensionThis document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.HTTP Alternative ServicesThis document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.Diameter Base ProtocolThe Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. [STANDARDS-TRACK]Domain-based Message Authentication, Reporting, and Conformance (DMARC)Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse.DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection.DNS Flag Day 2019Extension Mechanisms for DNS (EDNS(0))The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS.Is it still possible to extend TCP?IMC '11: Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conferenceDesign Considerations for Protocol ExtensionsThis document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS ExtensibilityThis document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values.Deploying a New Hash AlgorithmProceedings of NDSSHTTP SemanticsWork in ProgressStructured Field Values for HTTPThis document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.HTTP/1.1Work in ProgressRe: [TLS] Thoughts on Version IntoleranceTCP Extensions for Multipath Operation with Multiple AddressesTCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and thus improve user experience through higher throughput and improved resilience to network failure.Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., a reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths.This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC 6824, through clarifications and modifications primarily driven by deployment experience.How Hard Can It Be? Designing and Implementing a Deployable Multipath TCPOn the usability of transport protocols other than TCP: A home gateway and internet path traversal studyComputer Networks, Vol. 173, pp. 107211Transport Protocol Path SignalsThis document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.QUIC: A UDP-Based Multiplexed and Secure TransportThis document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.Version-Independent Properties of QUICThis document defines the properties of the QUIC transport protocol that are common to all versions of the protocol.IP Router Alert OptionThis memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. [STANDARDS-TRACK]IPv6 Router Alert OptionThis memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. [STANDARDS-TRACK]Internet ProtocolHost extensions for IP multicastingThis memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK]Transmission of IPv6 Packets over Ethernet NetworksThis document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. [STANDARDS-TRACK]Uncoordinated Protocol Development Considered HarmfulIABThis document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations (SDOs). Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as Transport MPLS (T-MPLS), as recent examples to describe the hazard to the Internet architecture that results from uncoordinated adaptation of a protocol.This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the "Joint working team on MPLS-TP". In addition, the leadership of the two organizations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETF RFCs.Whilst we use ITU-T - IETF interactions in these case studies, the scope of the document extends to all SDOs that have an overlapping protocol interest with the IETF. This memo provides information for the Internet community.Handling of Unknown DNS Resource Record (RR) TypesExtending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS-TRACK]SIP: Session Initiation ProtocolThis document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]Simple Mail Transfer ProtocolThis document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK]SMTP TLS ReportingA number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS- Based Authentication of Named Entities (DANE) TLSA, and MTA Strict Transport Security (MTA-STS). These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attacks and diagnose unintentional misconfigurations.[TLS] Accepting that other SNI name types will never work.Simple Network Management Protocol (SNMP)This RFC is a re-release of RFC 1098, with a changed "Status of this Memo" section plus a few minor typographical corrections. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. [STANDARDS-TRACK]Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization.This document obsoletes RFC 4408.What Makes for a Successful Protocol?The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work. This memo provides information for the Internet community.Transmission Control ProtocolTCP Fast OpenThis document describes an experimental TCP mechanism called TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section.Transport Layer Security (TLS) Extensions: Extension DefinitionsThis document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Planning for Protocol Adoption and Subsequent TransitionsOver the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol. Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions; thus, some transitions, such as the introduction of IPv6, have been difficult. This document attempts to summarize some basic principles to enable future transitions, and it also summarizes what makes for a good transition plan.ExamplesThis appendix contains a brief study of problems in a range of
Internet protocols at different layers of the stack.DNSOssified DNS code bases and systems resulted in new Resource Record
Codes (RRCodes) being unusable. A new code point would take years of
coordination between implementations and deployments before it could
be relied upon.
Consequently, use of the TXT record was overloaded in order to avoid
the effort and delays involved in allocating new code points; this
approach was used in the Sender Policy Framework and other protocols.
It was not until after the standard mechanism for dealing with new
RRCodes was considered
widely deployed that new RRCodes could be safely created and used.HTTPHTTP has a number of very effective extension points in addition to
the aforementioned header fields. It also has some examples of
extension points that are so rarely used that it is possible that they
are not at all usable.Extension points in HTTP that might be unwise to use include the
extension point on each chunk in the chunked transfer coding (),
the ability to use transfer codings other than the chunked coding, and
the range unit in a range request ().IPThe version field in IP was rendered useless when encapsulated over
Ethernet, requiring a new EtherType with IPv6 , due in part to Layer 2 devices making
version-independent assumptions about the structure of the IPv4
header.Protocol identifiers or code points that are reserved for future use
can be especially problematic. Reserving values without attributing
semantics to their use can result in diverse or conflicting semantics
being attributed without any hope of interoperability.
An example of this is the 224/3 address space in IPv4 that reserved without assigning any semantics. partially reclaimed that reserved address space for
use in multicast (224/4), but the remaining address space (240/4) has
not been successfully reclaimed for any purpose.
For protocols that can use negotiation to attribute semantics to
values, it is possible that unused code points can be reclaimed for
active use, though this requires that the negotiation include all
protocol participants. For something as fundamental as addressing,
negotiation is difficult or even impossible, as all nodes on the
network path plus potential alternative paths would need to be
involved.IP Router Alerts use IP options or extension
headers to indicate that data is intended for consumption by the next-hop
router rather than the addressed destination. In part, the
deployment of router alerts was unsuccessful due to the realities of
processing IP packets at line rates, combined with bad assumptions in
the protocol design about these performance constraints. However,
this was not exclusively down to design problems or bugs, as the
capability was also deliberately blocked at some routers.SNMPAs a counter example, the first version of the Simple Network Management
Protocol (SNMP) states that unparseable or unauthenticated
messages are simply discarded without response:
It then verifies the version number of the SNMP message. If
there is a mismatch, it discards the datagram and performs no
further actions.
When SNMP versions 2, 2c, and 3 came along, older agents did exactly
what the protocol specifies. Deployment of new versions was likely
successful because the handling of newer versions was both clear and
simple.TCPExtension points in TCP
have been rendered difficult to use largely due to middlebox
interactions; see .
For instance, multipath TCP () can
only be deployed opportunistically; see . Since MPTCP is a protocol enhancement that doesn't impair
the connection if it is blocked, network path intolerance of the extension
only results in the multipath functionality becoming unavailable.
In comparison, the deployment of TCP Fast Open () critically depends on extension
capability being widely available. Though very few network paths were
intolerant of the extension in absolute terms, TCP Fast Open could not
be deployed as a result.TLSTransport Layer Security (TLS) provides examples of where a
design that is objectively sound fails when incorrectly implemented. TLS
provides examples of failures in protocol version negotiation and extensibility.Version negotiation in TLS 1.2 and earlier uses the "Highest mutually supported
version (HMSV)" scheme exactly as it is described in .
However, clients are unable to advertise a new version without causing a
non-trivial proportion of sessions to fail due to bugs in server and middlebox
implementations.Intolerance to new TLS versions is so severe that TLS 1.3
abandoned HMSV version negotiation for a new mechanism.The server name indication (SNI) in TLS is another
excellent example of the failure of a well-designed extensibility point. SNI
uses the same technique for extensions that is used successfully in other parts
of the TLS protocol. The original design of SNI anticipated the ability to
include multiple names of different types.SNI was originally defined with just one type of name: a domain name. No other
type has ever been standardized, though several have been proposed. Despite an
otherwise exemplary design, SNI is so inconsistently implemented that any hope
for using the extension point it defines has been abandoned .IAB Members at the Time of Approval
Internet Architecture Board members at the time this document was
approved for publication were:
Acknowledgments, , , , , and
made significant contributions to this document.Authors' Addressesmt@lowentropy.nettpauly@apple.com