idnits 2.17.1 draft-ietf-quic-manageability-08.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 (2 November 2020) is 1268 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 1044 == Unused Reference: 'Ding2015' is defined on line 1108, but no explicit reference was found in the text == Unused Reference: 'IPIM' is defined on line 1129, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-quic-load-balancers-05 == Outdated reference: A later version (-18) exists of draft-ietf-quic-applicability-07 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-32 == Outdated reference: A later version (-13) exists of draft-ietf-quic-invariants-11 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-32 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-32 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-08 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Kuehlewind 3 Internet-Draft Ericsson 4 Intended status: Informational B. Trammell 5 Expires: 6 May 2021 Google 6 2 November 2020 8 Manageability of the QUIC Transport Protocol 9 draft-ietf-quic-manageability-08 11 Abstract 13 This document discusses manageability of the QUIC transport protocol, 14 focusing on caveats impacting network operations involving QUIC 15 traffic. Its intended audience is network operators, as well as 16 content providers that rely on the use of QUIC-aware middleboxes, 17 e.g. for load balancing. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 6 May 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 54 2. Features of the QUIC Wire Image . . . . . . . . . . . . . . . 4 55 2.1. QUIC Packet Header Structure . . . . . . . . . . . . . . 4 56 2.2. Coalesced Packets . . . . . . . . . . . . . . . . . . . . 6 57 2.3. Use of Port Numbers . . . . . . . . . . . . . . . . . . . 6 58 2.4. The QUIC handshake . . . . . . . . . . . . . . . . . . . 7 59 2.5. Integrity Protection of the Wire Image . . . . . . . . . 11 60 2.6. Connection ID and Rebinding . . . . . . . . . . . . . . . 11 61 2.7. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 12 62 2.8. Version Negotiation and Greasing . . . . . . . . . . . . 12 63 3. Network-visible information about QUIC flows . . . . . . . . 12 64 3.1. Identifying QUIC traffic . . . . . . . . . . . . . . . . 13 65 3.1.1. Identifying Negotiated Version . . . . . . . . . . . 13 66 3.1.2. Rejection of Garbage Traffic . . . . . . . . . . . . 14 67 3.2. Connection confirmation . . . . . . . . . . . . . . . . . 14 68 3.3. Application Identification . . . . . . . . . . . . . . . 14 69 3.3.1. Extracting Server Name Indication (SNI) 70 Information . . . . . . . . . . . . . . . . . . . . . 15 71 3.4. Flow association . . . . . . . . . . . . . . . . . . . . 16 72 3.5. Flow teardown . . . . . . . . . . . . . . . . . . . . . . 16 73 3.6. Flow symmetry measurement . . . . . . . . . . . . . . . . 16 74 3.7. Round-Trip Time (RTT) Measurement . . . . . . . . . . . . 17 75 3.7.1. Measuring initial RTT . . . . . . . . . . . . . . . . 17 76 3.7.2. Using the Spin Bit for Passive RTT Measurement . . . 17 77 4. Specific Network Management Tasks . . . . . . . . . . . . . . 19 78 4.1. Stateful treatment of QUIC traffic . . . . . . . . . . . 19 79 4.2. Passive network performance measurement and 80 troubleshooting . . . . . . . . . . . . . . . . . . . . . 19 81 4.3. Server cooperation with load balancers . . . . . . . . . 20 82 4.4. DDoS Detection and Mitigation . . . . . . . . . . . . . . 20 83 4.5. UDP Policing . . . . . . . . . . . . . . . . . . . . . . 21 84 4.6. Distinguishing acknowledgment traffic . . . . . . . . . . 21 85 4.7. QoS support and ECMP . . . . . . . . . . . . . . . . . . 21 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 88 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 89 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 90 9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 9.1. Distinguishing IETF QUIC and Google QUIC Versions . . . . 23 92 9.2. Extracting the CRYPTO frame . . . . . . . . . . . . . . . 24 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 95 10.2. Informative References . . . . . . . . . . . . . . . . . 25 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 98 1. Introduction 100 QUIC [QUIC-TRANSPORT] is a new transport protocol currently under 101 development in the IETF QUIC working group, focusing on support of 102 semantics as needed for HTTP/2 [QUIC-HTTP]. Based on current 103 deployment practices, QUIC is encapsulated in UDP and encrypted by 104 default. The current version of QUIC integrates TLS [QUIC-TLS] to 105 encrypt all payload data and most control information. 107 Given that QUIC is an end-to-end transport protocol, all information 108 in the protocol header, even that which can be inspected, is not 109 meant to be mutable by the network, and is therefore integrity- 110 protected. While less information is visible to the network than for 111 TCP, integrity protection can also simplify troubleshooting because 112 none of the nodes on the network path can modify the transport layer 113 information. 115 This document provides guidance for network operation on the 116 management of QUIC traffic. This includes guidance on how to 117 interpret and utilize information that is exposed by QUIC to the 118 network as well as explaining requirement and assumptions that the 119 QUIC protocol design takes toward the expected network treatment. It 120 also discusses how common network management practices will be 121 impacted by QUIC. 123 Since QUIC's wire image [WIRE-IMAGE] is integrity protected and not 124 modifiable on path, in-network operations are not possible without 125 terminating the QUIC connection, for instance using a back-to-back 126 proxy. Proxy operations are not in scope for this document. QUIC 127 proxies must be fully-fledged QUIC endpoints, implementing the 128 transport as defined in [QUIC-TRANSPORT] and [QUIC-TLS] as well as 129 proxy-relevant semantics for the application(s) running over QUIC 130 (e.g. HTTP/3 as defined in [QUIC-HTTP]). 132 Network management is not a one-size-fits-all endeavour: practices 133 considered necessary or even mandatory within enterprise networks 134 with certain compliance requirements, for example, would be 135 impermissible on other networks without those requirements. This 136 document therefore does not make any specific recommendations as to 137 which practices should or should not be applied; for each practice, 138 it describes what is and is not possible with the QUIC transport 139 protocol as defined. 141 QUIC is at the moment very much a moving target. This document 142 refers the state of the QUIC working group drafts as well as to 143 changes under discussion, via issues and pull requests in GitHub 144 current as of the time of writing. 146 1.1. Notational Conventions 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in BCP 151 14 [RFC2119] [RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 2. Features of the QUIC Wire Image 156 In this section, we discusses those aspects of the QUIC transport 157 protocol that have an impact on the design and operation of devices 158 that forward QUIC packets. Here, we are concerned primarily with the 159 unencrypted part of QUIC's wire image [WIRE-IMAGE], which we define 160 as the information available in the packet header in each QUIC 161 packet, and the dynamics of that information. Since QUIC is a 162 versioned protocol, the wire image of the header format can also 163 change from version to version. However, at least the mechanism by 164 which a receiver can determine which version is used and the meaning 165 and location of fields used in the version negotiation process is 166 invariant [QUIC-INVARIANTS]. 168 This document describes only version 1 the QUIC protocol, whose wire 169 image is fully defined in [QUIC-TRANSPORT] and [QUIC-TLS]. Note that 170 features of the wire image described herein and in those documents 171 may change in future versions of the protocol, and cannot be used to 172 identify QUIC as a protocol or to infer the behavior of future 173 versions of QUIC. Section 9.1 provides non-normative guidance on the 174 identification of QUIC version 1 packets compared to other deployed 175 versions at the date if publication. 177 2.1. QUIC Packet Header Structure 179 QUIC packets may have either a long header, or a short header. The 180 first bit of the QUIC header us the Header Form bit, and indicates 181 which type of header is present. 183 The long header exposes more information. It is used during 184 connection establishment, including version negotiation, retry, and 185 0-RTT data. It contains a version number, as well as source and 186 destination connection IDs for grouping packets belonging to the same 187 flow. The definition and location of these fields in the QUIC long 188 header are invariant for future versions of QUIC, although future 189 versions of QUIC may provide additional fields in the long header 190 [QUIC-INVARIANTS]. 192 Short headers are used after connection establishment, and contain 193 only an optional destination connection ID and the spin bit for RTT 194 measurement. 196 The following information is exposed in QUIC packet headers: 198 * "fixed bit": the second most significant bit of the first octet 199 most QUIC packets of the current version is currently set to 1, 200 for demultiplexing with other UDP-encapsulated protocols. 202 * latency spin bit: the third most significant bit of first octet in 203 the short packet header. The spin bit is set by endpoints such 204 that tracking edge transitions can be used to passively observe 205 end-to-end RTT. See Section 3.7.2 for further details. 207 * header type: the long header has a 2 bit packet type field 208 following the Header Form and fixed bits. Header types correspond 209 to stages of the handshake; see Section 17.2 of [QUIC-TRANSPORT] 210 for details. 212 * version number: the version number present in the long header, and 213 identifies the version used for that packet. Note that during 214 Version Negotiation (see Section 2.8, and Section 17.2.1 of 215 [QUIC-TRANSPORT], the version number field has a special value 216 (0x00000000) that identifies the packet as a Version Negotiation 217 packet. QUIC versions that start with 0xff are IETF drafts. QUIC 218 versions that start with 0x0000 are reserved for IETF consensus 219 documents, for example the QUIC version 1 is expected to use 220 version 0x00000001. 222 * source and destination connection ID: short and long packet 223 headers carry a destination connection ID, a variable-length field 224 that can be used to identify the connection associated with a QUIC 225 packet, for load-balancing and NAT rebinding purposes; see 226 Section 4.3 and Section 2.6. Long packet headers additionally 227 carry a source connection ID. The source connection ID 228 corresponds to the destination connection ID the source would like 229 to have on packets sent to it, and is only present on long packet 230 headers. On long header packets, the length of the connection IDs 231 is also present; on short header packets, the length of the 232 destination connection ID is implicit. 234 * length: the length of the remaining QUIC packet after the length 235 field, present on long headers. This field is used to implement 236 coalesced packets during the handshake (see Section 2.2). 238 * token: Initial packets may contain a token, a variable-length 239 opaque value optionally sent from client to server, used for 240 validating the client's address. Retry packets also contain a 241 token, which can be used by the client in an Initial packet on a 242 subsequent connection attempt. The length of the token is 243 explicit in both cases. 245 Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation 246 (Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or 247 obfuscated in any way. For other kinds of packets, other information 248 in the packet headers is cryptographically obfuscated: 250 * packet number: All packets except Version Negotiation and Retry 251 packets have an associated packet number; however, this packet 252 number is encrypted, and therefore not of use to on-path 253 observers. The offset of the packet number is encoded in the 254 header for packets with long headers, while it is implicit 255 (depending on Destination Connection ID length) in short header 256 packets. The length of the packet number is cryptographically 257 obfuscated. 259 * key phase: The Key Phase bit, present in short headers, specifies 260 the keys used to encrypt the packet, supporting key rotation. The 261 Key Phase bit is cryptographically obfuscated. 263 2.2. Coalesced Packets 265 Multiple QUIC packets may be coalesced into a UDP datagram, with a 266 datagram carrying one or more long header packets followed by zero or 267 one short header packets. When packets are coalesced, the Length 268 fields in the long headers are used to separate QUIC packets. The 269 length header field is variable length and its position in the header 270 is also variable depending on the length of the source and 271 destination connection ID. See Section 4.6 of [QUIC-TRANSPORT]. 273 2.3. Use of Port Numbers 275 Applications that have a mapping for TCP as well as QUIC are expected 276 to use the same port number for both services. However, as with TCP- 277 based services, especially when application layer information is 278 encrypted, there is no guarantee that a specific application will use 279 the registered port, or the used port is carrying traffic belonging 280 to the respective registered service. For example, [QUIC-TRANSPORT] 281 specifies the use of Alt-Svc for discovery of QUIC/HTTP services on 282 other ports. 284 Further, as QUIC has a connection ID, it is also possible to maintain 285 multiple QUIC connections over one 5-tuple. However, if the 286 connection ID is not present in the packet header, all packets of the 287 5-tuple belong to the same QUIC connection. 289 2.4. The QUIC handshake 291 New QUIC connections are established using a handshake, which is 292 distinguishable on the wire and contains some information that can be 293 passively observed. 295 To illustrate the information visible in the QUIC wire image during 296 the handshake, we first show the general communication pattern 297 visible in the UDP datagrams containing the QUIC handshake, then 298 examine each of the datagrams in detail. 300 In the nominal case, the QUIC handshake can be recognized on the wire 301 through at least four datagrams we'll call "QUIC Client Hello", "QUIC 302 Server Hello", and "Initial Completion", and "Handshake Completion", 303 for purposes of this illustration, as shown in Figure 1. 305 Packets in the handshake belong to three separate cryptographic and 306 transport contexts ("Initial", which contains observable payload, and 307 "Handshake" and "1-RTT", which do not). QUIC packets in separate 308 contexts during the handshake are generally coalesced (see 309 Section 2.2) in order to reduce the number of UDP datagrams sent 310 during the handshake. 312 As shown here, the client can send 0-RTT data as soon as it has sent 313 its Client Hello, and the server can send 1-RTT data as soon as it 314 has sent its Server Hello. 316 Client Server 317 | | 318 +----QUIC Client Hello-------------------->| 319 +----(zero or more 0RTT)------------------>| 320 | | 321 |<--------------------QUIC Server Hello----+ 322 |<---------(1RTT encrypted data starts)----+ 323 | | 324 +----Initial Completion------------------->| 325 +----(1RTT encrypted data starts)--------->| 326 | | 327 |<-----------------Handshake Completion----+ 328 | | 330 Figure 1: General communication pattern visible in the QUIC handshake 331 A typical handshake starts with the client sending of a QUIC Client 332 Hello datagram as shown in Figure 2, which elicits a QUIC Server 333 Hello datagram as shown in Figure 3 typically containing three 334 packets: an Initial packet with the Server Hello, a Handshake packet 335 with the rest of the server's side of the TLS handshake, and initial 336 1-RTT data, if present. 338 The content of QUIC Initial packets are encrypted using Initial 339 Secrets, which are derived from a per-version constant and the 340 client's destination connection ID; they are therefore observable by 341 any on-path device that knows the per-version constant; we therefore 342 consider these as visible in our illustration. The content of QUIC 343 Handshake packets are encrypted using keys established during the 344 initial handshake exchange, and are therefore not visible. 346 Initial, Handshake, and the Short Header packets transmitted after 347 the handshake belong to cryptographic and transport contexts. The 348 Initial Completion Figure 4 and the Handshake Completion Figure 5 349 datagrams finish these first two contexts, by sending the final 350 acknowledgment and finishing the transmission of CRYPTO frames. 352 +----------------------------------------------------------+ 353 | UDP header (source and destination UDP ports) | 354 +----------------------------------------------------------+ 355 | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 356 +----------------------------------------------------------+ | 357 | QUIC CRYPTO frame header | | 358 +----------------------------------------------------------+ | 359 | TLS Client Hello (incl. TLS SNI) | | 360 +----------------------------------------------------------+ | 361 | QUIC PADDING frame | | 362 +----------------------------------------------------------+<-+ 364 Figure 2: Typical 1-RTT QUIC Client Hello datagram pattern 366 The Client Hello datagram exposes version number, source and 367 destination connection IDs in the clear. Information in the TLS 368 Client Hello frame, including any TLS Server Name Indication (SNI) 369 present, is obfuscated using the Initial secret. The QUIC PADDING 370 frame shown here may be present to ensure the Client Hello datagram 371 has a minimum size of 1200 octets, to mitigate the possibility of 372 handshake amplification. Note that the location of PADDING is 373 implementation-dependent, and PADDING frames may not appear in the 374 Initial packet in a coalesced packet. 376 +------------------------------------------------------------+ 377 | UDP header (source and destination UDP ports) | 378 +------------------------------------------------------------+ 379 | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 380 +------------------------------------------------------------+ | 381 | QUIC CRYPTO frame header | | 382 +------------------------------------------------------------+ | 383 | TLS Server Hello | | 384 +------------------------------------------------------------+ | 385 | QUIC ACK frame (acknowledging client hello) | | 386 +------------------------------------------------------------+<-+ 387 | QUIC long header (type = Handshake, Version, DCID, SCID) (Length) 388 +------------------------------------------------------------+ | 389 | encrypted payload (presumably CRYPTO frames) | | 390 +------------------------------------------------------------+<-+ 391 | QUIC short header | 392 +------------------------------------------------------------+ 393 | 1-RTT encrypted payload | 394 +------------------------------------------------------------+ 396 Figure 3: Typical QUIC Server Hello datagram pattern 398 The Server Hello datagram also exposes version number, source and 399 destination connection IDs and information in the TLS Server Hello 400 message which is obfuscated using the Initial secret. 402 +------------------------------------------------------------+ 403 | UDP header (source and destination UDP ports) | 404 +------------------------------------------------------------+ 405 | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 406 +------------------------------------------------------------+ | 407 | QUIC ACK frame (acknowledging Server Hello Initial) | | 408 +------------------------------------------------------------+<-+ 409 | QUIC long header (type = Handshake, Version, DCID, SCID) (Length) 410 +------------------------------------------------------------+ | 411 | encrypted payload (presumably CRYPTO/ACK frames) | | 412 +------------------------------------------------------------+<-+ 413 | QUIC short header | 414 +------------------------------------------------------------+ 415 | 1-RTT encrypted payload | 416 +------------------------------------------------------------+ 418 Figure 4: Typical QUIC Initial Completion datagram pattern 420 The Initial Completion datagram does not expose any additional 421 information; however, recognizing it can be used to determine that a 422 handshake has completed (see Section 3.2), and for three-way 423 handshake RTT estimation as in Section 3.7. 425 +------------------------------------------------------------+ 426 | UDP header (source and destination UDP ports) | 427 +------------------------------------------------------------+ 428 | QUIC long header (type = Handshake, Version, DCID, SCID) (Length) 429 +------------------------------------------------------------+ | 430 | encrypted payload (presumably ACK frame) | | 431 +------------------------------------------------------------+<-+ 432 | QUIC short header | 433 +------------------------------------------------------------+ 434 | 1-RTT encrypted payload | 435 +------------------------------------------------------------+ 437 Figure 5: Typical QUIC Handshake Completion datagram pattern 439 Similar to Initial Completion, Handshake Completion also exposes no 440 additional information; observing it serves only to determine that 441 the handshake has completed. 443 When the client uses 0-RTT connection resumption, 0-RTT data may also 444 be seen in the QUIC Client Hello datagram, as shown in Figure 6. 446 +----------------------------------------------------------+ 447 | UDP header (source and destination UDP ports) | 448 +----------------------------------------------------------+ 449 | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 450 +----------------------------------------------------------+ | 451 | QUIC CRYPTO frame header | | 452 +----------------------------------------------------------+ | 453 | TLS Client Hello (incl. TLS SNI) | | 454 +----------------------------------------------------------+<-+ 455 | QUIC long header (type = 0RTT, Version, DCID, SCID) (Length) 456 +----------------------------------------------------------+ | 457 | 0-rtt encrypted payload | | 458 +----------------------------------------------------------+<-+ 460 Figure 6: Typical 0-RTT QUIC Client Hello datagram pattern 462 In a 0-RTT QUIC Client Hello datagram, the PADDING frame is only 463 present if necessary to increase the size of the datagram with 0RTT 464 data to at least 1200 bytes. Additional datagrams containing only 465 0-RTT protected long header packets may be sent from the client to 466 the server after the Client Hello datagram, containing the rest of 467 the 0-RTT data. The amount of 0-RTT protected data is limited by the 468 initial congestion window, typically around 10 packets [RFC6928]. 470 2.5. Integrity Protection of the Wire Image 472 As soon as the cryptographic context is established, all information 473 in the QUIC header, including information exposed in the packet 474 header, is integrity protected. Further, information that was sent 475 and exposed in handshake packets sent before the cryptographic 476 context was established are validated later during the cryptographic 477 handshake. Therefore, devices on path MUST NOT change any 478 information or bits in QUIC packet headers, since alteration of 479 header information will lead to a failed integrity check at the 480 receiver, and can even lead to connection termination. 482 2.6. Connection ID and Rebinding 484 The connection ID in the QUIC packet headers allows routing of QUIC 485 packets at load balancers on other than five-tuple information, 486 ensuring that related flows are appropriately balanced together; and 487 to allow rebinding of a connection after one of the endpoint's 488 addresses changes - usually the client's, in the case of the HTTP 489 binding. Client and server negotiate connection IDs during the 490 handshake; typically, however, only the server will request a 491 connection ID for the lifetime of the connection. Connection IDs for 492 either endpoint may change during the lifetime of a connection, with 493 the new connection ID being negotiated via encrypted frames. See 494 Section 5.1 of [QUIC-TRANSPORT]. 496 Server-generated connection IDs should seek to obscure any encoding, 497 of routing identities or any other information. Exposing the server 498 mapping would allow linkage of multiple IP addresses to the same host 499 if the server also supports migration. Furthermore, this opens an 500 attack vector on specific servers or pools. 502 The best way to obscure an encoding is to appear random to observers, 503 which is most rigorously achieved with encryption. Even when 504 encrypted, a scheme could embed the unencrypted length of the 505 Connection ID in the Connection ID itself, instead of remembering it, 506 e.g. by using the first few bits to indicate a certain size of a 507 well-known set of possible sizes with multiple values that indicate 508 the same size but are selected randomly. 510 [QUIC_LB] further specified possible algorithms to generate 511 Connection IDs at load balancers. 513 2.7. Packet Numbers 515 The packet number field is always present in the QUIC packet header; 516 however, it is always encrypted. The encryption key for packet 517 number protection on handshake packets sent before cryptographic 518 context establishment is specific to the QUIC version, while packet 519 number protection on subsequent packets uses secrets derived from the 520 end-to-end cryptographic context. Packet numbers are therefore not 521 part of the wire image that is visible to on-path observers. 523 2.8. Version Negotiation and Greasing 525 Version negotiation is not protected, given the used protection 526 mechanism can change with the version. However, the choices provided 527 in the list of version in the Version Negotiation packet will be 528 validated as soon as the cryptographic context has been established. 529 Therefore any manipulation of this list will be detected and will 530 cause the endpoints to terminate the connection. 532 Also note that the list of versions in the Version Negotiation packet 533 may contain reserved versions. This mechanism is used to avoid 534 ossification in the implementation on the selection mechanism. 535 Further, a client may send a Initial Client packet with a reserved 536 version number to trigger version negotiation. In the Version 537 Negotiation packet the connection ID and packet number of the Client 538 Initial packet are reflected to provide a proof of return- 539 routability. Therefore changing these information will also cause 540 the connection to fail. 542 QUIC is expected to evolve rapidly, so new versions, both 543 experimental and IETF standard versions, will be deployed in the 544 Internet more often than with traditional Internet- and transport- 545 layer protocols. Using a particular version number to recognize 546 valid QUIC traffic is likely to persistently miss a fraction of QUIC 547 flows and completely fail in the multi-year timeframe so therefore 548 not recommended. 550 3. Network-visible information about QUIC flows 552 This section addresses the different kinds of observations and 553 inferences that can be made about QUIC flows by a passive observer in 554 the network based on the wire image in Section 2. Here we assume a 555 bidirectional observer (one that can see packets in both directions 556 in the sequence in which they are carried on the wire) unless noted. 558 3.1. Identifying QUIC traffic 560 The QUIC wire image is not specifically designed to be 561 distinguishable from other UDP traffic. 563 The only application binding defined by the IETF QUIC WG is HTTP/3 564 [QUIC-HTTP] at the time of this writing; however, many other 565 applications are currently being defined and deployed over QUIC, so 566 an assumption that all QUIC traffic is HTTP/3 is not valid. HTTP 567 over QUIC uses UDP port 443 by default, although URLs referring to 568 resources available over HTTP over QUIC may specify alternate port 569 numbers. Simple assumptions about whether a given flow is using QUIC 570 based upon a UDP port number may therefore not hold; see also 571 [RFC7605] section 5. 573 While the second most significant bit (0x40) of the first octet is 574 set to 1 in most QUIC packets of the current version (see 575 Section 2.1), this method of recognizing QUIC traffic is NOT 576 RECOMMENDED. First, it only provides one bit of information and is 577 quite prone to collide with UDP-based protocols other than those that 578 this static bit is meant to allow multiplexing with. Second, this 579 feature of the wire image is not invariant [QUIC-INVARIANTS] and may 580 change in future versions of the protocol, or even be negotiated 581 after handshake via future transport parameters. 583 3.1.1. Identifying Negotiated Version 585 An in-network observer assuming that a set of packets belongs to a 586 QUIC flow can infer the version number in use by observing the 587 handshake: an Initial packet with a given version from a client to 588 which a server responds with an Initial packet with the same version 589 implies acceptance of that version. 591 Negotiated version cannot be identified for flows for which a 592 handshake is not observed, such as in the case of connection 593 migration; however, these flows can be associated with flows for 594 which a version has been identified; see Section 3.4. 596 This document focuses on QUIC Version 1, and this section applies 597 only to packets belonging to Version 1 QUIC flows; for purposes of 598 on-path observation, it assumes that these packets have been 599 identified as such through the observation of a version negotiation. 601 3.1.2. Rejection of Garbage Traffic 603 A related question is whether a first packet of a given flow on known 604 QUIC-associated port is a valid QUIC packet, in order to support in- 605 network filtering of garbage UDP packets (reflection attacks, random 606 backscatter). While heuristics based on the first byte of the packet 607 (packet type) could be used to separate valid from invalid first 608 packet types, the deployment of such heuristics is not recommended, 609 as packet types may have different meanings in future versions of the 610 protocol. 612 3.2. Connection confirmation 614 Connection establishment uses Initial, Handshake, and Retry packets 615 containing a TLS handshake. Connection establishment can therefore 616 be detected using heuristics similar to those used to detect TLS over 617 TCP. A client using 0-RTT connection may also send data packets in 618 0-RTT Protected packets directly after the Initial packet containing 619 the TLS Client Hello. Since these packets may be reordered in the 620 network, note that 0-RTT Protected data packets may be seen before 621 the Initial packet. 623 Note that clients send Initial packets before servers do, servers 624 send Handshake packets before clients do, and only clients send 625 Initial packets with tokens, so the sides of a connection can be 626 generally be confirmed by an on-path observer. An attempted 627 connection after Retry can be detected by correlating the token on 628 the Retry with the token on the subsequent Initial packet. 630 3.3. Application Identification 632 The cleartext TLS handshake may contain Server Name Indication (SNI) 633 [RFC6066], by which the client reveals the name of the server it 634 intends to connect to, in order to allow the server to present a 635 certificate based on that name. It may also contain information from 636 Application-Layer Protocol Negotiation (ALPN) [RFC7301], by which the 637 client exposes the names of application-layer protocols it supports; 638 an observer can deduce that one of those protocols will be used if 639 the connection continues. 641 Work is currently underway in the TLS working group to encrypt the 642 SNI in TLS 1.3 [TLS-ESNI]. If used with QUIC, this would make SNI- 643 based application identification impossible through passive 644 measurement. 646 3.3.1. Extracting Server Name Indication (SNI) Information 648 If the SNI is not encrypted it can be derived from the QUIC Initial 649 packet by calculating the Initial Secret to decrypt the packet 650 payload and parse the QUIC CRYPTO Frame containing the TLS 651 ClientHello. 653 As both the initial salt for the Initial Secret as well as CRYPTO 654 frame itself are version-specific, the first step is always to parse 655 the version number (second to sixth byte of the long header). Note 656 that only long header packets carry the version number, so it is 657 necessary to also check the if first bit of the QUIC packet is set to 658 1, indicating a long header. 660 Note, that proprietary QUIC versions, that have been deployed before 661 standardization, might not set the first bit in a QUIC long header 662 packets to 1. To parse these versions example code is provided in 663 the appendix (see Section 9.1), however, it is expected that these 664 versions will gradually disappear over time. 666 When the version has been identified as QUIC version 1, the packet 667 type needs to be verified as an Initial packet by checking that the 668 third and fourth bit of the header are both set to 0. Then the 669 Client Destination Connection ID needs to be extracted to calculate 670 the Initial Secret together with the version specific initial salt, 671 as described in [QUIC-TLS]. The length of the connection ID is 672 indicated in the 6th byte of the header followed by the connection ID 673 itself. 675 To determine the end of the header and find the start of the payload 676 further the packet number length, the source connection ID length, as 677 well as the token length need to be extracted. The packet number 678 length is defined by the seventh and eight bits of the header as 679 described in section 17.2. of [QUIC-TRANSPORT]. The source 680 connection ID length is specified in the byte after the destination 681 connection ID. And the token length, which follows the source 682 connection ID, is a variable length integer as specified in section 683 16 of [QUIC-TRANSPORT]. 685 Finally after decryption, the Initial Client packet can be parsed to 686 detect the CRYPTO frame that contains the TLS Client Hello, which 687 then can be respectively parsed similar as for all other TLS 688 connections. The Initial client packet may contain other frames, so 689 the first byte of each frame need to be checked to identify the frame 690 type and the skip over the frame. Note that the length of the frames 691 is dependent on the frame type. Usually for QUIC version 1, the 692 packet is expected to only carry the CRYPTO frame and optionally 693 padding frames. However, padding which is one byte of zeros, may 694 also occur before or after the CRYPTO frame. 696 3.4. Flow association 698 The QUIC Connection ID (see Section 2.6) is designed to allow an on- 699 path device such as a load-balancer to associate two flows as 700 identified by five-tuple when the address and port of one of the 701 endpoints changes; e.g. due to NAT rebinding or server IP address 702 migration. An observer keeping flow state can associate a connection 703 ID with a given flow, and can associate a known flow with a new flow 704 when when observing a packet sharing a connection ID and one endpoint 705 address (IP address and port) with the known flow. 707 However, since the connection ID may change multiple times during the 708 lifetime of a flow, and the negotiation of connection ID changes is 709 encrypted, packets with the same 5-tuple but different connection IDs 710 may or may not belong to the same connection. 712 The connection ID value should be treated as opaque; see Section 4.3 713 for caveats regarding connection ID selection at servers. 715 3.5. Flow teardown 717 QUIC does not expose the end of a connection; the only indication to 718 on-path devices that a flow has ended is that packets are no longer 719 observed. Stateful devices on path such as NATs and firewalls must 720 therefore use idle timeouts to determine when to drop state for QUIC 721 flows, see further section Section 4.1. 723 3.6. Flow symmetry measurement 725 QUIC explicitly exposes which side of a connection is a client and 726 which side is a server during the handshake. In addition, the 727 symmetry of a flow (whether primarily client-to-server, primarily 728 server-to-client, or roughly bidirectional, as input to basic traffic 729 classification techniques) can be inferred through the measurement of 730 data rate in each direction. While QUIC traffic is protected and 731 ACKs may be padded, padding is not required. 733 3.7. Round-Trip Time (RTT) Measurement 735 Round-trip time of QUIC flows can be inferred by observation once per 736 flow, during the handshake, as in passive TCP measurement; this 737 requires parsing of the QUIC packet header and recognition of the 738 handshake, as illustrated in Section 2.4. It can also be inferred 739 during the flow's lifetime, if the endpoints use the spin bit 740 facility described below and in [QUIC-TRANSPORT], section 17.3.1. 742 3.7.1. Measuring initial RTT 744 In the common case, the delay between the Initial packet containing 745 the TLS Client Hello and the Handshake packet containing the TLS 746 Server Hello represents the RTT component on the path between the 747 observer and the server. The delay between the TLS Server Hello and 748 the Handshake packet containing the TLS Finished message sent by the 749 client represents the RTT component on the path between the observer 750 and the client. While the client may send 0-RTT Protected packets 751 after the Initial packet during 0-RTT connection re-establishment, 752 these can be ignored for RTT measurement purposes. 754 Handshake RTT can be measured by adding the client-to-observer and 755 observer-to-server RTT components together. This measurement 756 necessarily includes any transport and application layer delay (the 757 latter mainly caused by the asymmetric crypto operations associated 758 with the TLS handshake) at both sides. 760 3.7.2. Using the Spin Bit for Passive RTT Measurement 762 The spin bit provides an additional method to measure per-flow RTT 763 from observation points on the network path throughout the duration 764 of a connection. Endpoint participation in spin bit signaling is 765 optional in QUIC. That is, while its location is fixed in this 766 version of QUIC, an endpoint can unilaterally choose to not support 767 "spinning" the bit. Use of the spin bit for RTT measurement by 768 devices on path is only possible when both endpoints enable it. Some 769 endpoints may disable use of the spin bit by default, others only in 770 specific deployment scenarios, e.g. for servers and clients where the 771 RTT would reveal the presence of a VPN or proxy. To avoid making 772 these connections identifiable based on the usage of the spin bit, it 773 is recommended that all endpoints randomly disable "spinning" for at 774 least one eighth of connections, even if otherwise enabled by 775 default. An endpoint not participating in spin bit signaling for a 776 given connection can use a fixed spin value for the duration of the 777 connection, or can set the bit randomly on each packet sent. 779 When in use and a QUIC flow sends data continuously, the latency spin 780 bit in each direction changes value once per round-trip time (RTT). 781 An on-path observer can observe the time difference between edges 782 (changes from 1 to 0 or 0 to 1) in the spin bit signal in a single 783 direction to measure one sample of end-to-end RTT. 785 Note that this measurement, as with passive RTT measurement for TCP, 786 includes any transport protocol delay (e.g., delayed sending of 787 acknowledgements) and/or application layer delay (e.g., waiting for a 788 response to be generated). It therefore provides devices on path a 789 good instantaneous estimate of the RTT as experienced by the 790 application. A simple linear smoothing or moving minimum filter can 791 be applied to the stream of RTT information to get a more stable 792 estimate. 794 However, application-limited and flow-control-limited senders can 795 have application and transport layer delay, respectively, that are 796 much greater than network RTT. When the sender is application- 797 limited and e.g. only sends small amount of periodic application 798 traffic, where that period is longer than the RTT, measuring the spin 799 bit provides information about the application period, not the 800 network RTT. 802 Since the spin bit logic at each endpoint considers only samples from 803 packets that advance the largest packet number, signal generation 804 itself is resistant to reordering. However, reordering can cause 805 problems at an observer by causing spurious edge detection and 806 therefore inaccurate (i.e., lower) RTT estimates, if reordering 807 occurs across a spin-bit flip in the stream. 809 Simple heuristics based on the observed data rate per flow or changes 810 in the RTT series can be used to reject bad RTT samples due to lost 811 or reordered edges in the spin signal, as well as application or flow 812 control limitation; for example, QoF [TMA-QOF] rejects component RTTs 813 significantly higher than RTTs over the history of the flow. These 814 heuristics may use the handshake RTT as an initial RTT estimate for a 815 given flow. Usually such heuristics would also detect if the spin is 816 either constant or randomly set for a connection. 818 An on-path observer that can see traffic in both directions (from 819 client to server and from server to client) can also use the spin bit 820 to measure "upstream" and "downstream" component RTT; i.e, the 821 component of the end-to-end RTT attributable to the paths between the 822 observer and the server and the observer and the client, 823 respectively. It does this by measuring the delay between a spin 824 edge observed in the upstream direction and that observed in the 825 downstream direction, and vice versa. 827 4. Specific Network Management Tasks 829 In this section, we review specific network management and 830 measurement techniques and how QUIC's design impacts them. 832 4.1. Stateful treatment of QUIC traffic 834 Stateful treatment of QUIC traffic (e.g., at a firewall or NAT 835 middlebox) is possible through QUIC traffic and version 836 identification (Section 3.1) and observation of the handshake for 837 connection confirmation (Section 3.2). The lack of any visible end- 838 of-flow signal (Section 3.5) means that this state must be purged 839 either through timers or through least-recently-used eviction, 840 depending on application requirements. 842 [RFC4787] recommends a 2 minute timeout interval for UDP, however, 843 often timer are lower in the range of 15 to 30 second. In constrast 844 [RFC5382] recommends a timeout of more than 2 hours for TCP, given 845 TCP is a connection-oriented protocol with well defined closure 846 semantics. For network devices that are QUIC-aware, it is 847 recommended to also use longer timeouts for QUIC traffic, as QUIC is 848 connection-oriented and as such a handshake packet from the server 849 indicates the willingness of the server to communicate with the 850 client. 852 The QUIC header optionally contains a Connection ID which can be used 853 as additional entropy beyond the 5-tuple, if needed. The QUIC 854 handshake needs to be observed in order to understand whether the 855 Connection ID is present and what length it has. However, Connection 856 IDs may be renegotiated during a connection, and this renegotiation 857 is not visible to the path. Keying state off the Connection ID may 858 therefore cause undetectable and unrecoverable loss of state in the 859 middle of a connection. Use of Connection ID specifically 860 discouraged for NAT applications. 862 4.2. Passive network performance measurement and troubleshooting 864 Limited RTT measurement is possible by passive observation of QUIC 865 traffic; see Section 3.7. No passive measurement of loss is possible 866 with the present wire image. Extremely limited observation of 867 upstream congestion may be possible via the observation of CE 868 markings on ECN-enabled QUIC traffic. 870 4.3. Server cooperation with load balancers 872 In the case of content distribution networking architectures 873 including load balancers, the connection ID provides a way for the 874 server to signal information about the desired treatment of a flow to 875 the load balancers. Guidance on assigning connection IDs is given in 876 [QUIC-APPLICABILITY]. 878 4.4. DDoS Detection and Mitigation 880 Current practices in detection and mitigation of Distributed Denial 881 of Service (DDoS) attacks generally involves classification of 882 incoming traffic (as packets, flows, or some other aggregate) into 883 "good" (productive) and "bad" (DDoS) traffic, then differential 884 treatment of this traffic to forward only good traffic, to the extent 885 possible. This operation is often done in a separate specialized 886 mitigation environment through which all traffic is filtered; a 887 generalized architecture for separation of concerns in mitigation is 888 given in [DOTS-ARCH]. 890 Key to successful DDoS mitigation is efficient classification of this 891 traffic in the mitigation environment. Limited first-packet garbage 892 detection as in Section 3.1.2 and stateful tracking of QUIC traffic 893 as in Section 4.1 above may be useful during classification. 895 Note that the use of a connection ID to support connection migration 896 renders 5-tuple based filtering insufficient and requires more state 897 to be maintained by DDoS defense systems. For the common case of NAT 898 rebinding, DDoS defense systems can detect a change in client's 899 endpoint address by linking flows based on the first 8 bytes of the 900 server's connection IDs, provided the server is using at least 8- 901 bytes-long connection IDs. QUIC's linkability resistance ensures 902 that a deliberate connection migration is accompanied by a change in 903 the connection ID and necessitate that connection ID aware DDoS 904 defense system must have the same information about connection IDs as 905 the load balancer [I-D.ietf-quic-load-balancers]. This may be 906 complicated where mitigation and load balancing environments are 907 logically separate. 909 It is questionable whether connection migrations must be supported 910 during a DDoS attack. If the connection migration is not visible to 911 the network that performs the DDoS detection, an active, migrated 912 QUIC connection may be blocked by such a system under attack. As 913 soon as the connection blocking is detected by the client, the client 914 may rely on the fast resumption mechanism provided by QUIC. When 915 clients migrate to a new path, they should be prepared for the 916 migration to fail and attempt to reconnect quickly. 918 4.5. UDP Policing 920 Today, UDP is the most prevalent DDoS vector, since it is easy for 921 compromised non-admin applications to send a flood of large UDP 922 packets (while with TCP the attacker gets throttled by the congestion 923 controller) or to craft reflection and amplification attacks. 924 Networks should therefore be prepared for UDP flood attacks on ports 925 used for QUIC traffic. One possible response to this threat is to 926 police UDP traffic on the network, allocating a fixed portion of the 927 network capacity to UDP and blocking UDP datagram over that cap. 929 The recommended way to police QUIC packets is to either drop them all 930 or to throttle them based on the hash of the UDP datagram's source 931 and destination addresses, blocking a portion of the hash space that 932 corresponds to the fraction of UDP traffic one wishes to drop. When 933 the handshake is blocked, QUIC-capable applications may failover to 934 TCP (at least applications using well-known UDP ports). However, 935 blindly blocking a significant fraction of QUIC packets will allow 936 many QUIC handshakes to complete, preventing a TCP failover, but the 937 connections will suffer from severe packet loss. 939 4.6. Distinguishing acknowledgment traffic 941 Some deployed in-network functions distinguish pure-acknowledgment 942 (ACK) packets from packets carrying upper-layer data in order to 943 attempt to enhance performance, for example by queueing ACKs 944 differently or manipulating ACK signaling. Distinguishing ACK 945 packets is trivial in TCP, but not supported by QUIC, since 946 acknowledgment signaling is carried inside QUIC's encrypted payload, 947 and ACK manipulation is impossible. Specifically, heuristics 948 attempting to distinguish ACK-only packets from payload-carrying 949 packets based on packet size are likely to fail, and are emphatically 950 NOT RECOMMENDED. 952 4.7. QoS support and ECMP 954 [EDITOR'S NOTE: this is a bit speculative; keep?] 956 QUIC does not provide any additional information on requirements on 957 Quality of Service (QoS) provided from the network. QUIC assumes 958 that all packets with the same 5-tuple {dest addr, source addr, 959 protocol, dest port, source port} will receive similar network 960 treatment. That means all stream that are multiplexed over the same 961 QUIC connection require the same network treatment and are handled by 962 the same congestion controller. If differential network treatment is 963 desired, multiple QUIC connections to the same server might be used, 964 given that establishing a new connection using 0-RTT support is cheap 965 and fast. 967 QoS mechanisms in the network MAY also use the connection ID for 968 service differentiation, as a change of connection ID is bound to a 969 change of address which anyway is likely to lead to a re-route on a 970 different path with different network characteristics. 972 Given that QUIC is more tolerant of packet re-ordering than TCP (see 973 Section 2.7), Equal-cost multi-path routing (ECMP) does not 974 necessarily need to be flow based. However, 5-tuple (plus eventually 975 connection ID if present) matching is still beneficial for QoS given 976 all packets are handled by the same congestion controller. 978 5. IANA Considerations 980 This document has no actions for IANA. 982 6. Security Considerations 984 Supporting manageability of QUIC traffic inherently involves 985 tradeoffs with the confidentiality of QUIC's control information; 986 this entire document is therefore security-relevant. 988 7. Contributors 990 Dan Druta contributed text to Section 4.4. Igor Lubashev contributed 991 text to Section 4.3 on the use of the connection ID for load 992 balancing. Marcus Ilhar contributed text to Section 3.7 on the use 993 of the spin bit. The pseudo provided in the appendix is based on 994 input provided by David Schinazi. 996 8. Acknowledgments 998 Thanks to Martin Thomson and Martin Duke for contributing by 999 reviewing and providing text proposals. 1001 This work is partially supported by the European Commission under 1002 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 1003 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 1004 for Education, Research, and Innovation under contract no. 15.0268. 1005 This support does not imply endorsement. 1007 9. Appendix 1009 This appendix uses the following conventions: array[i] - one byte at 1010 index i of array array[i:j] - subset of array starting with index i 1011 (inclusive) up to j-1 (inclusive) array[i:] - subset of array 1012 starting with index i (inclusive) up to the end of the array 1014 9.1. Distinguishing IETF QUIC and Google QUIC Versions 1016 This section contains algorithms that allows parsing versions from 1017 both Google QUIC and IETF QUIC. These mechanisms will become 1018 irrelevant when IETF QUIC is fully deployed and Google QUIC is 1019 deprecated. 1021 Note that other than this appendix, nothing in this document applies 1022 to Google QUIC. And the purpose of this appendix is merely to 1023 distinguish IETF QUIC from any versions of Google QUIC. 1025 Conceptually, a Google QUIC version is an opaque 32bit field. When 1026 we refer to a version with four printable characters, we use its 1027 ASCII representation: for example, Q050 refers to {'Q', '0', '5', 1028 '0'} which is equal to {0x51, 0x30, 0x35, 0x30}. Otherwise, we use 1029 its hexadecimal representation: for example, 0xff00001d refers to 1030 {0xff, 0x00, 0x00, 0x1d}. 1032 QUIC versions that start with 'Q' or 'T' followed by three digits are 1033 Google QUIC versions. Versions up to and including 43 are documented 1034 by . Versions 1036 Q046, Q050, T050, and T051 are not fully documented, but this 1037 appendix should contain enough information to allow parsing Client 1038 Hellos for those versions. 1040 To extract the version number itself, one needs to look at the first 1041 byte of the QUIC packet, in other words the first byte of the UDP 1042 payload. 1044 first_byte = packet[0] 1045 first_byte_bit1 = ((first_byte & 0x80) != 0) 1046 first_byte_bit2 = ((first_byte & 0x40) != 0) 1047 first_byte_bit3 = ((first_byte & 0x20) != 0) 1048 first_byte_bit4 = ((first_byte & 0x10) != 0) 1049 first_byte_bit5 = ((first_byte & 0x08) != 0) 1050 first_byte_bit6 = ((first_byte & 0x04) != 0) 1051 first_byte_bit7 = ((first_byte & 0x02) != 0) 1052 first_byte_bit8 = ((first_byte & 0x01) != 0) 1053 if (first_byte_bit1) { 1054 version = packet[1:5] 1055 } else if (first_byte_bit5 && !first_byte_bit2) { 1056 if (!first_byte_bit8) { 1057 abort("Packet without version") 1058 } 1059 if (first_byte_bit5) { 1060 version = packet[9:13] 1061 } else { 1062 version = packet[5:9] 1063 } 1064 } else { 1065 abort("Packet without version") 1066 } 1068 9.2. Extracting the CRYPTO frame 1069 counter = 0 1070 while (payload[counter] == 0) { 1071 counter += 1 1072 } 1073 first_nonzero_payload_byte = payload[counter] 1074 fnz_payload_byte_bit3 = ((first_nonzero_payload_byte & 0x20) != 0) 1076 if (first_nonzero_payload_byte != 0x06) { 1077 abort("Unexpected frame") 1078 } 1079 if (payload[counter+1] != 0x00) { 1080 abort("Unexpected crypto stream offset") 1081 } 1082 counter += 2 1083 if ((payload[counter] & 0xc0) == 0) { 1084 crypto_data_length = payload[counter] 1085 counter += 1 1086 } else { 1087 crypto_data_length = payload[counter:counter+2] 1088 counter += 2 1089 } 1090 crypto_data = payload[counter:counter+crypto_data_length] 1091 ParseTLS(crypto_data) 1093 10. References 1095 10.1. Normative References 1097 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1098 Requirement Levels", BCP 14, RFC 2119, 1099 DOI 10.17487/RFC2119, March 1997, 1100 . 1102 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1103 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1104 May 2017, . 1106 10.2. Informative References 1108 [Ding2015] Ding, H. and M. Rabinovich, "TCP Stretch Acknowledgments 1109 and Timestamps - Findings and Impliciations for Passive 1110 RTT Measurement (ACM Computer Communication Review)", July 1111 2015, . 1114 [DOTS-ARCH] 1115 Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and 1116 R. Compton, "Distributed-Denial-of-Service Open Threat 1117 Signaling (DOTS) Architecture", Work in Progress, 1118 Internet-Draft, draft-ietf-dots-architecture-18, 6 March 1119 2020, . 1122 [I-D.ietf-quic-load-balancers] 1123 Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC 1124 Connection IDs", Work in Progress, Internet-Draft, draft- 1125 ietf-quic-load-balancers-05, 30 October 2020, 1126 . 1129 [IPIM] Allman, M., Beverly, R., and B. Trammell, "In-Protocol 1130 Internet Measurement (arXiv preprint 1612.02902)", 9 1131 December 2016, . 1133 [QUIC-APPLICABILITY] 1134 Kuehlewind, M. and B. Trammell, "Applicability of the QUIC 1135 Transport Protocol", Work in Progress, Internet-Draft, 1136 draft-ietf-quic-applicability-07, 8 July 2020, 1137 . 1140 [QUIC-HTTP] 1141 Bishop, M., "Hypertext Transfer Protocol Version 3 1142 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 1143 quic-http-32, 20 October 2020, . 1146 [QUIC-INVARIANTS] 1147 Thomson, M., "Version-Independent Properties of QUIC", 1148 Work in Progress, Internet-Draft, draft-ietf-quic- 1149 invariants-11, 24 September 2020, . 1152 [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 1153 Work in Progress, Internet-Draft, draft-ietf-quic-tls-32, 1154 20 October 2020, . 1157 [QUIC-TRANSPORT] 1158 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1159 and Secure Transport", Work in Progress, Internet-Draft, 1160 draft-ietf-quic-transport-32, 20 October 2020, 1161 . 1164 [QUIC_LB] Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC 1165 Connection IDs", Work in Progress, Internet-Draft, draft- 1166 ietf-quic-load-balancers-05, 30 October 2020, 1167 . 1170 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 1171 Translation (NAT) Behavioral Requirements for Unicast 1172 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 1173 2007, . 1175 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 1176 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1177 RFC 5382, DOI 10.17487/RFC5382, October 2008, 1178 . 1180 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1181 Extensions: Extension Definitions", RFC 6066, 1182 DOI 10.17487/RFC6066, January 2011, 1183 . 1185 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 1186 "Increasing TCP's Initial Window", RFC 6928, 1187 DOI 10.17487/RFC6928, April 2013, 1188 . 1190 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1191 "Transport Layer Security (TLS) Application-Layer Protocol 1192 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1193 July 2014, . 1195 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 1196 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 1197 August 2015, . 1199 [TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 1200 Encrypted Client Hello", Work in Progress, Internet-Draft, 1201 draft-ietf-tls-esni-08, 16 October 2020, 1202 . 1205 [TMA-QOF] Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data 1206 Integrity Signals for Passive Measurement (in Proc. TMA 1207 2014)", April 2014. 1209 [WIRE-IMAGE] 1210 Trammell, B. and M. Kuehlewind, "The Wire Image of a 1211 Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 1212 2019, . 1214 Authors' Addresses 1216 Mirja Kuehlewind 1217 Ericsson 1219 Email: mirja.kuehlewind@ericsson.com 1221 Brian Trammell 1222 Google 1223 Gustav-Gull-Platz 1 1224 CH- 8004 Zurich 1225 Switzerland 1227 Email: ietf@trammell.ch