<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.9 (Ruby 3.0.4) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-quic-bit-grease-03" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.12.6 -->
  <front>
    <title>Greasing the QUIC Bit</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-quic-bit-grease-03"/>
    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <email>mt@lowentropy.net</email>
      </address>
    </author>
    <date year="2022" month="May" day="18"/>
    <area>TSV</area>
    <workgroup>quic</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This document describes a method for negotiating the ability to send an
arbitrary value for the second-to-most significant bit in QUIC packets.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
  QUIC Working Group mailing list (quic@ietf.org),
  which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/quic/">https://mailarchive.ietf.org/arch/browse/quic/</eref>.</t>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/quicwg/quic-bit-grease">https://github.com/quicwg/quic-bit-grease</eref>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>QUIC <xref target="QUIC"/> intentionally describes a very narrow set
of fields that are visible to entities other than endpoints.  Beyond those
characteristics that are defined as invariant
<xref target="QUIC-INVARIANTS"/>, very little about the "wire
image" <xref target="RFC8546"/> of QUIC is visible.</t>
      <t>The second-to-most significant bit of the first byte in every QUIC packet is
defined as having a fixed value in QUIC version 1 <xref target="QUIC"/>.  The purpose of
having a fixed value is to allow QUIC to be efficiently distinguished from
other protocols; see <xref target="DEMUX"/> for a description of a system that might
use this property.  As this bit can identify a packet as QUIC, it is sometimes
referred to as the "QUIC Bit".</t>
      <t>Where endpoints and the intermediaries that support them do not depend on the
QUIC Bit having a fixed value, sending the same value in every packet is more of
liability than an asset.  If systems come to depend on a fixed value, then it
might become infeasible to define a version of QUIC that attributes semantics to
this bit.</t>
      <t>In order to safeguard future use of this bit, this document defines a QUIC
transport parameter that indicates that an endpoint is willing to receive QUIC
packets containing any value for this bit.  By sending different values for this
bit, the hope is that the value will remain available for future use
<xref target="USE-IT"/>.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <t>This document uses terms and notational conventions from <xref target="QUIC"/>.</t>
    </section>
    <section anchor="the-grease-quic-bit-transport-parameter">
      <name>The Grease QUIC Bit Transport Parameter</name>
      <t>The grease_quic_bit transport parameter (0x2ab2) can be sent by both client and
server.  The transport parameter is sent with an empty value; an endpoint that
understands this transport parameter MUST treat receipt of a non-empty value as
a connection error of type TRANSPORT_PARAMETER_ERROR.</t>
      <t>Advertising the grease_quic_bit transport parameter indicates that packets sent
to this endpoint MAY set a value of 0 for the QUIC Bit.  The QUIC Bit is defined
as the second-to-most significant bit of the first byte of QUIC packets (that
is, the value 0x40).</t>
      <t>A server MUST respect the value it previously provided for the grease_quic_bit
transport parameter if it accepts 0-RTT.  A client MAY forget the value.  In all
other cases, only the presence or absence of the transport parameter in the
current handshake is used to determine what values can be sent in the QUIC Bit.</t>
      <section anchor="clearing-the-quic-bit">
        <name>Clearing the QUIC Bit</name>
        <t>Endpoints that receive the grease_quic_bit transport parameter from a peer MAY
set the QUIC Bit to any value in packets they send to that peer.  Endpoints
SHOULD set the QUIC Bit to an unpredictable value unless another extension
assigns specific meaning to the value of the bit.</t>
        <t>All packets sent after receiving and processing transport parameters might be
affected, including Initial, Handshake, and Retry packets.</t>
        <t>A client MAY also clear the QUIC Bit in Initial, Handshake, or 0-RTT packets
that are sent prior to receiving transport parameters from the server.  However,
a client MUST NOT clear the QUIC Bit unless the Initial packets it sends include
a token provided by the server in a NEW_TOKEN frame (<xref section="19.7" sectionFormat="of" target="QUIC"/>),
received less than 604800 seconds (7 days) prior on a connection where the
server also included the grease_quic_bit transport parameter.</t>
        <aside>
          <t>This 7 day limit allows for changes in server configuration.  If server
configuration changes and a client does not set the QUIC Bit, then it is
possible that a server will drop packets, resulting in connection failures.</t>
        </aside>
        <t>A server MUST clear the QUIC bit only after processing transport parameters from
a client.  A server cannot remember that a client negotiated the extension in a
previous connection and clear the QUIC Bit based on that information.</t>
        <t>An endpoint cannot clear the QUIC Bit without knowing whether the peer supports
the extension.  As Stateless Reset packets (<xref section="10.3" sectionFormat="of" target="QUIC"/>) are only
used after a loss of connection state, endpoints are unlikely to be able to
clear the QUIC Bit on Stateless Reset packets.</t>
      </section>
      <section anchor="using-the-quic-bit">
        <name>Using the QUIC Bit</name>
        <t>The purpose of this extension is to allow for the use of the QUIC Bit by later
extensions.</t>
        <t>Extensions to QUIC that define semantics for the QUIC Bit can be negotiated at
the same time as the grease_quic_bit transport parameter.  In this case, a
recipient needs to be able to distinguish a randomized value from a value
carrying information according to the extension.  Extensions that use the QUIC
Bit MUST negotiate their use prior to acting on any semantic.</t>
        <t>For example, an extension might define a transport parameter that is sent in
addition to the grease_quic_bit transport parameter.  Though the value of the
QUIC Bit in packets received by a peer might be set according to rules defined
by the extension, they might also be randomized as specified in this document.</t>
        <t>Receiving a transport parameter for an extension that uses the QUIC Bit could be
used to confirm that a peer supports the semantic defined in the extension.  To
avoid acting on a randomized signal, the extension can require that endpoints
set the QUIC Bit according to the rules of the extension, but defer acting on
the information conveyed until the transport parameter for the extension is
received.</t>
        <t>Extensions that define semantics for the QUIC Bit can be negotiated without
using the grease_quic_bit transport parameter.  However, including both
extensions allows for the QUIC Bit to be greased even if the alternative use is
not supported.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document introduces no new security considerations for endpoints or
entities that can rely on endpoint cooperation.  However, this change makes the
task of identifying QUIC more difficult without cooperation of endpoints.  This
sometimes works counter to the security goals of network operators who rely on
network classification to identify threats.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document registers the grease_quic_bit transport parameter in the "QUIC
Transport Parameters" registry established in Section 22.2 of <xref target="QUIC"/>.  The
following fields are registered:</t>
      <dl>
        <dt>Value:</dt>
        <dd>
          <t>0x2ab2</t>
        </dd>
        <dt>Parameter Name:</dt>
        <dd>
          <t>grease_quic_bit</t>
        </dd>
        <dt>Status:</dt>
        <dd>
          <t>Permanent</t>
        </dd>
        <dt>Specification:</dt>
        <dd>
          <t>This document.</t>
        </dd>
        <dt>Date:</dt>
        <dd>
          <t>Date of registration.</t>
        </dd>
        <dt>Contact:</dt>
        <dd>
          <t>QUIC Working Group (quic@ietf.org)</t>
        </dd>
        <dt>Change Controller:</dt>
        <dd>
          <t>IETF (iesg@ietf.org)</t>
        </dd>
        <dt>Notes:</dt>
        <dd>
          <t>(none)</t>
        </dd>
      </dl>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="QUIC">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar">
              <organization/>
            </author>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <organization/>
            </author>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document defines the core of the QUIC transport protocol.  QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="QUIC-INVARIANTS">
          <front>
            <title>Version-Independent Properties of QUIC</title>
            <author fullname="M. Thomson" initials="M." surname="Thomson">
              <organization/>
            </author>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8999"/>
          <seriesInfo name="DOI" value="10.17487/RFC8999"/>
        </reference>
        <reference anchor="RFC8546">
          <front>
            <title>The Wire Image of a Network Protocol</title>
            <author fullname="B. Trammell" initials="B." surname="Trammell">
              <organization/>
            </author>
            <author fullname="M. Kuehlewind" initials="M." surname="Kuehlewind">
              <organization/>
            </author>
            <date month="April" year="2019"/>
            <abstract>
              <t>This document defines the wire image, an abstraction of the information available to an on-path non-participant in a networking protocol.  This abstraction is intended to shed light on the implications that increased encryption has for network functions that use the wire image.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8546"/>
          <seriesInfo name="DOI" value="10.17487/RFC8546"/>
        </reference>
        <reference anchor="DEMUX">
          <front>
            <title>Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)</title>
            <author fullname="M. Petit-Huguenin" initials="M." surname="Petit-Huguenin">
              <organization/>
            </author>
            <author fullname="G. Salgueiro" initials="G." surname="Salgueiro">
              <organization/>
            </author>
            <date month="September" year="2016"/>
            <abstract>
              <t>This document defines how Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket.  It overrides the guidance from RFC 5764 ("SRTP                Extension for DTLS"), which suffered from four issues described and fixed in this document.</t>
              <t>This document updates RFC 5764.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7983"/>
          <seriesInfo name="DOI" value="10.17487/RFC7983"/>
        </reference>
        <reference anchor="USE-IT">
          <front>
            <title>Long-Term Viability of Protocol Extension Mechanisms</title>
            <author fullname="M. Thomson" initials="M." surname="Thomson">
              <organization/>
            </author>
            <author fullname="T. Pauly" initials="T." surname="Pauly">
              <organization/>
            </author>
            <date month="December" year="2021"/>
            <abstract>
              <t>The ability to change protocols depends on exercising the extension and version-negotiation mechanisms that support change.  This document explores how regular use of new protocol features can ensure that it remains possible to deploy changes to a protocol. Examples are given where lack of use caused changes to be more difficult or costly.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9170"/>
          <seriesInfo name="DOI" value="10.17487/RFC9170"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA51ZYW8bNxL9zl/Bc78kgGXITtrEKq6tYiuNcbGdk5X2isMh
oHYpifAuuUdy7aiG/8v9lvtl94bkUitFQd0LAljaXXJn3sy8eUMNBgPmla/k
iB/8bKVwSi+5X0n+948XZ/yN8gesNIUWNR4orVj4gZJ+Mfh3q4rBXPnBktbI
wfAFK4SXS2PXI+58yZhq7Ih72zp/MhyeDk+YwJMjPrv5hd0be7u0pm1GnPZh
t3KNS+WIX2gvrZZ+cE5vYsx5octPojIab19Lxxo14v/0pjjkzlhv5cLh07qm
D/9iTLR+ZeyI8QHj+Ke0G/HLIz5bmdoZHa5FRy6F9Upv3TB2KbT6XXhlNB4w
v6uqEuGOrIWqRrz2P1XmXmpvTbM+gpGMaWNrLLiTI7irF71vbDAYcDF33ooC
D85WynHA2NZYz0vpCqvm0nHBawmTS461XAM9r7BDCoCYq0r5NfeGO6lLLjQg
BORW2DW/E1UrwzJ61MnC6HLgzaA2znOnllotVCHwMiwAEDGajShupXdHyb5a
lWUlGfuGcLembAtynrHw7MPDX+jvX6dvz06Hw+HjI3bxsB5PiKpabzlxJ2GR
Ftaae5jimVnwhZJV6WCc8ByB53fKqXklyRnaxCssNDCd7Bca18rG4AXuiPM3
cg1ncN04yYqVIAilVc6rordhKRdKS6DiYNidsArOsoeHH8nowcXVL+Ppxfhq
dkP2vz49PX18PIxmAlIkO8A1rQ/YHdwrK5mqxVIewOsfacG3L7+Dw3AjQIHY
JfOPKJR/CDfW0cYLZXFzvvaSAiDD23thwLas58RK3FHgBZZ9xpUY3y5wWOsA
PD/uwvL4CKDIlKa1DXDCO9n+HRxBjoghNGErfJtLLhewVyESFEmCVi9b5VZY
trCmZjEyjTUoNVO57+GxJGzOJ5cf/0GQvjp9/QIIUf6JlAoNpQb5LlCRzss6
xqpWy5VnLUz0VATYs5HWr2H+2MVLBBmw46qkzFissUFCCLCQzYecctih5FEt
qgYNoN6ltbCWfHMxjJmvEKRfYb7cJBVKpwwPUQrbWpYK+SJTMrm2acAldL9G
jXJtqEIbqjj4g6us23lvjA5DcXY160Avm9jFmOdw89rYEKlK5dqm5Kf/DnUD
TC4WCTzHC3hL/m1s2Xkv3gfQPAsII6hhAWiIODyVWsyvWKEuhSdmQSgj71HB
rQcSDiSnY4EZ1kUFQF5giS2pSkFCYiGXrbDIkda38KQNeZeDeBg/9WiOXk78
QK9k4C3tAtINShqRjLVP7FQq6h1dcW/YgDC7Bw8HdA23spCg17hd4jLApL1Q
OsRFb/Ni8gKMss5BKtUCqUPmhSddfpQlDyRfIUND3ZA1dCHuSYbABDQDROIO
LUEQyLR8AwcR0MebyeBiFnjz+BV4k9j2G35m9F1kz5iN5wSOCt8jp6AHcmqC
jh9cfryZHRzGv/zqOnyeTuD1dHJOn2/ejd+/zx9YeuLm3fXH9+ebT5uVZ9eX
l5Or87gYV/nWJXZwOf4Nd8iqg+sPs4vrq/H7A0rf7XAS6UbyCFXUWESQmIt1
naCkNW/OPvz3P8cviaeAwMnxMZg3fXl9/OolvtwjbePbjAb7xK+Aec1E00hh
aRfwFSihUV5UaPCocLcy95pTVROc2+0UuCNYqOuILOpXxC5FuZFBJ16DIYk8
Q0wI9iB5NmKHz3KWfuiyNMYn6pxPpFc+EWPtS+dnw88nYn7yPNDZnPoEdYQ1
n4NPeVGpAKMumZMWBZkYfN9GRHb08L3CQiqIuvEpt7/fKhDKUdZqVGiQSolR
920ZkgmKCTkd6qjxkau10YPe9hRQQcBpGdQAB88ixanM1yiL2XR8dfPhejr7
9GE8HV9OZpPpp8l0ej0FouMSTnmVBeRTENup/a6oyXmGZAveZGeRpyQviM6C
qTBqmCVQF8GEag4oZUrssix1ij/dvTvS7Kx7FlBX7rDHDsPPL4fPCQQegxvx
ttI1wLH3HF6AyrlTpnVIfnTDO7S9Mnuxg9le0lQL2kUUhWxgzHAwnc2om3YJ
Rihhu6XsvZY6S6iq1NkLvATmhwKkh2ASIC/gqiXVGj9GHPZHLfTForWBSVeU
eStxG1gT1VjG1kMlSd3nniKb2LZfGHGXTeCoJkGUFThgdwZhbJJ7eUiUrhU8
Nc9C9UNXSIrM+DfmEjo5TUhI5PYBy7pYEzFF+R3SkXJUhtLNBrFEt/u35K0G
uEhyH9pF3L/VlXTEVjEa8jOENbVnZChlI/IfWUM5ifFA6NT9NjmUIhM79BhU
2S8bjsEJe0aAYlcsKc8KvDHs9CU6jncSggl0R6jtEpJLF1UbWuYF9SlRHfJ3
XZwjfU+lz+rGhdTvZSCI2+A78fkWKIB2337Iu5DI3XYs6/zgU2OVsRsJ8FU/
QphjjSeGfYeRDZ8OidSSdamr7rMuBYauJSsztrhLaeASMIAK9txCgeUanq97
rw5djF9Nfv00u/7b5AqWkTJ89vBwk3j1+PToVccsj4/PD1lK6ZInE5A73w1f
vh4OE2GBd17xUqzd8wRHUIQ9pr4PopcKM5kQYpDMLZ9aKgjkwwgKspSP7Ace
Om14LQanmmiHJomomjCa6aUkQDqfYcxCLVsb+m9Ss+EOdtq6l9dSHuXIlAZX
SH7vllLWujQz/cAx8CSFG5Kke3sQaCXmiy5mh8S/bRUGahjZg2oB+QbJ5r4g
7J2cCP2ASDIW1R+VUZidOncCJ3fACE1+QT3Ket7p3ux3N/inIGU6CDnEunbR
t59g25O+c0HkG6aWoKvTiQRiAT97qiGZs2cHEhw0GN9qc09uIqfSkC4jeaZp
iQq0Z2mc5m4gvGTI3qmkEOZ+2cv64dGLXtaHCieAWWgbEWXBKwSYnup57Gjv
w/5IZwOPqltZrZMuFXHqYXv8wg5fsS61nY9fnHtF2beZr5MY2QSnN1l37TtP
RP2goHQEyci8lN45yV9ol81Mlia2zTy2q2+6FtpLGoiRPHvSfNyNxE+p9iAM
gmekCUDsxEOqSXkpS7eNbf+wAIHChqWp1e/5uCH12fCFFcLadSy+nImkWzDl
9HpaP4n6qBAa8dggTXzkfCjS7DrdUzY8lTuEKEK9hyJZZxyB+FtDnVbUTRX6
Vy+SsfvlWfnrg6rrhAsTZRmGt86Jp0E9Q20tV190ctbvjl3R5HYwX3fCpevS
UQT3cbQtEjvr3NSIsoNxvErLQ1PAHr3QiSw44gy3NfcBuelGS+wXV6Qa+4B2
sXM7mWvaqiSV0WnE0BNs3dHhFsGkXhrDl0/7kmbs58zMMHFnVNmPfN87UlSk
NraplarISsTLpjaSmeVLbfhFyka4U6H3YJ63IY2IwzpbWDx22uR/mEnXsKuF
Y9VXJXZX9n2+yRJhhz/+X95IZI9w/ImRraepehqRJtwewfVlwq4mnnevKel8
TNM4E067Kzr6D+fnoaDhbpACMR2CzxjZ0UdaSwdnZ3gLNEqUE273SECl8+yg
J+AyHUunhcXWwmDhpqkYsHR3Oh1gjWmCDmP67dPQGWYncjIakUWDsOE1VG1I
YeaFu6VU6U43Ca0ARzgMpOMoVUCj5M7b25yW9Q/GyUeWD0HptOiWVEGrfTyg
S8Nt9HNpUOm0g5aenuRxWwOZcr8ynVOsu1tUNHvQGNzRWj6O9Ss6NYiNkl+M
r8Z/AL6VSzQJ0kNPPwXYHOGyPScw7iBtinlDOpqk4lk11nXC4uTk6IS8zSc8
4RiALQwlImGefpAg2dAZKMsRY78QEY/YiMezG8byW/kV/VaEO7tDOSMp0Tq6
9QEzrtB0WsFu0swWf0HCvdkOjZ6j6Og6/SVTk0udQDujg8zC0xMhP35FWMjw
n+mHMv6M3v4T/fR2hNn+OR6PiUarLJyUlhZeTGZv+TNk77L/6JXxMlj7TBst
n7P/AXSy9h7zGwAA

-->

</rfc>
