Considerations For Maintaining Protocols Using Grease and Variability
draft-iab-protocol-greasing-02
This document is an Internet-Draft (I-D) that has been submitted to the Internet Architecture Board (IAB) stream.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (iab) | |
|---|---|---|---|
| Authors | Lucas Pardue , Tommy Pauly , Dave Thaler | ||
| Last updated | 2026-11-02 | ||
| Replaces | draft-edm-protocol-greasing | ||
| RFC stream | Internet Architecture Board (IAB) | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Stream | IAB state | Active IAB Document | |
| Consensus boilerplate | Unknown | ||
| IAB shepherd | (None) |
draft-iab-protocol-greasing-02
Network Working Group L. Pardue
Internet-Draft Cloudflare
Intended status: Informational T. Pauly
Expires: 6 May 2027 Apple
D. Thaler
Armidale Consulting
2 November 2026
Considerations For Maintaining Protocols Using Grease and Variability
draft-iab-protocol-greasing-02
Abstract
Active use and maintenance of network protocols is an important way
to ensure that protocols remain interoperable and extensible over
time. Techniques such as intentionally exercising extension points
with non-meaningful values (referred to as "grease") or adding
variability to how protocol elements are used help generate this
active use.
Grease and variability are used across various protocols developed by
the IETF. This document discusses considerations when designing and
deploying grease and variability mechanisms, and provides advice for
making them as effective as possible.
About This Document
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-iab-
protocol-greasing.html. Status information for this document may be
found at https://datatracker.ietf.org/doc/draft-iab-protocol-
greasing/.
Source for this draft and an issue tracker can be found at
https://github.com/intarchboard/draft-protocol-greasing.
Status of This Memo
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/.
Pardue, et al. Expires 6 May 2027 [Page 1]
Internet-Draft Protocol Greasing November 2026
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 6 May 2027.
Copyright Notice
Copyright (c) 2026 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Considerations for Greasing Protocols . . . . . . . . . . . . 4
2.1. Define and Register Grease Value Ranges . . . . . . . . . 4
2.1.1. Recommendations for IANA Considerations . . . . . . . 5
2.2. Use Unpredictable Grease Values . . . . . . . . . . . . . 6
2.3. Use Grease Values Unpredictably . . . . . . . . . . . . . 6
2.4. Don't Handle Grease Values as a Special Case . . . . . . 7
2.5. Greasing Protocol Versions . . . . . . . . . . . . . . . 9
2.6. Deployment Considerations and Incentives for Greasing . . 9
2.6.1. Negotiating Greasing: Greasing the Wire Image . . . . 11
2.6.2. Discouraging Ossification . . . . . . . . . . . . . . 11
3. Considerations for Increasing Protocol Variability . . . . . 12
3.1. Example: QUIC frames . . . . . . . . . . . . . . . . . . 13
3.2. Example: Post-quantum key exchange in TLS . . . . . . . . 13
3.3. Example: IPv6 . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Wire Image Variation . . . . . . . . . . . . . . . . . . 14
3.5. Variability in Protocol Choice . . . . . . . . . . . . . 15
3.6. Cost of Variability . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Informative References . . . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Pardue, et al. Expires 6 May 2027 [Page 2]
Internet-Draft Protocol Greasing November 2026
1. Introduction
Section 3 of [VIABILITY] discusses "active use" as a category of
techniques that protocol designers and implementers employ to ensure
that protocol extension mechanisms are exercised and can be used in
the future. This ability to change (to handle protocol updates and
extensions) is an important factor in the success of protocol
deployment, as discussed in [SUCCESS].
Active use of protocol features and extensions often requires
intentional efforts beyond what would organically occur in
deployments. Some extension points rarely see new values being used,
but it is important that they remain usable in the future. Some
patterns of protocol usage might be relatively static without
specific efforts to ensure that they can change in the future.
One key technique for intentional use is "grease" (an acronym for
Generate Random Extensions And Sustain Extensibility), or "greasing".
Greasing was initially designed for TLS [GREASE] and was later
adopted by other protocols such as QUIC [QUIC]. In these protocols,
some extension codepoints are reserved for greasing, and receivers
must ignore them. Greasing is suitable for many protocols but not
all; Section 3.3 of [VIABILITY] discusses the applicability and
limitations of greasing.
While it is becoming more common, designing and applying grease is
not necessarily trivial. There are best practices, and some common
pitfalls to avoid, that have been developed by the protocols using
grease thus far. Section 2 takes these learnings and provides
considerations for new protocol design and deployment.
Separate from greasing using reserved values, protocol deployments
can intentionally add variability to ensure that network endpoints
and middleboxes do not end up ossifying certain patterns. If
expectations have been formed around historical patterns of use,
changing application or transport protocol feature use could alter
the network traffic profile and invalidate such expectations,
possibly leading to deployment problems. For example, an HTTP
deployment that had previously focused on downloads could add a new
upload workload that changes the characteristics of packet flows.
Section 3 presents considerations about how intentionally increasing
the variability of protocols can mitigate some ossification concerns.
Protocol extensions can provide longevity in the face of changing
needs or environment. However, a replacement 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
Pardue, et al. Expires 6 May 2027 [Page 3]
Internet-Draft Protocol Greasing November 2026
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 2.5
presents considerations about designing for and/or implementing
version negotiation and migration.
2. Considerations for Greasing Protocols
Greasing can take many forms, depending on the protocol and the
nature of its extension points. The common pattern across forms of
greasing is that values are generated that have no useful meaning to
the protocol and are meant to be ignored upon receipt. Such values
used for the purpose of greasing are referred to as "grease values"
within this document.
More background to this approach is given in Section 3.3 of
[VIABILITY].
This section provides some practical considerations for how to define
and use greasing, and avoid possible pitfalls.
2.1. Define and Register Grease Value Ranges
Many protocols that use greasing have a limited set of possible
values or codepoints that can be used in a particular extension
point. A common approach is to reserve a subset of the registrable
space for greasing.
The following are some examples of protocols that have reserved
codepoints for grease values:
* TLS ([GREASE])
* QUIC (Section 18.1 of [QUIC])
* HTTP/3 (Section 7.2.8 of [HTTP/3])
* Privacy Pass ([PRIVACYPASS])
Pardue, et al. Expires 6 May 2027 [Page 4]
Internet-Draft Protocol Greasing November 2026
The specifics of how to reserve values depends on the nature of the
available space. For protocols with large possible spaces, it is
useful to have a large set of grease values to increase the chance
that receiver greasing requirements are exercised. 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, 16-bit fields
can usually afford a small set (TLS reserves 16 values in each of its
16-bit registries [GREASE]), and 32-bit or 64-bit fields are likely
to have no such limitations.
Reserving grease values has a lasting cost. Grease values cannot be
used or registered for any other purpose (see Section 2.1.1), so each
reserved value is permanently removed from the space available to
future extensions. Designers need to be aware that reserving too
many values for greasing can leave few values for defining new
extensions. Separately from greasing, reserved space can also be
hard to reclaim. For example, the IPv4 address block 240.0.0.0/4 was
reserved for future use in 1989 [RFC1112], and is still listed as
reserved [RFC6890].
It is recommended to use an algorithm to reserve large sets of
values. For example, [QUIC] uses an algorithm of 31 * N + 27 to
allocate grease values for transport parameters. These values span
all four sizes of QUIC's variable-length integer encoding (1, 2, 4,
and 8 bytes; Section 16 of [QUIC]), so grease exercises each size.
One possible problem with some algorithms is that they will spread
out values over the space, and impact the ability to use or reserve
contiguous blocks of non-grease values. It is common for protocol
extension designers to want to reserve contiguous blocks of
codepoints in order to aid iteration and experimentation. Reserved
grease values can end up being in spaces that would otherwise be used
for such contiguous blocks.
Codepoints being used for new reservations, or experimentation, need
to be careful to not unintentionally use grease values. Doing so
could lead to interoperability failures.
2.1.1. Recommendations for IANA Considerations
IANA registries that contain reserved grease values need to indicate
that the values are reserved in order to prevent them from being
allocated for other uses. The specifics of how to represent the
reservations is up to the documents that define the registries.
Pardue, et al. Expires 6 May 2027 [Page 5]
Internet-Draft Protocol Greasing November 2026
Some registries list out the reserved grease values individually,
marked as "Reserved". For example, the TLS registry uses this
approach (https://www.iana.org/assignments/tls-parameters/tls-
parameters.xhtml).
If an algorithm or pattern is used to define grease values, it is
recommended when possible to instead only define a single entry for
the entire grease value set. This entry should include the pattern
or algorithm. This approach is used by the QUIC registry
(https://www.iana.org/assignments/quic/quic.xhtml) and the HTTP/3
registry (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.
This is in contrast to other potentially "reserved" values that might
be reused or claimed for a new purpose in the future. To avoid
confusion, it is recommended to label the reservation with a clear
identifier, such as "reserved for greasing".
2.2. Use Unpredictable Grease Values
In order to gain the benefits of active use and avoid ossification,
grease values used in actual packets need to be sent in ways that
won't become a predictable pattern that receiver and middlebox
implementations and deployments ossify around.
Implementations that generate grease values should pick unpredictable
entries from the set of reserved grease values. It is most important
that values be unpredictable across the set of all protocol
participants for particular deployments. This can be achieved in
multiple ways: for example, an individual sender might pick random
values from the grease value space on each interaction;
alternatively, a single sender could pick a specific grease value to
use, while other senders pick other values.
In order to support picking unpredictable values, the set of reserved
values should be large, when possible. See Section 2.1 for a
discussion of how to allocate grease values.
2.3. Use Grease Values Unpredictably
In addition to selecting unpredictable values, the inclusion of
grease itself can be made unpredictable. Implementations can vary
their behavior by including no grease values, one grease value, or
multiple grease values for a given protocol extension point.
Pardue, et al. Expires 6 May 2027 [Page 6]
Internet-Draft Protocol Greasing November 2026
How consistently and frequently to use grease values is a choice that
implementations and deployments need to consider and weigh against
several factors.
Deployments of greasing should consider how they expect errors
exposed by using grease values to be noticed and measured
(Section 4.4 of [VIABILITY]). Counting failures separately for
interactions with and without grease helps attribute them, and
detailed logs help diagnose them. Logs can reveal more than the wire
image, so sharing them needs care.
In order to correctly report the effects of greasing, logging systems
and formats should record unknown values, including grease values.
If these values are discarded and not logged, failures exposed by
greasing can be hidden or misattributed. One example of a logging
format that includes greasing values is qlog, a structured logging
format for QUIC [QLOG-QUIC] and HTTP/3 [QLOG-H3].
If grease values are sent too infrequently, so that errors due to
sending grease values blend in with the noise of other errors, it is
likely that no one will notice failures, thus defeating the purpose
of greasing. When grease values are sent more frequently, they will
be noticed more. However, if grease values are sent too
consistently, receiver implementations might end up special-casing
grease values.
The patterns for sending grease values can be made more effective by
coordinating between devices sending the values. One example of
coordination is having a "flag day" where implementations start
sending grease values broadly, and measure to see where errors occur.
See Section 3 of [TRANSITION] for more considerations concerning the
use of a flag day.
2.4. Don't Handle Grease Values as a Special Case
Implementations that read and process grease values must ignore the
values. "Ignoring" a value upon receipt can have multiple
dimensions, however. Simply not performing any protocol action based
on the grease value isn't enough to ensure that the protocol will
remain extensible. The ignoring must be handled as a general case of
"unknown" or "unhandled" values, not as a special case for ignored
grease values.
This means that grease values can only meaningfully be used for
protocol elements where all unknown values are ignored by default.
(Protocols may have ways to indicate that some specific values are
"mandatory" or "critical" in order to have the protocol interaction
succeed, but these must not be marked for any grease values.)
Pardue, et al. Expires 6 May 2027 [Page 7]
Internet-Draft Protocol Greasing November 2026
One pitfall that implementations may encounter when building logic to
handle the receipt of grease values is related to cases where some
recognized non-grease values need to be handled as errors. Consider
the following abstract example:
1. A protocol element has values 1, 2, 3, and 4 defined and
registered for use. The values 13 and 42 are reserved as grease
values.
2. In a specific scenario, only the known values 1 and 2 are valid;
3 and 4 are considered errors.
3. An implementation might naively choose to check for the value
being 1 or 2, handle those cases, and send an error otherwise.
4. When grease values are used, the previous logic will flag an
error for the grease value. If this is detected, implementations
might choose to work around this by updating the logic to check
for the value being 1 or 2, then check for grease values to
ignore, and then send an error otherwise. This logic is also
incorrect since it doesn't allow for new extensibility.
The correct logic for the above scenario would be to check for the
value being 1 or 2, then explicitly check for the value being 3 or 4
(to handle the error), with a catch-all for ignored values.
In pseudo-code, the correct logic would work like this, where the
grease values would fall into the final else case as ignored values.
if is_valid_case_one(value):
handle_case_one()
else if is_valid_case_two(value):
handle_case_two()
else if is_known_invalid_case(value):
handle_error()
else:
ignore_value()
Implementations need to take care when implementing such logic.
Protocol specification designers should emphasize that grease values
must not be special-cased. It is also recommended to provide example
logic or pseudocode in specifications, similar to the example above,
as guidance to implementers on how to correctly process protocol
elements like these. Documents can also provide test vectors, when
applicable, that include grease values to ensure they are processed
correctly.
Pardue, et al. Expires 6 May 2027 [Page 8]
Internet-Draft Protocol Greasing November 2026
One limitation of greasing is that it only exercises grease values.
It does not check whether other values that are reserved for future
use are correctly treated as ignored or errors. As such,
ossification remains a possibility for non-grease values. The goal
of greasing is to increase the chances of correct implementation, and
thereby reduce (but not eliminate) the possibility of ossification.
Reserved fields, which senders set to a fixed value (typically zero),
are a related case. A later specification can give such a field
meaning, so receivers need to ignore its value rather than reject
messages where it is non-zero; Section 4.2 of [EXTENSIBILITY] calls
that rejection a common mistake. Because senders always send the
same value, these fields are prone to ossification (Section 2.2 of
[VIABILITY]). They are often only a few bits long, leaving no room
to reserve grease values. Negotiated greasing, as [QUICBIT] does for
QUIC's fixed bit, can exercise such a field without consuming any of
its values.
2.5. Greasing Protocol Versions
[TRANSITION] discusses considerations around planning for
transitioning from an existing protocol, or protocol version, to a
new one. There are also intrinsic and well-documented issues related
to testing version negotiation of protocols; see [EXTENSIBILITY] and
Sections 2.1 and 3.2 of [VIABILITY].
One way to grease protocol versions is to have a protocol pass a list
of supported versions or features (e.g., cipher suites), along with a
grease value, such that the grease value will not impact the actual
version or features chosen, since it will not be selected by the
receiving entity.
Another method is to have a protocol include a recovery mechanism
(e.g., an extra round trip to try with another option) for cases when
an unsupported version or feature is attempted. In this case, a
grease value might be attempted at some frequency or opportunity that
would not adversely affect performance.
2.6. Deployment Considerations and Incentives for Greasing
Greasing can be used as a tool to improve the active use of existing
protocol elements (which weren't necessarily designed with greasing
to begin with, or weren't deployed with greasing); or as part of new
protocol design and deployments.
When greasing isn't used from the beginning of protocol deployment,
starting to use greasing comes with the risk of triggering failures
or anomalies. These failures might be innocuous, but they also might
Pardue, et al. Expires 6 May 2027 [Page 9]
Internet-Draft Protocol Greasing November 2026
be very impactful and visible to users. This risk creates a
disincentive to deploy greasing in existing systems, since the change
that triggers failures is often blamed for the failure. The risk is
highest when adding greasing to a particular protocol flow that
doesn't require any change of behavior or adoption to hit the
greasing behavior. For example, if a service migrates to use a new
web server implementation that enables greasing, while the previous
server didn't, some new failures may be hit if clients react poorly
to greasing.
Some approaches to avoid failures due to greasing include:
* Designing, implementing, and using greasing very early on in
protocol development and deployment. This avoids the
aforementioned risk of adding greasing late in a deployment.
* Enabling greasing along with other major protocol feature changes
or deployment changes. For example, when upgrading to a new
protocol version that requires implementation updates on multiple
systems, greasing can be added for the new version specifically.
This approach works well for situations where the protocol
participants are known and already need to cooperate (such as
within an encrypted protocol between two endpoints). This
approach applies less well for situations where non-cooperating
entities (such as middleboxes) are the source of ossification.
* Using heuristics to disable greasing when errors are encountered.
For example, if a client-initiated protocol operation fails
multiple times when grease values are used, it can be retried
without any grease values. Alternatively, if a server recognizes
a property of a client that always fails when greasing is used, it
could choose to disable greasing when that client is detected.
This reduces the effectiveness of grease values in removing
existing ossification, but can still have benefits for flagging
issues in new implementations when they receive grease values.
Ossification of DNS implementations presents an illustrative
challenge for greasing. Non-encrypted DNS involves many network
observers and participants, and the protocol has numerous fields that
have been defined and deployed for many years. [DNS-GREASE]
discusses approaches that can be used to grease DNS, including being
able to more easily tie greasing to using encrypted DNS (thus
enabling grease along with another major feature change). It also
describes how the common approach in DNS to deal with failures, by
retrying without options, interacts with grease.
Pardue, et al. Expires 6 May 2027 [Page 10]
Internet-Draft Protocol Greasing November 2026
2.6.1. Negotiating Greasing: Greasing the Wire Image
Greasing is always intended to prevent ossification, but the protocol
participants targeted by greasing can vary. Typically, greasing
fields that are part of an end-to-end encrypted protocol allows a
sender to target greasing at a known peer. In this case, the sender
chooses to send grease without any explicit negotiation with the
peer, since the point is to ensure that the peer will tolerate
receiving grease.
Other kinds of greasing apply to protocol fields that are visible in
the wire image of a protocol [WIREIMAGE], generally unencrypted
fields in a protocol. These cases target greasing at all parties
that can observe the wire image, including any middleboxes. In these
cases, the two endpoints of a protocol might explicitly negotiate the
use of greasing. This doesn't prevent the endpoints themselves
ossifying (since they might choose to not negotiate), but it can
still be effective for preventing ossification of middleboxes. For
example, the "QUIC bit" is an unencrypted bit visible in QUIC's wire
image that is used to differentiate it from other UDP traffic, and is
set to a value of 1 in version 1 of QUIC. Being able to set the bit
to 0 requires negotiation between clients and servers to ensure that
the QUIC traffic won't conflict with other traffic ([QUICBIT]). The
purpose of this mechanism is to grease the wire image by ensuring
middleboxes can tolerate the bit being set to 0, but it cannot be
used to grease the peer since it requires negotiation.
Greasing the wire image inherently involves more parties than other
kinds of greasing, and it is more difficult for implementations to
anticipate all possible incompatibilities, so it is more likely to
encounter deployment challenges.
2.6.2. Discouraging Ossification
Greasing alone can help ensure that middleboxes tolerate unrecognized
extensions rather than crashing, but one common middlebox behavior is
to simply drop all unrecognized extensions. Techniques such as
disabling greasing when errors are encountered can enable
communication but may not provide enough incentive to discourage
ossification.
One approach to preserving the incentive to grease without being
blamed for doing so, while still potentially discouraging
ossification, is to make any such ossification visible. For example,
a sender can log and report ossification issues on a given path when
falling back to non-grease values. Similarly, a receiver can log and
report communication that does not include grease values. Such
reports might be used in social feedback (e.g., public product or
Pardue, et al. Expires 6 May 2027 [Page 11]
Internet-Draft Protocol Greasing November 2026
service reviews), or in contractual business relationship (e.g., SLA)
discussion, in order to provide an incentive to implementers or
deployers of ossified implementations.
Similar techniques can be used to encourage greasing and variability
by others, to provide further discouragements against ossification in
the future. Having a receiver log and report communication that does
not include grease values, as noted above, can also be used to report
on senders that do not support greasing. It is useful, however, to
be able to distinguish between the sender not supporting greasing,
versus the sender supporting greasing but only non-greased messages
arriving at the receiver. Protocols defining greasing mechanisms
should consider whether receivers can distinguish between these two
cases.
It is not generally recommended to use more drastic incentives to
require greasing such as degrading performance or reliability for
senders that don't support greasing. While this is possible, the
benefits of greasing are longer term, rather than immediate, and the
incentives are often not aligned. Section 2.1.1 of [SUCCESS]
explains that success most easily comes when those who are required
to make a change are the ones who gain the most benefit, and the
benefit is noticeable. If the sending implementation does not plan
to use new extensions in the future, it would not see any benefit
from being pushed to add greasing.
3. Considerations for Increasing Protocol Variability
Greasing can maintain protocol extensibility by falsifying active use
of its extension points (see Section 3.3 of [VIABILITY]). 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 safely changed, as shown in the following examples.
The principles in these examples are not limited to the protocols
mentioned, but also arise in many other protocols (e.g., the Session
Initiation Protocol (SIP) [SIP]).
Pardue, et al. Expires 6 May 2027 [Page 12]
Internet-Draft Protocol Greasing November 2026
3.1. 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, the sender can vary
the sequence order of offset values. This allows exercising 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.
3.2. Example: Post-quantum key exchange in TLS
Post-quantum key exchange in TLS (such as defined in [PQTLS]) expands
the key sizes sent in Client Hello messages in TLS 1.3 [TLS]. Before
using these algorithms, Client Hello messages would generally fit
within a single packet (either in TCP or QUIC). However, with these
larger keys, Client Hello messages need to be split across two (or
more) separate packets. Initial deployments of these keys uncovered
many buggy server and middlebox implementations that did not
correctly handle Client Hello messages being split across multiple
packets.
This is a case in which adding variability to how TLS Client Hello
messages were sent could have helped avoid ossification and buggy
implementations. Variations could include intentionally splitting
the messages across packets without increasing message size, and also
adding other values to messages to force them to exceed the length
that can fit within a single packet.
3.3. Example: IPv6
The IPv6 protocol [IPV6] defines the ability to use extension
headers, and further defines the ability to include options in two of
those headers. It also defines a recommended (but not required)
order of such headers.
Pardue, et al. Expires 6 May 2027 [Page 13]
Internet-Draft Protocol Greasing November 2026
If the same headers tend to appear in the same order, and with the
same size and offset most of the time, middleboxes can begin to
incorrectly rely on assumptions that those will always be the case,
and lead to ossification and inability to use new headers or options
or differing orders in the future.
IPv6 did not define grease values, but a sender may vary some aspects
of the protocol, such as varying the order of options within an
extension header, or even including a Destination Options Header with
only Pad1 or PadN options between other headers.
While doing such variations can discourage ossification, they might
also have a negative performance impact if done indiscriminately.
For example, making packets larger as a result might result in
fragmentation.
Finally, there may be security or gateway middleboxes already
deployed that incorrectly rely on assumptions about header order,
size, or location in a packet. Introducing variability might then
cause operational problems in such networks and result in a
disincentive to use the protocol or device or application using it.
In practice, adding a padding-only Destination Options header already
causes loss: about 11% to 21% of packets with an 8-byte Destination
Options header of PadN options sent to public servers were dropped in
measurements from 2014 and 2015 [RFC7872]. Guidance for transit
routers has since recommended permitting such packets [RFC9288], but
senders cannot assume that every path follows that guidance.
3.4. Wire Image Variation
The examples of variation above highlight ways in which specific
protocol fields are sent. Variation can also apply to more generic
aspects of a flow's wire image [WIREIMAGE]. Even when fields are
encrypted, there are aspects of a protocol's wire image that
middleboxes observe and can ossify around.
Aspects of the wire image include packet sizes (and patterns in
packet sizes), number of packets in a flow, directionality of flows
(how many packets are sent in one direction or another), and relative
timing of packet transmissions.
Senders can induce intentional wire image variations in many ways,
including: adding padding to extend packet sizes, breaking up data
across multiple packets to reduce packet sizes, pacing or bursting
packets to change the frequency of packet sends, and adding packets
that are purely padding or random data (often referred to as
"chaff").
Pardue, et al. Expires 6 May 2027 [Page 14]
Internet-Draft Protocol Greasing November 2026
3.5. Variability in Protocol Choice
Variation can occur when an endpoint chooses to use one protocol over
another, given the option to use either. For example, a client
connecting to an HTTP server when connected to a dual-stack network
might have several such choices:
* Perform DNS resolution using unencrypted DNS, or DNS over TLS
[DOT], or DNS over HTTPS [DOH]
* Connect to the server's IPv6 or IPv4 address, or both
* Connect to the server using HTTP/3 (over QUIC) or HTTP/2 (over
TCP)
Endpoints often will have a preferred set of protocols to use, and
will use the less preferred protocols as options they fall back to
(as described in "Happy Eyeballs", [HEv3]). However, for the sake of
variation and preventing ossification, endpoints can intentionally
choose to alter their preferences some percentage of the time.
Variation can also be created when an endpoint chooses to not use a
protocol feature, as an intentional way to ensure the network path or
peer still tolerates its absence. For example, Section 3.1 of
[PRIVACYPASS] recommends that, in some situations, clients randomly
act as if they don't support sending privacy pass tokens, to ensure
that receivers cannot ossify around them being available.
Note that sometimes, it is desirable to reduce the appearance of
variation instead of increasing it, particularly when trying to
increase an anonymity set by making connections look more similar to
network observers. For example, a TLS client that supports Encrypted
Client Hello (ECH), but is not aware of an ECH configuration for a
server it is contacting, will send a fake ECH extension made to look
like a real one (Section 6.2 of [ECH]). When many clients do this,
real ECH is harder to tell apart from fake, which discourages
networks from treating it differently (Section 10.10.4 of [ECH]).
3.6. Cost of Variability
Adding variability to implementations and deployments can come with
costs for complexity and performance, and needs to be weighed against
the benefits of reducing or preventing ossification.
* Implementation complexity: Correctly implemented receivers need to
be able to handle all valid inputs, but sender-side logic is often
made more complex by adding support for variation. The kinds of
protocol variability described in this document can require sender
Pardue, et al. Expires 6 May 2027 [Page 15]
Internet-Draft Protocol Greasing November 2026
logic to not only support less straightforward ways of
constructing packets, but also support randomly deciding when to
induce variability.
* Processing overhead: For both senders and receivers, protocol
variability can lead to processing overhead, and potentially
higher memory usage. For example, intentionally breaking up and
reordering data frames is less efficient than processing a
complete data chunk.
* Network efficiency: Variability that changes the wire image of a
protocol (Section 3.4) might be achieved by spreading data out
across more packets, sending smaller packets, adding chaff
packets, or adding delay. All of these, if used in excess, could
degrade the overall performance of a flow on a network, such as to
reduce goodput, increase latency, etc.
4. Security Considerations
The considerations in [MAINTENANCE], [GREASE], [END-USERS], and
[VIABILITY] all apply to the topics discussed in this document.
Security devices that inspect traffic, such as firewalls and
intrusion detection systems, also process grease. Grease is normal
protocol behavior, so if these systems categorize it as an attack,
greasing fails and senders may stop greasing. Recognizing grease
values specifically does not help: a device that permits grease but
blocks other unknown values still blocks real extensions. To
mitigate this, protocol specifications can define how intermediaries
handle unknown values, as TLS does (Section 9.3 of [TLS]), and as
operational guidance does for QUIC (Section 2.8 of [RFC9312]) and DNS
(Section 4 of [RFC8906]). These security devices typically also
fingerprint traffic (Section 2.4.5 of [RFC9065]), which grease can
disrupt.
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.
5. IANA Considerations
This document has no IANA actions itself. Guidance on how other
documents can effectively instruct IANA about protocol greasing is
provided in Section 2.1.1.
6. Informative References
Pardue, et al. Expires 6 May 2027 [Page 16]
Internet-Draft Protocol Greasing November 2026
[DNS-GREASE]
Huque, S. and M. P. Andrews, "Greasing Protocol Extension
Points in the DNS", Work in Progress, Internet-Draft,
draft-ietf-dnsop-grease-03, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
grease-03>.
[DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/rfc/rfc8484>.
[DOT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/rfc/rfc7858>.
[ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", RFC 9849, DOI 10.17487/RFC9849,
March 2026, <https://www.rfc-editor.org/rfc/rfc9849>.
[END-USERS]
Nottingham, M., "The Internet is for End Users", RFC 8890,
DOI 10.17487/RFC8890, August 2020,
<https://www.rfc-editor.org/rfc/rfc8890>.
[EXTENSIBILITY]
Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709,
DOI 10.17487/RFC6709, September 2012,
<https://www.rfc-editor.org/rfc/rfc6709>.
[GREASE] Benjamin, D., "Applying Generate Random Extensions And
Sustain Extensibility (GREASE) to TLS Extensibility",
RFC 8701, DOI 10.17487/RFC8701, January 2020,
<https://www.rfc-editor.org/rfc/rfc8701>.
[HEv3] Pauly, T., Schinazi, D., Jaju, N., and K. Ishibashi,
"Happy Eyeballs Version 3: Better Connectivity Using
Concurrency", Work in Progress, Internet-Draft, draft-
ietf-happy-happyeyeballs-v3-05, 2 November 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-happy-
happyeyeballs-v3-05>.
[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.
Pardue, et al. Expires 6 May 2027 [Page 17]
Internet-Draft Protocol Greasing November 2026
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>.
[MAINTENANCE]
Thomson, M. and D. Schinazi, "Maintaining Robust
Protocols", RFC 9413, DOI 10.17487/RFC9413, June 2023,
<https://www.rfc-editor.org/rfc/rfc9413>.
[PQTLS] Kwiatkowski, K., Kampanakis, P., Westerbaan, B. E., and D.
Stebila, "Post-Quantum Traditional (PQ/T) Hybrid Key
Agreement Mechanisms for TLS 1.3", RFC 10024,
DOI 10.17487/RFC10024, August 2026,
<https://www.rfc-editor.org/rfc/rfc10024>.
[PRIVACYPASS]
Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass
HTTP Authentication Scheme", RFC 9577,
DOI 10.17487/RFC9577, June 2024,
<https://www.rfc-editor.org/rfc/rfc9577>.
[PRIVCON] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/rfc/rfc6973>.
[QLOG-H3] Marx, R., Niccolini, L., Seemann, M., and L. Pardue,
"HTTP/3 qlog event definitions", Work in Progress,
Internet-Draft, draft-ietf-quic-qlog-h3-events-14, 2
November 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-quic-qlog-h3-events-14>.
[QLOG-QUIC]
Marx, R., Niccolini, L., Seemann, M., and L. Pardue, "QUIC
event definitions for qlog", Work in Progress, Internet-
Draft, draft-ietf-quic-qlog-quic-events-14, 2 November
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
quic-qlog-quic-events-14>.
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
Pardue, et al. Expires 6 May 2027 [Page 18]
Internet-Draft Protocol Greasing November 2026
[QUICBIT] Thomson, M., "Greasing the QUIC Bit", RFC 9287,
DOI 10.17487/RFC9287, August 2022,
<https://www.rfc-editor.org/rfc/rfc9287>.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/rfc/rfc1112>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<https://www.rfc-editor.org/rfc/rfc6890>.
[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu,
"Observations on the Dropping of Packets with IPv6
Extension Headers in the Real World", RFC 7872,
DOI 10.17487/RFC7872, June 2016,
<https://www.rfc-editor.org/rfc/rfc7872>.
[RFC8906] Andrews, M. and R. Bellis, "A Common Operational Problem
in DNS Servers: Failure to Communicate", BCP 231,
RFC 8906, DOI 10.17487/RFC8906, September 2020,
<https://www.rfc-editor.org/rfc/rfc8906>.
[RFC9065] Fairhurst, G. and C. Perkins, "Considerations around
Transport Header Confidentiality, Network Operations, and
the Evolution of Internet Transport Protocols", RFC 9065,
DOI 10.17487/RFC9065, July 2021,
<https://www.rfc-editor.org/rfc/rfc9065>.
[RFC9288] Gont, F. and W. Liu, "Recommendations on the Filtering of
IPv6 Packets Containing IPv6 Extension Headers at Transit
Routers", RFC 9288, DOI 10.17487/RFC9288, August 2022,
<https://www.rfc-editor.org/rfc/rfc9288>.
[RFC9312] Kühlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", RFC 9312, DOI 10.17487/RFC9312,
September 2022, <https://www.rfc-editor.org/rfc/rfc9312>.
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, July 2002,
<https://www.rfc-editor.org/rfc/rfc3261>.
[SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
<https://www.rfc-editor.org/rfc/rfc5218>.
Pardue, et al. Expires 6 May 2027 [Page 19]
Internet-Draft Protocol Greasing November 2026
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[TRANSITION]
Thaler, D., Ed., "Planning for Protocol Adoption and
Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170,
May 2017, <https://www.rfc-editor.org/rfc/rfc8170>.
[VIABILITY]
Thomson, M. and T. Pauly, "Long-Term Viability of Protocol
Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170,
December 2021, <https://www.rfc-editor.org/rfc/rfc9170>.
[WIREIMAGE]
Trammell, B. and M. Kuehlewind, "The Wire Image of a
Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April
2019, <https://www.rfc-editor.org/rfc/rfc8546>.
Acknowledgments
This work is a summary of the topics discussed during EDM meetings.
The contributors at those meetings are thanked.
Authors' Addresses
Lucas Pardue
Cloudflare
Email: lucas@lucaspardue.com
Tommy Pauly
Apple
Email: tpauly@apple.com
Dave Thaler
Armidale Consulting
Email: dave.thaler.ietf@gmail.com
Pardue, et al. Expires 6 May 2027 [Page 20]