idnits 2.17.00 (12 Aug 2021) /tmp/idnits13292/draft-ietf-quic-bit-grease-02.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 (10 November 2021) is 185 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) == Outdated reference: draft-iab-use-it-or-lose-it has been published as RFC 9170 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 10 November 2021 5 Expires: 14 May 2022 7 Greasing the QUIC Bit 8 draft-ietf-quic-bit-grease-02 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 14 May 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 . . . . . . . . . . . . . . . . . . 3 66 3.2. Using the QUIC Bit . . . . . . . . . . . . . . . . . . . 4 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 71 6.2. Informative References . . . . . . . . . . . . . . . . . 5 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 QUIC [QUIC] intentionally describes a very narrow set of fields that 77 are visible to entities other than endpoints. Beyond those 78 characteristics that are defined as invariant [QUIC-INVARIANTS], very 79 little about the "wire image" [RFC8546] of QUIC is visible. 81 The second-to-most significant bit of the first byte in every QUIC 82 packet is defined as having a fixed value in QUIC version 1 [QUIC]. 83 The purpose of having a fixed value is to allow intermediaries and 84 endpoints to efficiently distinguish between QUIC and other 85 protocols; see [DEMUX] for a description of a scheme that QUIC can 86 integrate with as a result. As this bit effectively identifies a 87 packet as QUIC, it is sometimes referred to as the "QUIC Bit". 89 Where endpoints and the intermediaries that support them do not 90 depend on the QUIC Bit having a fixed value, sending the same value 91 in every packet is more of liability than an asset. If systems come 92 to depend on a fixed value, then it might become infeasible to define 93 a version of QUIC that attributes semantics to this bit. 95 In order to safeguard future use of this bit, this document defines a 96 QUIC transport parameter that indicates that an endpoint is willing 97 to receive QUIC packets containing any value for this bit. By 98 sending different values for this bit, the hope is that the value 99 will remain available for future use [USE-IT]. 101 2. Conventions and Definitions 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 This document uses terms and notational conventions from [QUIC]. 111 3. The Grease QUIC Bit Transport Parameter 113 The grease_quic_bit transport parameter (0x2ab2) can be sent by both 114 client and server. The transport parameter is sent with an empty 115 value; an endpoint that understands this transport parameter MUST 116 treat receipt of a non-empty value as a connection error of type 117 TRANSPORT_PARAMETER_ERROR. 119 Advertising the grease_quic_bit transport parameter indicates that 120 packets sent to this endpoint MAY set a value of 0 for the QUIC Bit. 121 The QUIC Bit is defined as the second-to-most significant bit of the 122 first byte of QUIC packets (that is, the value 0x40). 124 A server MUST respect the value it previously provided for the 125 grease_quic_bit transport parameter if it accepts 0-RTT. A client 126 MAY forget the value. In all other cases, only the presence or 127 absence of the transport parameter in the current handshake is used 128 to determine what values can be sent in the QUIC Bit. 130 3.1. Clearing the QUIC Bit 132 Endpoints that receive the grease_quic_bit transport parameter from a 133 peer MAY set the QUIC Bit to any value in packets they send to that 134 peer. Endpoints SHOULD set the QUIC Bit to an unpredictable value 135 unless another extension assigns specific meaning to the value of the 136 bit. All packets sent after receiving and processing transport 137 parameters are affected, including Retry, Initial, and Handshake 138 packets. 140 A client MAY also clear the QUIC Bit in Initial packets that are sent 141 prior to receiving transport parameters from the server. A client 142 can only clear the QUIC Bit if such packets include a token provided 143 by the server in a NEW_TOKEN frame on a connection where the server 144 also included the grease_quic_bit transport parameter. To allow for 145 changes in server configuration, clients SHOULD set the QUIC Bit if 146 the token was provided more than 7 days prior. 148 3.2. Using the QUIC Bit 150 The purpose of this extension is to allow for the use of the QUIC Bit 151 by later extensions. 153 Extensions to QUIC that define semantics for the QUIC Bit can be 154 negotiated at the same time as the grease_quic_bit transport 155 parameter. In this case, a recipient needs to be able to distinguish 156 a randomized value from a value carrying information according to the 157 extension. Extensions that use the QUIC Bit MUST negotiate their use 158 prior to acting on any semantic. Endpoints MAY send a signal prior 159 to this negotiation completing, but any value carried by the bit 160 cannot be used until it is clear that the peer is using the 161 extension. 163 For example, an extension might define a transport parameter that is 164 sent in addition to the grease_quic_bit transport parameter. Though 165 the value of the QUIC Bit in packets received by a peer might be set 166 according to rules defined by the extension, they might also be 167 randomized as specified in this document. Including both extensions 168 allows for the QUIC Bit to be greased even if the alternative use is 169 not supported. 171 Receiving a transport parameter for an extension that uses the QUIC 172 Bit could be used to confirm that a peer supports the semantic 173 defined in the extension. To avoid acting on a randomized signal, 174 the extension can require that endpoints set the QUIC Bit according 175 to the rules of the extension, but defer acting on the information 176 conveyed until the transport parameter for the extension is received. 178 Extensions that define semantics for the QUIC Bit can be negotiated 179 without using the grease_quic_bit transport parameter. 181 4. Security Considerations 183 This document introduces no new security considerations for endpoints 184 or entities that can rely on endpoint cooperation. However, this 185 change makes the task of identifying QUIC more difficult without 186 cooperation of endpoints. This sometimes works counter to the 187 security goals of network operators who rely on network 188 classification to identify threats. 190 5. IANA Considerations 192 This document registers the grease_quic_bit transport parameter in 193 the "QUIC Transport Parameters" registry established in Section 22.2 194 of [QUIC]. The following fields are registered: 196 Value: 0x2ab2 198 Parameter Name: grease_quic_bit 200 Status: Permanent 202 Specification: This document. 204 Date: Date of registration. 206 Contact: QUIC Working Group (quic@ietf.org) 208 Change Controller: IETF (iesg@ietf.org) 210 Notes: (none) 212 6. References 214 6.1. Normative References 216 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 217 Multiplexed and Secure Transport", RFC 9000, 218 DOI 10.17487/RFC9000, May 2021, 219 . 221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 222 Requirement Levels", BCP 14, RFC 2119, 223 DOI 10.17487/RFC2119, March 1997, 224 . 226 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 227 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 228 May 2017, . 230 6.2. Informative References 232 [DEMUX] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 233 Updates for Secure Real-time Transport Protocol (SRTP) 234 Extension for Datagram Transport Layer Security (DTLS)", 235 RFC 7983, DOI 10.17487/RFC7983, September 2016, 236 . 238 [QUIC-INVARIANTS] 239 Thomson, M., "Version-Independent Properties of QUIC", 240 RFC 8999, DOI 10.17487/RFC8999, May 2021, 241 . 243 [RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a 244 Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 245 2019, . 247 [USE-IT] Thomson, M. and T. Pauly, "Long-term Viability of Protocol 248 Extension Mechanisms", Work in Progress, Internet-Draft, 249 draft-iab-use-it-or-lose-it-04, 12 October 2021, 250 . 253 Author's Address 255 Martin Thomson 256 Mozilla 258 Email: mt@lowentropy.net