idnits 2.17.1 draft-ietf-quic-bit-grease-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (18 October 2021) is 920 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 quic M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track 18 October 2021 5 Expires: 21 April 2022 7 Greasing the QUIC Bit 8 draft-ietf-quic-bit-grease-01 10 Abstract 12 This document describes a method for negotiating the ability to send 13 an arbitrary value for the second-to-most significant bit in QUIC 14 packets. 16 Discussion Venues 18 This note is to be removed before publishing as an RFC. 20 Discussion of this document takes place on the QUIC Working Group 21 mailing list (quic@ietf.org), which is archived at 22 https://mailarchive.ietf.org/arch/browse/quic/ 23 (https://mailarchive.ietf.org/arch/browse/quic/). 25 Source for this draft and an issue tracker can be found at 26 https://github.com/quicwg/quic-bit-grease (https://github.com/quicwg/ 27 quic-bit-grease). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 21 April 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 64 3. The Grease QUIC Bit Transport Parameter . . . . . . . . . . . 3 65 3.1. Clearing the QUIC Bit . . . . . . . . . . . . . . . . . . 4 66 3.2. Using the QUIC Bit . . . . . . . . . . . . . . . . . . . 4 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 71 6.2. Informative References . . . . . . . . . . . . . . . . . 6 72 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 QUIC [QUIC] intentionally describes a very narrow set of fields that 78 are visible to entities other than endpoints. Beyond those 79 characteristics that are defined as invariant [QUIC-INVARIANTS], very 80 little about the "wire image" [RFC8546] of QUIC is visible. 82 The second-to-most significant bit of the first byte in every QUIC 83 packet is defined as having a fixed value in QUIC version 1 [QUIC]. 84 The purpose of having a fixed value is to allow intermediaries and 85 endpoints to efficiently distinguish between QUIC and other 86 protocols; see [DEMUX] for a description of a scheme that QUIC can 87 integrate with as a result. As this bit effectively identifies a 88 packet as QUIC, it is sometimes referred to as the "QUIC Bit". 90 Where endpoints and the intermediaries that support them do not 91 depend on the QUIC Bit having a fixed value, sending the same value 92 in every packet is more of liability than an asset. If systems come 93 to depend on a fixed value, then it might become infeasible to define 94 a version of QUIC that attributes semantics to this bit. 96 In order to safeguard future use of this bit, this document defines a 97 QUIC transport parameter that indicates that an endpoint is willing 98 to receive QUIC packets containing any value for this bit. By 99 sending different values for this bit, the hope is that the value 100 will remain available for future use [USE-IT]. 102 2. Conventions and Definitions 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in 107 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 This document uses terms and notational conventions from [QUIC]. 112 3. The Grease QUIC Bit Transport Parameter 114 The grease_quic_bit transport parameter (0x2ab2) can be sent by both 115 client and server. The transport parameter is sent with an empty 116 value; an endpoint that understands this transport parameter MUST 117 treat receipt of a non-empty value as a connection error of type 118 TRANSPORT_PARAMETER_ERROR. 120 Advertising the grease_quic_bit transport parameter indicates that 121 packets sent to this endpoint MAY set a value of 0 for the QUIC Bit. 122 The QUIC Bit is defined as the second-to-most significant bit of the 123 first byte of QUIC packets (that is, the value 0x40). 125 A server MUST respect the value it previously provided for the 126 grease_quic_bit transport parameter if it accepts 0-RTT. A client 127 MAY forget the value. In all other cases, only the presence or 128 absence of the transport parameter in the current handshake is used 129 to determine what values can be sent in the QUIC Bit. 131 3.1. Clearing the QUIC Bit 133 Endpoints that receive the grease_quic_bit transport parameter from a 134 peer MAY set the QUIC Bit to any value in packets they sent to that 135 peer. Endpoints SHOULD set the QUIC Bit to an unpredictable value 136 unless another extension assigns specific meaning to the value of the 137 bit. All packets sent after receiving and processing transport 138 parameters are affected, including Retry, Initial, and Handshake 139 packets. 141 A client MAY also clear the QUIC Bit in Initial packets that are sent 142 to establish a new connection. A client can only clear the QUIC Bit 143 if the packet includes a token provided by the server in a NEW_TOKEN 144 frame on a connection where the server also included the 145 grease_quic_bit transport parameter. To allow for changes in server 146 configuration, clients SHOULD set the QUIC Bit if the token was 147 provided more than 7 days prior. 149 3.2. Using the QUIC Bit 151 The purpose of this extension is to allow for the use of the QUIC Bit 152 by later extensions. 154 Extensions to QUIC that define semantics for the QUIC Bit can be 155 negotiated at the same time as the grease_quic_bit transport 156 parameter. In this case, a recipient needs to be able to distinguish 157 a randomized value from a value carrying information according to the 158 extension. Extensions that use the QUIC Bit MUST negotiate their use 159 prior to acting on any semantic. Endpoints MAY send a signal prior 160 to this negotiation completing, but any value carried by the bit 161 cannot be used until it is clear that the peer is using the 162 extension. 164 For example, an extension might define a transport parameter that is 165 sent in addition to the grease_quic_bit transport parameter. Though 166 the value of the QUIC Bit in packets received by a peer might be set 167 according to rules defined by the extension, they might also be 168 randomized according to the definition of the grease_quic_bit 169 extension. Receiving the transport parameter for the extension could 170 be used to confirm that a peer supports the semantic defined in the 171 extension. To avoid acting on a randomized signal, the extension can 172 require that endpoints set the QUIC Bit according to the rules of the 173 extension, but defer acting on the information conveyed until the 174 transport parameter for the extension is received. 176 Extensions that define semantics for the QUIC Bit can be negotiated 177 without using the grease_quic_bit transport parameter. 179 4. Security Considerations 181 This document introduces no new security considerations for endpoints 182 or entities that can rely on endpoint cooperation. However, this 183 change makes the task of identifying QUIC more difficult without 184 cooperation of endpoints. This sometimes works counter to the 185 security goals of network operators who rely on network 186 classification to identify threats. 188 5. IANA Considerations 190 This document registers the grease_quic_bit transport parameter in 191 the "QUIC Transport Parameters" registry established in Section 22.2 192 of [QUIC]. The following fields are registered: 194 Value: 0x2ab2 196 Parameter Name: grease_quic_bit 198 Status: Permanent 200 Specification: This document. 202 Date: Date of registration. 204 Contact: QUIC Working Group (quic@ietf.org) 206 Change Controller: IETF (iesg@ietf.org) 208 Notes: (none) 210 6. References 212 6.1. Normative References 214 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 215 and Secure Transport", Work in Progress, Internet-Draft, 216 draft-ietf-quic-transport-34, 14 January 2021, 217 . 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, 222 DOI 10.17487/RFC2119, March 1997, 223 . 225 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 226 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 227 May 2017, . 229 6.2. Informative References 231 [DEMUX] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 232 Updates for Secure Real-time Transport Protocol (SRTP) 233 Extension for Datagram Transport Layer Security (DTLS)", 234 RFC 7983, DOI 10.17487/RFC7983, September 2016, 235 . 237 [QUIC-INVARIANTS] 238 Thomson, M., "Version-Independent Properties of QUIC", 239 Work in Progress, Internet-Draft, draft-ietf-quic- 240 invariants-13, 14 January 2021, 241 . 244 [RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a 245 Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 246 2019, . 248 [USE-IT] Thomson, M. and T. Pauly, "Long-term Viability of Protocol 249 Extension Mechanisms", Work in Progress, Internet-Draft, 250 draft-iab-use-it-or-lose-it-04, 12 October 2021, 251 . 254 Acknowledgments 256 TODO 258 Author's Address 260 Martin Thomson 261 Mozilla 263 Email: mt@lowentropy.net