RFC 9287

Greasing the QUIC Bit

📅 published August 2022, from ietf

Abstract 🦋

okay bestie, so this doc is about a way to negotiate being able to send any value you want in the second-most significant bit of QUIC packets. the vibe is "let's keep this bit flexible for the future" 💅

Status of This Memo 📜

This is an Internet Standards Track document ✨

It's a product of the Internet Engineering Task Force (IETF), so it represents consensus from the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841 🤓

For the current status, errata, and feedback, go to https://www.rfc-editor.org/info/rfc9287 🔗

Copyright (c) 2022 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) as they stand on the publication date. Please read these carefully because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License describes 📝

Table of Contents 🗂️

  • 1. Introduction
  • 2. Conventions and Definitions
  • 3. The Grease QUIC Bit Transport Parameter
    • 3.1. Clearing the QUIC Bit
    • 3.2. Using the QUIC Bit
  • 4. Security Considerations
  • 5. IANA Considerations
  • 6. References
    • 6.1. Normative References
    • 6.2. Informative References
  • Author's Address

1. Introduction ✨

okay so the version-independent definition of QUIC [QUIC-INVARIANTS] is intentionally super minimal about which fields other entities can see. Past those invariant bits, barely anything about QUIC's "wire image" [RFC8546] is visible 👀

The second-most significant bit of the first byte in every QUIC packet has a fixed value in QUIC version 1 [QUIC]. That fixed value lets endpoints tell QUIC apart from other protocols quickly. [DEMUX] describes a system that could use this property 🧚 Since this bit can identify a packet as QUIC, people call it the "QUIC Bit" 💜

Here's the tea: if endpoints and the middleboxes that support them don't actually depend on the QUIC Bit being fixed, then sending the same value in every packet is more of a liability than a perk 😬 And if systems start depending on that fixed value, it could become basically impossible to define a version of QUIC that gives this bit a meaning.

So to protect the bit's future, this document defines a QUIC transport parameter. It says an endpoint is happy to receive QUIC packets with any value in this bit. By sending different values, the hope is the value stays free for future use [USE-IT] 🦋

2. 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 💅

This document uses terms and notational conventions from [QUIC] 🌈

3. The Grease QUIC Bit Transport Parameter 🎀

The grease_quic_bit transport parameter (0x2ab2) is defined for QUIC version 1 [QUIC]. Both client and server can send it. It goes out with an empty value. An endpoint that understands this parameter MUST treat receipt of a non-empty value as a connection error of type TRANSPORT_PARAMETER_ERROR 🚫

An endpoint that advertises the grease_quic_bit transport parameter MUST accept packets with the QUIC Bit set to 0. The QUIC Bit is the second-most significant bit of the first byte of QUIC packets, which is the value 0x40 🍓

3.1. Clearing the QUIC Bit 🧹

Endpoints that get the grease_quic_bit transport parameter from a peer SHOULD set the QUIC Bit to an unpredictable value, unless another extension gives that bit specific meaning 🎲

Endpoints can set the QUIC Bit to 0 on every packet they send after they've received and processed transport parameters. That can include Initial, Handshake, and Retry packets ✨

A client MAY also set the QUIC Bit to 0 in Initial, Handshake, or 0-RTT packets it sends before it has received transport parameters from the server. But a client MUST NOT set the QUIC Bit to 0 unless its Initial packets include a token the server gave it in a NEW_TOKEN frame (Section 19.7 of [QUIC]). That token has to have been received less than 604800 seconds (7 days) earlier, on a connection where the server also included the grease_quic_bit transport parameter 🙈

the 7-day limit leaves room for server config changes. if the server config changes and the client doesn't set the QUIC Bit, the server might drop packets, and then connections fail 💀

A server MUST set the QUIC Bit to 0 only after it has processed transport parameters from a client. A server MUST NOT remember that a client negotiated the extension in a previous connection and then set the QUIC Bit to 0 based on that memory 🧠

An endpoint MUST NOT set the QUIC Bit to 0 without knowing whether its peer supports the extension. Stateless Reset packets (Section 10.3 of [QUIC]) are only used after connection state has been lost, so endpoints probably can't set the QUIC Bit to 0 on Stateless Reset packets 😭

3.2. Using the QUIC Bit 🔥

The whole point of this extension is letting later extensions use the QUIC Bit 👑

Extensions to QUIC that give the QUIC Bit semantics can be negotiated at the same time as the grease_quic_bit transport parameter. When that happens, a recipient has to be able to tell a randomized value apart from a value that carries information under the extension. Extensions that use the QUIC Bit MUST negotiate their use before acting on any of its semantics 🫶

For example, an extension might define a transport parameter that gets sent alongside grease_quic_bit. The QUIC Bit in packets a peer receives might be set by the extension's rules, but it might also be randomized as this document describes 🌸

Receiving the transport parameter for an extension that uses the QUIC Bit could confirm that a peer supports the semantic that extension defines. To avoid acting on a randomized signal, the extension can require endpoints to set the QUIC Bit according to its rules, but hold off on acting on that information until the extension's transport parameter arrives 🧚

Extensions that give the QUIC Bit semantics can also be negotiated without grease_quic_bit. But including both lets the QUIC Bit get greased even when the alternative use isn't supported 💖

4. Security Considerations 🚨

This document adds no new security considerations for endpoints or for entities that can rely on endpoint cooperation. However, it does make identifying QUIC harder when endpoints don't cooperate. That sometimes clashes with the security goals of network operators who use network classification to spot threats. See Section 3.1 of [MANAGEABILITY] for a fuller take on this 🕵️

5. IANA Considerations 🏷️

This document registers the grease_quic_bit transport parameter in the "QUIC Transport Parameters" registry, which Section 22.3 of [QUIC] set up. The registered fields are:

Value:  0x2ab2

Parameter Name:  grease_quic_bit

Status:  Permanent

Specification:  RFC 9287

Date:  2022-07-13

Change Controller:  IETF (iesg@ietf.org)

Contact:  QUIC Working Group (quic@ietf.org)

Notes:  (none)

6. References 📖

6.1. Normative References 💜

6.2. Informative References 🌙

Author's Address 💌

Martin Thomson Mozilla Email: mt@lowentropy.net

📦 where this page comes from