| Internet-Draft | +Protocol Greasing | +October 2024 | +
| Pardue | +Expires 24 April 2025 | +[Page] | +
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.¶
+This note is to be removed before publishing as an RFC.¶
++ 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.¶
++ This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79.¶
++ Internet-Drafts are working documents of the Internet Engineering Task + Force (IETF). Note that other groups may also distribute working + documents as Internet-Drafts. The list of current Internet-Drafts is + at https://datatracker.ietf.org/drafts/current/.¶
++ Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress."¶
++ This Internet-Draft will expire on 24 April 2025.¶
++ Copyright (c) 2024 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 + (https://trustee.ietf.org/license-info) 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.¶
+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. In these protocols, extension +codepoints are reserved only for greasing and when received must be ignored. +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.¶
+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.¶
+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 [HTTP/3]). 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.¶
+Protocol designers 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.¶
+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.¶
+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.¶
+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.¶
+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 [PRIVCON]. 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.¶
+This document has no IANA actions itself. Guidance on how other documents can effectively +instruct IANA about protocol greasing is provided in Section 3.4.1¶
+This work is a summary of the topics discussed during EDM meetings. The +contributors at those meetings are thanked.¶
+| Protocol Greasing | +plain text | +same as main | +
| Protocol Greasing | +plain text | +same as main | +