From 39fb94ad2c67ddf4a71402e5391984eb251d39c2 Mon Sep 17 00:00:00 2001 From: Tommy Pauly Date: Sun, 5 Jul 2026 16:40:28 -0700 Subject: [PATCH 1/2] Add sections for wire image, protocol choice, and cost --- draft-iab-protocol-greasing.md | 87 ++++++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) diff --git a/draft-iab-protocol-greasing.md b/draft-iab-protocol-greasing.md index e58fd18..0d9c92f 100644 --- a/draft-iab-protocol-greasing.md +++ b/draft-iab-protocol-greasing.md @@ -344,6 +344,27 @@ 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. +### 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=RFC8546}}, 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, +{{?QUICBIT=RFC9287}} defines a way for QUIC clients and server to negotiate greasing the "QUIC bit", +which is an unencrypted bit visible in QUIC's wire image. + +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. + ### Discouraging Ossification Greasing alone can help ensure that middleboxes tolerate unrecognized extensions rather than @@ -457,6 +478,72 @@ incorrectly rely on assumptions about header order, size, or location in a packe 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. +## Wire Image Variation {#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=RFC8546}}. 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"). + +## 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 a 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=RFC7858}}, +or DNS over HTTPS {{?DOH=RFC8484}} +- 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=I-D.ietf-happy-happyeyeballs-v3}}). 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=RFC9577}} +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. + +## 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 +received 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 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 +({{wire-image-variation}}) 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. # Security Considerations From e6365bf55c72703b4fe6f7f0941cc64d3863ee70 Mon Sep 17 00:00:00 2001 From: Tommy Pauly Date: Sun, 5 Jul 2026 16:50:14 -0700 Subject: [PATCH 2/2] Elaborate QUIC bit explanation --- draft-iab-protocol-greasing.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/draft-iab-protocol-greasing.md b/draft-iab-protocol-greasing.md index 0d9c92f..ff2405e 100644 --- a/draft-iab-protocol-greasing.md +++ b/draft-iab-protocol-greasing.md @@ -358,8 +358,12 @@ greasing at all parties that can observe the wire image, including any middlebox 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, -{{?QUICBIT=RFC9287}} defines a way for QUIC clients and server to negotiate greasing the "QUIC bit", -which is an unencrypted bit visible in QUIC's wire image. +the "QUIC bit" is a 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=RFC9287}}). 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