Maintaining Protocols Using Grease and Variability
Internet-Draft draft-edm-protocol-greasing-03
Lucas Pardue
Cloudflare
lucas@lucaspardue.com
07 May 2024
next generation
unicorn
sparkling distributed ledger
Long-term interoperability of protocols is an important goal of the network standards process. Deployment success can depend on supporting change, which can include modifying how the protocol is used, extending the protocol, or replacing the protocol. This document presents concepts, considerations, and techniques related to protocol maintenance, such as greasing or variability. The intended audience is protocol designers and implementers.
About This Document
The latest revision of this draft can be found at https://intarchboard.github.io/draft-protocol-greasing/draft-edm-protocol-greasing.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-edm-protocol-greasing/.
Source for this draft and an issue tracker can be found at https://github.com/intarchboard/draft-protocol-greasing.
Introduction
Long-term interoperability of protocols is an important goal of the network standards process [MAINTENANCE]. Protocol deployment success [SUCCESS] can depend on supporting change, which can include modifying how the protocol is used, extending the protocol, or replacing the protocol.
Greasing, a technique initially designed for TLS [GREASE] and later adopted by other protocols such as QUIC [QUIC], can help support the long-term viability of protocol extension points. Greasing is suitable for many protocols but not all; Section 3.3 of [VIABILITY] discusses the applicability and limitations of greasing. Section 3 provides additional protocol maintenance considerations.
Applications are built with the intent of serving user needs [END-USERS], which might only require support for a subset of protocol features. Adapting to changing user needs is a maintenance activity. For example, an HTTP deployment focused on downloads might want to add support for uploads. Changing use of the application and transport protocol features can affect the deployment's network traffic profile. If expectations have been formed around historical patterns of use i.e., ossification, introducing change might lead to deployment problems. Section 4 presents considerations about how intentionally increasing the variability of protocols can mitigate some of these concerns.
Protocol extensions can provide longevity in the face of changing needs or environment. However, a replacment protocol might be preferred when extensions are not adequate or feasible. A protocol replacement could aggregate common extensions and possibly make them mandatory, effectively defining a new baseline that can simplify deployment and interoperability. A replacement protocol version may or may not be compatible with other versions. A protocol may or may not have a mechanism for version selection or agility. Section 5 presents considerations about designing for and/or implementing version negotiation and migration.
Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Considerations for Applying Greasing
Greasing can take many forms, depending on the protocol and the nature of its extension points.
Many protocols register values, codepoints, or numbers in a limited space. A common approach that has developed in more recent protocols is to reserve a subset of the space for greasing (see [GREASE], Section 18.1 of [QUIC], or Section 7.2.8 of [RFC9114]). Values reserved for the purpose of greasing are herein referred to as grease values. Implementations that receive grease values are required to ignore them. More background to this approach is given in Section 3.3 of [VIABILITY]. This section provides concrete suggestions for its usage.
It is assumed that endpoints should implement robust and broad extension handling. A receiver or a parser implementation should not treat grease values as individually special. Instead of identifying each grease value explicitly, it is better to have a "catch all" mechanism that can handle receipt of unknown extensions, whether grease values or not, gracefully or without error.
It is recommended that senders pick an unpredictable grease value to include in relevant protocol elements. This ensures that receiver greasing requirements are exercised. Using predictable grease values risks ossification. To increase the variety of grease values, it is advised to reserve a large range. However, the specific size and distribution of the grease range needs to accommodate the protocol constraints. For instance, protocols that use 8-bit fields may find it too costly to dedicate many grease values, while 32-bit or 64-bit fields are likely to have no limitations.
It is recommended that senders use grease values at unpredictable times or sequence points during protocol interactions. This avoids receivers unintentionally ossifying on the occurrence of greasing in the temporal or spatial domain.
It is recommended that large grease value sets are allocated in protocol documents by defining a unique algorithm, to increase the chance that receiver greasing requirements are exercised. However, the choice of algorithm needs to consider the spread of values and the size of contiguous blocks between grease values. It is common for protocol extension designers to want to reserve a contiguous block of code points in order to aid iteration and experimentation. Small contiguous blocks increase the chance that such reservations might unintentionally use grease values, which could lead to interoperability failures.
Protocols might ask IANA to create new registries for their extension points. When greasing, it is recommended that only a single entry for the entire grease value set is registered. When an algorithm has been used, it should be included in the entry; see for example https://www.iana.org/assignments/http3-parameters/http3-parameters.xhtml#http3-parameters-frame-types.
Grease values must not be used or registered for any other purpose. Registries should include a label to identify the protected grease value range; a label of "reserved" may be confused with other ranges that are reserved for private or experimental extensions. An implementer that conflates these two meanings may cause a new class of interoperability failure. Therefore a label such as "reserved for greasing" may help to avoid the confusion.
Considerations for Increasing Protocol Variability
Greasing can maintain protocol extensibility by falsifying active use of its extension points. However, greasing alone does not ensure positive use of extension mechanisms. A protocol may define a wide-ranging extension capability that remains unused in the absence of real use cases. This can lead to ossification that does not expect extensions, leading to interoperability problems later on.
Long-term maintenance and interoperability can be ensured by exercising extension points positively. To some extent this can be thought of as protocol fuzzing. This might be difficult to exercise because varying the protocol elements might change the outcome of interactions, leading to real errors. However, some protocols allow elements to be be safely changed, as shown in the following examples.
Example: QUIC frames
QUIC packets contain frames. Receivers might build expectations on the longitudinal aspects of packets or frames - size, ordering, frequency, etc. A sender can quite often manipulate these parameters and stay compliant to the requirements of the QUIC protocol.
A QUIC stream is an ordered reliable byte stream that is serialized as a sequence of STREAM frames with a length and offset. Receivers are expected to reassemble frames, which could arrive in any order, into an ordered reliable byte stream that is readable by applications.
A form of positive testing is for a sender to unpredictably order the STREAM frames that it transmits. For example, varying the sequence order of offset values. This allows to exercise the QUIC reassembly features of the receiver with the expectation that no failure would occur. However, doing this may introduce delay or stream head-of-line blocking that affects the performance aspects of a transmission, which may not be acceptable for a given use case. As such, positive testing might be most appropriate to use in a subset of connections, or phases within a connection.
Considerations for Protocol Versions
There are intrinsic and well-documented issues related to testing version negotiation of protocols; see [EXTENSIBILITY] and Sections 2.1 and 3.2 of [VIABILITY]. This section will be expanded with advice for protocol designers and implementers about how to approach these problems.
Security Considerations
The considerations in [MAINTENANCE], [GREASE], [END-USERS], and [VIABILITY] all apply to the topics discussed in this document.
The use of protocol features, extensions, and versions can already allow fingerprinting. Any techniques that change parameters in any way, including but not limited to those discussed in this document, can affect fingerprinting. A deeper analysis of this topic has been deemed out of scope.
IANA Considerations
This document has no IANA actions.
References
Normative References
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[RFC9114]

HTTP/3
M. Bishop, Ed.
June 2022
RFC 9114
DOI 10.17487/RFC9114
[MAINTENANCE]

Maintaining Robust Protocols
M. Thomson
D. Schinazi
June 2023
RFC 9413
DOI 10.17487/RFC9413
[SUCCESS]

What Makes for a Successful Protocol?
D. Thaler
B. Aboba
July 2008
RFC 5218
DOI 10.17487/RFC5218
[GREASE]

Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility
D. Benjamin
January 2020
RFC 8701
DOI 10.17487/RFC8701
[QUIC]

QUIC: A UDP-Based Multiplexed and Secure Transport
J. Iyengar, Ed.
M. Thomson, Ed.
May 2021
RFC 9000
DOI 10.17487/RFC9000
[VIABILITY]

Long-Term Viability of Protocol Extension Mechanisms
M. Thomson
T. Pauly
December 2021
RFC 9170
DOI 10.17487/RFC9170
[END-USERS]

The Internet is for End Users
M. Nottingham
August 2020
RFC 8890
DOI 10.17487/RFC8890
[EXTENSIBILITY]

Design Considerations for Protocol Extensions
B. Carpenter
B. Aboba, Ed.
S. Cheshire
September 2012
RFC 6709
DOI 10.17487/RFC6709
Acknowledgments
This work is a summary of the topics discussed during EDM meetings. The contributors at those meetings are thanked.