< draft-thomson-use-it-or-lose-it-03.txt   draft-thomson-use-it-or-lose-it-04.txt >
Network Working Group M. Thomson Network Working Group M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Informational January 02, 2019 Intended status: Informational July 08, 2019
Expires: July 6, 2019 Expires: January 9, 2020
Long-term Viability of Protocol Extension Mechanisms Long-term Viability of Protocol Extension Mechanisms
draft-thomson-use-it-or-lose-it-03 draft-thomson-use-it-or-lose-it-04
Abstract Abstract
The ability to change protocols depends on exercising the extension The ability to change protocols depends on exercising the extension
and version negotiation mechanisms that support change. Protocols and version negotiation mechanisms that support change. Protocols
that don't use these mechanisms can find that deploying changes can that don't use these mechanisms can find that deploying changes can
be difficult and costly. be difficult and costly.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 6, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Implementations of Protocols are Imperfect . . . . . . . . . 3 2. Implementations of Protocols are Imperfect . . . . . . . . . 3
2.1. Good Protocol Design is Not Sufficient . . . . . . . . . 3 2.1. Good Protocol Design is Not Itself Sufficient . . . . . . 3
2.2. Multi-Party Interactions and Middleboxes . . . . . . . . 5 2.2. Multi-Party Interactions and Middleboxes . . . . . . . . 5
3. Retaining Viable Protocol Evolution Mechanisms . . . . . . . 6 3. Retaining Viable Protocol Evolution Mechanisms . . . . . . . 6
3.1. Examples of Active Use . . . . . . . . . . . . . . . . . 6 3.1. Examples of Active Use . . . . . . . . . . . . . . . . . 7
3.2. Dependency is Better . . . . . . . . . . . . . . . . . . 7 3.2. Dependency is Better . . . . . . . . . . . . . . . . . . 7
3.3. Unused Extension Points Become Unusable . . . . . . . . . 7 3.3. Unused Extension Points Become Unusable . . . . . . . . . 8
4. Defensive Design Principles for Protocols . . . . . . . . . . 8 4. Defensive Design Principles for Protocols . . . . . . . . . . 9
4.1. Active Use . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Active Use . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Grease . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Cryptography . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Cryptography . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Grease . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Effective Feedback . . . . . . . . . . . . . . . . . . . 10 4.4. Invariants . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4.5. Effective Feedback . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Informative References . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Informative References . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
A successful protocol [SUCCESS] will change in ways that allow it to A successful protocol [SUCCESS] will change in ways that allow it to
continue to fulfill the needs of its users. New use cases, continue to fulfill the needs of its users. New use cases,
conditions and constraints on the deployment of a protocol can render conditions and constraints on the deployment of a protocol can render
a protocol that does not change obsolete. a protocol that does not change obsolete.
Usage patterns and requirements for a protocol shift over time. Usage patterns and requirements for a protocol shift over time. In
Protocols can react to these shifts in one of three ways: adjust response, implementations might adjust usage patterns within the
usage patterns within the constraints of the protocol, extend the constraints of the protocol, the protocol could be extended, or a
protocol, and replace the protocol. These reactions are replacement protocol might be developed. Experience with Internet-
progressively more disruptive, but are also dictated by the nature of scale protocol deployment shows that each option comes with different
the change in requirements over longer periods. costs. [TRANSITIONS] examines the problem of protocol evolution more
broadly.
Experience with Internet-scale protocol deployment shows that
changing protocols is not uniformly successful. [TRANSITIONS]
examines the problem more broadly.
This document examines the specific conditions that determine whether This document examines the specific conditions that determine whether
protocol maintainers have the ability to design and deploy new or protocol maintainers have the ability to design and deploy new or
modified protocols. Section 4 outlines several strategies that might modified protocols. Section 2 highlights some historical issues with
aid in ensuring that protocol changes remain possible over time. difficulties in transitions to new protocol features. Section 3
argues that ossified protocols are more difficult to update and
successful protocols make frequent use of new extensions and code-
points. Section 4 outlines several 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 that operate at
very large scale and Internet-scale applications. It is possible
that these conclusions are less applicable to protocol deployments
that have less scale and diversity, or operate under different
constraints.
2. Implementations of Protocols are Imperfect 2. Implementations of Protocols are Imperfect
A change to a protocol can be made extremely difficult to deploy if A change to a protocol can be made extremely difficult to deploy if
there are bugs in implementations with which the new deployment needs there are bugs in implementations with which the new deployment needs
to interoperate. Bugs in the handling of new codepoints or to interoperate. Bugs in the handling of new codepoints or
extensions can mean that instead of handling the mechanism as extensions can mean that instead of handling the mechanism as
designed, endpoints react poorly. This can manifest as abrupt designed, endpoints react poorly. This can manifest as abrupt
termination of sessions, errors, crashes, or disappearances of termination of sessions, errors, crashes, or disappearances of
endpoints and timeouts. endpoints and timeouts.
Interoperability with other implementations is usually highly valued, Interoperability with other implementations is usually highly valued,
so deploying mechanisms that trigger adverse reactions like these can so deploying mechanisms that trigger adverse reactions can be
be untenable. Where interoperability is a competitive advantage, untenable. Where interoperability is a competitive advantage, this
this is true even if the negative reactions happen infrequently or is true even if the negative reactions happen infrequently or only
only under relatively rare conditions. under relatively rare conditions.
Deploying a change to a protocol could require fixing a substantial Deploying a change to a protocol could require implementations fix a
proportion of the bugs that the change exposes. This can involve a substantial proportion of the bugs that the change exposes. This can
difficult process that includes identifying the cause of these involve a difficult process that includes identifying the cause of
errors, finding the responsible implementation, coordinating a bug these errors, finding the responsible implementation(s), coordinating
fix and release plan, contacting the operator of affected services, a bug fix and release plan, contacting users and/or the operator of
and waiting for the fix to be deployed to those services. affected services, and waiting for the fix to be deployed.
Given the effort involved in fixing these problems, the existence of Given the effort involved in fixing problems, the existence of these
these sorts of bugs can outright prevent the deployment of some types sorts of bugs can outright prevent the deployment of some types of
of protocol changes. It could even be necessary to come up with a protocol changes, especially for protocols involving multiple parties
new protocol design that uses a different method to achieve the same or that are considered critical infrastructure (e.g., IP, BGP, DNS,
result. 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.
The set of interoperable features in a protocol is often the subset The set of interoperable features in a protocol is often the subset
of its features that have some value to those implementing and of its features that have some value to those implementing and
deploying the protocol. It is not always the case that future deploying the protocol. It is not always the case that future
extensibility is in that set. extensibility is in that set.
2.1. Good Protocol Design is Not Sufficient 2.1. Good Protocol Design is Not Itself Sufficient
It is often argued that the design of a protocol extension point or It is often argued that the design of a protocol extension point or
version negotiation capability is critical to the freedom that it version negotiation capability is critical to the freedom that it
ultimately offers. ultimately offers.
RFC 6709 [EXTENSIBILITY] contains a great deal of well-considered RFC 6709 [EXTENSIBILITY] contains a great deal of well-considered
advice on designing for extension. It includes the following advice: advice on designing for extension. It includes the following advice:
This means that, to be useful, a protocol version- negotiation This means that, to be useful, a protocol version- negotiation
mechanism should be simple enough that it can reasonably be mechanism should be simple enough that it can reasonably be
assumed that all the implementers of the first protocol version at assumed that all the implementers of the first protocol version at
least managed to implement the version-negotiation mechanism least managed to implement the version-negotiation mechanism
correctly. correctly.
This has proven to be insufficient in practice. Many protocols have This has proven to be insufficient in practice. Many protocols have
evidence of imperfect implementation of these critical mechanisms. evidence of imperfect implementation of critical mechanisms of this
Mechanisms that aren't used are the ones that fail most often. The sort. Mechanisms that aren't used are the ones that fail most often.
same paragraph from RFC 6709 acknowledges the existence of this The same paragraph from RFC 6709 acknowledges the existence of this
problem, but does not offer any remedy: problem, but does not offer any remedy:
The nature of protocol version-negotiation mechanisms is that, by The nature of protocol version-negotiation mechanisms is that, by
definition, they don't get widespread real-world testing until definition, they don't get widespread real-world testing until
_after_ the base protocol has been deployed for a while, and its _after_ the base protocol has been deployed for a while, and its
deficiencies have become evident. deficiencies have become evident.
Indeed, basic interoperability is considered critical early in the Indeed, basic interoperability is considered critical early in the
deployment of a protocol, and any engineering practice that values deployment of a protocol. Race-to-market attitudes frequently result
simplicity will tend to make version negotiation and extension in an engineering practice that values simplicity will tend to make
mechanisms optional for this basic interoperability. This leads to version negotiation and extension mechanisms optional for this basic
these mechanisms being uniquely affected by this problem. interoperability. This leads to these mechanisms being uniquely
affected by this problem.
Transport Layer Security (TLS) [TLS12] provides examples of where a Transport Layer Security (TLS) [TLS12] provides examples of where a
design that is objectively sound fails when incorrectly implemented. design that is objectively sound fails when incorrectly implemented.
TLS provides examples of failures in protocol version negotiation and TLS provides examples of failures in protocol version negotiation and
extensibility. extensibility.
Version negotiation in TLS 1.2 and earlier uses the "Highest mutually Version negotiation in TLS 1.2 and earlier uses the "Highest mutually
supported version (HMSV)" scheme exactly as it is described in supported version (HMSV)" scheme exactly as it is described in
[EXTENSIBILITY]. However, clients are unable to advertise a new [EXTENSIBILITY]. However, clients are unable to advertise a new
version without causing a non-trivial proportions of sessions to fail version without causing a non-trivial proportions of sessions to fail
skipping to change at page 5, line 5 skipping to change at page 5, line 9
original design of SNI includes the ability to include multiple names original design of SNI includes the ability to include multiple names
of different types. of different types.
What is telling in this case is that SNI was defined with just one What is telling in this case is that SNI was defined with just one
type of name: a domain name. No other type has ever been type of name: a domain name. No other type has ever been
standardized, though several have been proposed. Despite an standardized, though several have been proposed. Despite an
otherwise exemplary design, SNI is so inconsistently implemented that otherwise exemplary design, SNI is so inconsistently implemented that
any hope for using the extension point it defines has been abandoned any hope for using the extension point it defines has been abandoned
[SNI]. [SNI].
Requiring simplistic processing steps when encountering unknown
conditions, such as unsupported version numbers, can potentially
prevent these sorts of situations. A counter example is the first
version of the Simple Network Management Protocol (SNMP), where an
unparseable and an authentication message are treated the same way by
the server: no response is generated [SNMPv1]:
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 should have done: dropped it from being
processing without returning a response. This was likely successful
because there was no requirement to create and return an elaborate
error response to the client.
2.2. Multi-Party Interactions and Middleboxes 2.2. Multi-Party Interactions and Middleboxes
Even the most superficially simple protocols can often involve more Even the most superficially simple protocols can often involve more
actors than is immediately apparent. A two-party protocol has two actors than is immediately apparent. A two-party protocol has two
ends, but even at the endpoints of an interaction, protocol elements ends, but even at the endpoints of an interaction, protocol elements
can be passed on to other entities in ways that can affect protocol can be passed on to other entities in ways that can affect protocol
operation. operation.
One of the key challenges in deploying new features in a protocol is One of the key challenges in deploying new features is ensuring
ensuring compatibility with all actors that could influence the compatibility with all actors that could be involved in the protocol.
outcome.
Protocols deployed without active measures against intermediation Protocols deployed without active measures against intermediation
will tend to become intermediated over time, as network operators will tend to become intermediated over time, as network operators
deploy middleboxes to perform some function on traffic. In deploy middleboxes to perform some function on traffic
particular, one of the consequences of an unencrypted protocol is [PATH-SIGNALS]. In particular, one of the consequences of an
that any element on path can interact with the protocol. For unencrypted protocol is that any element on path can interact with
example, HTTP was specifically designed with intermediation in mind, the protocol. For example, HTTP was specifically designed with
transparent proxies [HTTP] are not only possible but sometimes intermediation in mind, transparent proxies [HTTP] are not only
advantageous, despite some significant downsides. Consequently, possible but sometimes advantageous, despite some significant
transparent proxies for cleartext HTTP are commonplace. downsides. Consequently, transparent proxies for cleartext HTTP are
commonplace. The DNS protocol was designed with intermediation in
mind through its use of caching recursive resolvers [DNS]. What was
less anticipated was the forced spoofing of DNS records by many
middle-boxes such as those that inject authentication or pay-wall
mechanisms as an authentication and authorization check, which are
now prevalent in hotels, coffee shops and business networks.
Middleboxes are also protocol participants, to the degree that they Middleboxes are also protocol participants, to the degree that they
are able to observe and act in ways that affect the protocol. The are able to observe and act in ways that affect the protocol. The
degree to which a middlebox participates varies from the basic degree to which a middlebox participates varies from the basic
functions that a router performs to full participation. For example, functions that a router performs to full participation. For example,
a SIP back-to-back user agent (B2BUA) [B2BUA] can be very deeply a SIP back-to-back user agent (B2BUA) [B2BUA] can be very deeply
involved in the SIP protocol. involved in the SIP protocol.
This phenomenon appears at all layers of the protocol stack, even This phenomenon appears at all layers of the protocol stack, even
when protocols are not designed with middlebox participation in mind. when protocols are not designed with middlebox participation in mind.
TCP's [TCP] extension points have been rendered difficult to use, TCP's [TCP] extension points have been rendered difficult to use,
largely due to middlebox interactions, as experience with Multipath largely due to middlebox interactions, as experience with Multipath
TCP [MPTCP] has shown. IP's version field was rendered useless when TCP [MPTCP] and Fast Open [TFO] has shown. IP's version field was
encapsulated over Ethernet, requring a new ethertype with IPv6 rendered useless when encapsulated over Ethernet, requring a new
[RFC2462], due in part to layer 2 devices making version-independent ethertype with IPv6 [RFC2462], due in part to layer 2 devices making
assumptions about the structure of the IPv4 header. version-independent assumptions about the structure of the IPv4
header.
By increasing the number of different actors involved in any single By increasing the number of different actors involved in any single
protocol exchange, the number of potential implementation bugs that a protocol exchange, the number of potential implementation bugs that a
deployment needs to contend with also increases. In particular, deployment needs to contend with also increases. In particular,
incompatible changes to a protocol that might be negotiated between incompatible changes to a protocol that might be negotiated between
endpoints in ignorance of the presence of a middlebox can result in a endpoints in ignorance of the presence of a middlebox can result in a
middlebox acting badly. middlebox interfering in negative and unexpected ways.
Thus, middleboxes can increase the difficulty of deploying changes to Unfortunately, middleboxes can considerably increase the difficulty
a protocol considerably. of deploying new versions or other changes to a protocol.
3. Retaining Viable Protocol Evolution Mechanisms 3. Retaining Viable Protocol Evolution Mechanisms
The design of a protocol for extensibility and eventual replacement The design of a protocol for extensibility and eventual replacement
[EXTENSIBILITY] does not guarantee the ability to exercise those [EXTENSIBILITY] does not guarantee the ability to exercise those
options. The set of features that enable future evolution need to be options. The set of features that enable future evolution need to be
interoperable in the first implementations and deployments of the interoperable in the first implementations and deployments of the
protocol. Active use of mechanisms that support evolution is the protocol. Active use of mechanisms that support evolution is the
only way to ensure that they remain available for new uses. only way to ensure that they remain available for new uses.
3.1. Examples of Active Use
The conditions for retaining the ability to evolve a design is most The conditions for retaining the ability to evolve a design is most
clearly evident in the protocols that are known to have viable clearly evident in the protocols that are known to have viable
version negotiation or extension points. The definition of version negotiation or extension points. The definition of
mechanisms alone is insufficient; it's the active use of those mechanisms alone is insufficient; it's the active use of those
mechanisms that determines the existence of freedom. mechanisms that determines the existence of freedom. Protocols that
routinely add new extensions and code points rarely have trouble
adding additional ones, especially when unknown code-points and
extensions are to be safely ignored when not understood.
3.1. Examples of Active Use
For example, header fields in email [SMTP], HTTP [HTTP] and SIP [SIP] For example, header fields in email [SMTP], HTTP [HTTP] and SIP [SIP]
all derive from the same basic design. There is no evidence of all derive from the same basic design, which amounts to a list name/
significant barriers to deploying header fields with new names and value pairs. There is no evidence of significant barriers to
semantics in email and HTTP, though the widespread deployment of SIP deploying header fields with new names and semantics in email and
B2BUAs means that new SIP header fields can be more difficult. HTTP as clients and servers can ignore headers they do not understand
or need. The widespread deployment of SIP B2BUAs means that new SIP
header fields do not reliably reach peers, however, which doesn't
necessarily cause interoperability issues but rather does cause
feature deployment issues.
In another example, the attribute-value pairs (AVPs) in Diameter In another example, the attribute-value pairs (AVPs) in Diameter
[DIAMETER] are fundamental to the design of the protocol. The [DIAMETER] are fundamental to the design of the protocol. Any use of
definition of new uses of Diameter regularly exercise the ability to Diameter requires exercising the ability to add new AVPs. This is
add new AVPs and do so with no fear that the new feature might not be routinely done without fear that the new feature might not be
successfully deployed. successfully deployed.
These examples show extension points that are heavily used also being Ossified DNS code bases and systems resulted in fears that new
relatively unaffected by deployment issues preventing addition of new Resource Record Codes (RRCodes) would take years of software
values for new use cases. propagation before new RRCodes could be used. The result for a long
time was heavily overloaded use of the TXT record, such as in the
Sender Policy Framework [SPF]. It wasn't until after the standard
mechanism for dealing with new RRCodes [RRTYPE] was considered widely
deployed that new RRCodes can be safely created and used immediately.
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 also confirm the case that good design is not a These examples also confirm the case that good design is not a
prerequisite for success. On the contrary, success is often despite prerequisite for success. On the contrary, success is often despite
shortcomings in the design. For instance, the shortcomings of HTTP shortcomings in the design. For instance, the shortcomings of HTTP
header fields are significant enough that there are ongoing efforts header fields are significant enough that there are ongoing efforts
to improve the syntax [HTTP-HEADERS]. to improve the syntax [HTTP-HEADERS].
Only using a protocol capability is able to ensure availability of Only by using a protocol's extension capabilities does it ensure the
that capability. Protocols that fail to use a mechanism, or a availability of that capability. Protocols that fail to use a
protocol that only rarely uses a mechanism, suffer an inability to mechanism, or a protocol that only rarely uses a mechanism, may
rely on that mechanism. suffer an inability to rely on that mechanism.
3.2. Dependency is Better 3.2. Dependency is Better
The best way to guarantee that a protocol mechanism is used is to The best way to guarantee that a protocol mechanism is used is to
make it critical to an endpoint participating in that protocol. This make it critical to an endpoint participating in that protocol. This
means that implementations rely on both the existence of the protocol means that implementations rely on both the existence of the protocol
mechanism and its use. mechanism and its use.
For example, the message format in SMTP relies on header fields for For example, the message format in SMTP relies on header fields for
most of its functions, including the most basic functions. A most of its functions, including the most basic functions. A
skipping to change at page 8, line 10 skipping to change at page 9, line 5
Even where extension points have multiple valid values, if the set of Even where extension points have multiple valid values, if the set of
permitted values does not change over time, there is still a risk permitted values does not change over time, there is still a risk
that new values are not tolerated by existing implementations. If that new values are not tolerated by existing implementations. If
the set of values for a particular field remains fixed over a long the set of values for a particular field remains fixed over a long
period, some implementations might not correctly handle a new value period, some implementations might not correctly handle a new value
when it is introduced. For example, implementations of TLS broke when it is introduced. For example, implementations of TLS broke
when new values of the signature_algorithms extension were when new values of the signature_algorithms extension were
introduced. introduced.
Codepoints that are reserved for future use can be especially
problematic. Reserving codepoints 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 "class E" address space in IPv4 [RFC0988], which was reserved
without assigning any semantics. For protocols that can use
negotiation to attribute semantics to codepoints, it is possible that
unused codepoints can be reclaimed for active use, though this
requires that the negotiation include all protocol participants.
4. Defensive Design Principles for Protocols 4. Defensive Design Principles for Protocols
There are several potential approaches that can provide some measure There are several potential approaches that can provide some measure
of protection against a protocol deployment becoming resistant to of protection against a protocol deployment becoming resistant to
change. change.
4.1. Active Use 4.1. Active Use
As discussed in Section 3, the most effective defense against misuse As discussed in Section 3, the most effective defense against misuse
of protocol extension points is active use. of protocol extension points is active use.
skipping to change at page 8, line 37 skipping to change at page 9, line 42
more difficult it is to correct. more difficult it is to correct.
What active use means could depend greatly on the environment in What active use means could depend greatly on the environment in
which a protocol is deployed. The frequency of changes necessary to which a protocol is deployed. The frequency of changes necessary to
safeguard some mechanisms might be slow enough to attract safeguard some mechanisms might be slow enough to attract
ossification in another protocol deployment, while being excessive in ossification in another protocol deployment, while being excessive in
others. There are currently no firm guidelines for new protocol others. There are currently no firm guidelines for new protocol
development, as much is being learned about what techniques are most development, as much is being learned about what techniques are most
effective. effective.
4.2. Grease 4.2. Cryptography
Cryptography can be used to reduce the number of entities that can
participate in a protocol. Using tools like TLS ensures that only
authorized participants are able to influence whether a new protocol
feature is used.
Permitting fewer protocol participants reduces the number of
implementations that can prevent a new mechanism from being deployed.
As recommended in [PATH-SIGNALS], use of encryption and integrity
protection can be used to limit participation.
For example, the QUIC protocol [QUIC] adopts both encryption and
integrity protection. Encryption is used to carefully control what
information is exposed to middleboxes. For those fields that are not
encrypted, QUIC uses integrity protection to prevent modification.
4.3. Grease
"Grease" [GREASE] identifies lack of use as an issue (protocol "Grease" [GREASE] identifies lack of use as an issue (protocol
mechanisms "rusting" shut) and proposes a system of use that mechanisms "rusting" shut) and proposes reserving values for
exercises extension points by using dummy values. extensions that have no semantic value attached.
The primary feature of the grease design is aimed at the style of The design in [GREASE] is aimed at the style of negotiation most used
negotiation most used in TLS, where the client offers a set of in TLS, where the client offers a set of options and the server
options and the server chooses the one that it most prefers from chooses the one that it most prefers from those that it supports. A
those that it supports. A client that uses grease randomly offers client that uses grease randomly offers options - usually just one -
options - usually just one - from a set of reserved values. These from a set of reserved values. These values are guaranteed to never
values are guaranteed to never be assigned real meaning, so the be assigned real meaning, so the server will never have cause to
server will never have cause to genuinely select one of these values. 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 The principle that grease operates on is that an implementation that
is regularly exposed to unknown values is not likely to become is regularly exposed to unknown values is less likely to be
intolerant of new values when they appear. This depends largely on intolerant of new values when they appear. This depends largely on
the assumption that the difficulty of implementing the protocol the assumption that the difficulty of implementing the extension
mechanism correctly is not significantly more effort than mechanism correctly is not significantly more effort than
implementing code to specifically filter out the randomized grease implementing code to identify and filter out reserved values.
values. Reserving random or unevenly distributed values for this purpose is
thought to further discourage special treatment.
To avoid simple techniques for filtering greasing codepoints, grease
values are not reserved from a single contiguous block of code
points, but are distributed evenly across the entire space of code
points. Reserving a randomly selected set of code points has a
greater chance of avoiding this problem, though it might be more
difficult to specify and implement, especially over larger code point
spaces.
Without reserved greasing codepoints, an implementation can use code Without reserved greasing codepoints, an implementation can use code
points from spaces used for private or experimental use if such a points from spaces used for private or experimental use if such a
range exists. In addition to the risk of triggering participation in range exists. In addition to the risk of triggering participation in
an unwanted experiment, this can be less effective. Incorrect an unwanted experiment, this can be less effective. Incorrect
implementations might still be able to correctly identify these code implementations might still be able to correctly identify these code
points and ignore them. points and ignore them.
Grease is deployed with the intent of quickly detecting errors in In addition to advertising bogus capabilities, an endpoint might also
implementing the mechanisms it safeguards. Though it has been selectively disable non-critical protocol elements to test the
effective at revealing problems in some cases with TLS, its efficacy ability of peers to handle the absence of certain capabilities.
isn't proven more generally.
This style of defensive design has some limitations. It does not This style of defensive design is limited because it is only
necessarily create the need for an implementation to rely on the superficial. It only exercises a small part of the mechanisms that
mechanism it safeguards; that is determined by the underlying support extensibility. More critically, it does not easily translate
protocol itself. More critically, it does not easily translate to to all forms of extension point. For instance, HMSV negotiation
other forms of extension point. For instance, HMSV negotiation
cannot be greased in this fashion. Other techniques might be cannot be greased in this fashion. Other techniques might be
necessary for protocols that don't rely on the particular style of necessary for protocols that don't rely on the particular style of
exchange that is predominant in TLS. exchange that is predominant in TLS.
4.3. Cryptography 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.
Cryptography can be used to reduce the number of entities that can 4.4. Invariants
participate in a protocol. Using tools like TLS ensures that only
authorized participants are able to influence whether a new protocol
feature is used.
Permitting fewer protocol participants reduces the number of Documenting aspects of the protocol that cannot or will not change as
implementations that can prevent a new mechanism from being deployed. extensions or new versions are added can be a useful exercise.
As recommended in [PATH-SIGNALS], use of encryption and integrity Understanding what aspects of a protocol are invariant can help guide
protection can be used to limit participation. the process of identifying those parts of the protocol that might
change.
For example, the QUIC protocol [QUIC] adopts both encryption and As a means of protecting extensibility, a declaration of protocol
integrity protection. Encryption is used to carefully control what invariants is useful only to the extent that protocol participants
information is exposed to middleboxes. For those fields that are not are willing to allow new uses for the protocol. Like greasing,
encrypted, QUIC uses integrity protection to prevent modification. protocol participants could still purposefully block the deployment
of new features. A protocol that declares protocol invariants relies
on implementations understanding and respecting those invariants.
4.4. Effective Feedback Protocol invariants need to be clearly and concisely documented.
Including examples of aspects of the protocol that are not invariant,
such as the appendix of [QUIC-INVARIANTS], can be used to clarify
intent.
4.5. Effective Feedback
While not a direct means of protecting extensibility mechanisms, While not a direct means of protecting extensibility mechanisms,
feedback systems can be important to discovering problems. feedback systems can be important to discovering problems.
Visibility of errors is critical to the success of the grease Visibility of errors is critical to the success of the grease
technique (see Section 4.2). The grease design is most effective if technique (see Section 4.3). The grease design is most effective if
a deployment has a means of detecting and reporting errors. Ignoring a deployment has a means of detecting and reporting errors. Ignoring
errors could allow problems to become entrenched. errors could allow problems to become entrenched.
Feedback on errors is more important during the development and early Feedback on errors is more important during the development and early
deployment of a change. It might also be helpful to disable deployment of a change. It might also be helpful to disable
automatic error recovery methods during development. automatic error recovery methods during development.
Automated feedback systems are important for automated systems, or Automated feedback systems are important for automated systems, or
where error recovery is also automated. For instance, connection where error recovery is also automated. For instance, connection
failures with HTTP alternative services [ALT-SVC] are not permitted failures with HTTP alternative services [ALT-SVC] are not permitted
to affect the outcome of transactions. An automated feedback system to affect the outcome of transactions. An automated feedback system
for capturing failures in alternative services is therefore necessary for capturing failures in alternative services is therefore necessary
for failures to be detected. 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.
5. Security Considerations 5. Security Considerations
The ability to design, implement, and deploy new protocol mechanisms The ability to design, implement, and deploy new protocol mechanisms
can be critical to security. In particular, it is important to be can be critical to security. In particular, it is important to be
able to replace cryptographic algorithms over time [AGILITY]. For able to replace cryptographic algorithms over time [AGILITY]. For
example, preparing for replacement of weak hash algorithms was made example, preparing for replacement of weak hash algorithms was made
more difficult through misuse [HASH]. more difficult through misuse [HASH].
6. IANA Considerations 6. IANA Considerations
skipping to change at page 11, line 16 skipping to change at page 12, line 48
Initiation Protocol (SIP) Back-to-Back User Agents", Initiation Protocol (SIP) Back-to-Back User Agents",
RFC 7092, DOI 10.17487/RFC7092, December 2013, RFC 7092, DOI 10.17487/RFC7092, December 2013,
<https://www.rfc-editor.org/info/rfc7092>. <https://www.rfc-editor.org/info/rfc7092>.
[DIAMETER] [DIAMETER]
Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733, Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012, DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>. <https://www.rfc-editor.org/info/rfc6733>.
[DNS] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[EXTENSIBILITY] [EXTENSIBILITY]
Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709, Considerations for Protocol Extensions", RFC 6709,
DOI 10.17487/RFC6709, September 2012, DOI 10.17487/RFC6709, September 2012,
<https://www.rfc-editor.org/info/rfc6709>. <https://www.rfc-editor.org/info/rfc6709>.
[GREASE] Benjamin, D., "Applying GREASE to TLS Extensibility", [GREASE] Benjamin, D., "Applying GREASE to TLS Extensibility",
draft-ietf-tls-grease-01 (work in progress), June 2018. draft-ietf-tls-grease-02 (work in progress), January 2019.
[HASH] Bellovin, S. and E. Rescorla, "Deploying a New Hash [HASH] Bellovin, S. and E. Rescorla, "Deploying a New Hash
Algorithm", Proceedings of NDSS '06 , 2006, Algorithm", Proceedings of NDSS '06 , 2006,
<https://www.cs.columbia.edu/~smb/papers/new-hash.pdf>. <https://www.cs.columbia.edu/~smb/papers/new-hash.pdf>.
[HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[HTTP-HEADERS] [HTTP-HEADERS]
Nottingham, M. and P. Kamp, "Structured Headers for HTTP", Nottingham, M. and P. Kamp, "Structured Headers for HTTP",
draft-ietf-httpbis-header-structure-09 (work in progress), draft-ietf-httpbis-header-structure-10 (work in progress),
December 2018. April 2019.
[HTTP-RANGE] [HTTP-RANGE]
Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests", "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
RFC 7233, DOI 10.17487/RFC7233, June 2014, RFC 7233, DOI 10.17487/RFC7233, June 2014,
<https://www.rfc-editor.org/info/rfc7233>. <https://www.rfc-editor.org/info/rfc7233>.
[INTOLERANCE] [INTOLERANCE]
Kario, H., "Re: [TLS] Thoughts on Version Intolerance", Kario, H., "Re: [TLS] Thoughts on Version Intolerance",
July 2016, <https://mailarchive.ietf.org/arch/msg/tls/ July 2016, <https://mailarchive.ietf.org/arch/msg/tls/
bOJ2JQc3HjAHFFWCiNTIb0JuMZc>. bOJ2JQc3HjAHFFWCiNTIb0JuMZc>.
[MPTCP] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, [MPTCP] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<https://www.rfc-editor.org/info/rfc6824>. <https://www.rfc-editor.org/info/rfc6824>.
[PATH-SIGNALS] [PATH-SIGNALS]
Hardie, T., "Transport Protocol Path Signals", draft-iab- Hardie, T., "Transport Protocol Path Signals", draft-iab-
path-signals-02 (work in progress), November 2018. path-signals-03 (work in progress), January 2019.
[QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-17 (work and Secure Transport", draft-ietf-quic-transport-20 (work
in progress), December 2018. in progress), April 2019.
[QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC",
draft-ietf-quic-invariants-04 (work in progress), April
2019.
[RFC0988] Deering, S., "Host extensions for IP multicasting",
RFC 988, DOI 10.17487/RFC0988, July 1986,
<https://www.rfc-editor.org/info/rfc988>.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, DOI 10.17487/RFC2462, Autoconfiguration", RFC 2462, DOI 10.17487/RFC2462,
December 1998, <https://www.rfc-editor.org/info/rfc2462>. December 1998, <https://www.rfc-editor.org/info/rfc2462>.
[RRTYPE] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
2003, <https://www.rfc-editor.org/info/rfc3597>.
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[SMTP] Resnick, P., Ed., "Internet Message Format", RFC 5322, [SMTP] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[SNI] Langley, A., "Accepting that other SNI name types will [SNI] Langley, A., "Accepting that other SNI name types will
never work", March 2016, never work", March 2016,
<https://mailarchive.ietf.org/arch/msg/ <https://mailarchive.ietf.org/arch/msg/
tls/1t79gzNItZd71DwwoaqcQQ_4Yxc>. tls/1t79gzNItZd71DwwoaqcQQ_4Yxc>.
[SNMPv1] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", RFC 1157,
DOI 10.17487/RFC1157, May 1990,
<https://www.rfc-editor.org/info/rfc1157>.
[SPF] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
[SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful [SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
<https://www.rfc-editor.org/info/rfc5218>. <https://www.rfc-editor.org/info/rfc5218>.
[TCP] Postel, J., "Transmission Control Protocol", STD 7, [TCP] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[TFO] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>.
[TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS) [TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress), Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
March 2018. <https://www.rfc-editor.org/info/rfc8446>.
[TRANSITIONS] [TRANSITIONS]
Thaler, D., Ed., "Planning for Protocol Adoption and Thaler, D., Ed., "Planning for Protocol Adoption and
Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170,
May 2017, <https://www.rfc-editor.org/info/rfc8170>. May 2017, <https://www.rfc-editor.org/info/rfc8170>.
Acknowledgments Acknowledgments
Mirja Kuehlewind, Mark Nottingham, and Brian Trammell made Mirja Kuehlewind, Mark Nottingham, and Brian Trammell made
significant contributions to this document. significant contributions to this document.
 End of changes. 51 change blocks. 
140 lines changed or deleted 259 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/