idnits 2.17.1 draft-ietf-quic-manageability-07.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 (8 July 2020) is 1380 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Ding2015' is defined on line 939, but no explicit reference was found in the text == Unused Reference: 'IPIM' is defined on line 960, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-quic-load-balancers-02 == Outdated reference: A later version (-18) exists of draft-ietf-quic-applicability-06 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-29 == Outdated reference: A later version (-13) exists of draft-ietf-quic-invariants-09 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-29 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-29 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-07 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). 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: 9 January 2021 Google 6 8 July 2020 8 Manageability of the QUIC Transport Protocol 9 draft-ietf-quic-manageability-07 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 9 January 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 . . . . . . . . . . . . . . . . . . . 6 59 2.5. Integrity Protection of the Wire Image . . . . . . . . . 11 60 2.6. Connection ID and Rebinding . . . . . . . . . . . . . . . 11 61 2.7. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 11 62 2.8. Version Negotiation and Greasing . . . . . . . . . . . . 11 63 3. Network-visible information about QUIC flows . . . . . . . . 12 64 3.1. Identifying QUIC traffic . . . . . . . . . . . . . . . . 12 65 3.1.1. Identifying Negotiated Version . . . . . . . . . . . 13 66 3.1.2. Rejection of Garbage Traffic . . . . . . . . . . . . 13 67 3.2. Connection confirmation . . . . . . . . . . . . . . . . . 13 68 3.3. Application Identification . . . . . . . . . . . . . . . 14 69 3.4. Flow association . . . . . . . . . . . . . . . . . . . . 14 70 3.5. Flow teardown . . . . . . . . . . . . . . . . . . . . . . 14 71 3.6. Flow symmetry measurement . . . . . . . . . . . . . . . . 15 72 3.7. Round-Trip Time (RTT) Measurement . . . . . . . . . . . . 15 73 3.7.1. Measuring initial RTT . . . . . . . . . . . . . . . . 15 74 3.7.2. Using the Spin Bit for Passive RTT Measurement . . . 15 75 4. Specific Network Management Tasks . . . . . . . . . . . . . . 17 76 4.1. Stateful treatment of QUIC traffic . . . . . . . . . . . 17 77 4.2. Passive network performance measurement and 78 troubleshooting . . . . . . . . . . . . . . . . . . . . . 18 79 4.3. Server cooperation with load balancers . . . . . . . . . 18 80 4.4. DDoS Detection and Mitigation . . . . . . . . . . . . . . 18 81 4.5. UDP Policing . . . . . . . . . . . . . . . . . . . . . . 19 82 4.6. Distinguishing acknowledgment traffic . . . . . . . . . . 19 83 4.7. QoS support and ECMP . . . . . . . . . . . . . . . . . . 19 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 86 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 90 9.2. Informative References . . . . . . . . . . . . . . . . . 21 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 93 1. Introduction 95 QUIC [QUIC-TRANSPORT] is a new transport protocol currently under 96 development in the IETF QUIC working group, focusing on support of 97 semantics as needed for HTTP/2 [QUIC-HTTP]. Based on current 98 deployment practices, QUIC is encapsulated in UDP and encrypted by 99 default. The current version of QUIC integrates TLS [QUIC-TLS] to 100 encrypt all payload data and most control information. 102 Given that QUIC is an end-to-end transport protocol, all information 103 in the protocol header, even that which can be inspected, is not 104 meant to be mutable by the network, and is therefore integrity- 105 protected. While less information is visible to the network than for 106 TCP, integrity protection can also simplify troubleshooting because 107 none of the nodes on the network path can modify the transport layer 108 information. 110 This document provides guidance for network operation on the 111 management of QUIC traffic. This includes guidance on how to 112 interpret and utilize information that is exposed by QUIC to the 113 network as well as explaining requirement and assumptions that the 114 QUIC protocol design takes toward the expected network treatment. It 115 also discusses how common network management practices will be 116 impacted by QUIC. 118 Since QUIC's wire image [WIRE-IMAGE] is integrity protected and not 119 modifiable on path, in-network operations are not possible without 120 terminating the QUIC connection, for instance using a back-to-back 121 proxy. Proxy operations are not in scope for this document. QUIC 122 proxies must be fully-fledged QUIC endpoints, implementing the 123 transport as defined in [QUIC-TRANSPORT] and [QUIC-TLS] as well as 124 proxy-relevant semantics for the application(s) running over QUIC 125 (e.g. HTTP/3 as defined in [QUIC-HTTP]). 127 Network management is not a one-size-fits-all endeavour: practices 128 considered necessary or even mandatory within enterprise networks 129 with certain compliance requirements, for example, would be 130 impermissible on other networks without those requirements. This 131 document therefore does not make any specific recommendations as to 132 which practices should or should not be applied; for each practice, 133 it describes what is and is not possible with the QUIC transport 134 protocol as defined. 136 QUIC is at the moment very much a moving target. This document 137 refers the state of the QUIC working group drafts as well as to 138 changes under discussion, via issues and pull requests in GitHub 139 current as of the time of writing. 141 1.1. Notational Conventions 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 2. Features of the QUIC Wire Image 151 In this section, we discusses those aspects of the QUIC transport 152 protocol that have an impact on the design and operation of devices 153 that forward QUIC packets. Here, we are concerned primarily with the 154 unencrypted part of QUIC's wire image [WIRE-IMAGE], which we define 155 as the information available in the packet header in each QUIC 156 packet, and the dynamics of that information. Since QUIC is a 157 versioned protocol, the wire image of the header format can also 158 change from version to version. However, at least the mechanism by 159 which a receiver can determine which version is used and the meaning 160 and location of fields used in the version negotiation process is 161 invariant [QUIC-INVARIANTS]. 163 This document is focused on the protocol as presently defined in 164 [QUIC-TRANSPORT] and [QUIC-TLS]. Non-invariant parts of the wire 165 image as described herein and in those documents cannot be used to 166 identify QUIC as a protocol, and cannot be relied upon to infer 167 behavior of future versions of QUIC. 169 2.1. QUIC Packet Header Structure 171 QUIC packets may have either a long header, or a short header. The 172 first bit of the QUIC header us the Header Form bit, and indicates 173 which type of header is present. 175 The long header exposes more information. It is used during 176 connection establishment, including version negotiation, retry, and 177 0-RTT data. It contains a version number, as well as source and 178 destination connection IDs for grouping packets belonging to the same 179 flow. The definition and location of these fields in the QUIC long 180 header are invariant for future versions of QUIC, although future 181 versions of QUIC may provide additional fields in the long header 182 [QUIC-INVARIANTS]. 184 Short headers are used after connection establishment, and contain 185 only an optional destination connection ID and the spin bit for RTT 186 measurement. 188 The following information is exposed in QUIC packet headers: 190 * "fixed bit": the second most significant bit of the first octet 191 most QUIC packets of the current version is currently set to 1, 192 for demultiplexing with other UDP-encapsulated protocols. 194 * latency spin bit: the third most significant bit of first octet in 195 the short packet header. The spin bit is set by endpoints such 196 that tracking edge transitions can be used to passively observe 197 end-to-end RTT. See Section 3.7.2 for further details. 199 * header type: the long header has a 2 bit packet type field 200 following the Header Form and fixed bits. Header types correspond 201 to stages of the handshake; see Section 17.2 of [QUIC-TRANSPORT] 202 for details. 204 * version number: the version number present in the long header, and 205 identifies the version used for that packet. Note that during 206 Version Negotiation (see Section 2.8, and Section 17.2.1 of 207 [QUIC-TRANSPORT], the version number field has a special value 208 (0x00000000) that identifies the packet as a Version Negotiation 209 packet. 211 * source and destination connection ID: short and long packet 212 headers carry a destination connection ID, a variable-length field 213 that can be used to identify the connection associated with a QUIC 214 packet, for load-balancing and NAT rebinding purposes; see 215 Section 4.3 and Section 2.6. Long packet headers additionally 216 carry a source connection ID. The source connection ID 217 corresponds to the destination connection ID the source would like 218 to have on packets sent to it, and is only present on long packet 219 headers. On long header packets, the length of the connection IDs 220 is also present; on short header packets, the length of the 221 destination connection ID is implicit. 223 * length: the length of the remaining QUIC packet after the length 224 field, present on long headers. This field is used to implement 225 coalesced packets during the handshake (see Section 2.2). 227 * token: Initial packets may contain a token, a variable-length 228 opaque value optionally sent from client to server, used for 229 validating the client's address. Retry packets also contain a 230 token, which can be used by the client in an Initial packet on a 231 subsequent connection attempt. The length of the token is 232 explicit in both cases. 234 Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation 235 (Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or 236 obfuscated in any way. For other kinds of packets, other information 237 in the packet headers is cryptographically obfuscated: 239 * packet number: All packets except Version Negotiation and Retry 240 packets have an associated packet number; however, this packet 241 number is encrypted, and therefore not of use to on-path 242 observers. The offset of the packet number is encoded in the 243 header for packets with long headers, while it is implicit 244 (depending on Destination Connection ID length) in short header 245 packets. The length of the packet number is cryptographically 246 obfuscated. 248 * key phase: The Key Phase bit, present in short headers, specifies 249 the keys used to encrypt the packet, supporting key rotation. The 250 Key Phase bit is cryptographically obfuscated. 252 2.2. Coalesced Packets 254 Multiple QUIC packets may be coalesced into a UDP datagram, with a 255 datagram carrying one or more long header packets followed by zero or 256 one short header packets. When packets are coalesced, the Length 257 fields in the long headers are used to separate QUIC packets. The 258 length header field is variable length and its position in the header 259 is also variable depending on the length of the source and 260 destination connection ID. See Section 4.6 of [QUIC-TRANSPORT]. 262 2.3. Use of Port Numbers 264 Applications that have a mapping for TCP as well as QUIC are expected 265 to use the same port number for both services. However, as with TCP- 266 based services, especially when application layer information is 267 encrypted, there is no guarantee that a specific application will use 268 the registered port, or the used port is carrying traffic belonging 269 to the respective registered service. For example, [QUIC-TRANSPORT] 270 specifies the use of Alt-Svc for discovery of QUIC/HTTP services on 271 other ports. 273 Further, as QUIC has a connection ID, it is also possible to maintain 274 multiple QUIC connections over one 5-tuple. However, if the 275 connection ID is not present in the packet header, all packets of the 276 5-tuple belong to the same QUIC connection. 278 2.4. The QUIC handshake 280 New QUIC connections are established using a handshake, which is 281 distinguishable on the wire and contains some information that can be 282 passively observed. 284 To illustrate the information visible in the QUIC wire image during 285 the handshake, we first show the general communication pattern 286 visible in the UDP datagrams containing the QUIC handshake, then 287 examine each of the datagrams in detail. 289 In the nominal case, the QUIC handshake can be recognized on the wire 290 through at least four datagrams we'll call "QUIC Client Hello", "QUIC 291 Server Hello", and "Initial Completion", and "Handshake Completion", 292 for purposes of this illustration, as shown in Figure 1. 294 Packets in the handshake belong to three separate cryptographic and 295 transport contexts ("Initial", which contains observable payload, and 296 "Handshake" and "1-RTT", which do not). QUIC packets in separate 297 contexts during the handshake are generally coalesced (see 298 Section 2.2) in order to reduce the number of UDP datagrams sent 299 during the handshake. 301 As shown here, the client can send 0-RTT data as soon as it has sent 302 its Client Hello, and the server can send 1-RTT data as soon as it 303 has sent its Server Hello. 305 Client Server 306 | | 307 +----QUIC Client Hello-------------------->| 308 +----(zero or more 0RTT)------------------>| 309 | | 310 |<--------------------QUIC Server Hello----+ 311 |<---------(1RTT encrypted data starts)----+ 312 | | 313 +----Initial Completion------------------->| 314 +----(1RTT encrypted data starts)--------->| 315 | | 316 |<-----------------Handshake Completion----+ 317 | | 319 Figure 1: General communication pattern visible in the QUIC handshake 321 A typical handshake starts with the client sending of a QUIC Client 322 Hello datagram as shown in Figure 2, which elicits a QUIC Server 323 Hello datagram as shown in Figure 3 typically containing three 324 packets: an Initial packet with the Server Hello, a Handshake packet 325 with the rest of the server's side of the TLS handshake, and initial 326 1-RTT data, if present. 328 The content of QUIC Initial packets are encrypted using Initial 329 Secrets, which are derived from a per-version constant and the 330 client's destination connection ID; they are therefore observable by 331 any on-path device that knows the per-version constant; we therefore 332 consider these as visible in our illustration. The content of QUIC 333 Handshake packets are encrypted using keys established during the 334 initial handshake exchange, and are therefore not visible. 336 Initial, Handshake, and the Short Header packets transmitted after 337 the handshake belong to cryptographic and transport contexts. The 338 Initial Completion Figure 4 and the Handshake Completion Figure 5 339 datagrams finish these first two contexts, by sending the final 340 acknowledgment and finishing the transmission of CRYPTO frames. 342 +----------------------------------------------------------+ 343 | UDP header (source and destination UDP ports) | 344 +----------------------------------------------------------+ 345 | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 346 +----------------------------------------------------------+ | 347 | QUIC CRYPTO frame header | | 348 +----------------------------------------------------------+ | 349 | TLS Client Hello (incl. TLS SNI) | | 350 +----------------------------------------------------------+ | 351 | QUIC PADDING frame | | 352 +----------------------------------------------------------+<-+ 354 Figure 2: Typical 1-RTT QUIC Client Hello datagram pattern 356 The Client Hello datagram exposes version number, source and 357 destination connection IDs, and information in the TLS Client Hello 358 message, including any TLS Server Name Indication (SNI) present, in 359 the clear. The QUIC PADDING frame shown here may be present to 360 ensure the Client Hello datagram has a minimum size of 1200 octets, 361 to mitigate the possibility of handshake amplification. Note that 362 the location of PADDING is implementation-dependent, and PADDING 363 frames may not appear in the Initial packet in a coalesced packet. 365 +------------------------------------------------------------+ 366 | UDP header (source and destination UDP ports) | 367 +------------------------------------------------------------+ 368 | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 369 +------------------------------------------------------------+ | 370 | QUIC CRYPTO frame header | | 371 +------------------------------------------------------------+ | 372 | TLS Server Hello | | 373 +------------------------------------------------------------+ | 374 | QUIC ACK frame (acknowledging client hello) | | 375 +------------------------------------------------------------+<-+ 376 | QUIC long header (type = Handshake, Version, DCID, SCID) (Length) 377 +------------------------------------------------------------+ | 378 | encrypted payload (presumably CRYPTO frames) | | 379 +------------------------------------------------------------+<-+ 380 | QUIC short header | 381 +------------------------------------------------------------+ 382 | 1-RTT encrypted payload | 383 +------------------------------------------------------------+ 385 Figure 3: Typical QUIC Server Hello datagram pattern 387 The Server Hello datagram exposes version number, source and 388 destination connection IDs, and information in the TLS Server Hello 389 message. 391 +------------------------------------------------------------+ 392 | UDP header (source and destination UDP ports) | 393 +------------------------------------------------------------+ 394 | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 395 +------------------------------------------------------------+ | 396 | QUIC ACK frame (acknowledging Server Hello Initial) | | 397 +------------------------------------------------------------+<-+ 398 | QUIC long header (type = Handshake, Version, DCID, SCID) (Length) 399 +------------------------------------------------------------+ | 400 | encrypted payload (presumably CRYPTO/ACK frames) | | 401 +------------------------------------------------------------+<-+ 402 | QUIC short header | 403 +------------------------------------------------------------+ 404 | 1-RTT encrypted payload | 405 +------------------------------------------------------------+ 407 Figure 4: Typical QUIC Initial Completion datagram pattern 409 The Initial Completion datagram does not expose any additional 410 information; however, recognizing it can be used to determine that a 411 handshake has completed (see Section 3.2), and for three-way 412 handshake RTT estimation as in Section 3.7. 414 +------------------------------------------------------------+ 415 | UDP header (source and destination UDP ports) | 416 +------------------------------------------------------------+ 417 | QUIC long header (type = Handshake, Version, DCID, SCID) (Length) 418 +------------------------------------------------------------+ | 419 | encrypted payload (presumably ACK frame) | | 420 +------------------------------------------------------------+<-+ 421 | QUIC short header | 422 +------------------------------------------------------------+ 423 | 1-RTT encrypted payload | 424 +------------------------------------------------------------+ 426 Figure 5: Typical QUIC Handshake Completion datagram pattern 428 Similar to Initial Completion, Handshake Completion also exposes no 429 additional information; observing it serves only to determine that 430 the handshake has completed. 432 When the client uses 0-RTT connection resumption, 0-RTT data may also 433 be seen in the QUIC Client Hello datagram, as shown in Figure 6. 435 +----------------------------------------------------------+ 436 | UDP header (source and destination UDP ports) | 437 +----------------------------------------------------------+ 438 | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 439 +----------------------------------------------------------+ | 440 | QUIC CRYPTO frame header | | 441 +----------------------------------------------------------+ | 442 | TLS Client Hello (incl. TLS SNI) | | 443 +----------------------------------------------------------+<-+ 444 | QUIC long header (type = 0RTT, Version, DCID, SCID) (Length) 445 +----------------------------------------------------------+ | 446 | 0-rtt encrypted payload | | 447 +----------------------------------------------------------+<-+ 449 Figure 6: Typical 0-RTT QUIC Client Hello datagram pattern 451 In a 0-RTT QUIC Client Hello datagram, the PADDING frame is only 452 present if necessary to increase the size of the datagram with 0RTT 453 data to at least 1200 bytes. Additional datagrams containing only 454 0-RTT protected long header packets may be sent from the client to 455 the server after the Client Hello datagram, containing the rest of 456 the 0-RTT data. The amount of 0-RTT protected data is limited by the 457 initial congestion window, typically around 10 packets [RFC6928]. 459 2.5. Integrity Protection of the Wire Image 461 As soon as the cryptographic context is established, all information 462 in the QUIC header, including information exposed in the packet 463 header, is integrity protected. Further, information that was sent 464 and exposed in handshake packets sent before the cryptographic 465 context was established are validated later during the cryptographic 466 handshake. Therefore, devices on path MUST NOT change any 467 information or bits in QUIC packet headers, since alteration of 468 header information will lead to a failed integrity check at the 469 receiver, and can even lead to connection termination. 471 2.6. Connection ID and Rebinding 473 The connection ID in the QUIC packet headers allows routing of QUIC 474 packets at load balancers on other than five-tuple information, 475 ensuring that related flows are appropriately balanced together; and 476 to allow rebinding of a connection after one of the endpoint's 477 addresses changes - usually the client's, in the case of the HTTP 478 binding. Client and server negotiate connection IDs during the 479 handshake; typically, however, only the server will request a 480 connection ID for the lifetime of the connection. Connection IDs for 481 either endpoint may change during the lifetime of a connection, with 482 the new connection ID being negotiated via encrypted frames. See 483 Section 5.1 of [QUIC-TRANSPORT]. 485 2.7. Packet Numbers 487 The packet number field is always present in the QUIC packet header; 488 however, it is always encrypted. The encryption key for packet 489 number protection on handshake packets sent before cryptographic 490 context establishment is specific to the QUIC version, while packet 491 number protection on subsequent packets uses secrets derived from the 492 end-to-end cryptographic context. Packet numbers are therefore not 493 part of the wire image that is visible to on-path observers. 495 2.8. Version Negotiation and Greasing 497 Version negotiation is not protected, given the used protection 498 mechanism can change with the version. However, the choices provided 499 in the list of version in the Version Negotiation packet will be 500 validated as soon as the cryptographic context has been established. 501 Therefore any manipulation of this list will be detected and will 502 cause the endpoints to terminate the connection. 504 Also note that the list of versions in the Version Negotiation packet 505 may contain reserved versions. This mechanism is used to avoid 506 ossification in the implementation on the selection mechanism. 508 Further, a client may send a Initial Client packet with a reserved 509 version number to trigger version negotiation. In the Version 510 Negotiation packet the connection ID and packet number of the Client 511 Initial packet are reflected to provide a proof of return- 512 routability. Therefore changing these information will also cause 513 the connection to fail. 515 QUIC is expected to evolve rapidly, so new versions, both 516 experimental and IETF standard versions, will be deployed in the 517 Internet more often than with traditional Internet- and transport- 518 layer protocols. Using a particular version number to recognize 519 valid QUIC traffic is likely to persistently miss a fraction of QUIC 520 flows and completely fail in the multi-year timeframe so therefore 521 not recommended. 523 3. Network-visible information about QUIC flows 525 This section addresses the different kinds of observations and 526 inferences that can be made about QUIC flows by a passive observer in 527 the network based on the wire image in Section 2. Here we assume a 528 bidirectional observer (one that can see packets in both directions 529 in the sequence in which they are carried on the wire) unless noted. 531 3.1. Identifying QUIC traffic 533 The QUIC wire image is not specifically designed to be 534 distinguishable from other UDP traffic. 536 The only application binding defined by the IETF QUIC WG is HTTP/3 537 [QUIC-HTTP] at the time of this writing; however, many other 538 applications are currently being defined and deployed over QUIC, so 539 an assumption that all QUIC traffic is HTTP/3 is not valid. HTTP 540 over QUIC uses UDP port 443 by default, although URLs referring to 541 resources available over HTTP over QUIC may specify alternate port 542 numbers. Simple assumptions about whether a given flow is using QUIC 543 based upon a UDP port number may therefore not hold; see also 544 [RFC7605] section 5. 546 While the second most significant bit (0x40) of the first octet is 547 set to 1 in most QUIC packets of the current version (see 548 Section 2.1), this method of recognizing QUIC traffic is NOT 549 RECOMMENDED. First, it only provides one bit of information and is 550 quite prone to collide with UDP-based protocols other than those that 551 this static bit is meant to allow multiplexing with. Second, this 552 feature of the wire image is not invariant [QUIC-INVARIANTS] and may 553 change in future versions of the protocol, or even be negotiated 554 after handshake via future transport parameters. 556 3.1.1. Identifying Negotiated Version 558 An in-network observer assuming that a set of packets belongs to a 559 QUIC flow can infer the version number in use by observing the 560 handshake: an Initial packet with a given version from a client to 561 which a server responds with an Initial packet with the same version 562 implies acceptance of that version. 564 Negotiated version cannot be identified for flows for which a 565 handshake is not observed, such as in the case of connection 566 migration; however, these flows can be associated with flows for 567 which a version has been identified; see Section 3.4. 569 This document focuses on QUIC Version 1, and this section applies 570 only to packets belonging to Version 1 QUIC flows; for purposes of 571 on-path observation, it assumes that these packets have been 572 identified as such through the observation of a version negotiation. 574 3.1.2. Rejection of Garbage Traffic 576 A related question is whether a first packet of a given flow on known 577 QUIC-associated port is a valid QUIC packet, in order to support in- 578 network filtering of garbage UDP packets (reflection attacks, random 579 backscatter). While heuristics based on the first byte of the packet 580 (packet type) could be used to separate valid from invalid first 581 packet types, the deployment of such heuristics is not recommended, 582 as packet types may have different meanings in future versions of the 583 protocol. 585 3.2. Connection confirmation 587 Connection establishment uses Initial, Handshake, and Retry packets 588 containing a TLS handshake. Connection establishment can therefore 589 be detected using heuristics similar to those used to detect TLS over 590 TCP. A client using 0-RTT connection may also send data packets in 591 0-RTT Protected packets directly after the Initial packet containing 592 the TLS Client Hello. Since these packets may be reordered in the 593 network, note that 0-RTT Protected data packets may be seen before 594 the Initial packet. 596 Note that clients send Initial packets before servers do, servers 597 send Handshake packets before clients do, and only clients send 598 Initial packets with tokens, so the sides of a connection can be 599 generally be confirmed by an on-path observer. An attempted 600 connection after Retry can be detected by correlating the token on 601 the Retry with the token on the subsequent Initial packet. 603 3.3. Application Identification 605 The cleartext TLS handshake may contain Server Name Indication (SNI) 606 [RFC6066], by which the client reveals the name of the server it 607 intends to connect to, in order to allow the server to present a 608 certificate based on that name. It may also contain information from 609 Application-Layer Protocol Negotiation (ALPN) [RFC7301], by which the 610 client exposes the names of application-layer protocols it supports; 611 an observer can deduce that one of those protocols will be used if 612 the connection continues. 614 Work is currently underway in the TLS working group to encrypt the 615 SNI in TLS 1.3 [TLS-ESNI]. If used with QUIC, this would make SNI- 616 based application identification impossible through passive 617 measurement. 619 3.4. Flow association 621 The QUIC Connection ID (see Section 2.6) is designed to allow an on- 622 path device such as a load-balancer to associate two flows as 623 identified by five-tuple when the address and port of one of the 624 endpoints changes; e.g. due to NAT rebinding or server IP address 625 migration. An observer keeping flow state can associate a connection 626 ID with a given flow, and can associate a known flow with a new flow 627 when when observing a packet sharing a connection ID and one endpoint 628 address (IP address and port) with the known flow. 630 However, since the connection ID may change multiple times during the 631 lifetime of a flow, and the negotiation of connection ID changes is 632 encrypted, packets with the same 5-tuple but different connection IDs 633 may or may not belong to the same connection. 635 The connection ID value should be treated as opaque; see Section 4.3 636 for caveats regarding connection ID selection at servers. 638 3.5. Flow teardown 640 QUIC does not expose the end of a connection; the only indication to 641 on-path devices that a flow has ended is that packets are no longer 642 observed. Stateful devices on path such as NATs and firewalls must 643 therefore use idle timeouts to determine when to drop state for QUIC 644 flows, see further section Section 4.1. 646 3.6. Flow symmetry measurement 648 QUIC explicitly exposes which side of a connection is a client and 649 which side is a server during the handshake. In addition, the 650 symmetry of a flow (whether primarily client-to-server, primarily 651 server-to-client, or roughly bidirectional, as input to basic traffic 652 classification techniques) can be inferred through the measurement of 653 data rate in each direction. While QUIC traffic is protected and 654 ACKs may be padded, padding is not required. 656 3.7. Round-Trip Time (RTT) Measurement 658 Round-trip time of QUIC flows can be inferred by observation once per 659 flow, during the handshake, as in passive TCP measurement; this 660 requires parsing of the QUIC packet header and recognition of the 661 handshake, as illustrated in Section 2.4. It can also be inferred 662 during the flow's lifetime, if the endpoints use the spin bit 663 facility described below and in [QUIC-TRANSPORT], section 17.3.1. 665 3.7.1. Measuring initial RTT 667 In the common case, the delay between the Initial packet containing 668 the TLS Client Hello and the Handshake packet containing the TLS 669 Server Hello represents the RTT component on the path between the 670 observer and the server. The delay between the TLS Server Hello and 671 the Handshake packet containing the TLS Finished message sent by the 672 client represents the RTT component on the path between the observer 673 and the client. While the client may send 0-RTT Protected packets 674 after the Initial packet during 0-RTT connection re-establishment, 675 these can be ignored for RTT measurement purposes. 677 Handshake RTT can be measured by adding the client-to-observer and 678 observer-to-server RTT components together. This measurement 679 necessarily includes any transport and application layer delay (the 680 latter mainly caused by the asymmetric crypto operations associated 681 with the TLS handshake) at both sides. 683 3.7.2. Using the Spin Bit for Passive RTT Measurement 685 The spin bit provides an additional method to measure per-flow RTT 686 from observation points on the network path throughout the duration 687 of a connection. Endpoint participation in spin bit signaling is 688 optional in QUIC. That is, while its location is fixed in this 689 version of QUIC, an endpoint can unilaterally choose to not support 690 "spinning" the bit. Use of the spin bit for RTT measurement by 691 devices on path is only possible when both endpoints enable it. Some 692 endpoints may disable use of the spin bit by default, others only in 693 specific deployment scenarios, e.g. for servers and clients where the 694 RTT would reveal the presence of a VPN or proxy. To avoid making 695 these connections identifiable based on the usage of the spin bit, it 696 is recommended that all endpoints randomly disable "spinning" for at 697 least one eighth of connections, even if otherwise enabled by 698 default. An endpoint not participating in spin bit signaling for a 699 given connection can use a fixed spin value for the duration of the 700 connection, or can set the bit randomly on each packet sent. 702 When in use and a QUIC flow sends data continuously, the latency spin 703 bit in each direction changes value once per round-trip time (RTT). 704 An on-path observer can observe the time difference between edges 705 (changes from 1 to 0 or 0 to 1) in the spin bit signal in a single 706 direction to measure one sample of end-to-end RTT. 708 Note that this measurement, as with passive RTT measurement for TCP, 709 includes any transport protocol delay (e.g., delayed sending of 710 acknowledgements) and/or application layer delay (e.g., waiting for a 711 response to be generated). It therefore provides devices on path a 712 good instantaneous estimate of the RTT as experienced by the 713 application. A simple linear smoothing or moving minimum filter can 714 be applied to the stream of RTT information to get a more stable 715 estimate. 717 However, application-limited and flow-control-limited senders can 718 have application and transport layer delay, respectively, that are 719 much greater than network RTT. When the sender is application- 720 limited and e.g. only sends small amount of periodic application 721 traffic, where that period is longer than the RTT, measuring the spin 722 bit provides information about the application period, not the 723 network RTT. 725 Since the spin bit logic at each endpoint considers only samples from 726 packets that advance the largest packet number, signal generation 727 itself is resistant to reordering. However, reordering can cause 728 problems at an observer by causing spurious edge detection and 729 therefore inaccurate (i.e., lower) RTT estimates, if reordering 730 occurs across a spin-bit flip in the stream. 732 Simple heuristics based on the observed data rate per flow or changes 733 in the RTT series can be used to reject bad RTT samples due to lost 734 or reordered edges in the spin signal, as well as application or flow 735 control limitation; for example, QoF [TMA-QOF] rejects component RTTs 736 significantly higher than RTTs over the history of the flow. These 737 heuristics may use the handshake RTT as an initial RTT estimate for a 738 given flow. Usually such heuristics would also detect if the spin is 739 either constant or randomly set for a connection. 741 An on-path observer that can see traffic in both directions (from 742 client to server and from server to client) can also use the spin bit 743 to measure "upstream" and "downstream" component RTT; i.e, the 744 component of the end-to-end RTT attributable to the paths between the 745 observer and the server and the observer and the client, 746 respectively. It does this by measuring the delay between a spin 747 edge observed in the upstream direction and that observed in the 748 downstream direction, and vice versa. 750 4. Specific Network Management Tasks 752 In this section, we review specific network management and 753 measurement techniques and how QUIC's design impacts them. 755 4.1. Stateful treatment of QUIC traffic 757 Stateful treatment of QUIC traffic (e.g., at a firewall or NAT 758 middlebox) is possible through QUIC traffic and version 759 identification (Section 3.1) and observation of the handshake for 760 connection confirmation (Section 3.2). The lack of any visible end- 761 of-flow signal (Section 3.5) means that this state must be purged 762 either through timers or through least-recently-used eviction, 763 depending on application requirements. 765 [RFC4787] recommends a 2 minute timeout interval for UDP, however, 766 often timer are lower in the range of 15 to 30 second. In constrast 767 [RFC5382] recommends a timeout of more than 2 hours for TCP, given 768 TCP is a connection-oriented protocol with well defined closure 769 semantics. For network devices that are QUIC-aware, it is 770 recommended to also use longer timeouts for QUIC traffic, as QUIC is 771 connection-oriented and as such a handshake packet from the server 772 indicates the willingness of the server to communicate with the 773 client. 775 The QUIC header optionally contains a Connection ID which can be used 776 as additional entropy beyond the 5-tuple, if needed. The QUIC 777 handshake needs to be observed in order to understand whether the 778 Connection ID is present and what length it has. However, Connection 779 IDs may be renegotiated during a connection, and this renegotiation 780 is not visible to the path. Keying state off the Connection ID may 781 therefore cause undetectable and unrecoverable loss of state in the 782 middle of a connection. Use of Connection ID specifically 783 discouraged for NAT applications. 785 4.2. Passive network performance measurement and troubleshooting 787 Limited RTT measurement is possible by passive observation of QUIC 788 traffic; see Section 3.7. No passive measurement of loss is possible 789 with the present wire image. Extremely limited observation of 790 upstream congestion may be possible via the observation of CE 791 markings on ECN-enabled QUIC traffic. 793 4.3. Server cooperation with load balancers 795 In the case of content distribution networking architectures 796 including load balancers, the connection ID provides a way for the 797 server to signal information about the desired treatment of a flow to 798 the load balancers. Guidance on assigning connection IDs is given in 799 [QUIC-APPLICABILITY]. 801 4.4. DDoS Detection and Mitigation 803 Current practices in detection and mitigation of Distributed Denial 804 of Service (DDoS) attacks generally involves classification of 805 incoming traffic (as packets, flows, or some other aggregate) into 806 "good" (productive) and "bad" (DDoS) traffic, then differential 807 treatment of this traffic to forward only good traffic, to the extent 808 possible. This operation is often done in a separate specialized 809 mitigation environment through which all traffic is filtered; a 810 generalized architecture for separation of concerns in mitigation is 811 given in [DOTS-ARCH]. 813 Key to successful DDoS mitigation is efficient classification of this 814 traffic in the mitigation environment. Limited first-packet garbage 815 detection as in Section 3.1.2 and stateful tracking of QUIC traffic 816 as in Section 4.1 above may be useful during classification. 818 Note that the use of a connection ID to support connection migration 819 renders 5-tuple based filtering insufficient and requires more state 820 to be maintained by DDoS defense systems. For the common case of NAT 821 rebinding, DDoS defense systems can detect a change in client's 822 endpoint address by linking flows based on the first 8 bytes of the 823 server's connection IDs, provided the server is using at least 8- 824 bytes-long connection IDs. QUIC's linkability resistance ensures 825 that a deliberate connection migration is accompanied by a change in 826 the connection ID and necessitate that connection ID aware DDoS 827 defense system must have the same information about connection IDs as 828 the load balancer [I-D.ietf-quic-load-balancers]. This may be 829 complicated where mitigation and load balancing environments are 830 logically separate. 832 It is questionable whether connection migrations must be supported 833 during a DDoS attack. If the connection migration is not visible to 834 the network that performs the DDoS detection, an active, migrated 835 QUIC connection may be blocked by such a system under attack. As 836 soon as the connection blocking is detected by the client, the client 837 may rely on the fast resumption mechanism provided by QUIC. When 838 clients migrate to a new path, they should be prepared for the 839 migration to fail and attempt to reconnect quickly. 841 4.5. UDP Policing 843 Today, UDP is the most prevalent DDoS vector, since it is easy for 844 compromised non-admin applications to send a flood of large UDP 845 packets (while with TCP the attacker gets throttled by the congestion 846 controller) or to craft reflection and amplification attacks. 847 Networks should therefore be prepared for UDP flood attacks on ports 848 used for QUIC traffic. One possible response to this threat is to 849 police UDP traffic on the network, allocating a fixed portion of the 850 network capacity to UDP and blocking UDP datagram over that cap. 852 The recommended way to police QUIC packets is to either drop them all 853 or to throttle them based on the hash of the UDP datagram's source 854 and destination addresses, blocking a portion of the hash space that 855 corresponds to the fraction of UDP traffic one wishes to drop. When 856 the handshake is blocked, QUIC-capable applications may failover to 857 TCP (at least applications using well-known UDP ports). However, 858 blindly blocking a significant fraction of QUIC packets will allow 859 many QUIC handshakes to complete, preventing a TCP failover, but the 860 connections will suffer from severe packet loss. 862 4.6. Distinguishing acknowledgment traffic 864 Some deployed in-network functions distinguish pure-acknowledgment 865 (ACK) packets from packets carrying upper-layer data in order to 866 attempt to enhance performance, for example by queueing ACKs 867 differently or manipulating ACK signaling. Distinguishing ACK 868 packets is trivial in TCP, but not supported by QUIC, since 869 acknowledgment signaling is carried inside QUIC's encrypted payload, 870 and ACK manipulation is impossible. Specifically, heuristics 871 attempting to distinguish ACK-only packets from payload-carrying 872 packets based on packet size are likely to fail, and are emphatically 873 NOT RECOMMENDED. 875 4.7. QoS support and ECMP 877 [EDITOR'S NOTE: this is a bit speculative; keep?] 878 QUIC does not provide any additional information on requirements on 879 Quality of Service (QoS) provided from the network. QUIC assumes 880 that all packets with the same 5-tuple {dest addr, source addr, 881 protocol, dest port, source port} will receive similar network 882 treatment. That means all stream that are multiplexed over the same 883 QUIC connection require the same network treatment and are handled by 884 the same congestion controller. If differential network treatment is 885 desired, multiple QUIC connections to the same server might be used, 886 given that establishing a new connection using 0-RTT support is cheap 887 and fast. 889 QoS mechanisms in the network MAY also use the connection ID for 890 service differentiation, as a change of connection ID is bound to a 891 change of address which anyway is likely to lead to a re-route on a 892 different path with different network characteristics. 894 Given that QUIC is more tolerant of packet re-ordering than TCP (see 895 Section 2.7), Equal-cost multi-path routing (ECMP) does not 896 necessarily need to be flow based. However, 5-tuple (plus eventually 897 connection ID if present) matching is still beneficial for QoS given 898 all packets are handled by the same congestion controller. 900 5. IANA Considerations 902 This document has no actions for IANA. 904 6. Security Considerations 906 Supporting manageability of QUIC traffic inherently involves 907 tradeoffs with the confidentiality of QUIC's control information; 908 this entire document is therefore security-relevant. 910 7. Contributors 912 Dan Druta contributed text to Section 4.4. Igor Lubashev contributed 913 text to Section 4.3 on the use of the connection ID for load 914 balancing. Marcus Ilhar contributed text to Section 3.7 on the use 915 of the spin bit. 917 8. Acknowledgments 919 This work is partially supported by the European Commission under 920 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 921 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 922 for Education, Research, and Innovation under contract no. 15.0268. 923 This support does not imply endorsement. 925 9. References 926 9.1. Normative References 928 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 929 Requirement Levels", BCP 14, RFC 2119, 930 DOI 10.17487/RFC2119, March 1997, 931 . 933 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 934 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 935 May 2017, . 937 9.2. Informative References 939 [Ding2015] Ding, H. and M. Rabinovich, "TCP Stretch Acknowledgments 940 and Timestamps - Findings and Impliciations for Passive 941 RTT Measurement (ACM Computer Communication Review)", July 942 2015, . 945 [DOTS-ARCH] 946 Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and 947 R. Compton, "Distributed-Denial-of-Service Open Threat 948 Signaling (DOTS) Architecture", Work in Progress, 949 Internet-Draft, draft-ietf-dots-architecture-18, 6 March 950 2020, . 953 [I-D.ietf-quic-load-balancers] 954 Duke, M. and N. Banks, "QUIC-LB: Generating Routable QUIC 955 Connection IDs", Work in Progress, Internet-Draft, draft- 956 ietf-quic-load-balancers-02, 9 March 2020, 957 . 960 [IPIM] Allman, M., Beverly, R., and B. Trammell, "In-Protocol 961 Internet Measurement (arXiv preprint 1612.02902)", 9 962 December 2016, . 964 [QUIC-APPLICABILITY] 965 Kuehlewind, M. and B. Trammell, "Applicability of the QUIC 966 Transport Protocol", Work in Progress, Internet-Draft, 967 draft-ietf-quic-applicability-06, 6 January 2020, 968 . 971 [QUIC-HTTP] 972 Bishop, M., "Hypertext Transfer Protocol Version 3 973 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 974 quic-http-29, 9 June 2020, . 977 [QUIC-INVARIANTS] 978 Thomson, M., "Version-Independent Properties of QUIC", 979 Work in Progress, Internet-Draft, draft-ietf-quic- 980 invariants-09, 9 June 2020, . 983 [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 984 Work in Progress, Internet-Draft, draft-ietf-quic-tls-29, 985 9 June 2020, . 988 [QUIC-TRANSPORT] 989 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 990 and Secure Transport", Work in Progress, Internet-Draft, 991 draft-ietf-quic-transport-29, 9 June 2020, 992 . 995 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 996 Translation (NAT) Behavioral Requirements for Unicast 997 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 998 2007, . 1000 [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. 1001 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1002 RFC 5382, DOI 10.17487/RFC5382, October 2008, 1003 . 1005 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1006 Extensions: Extension Definitions", RFC 6066, 1007 DOI 10.17487/RFC6066, January 2011, 1008 . 1010 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 1011 "Increasing TCP's Initial Window", RFC 6928, 1012 DOI 10.17487/RFC6928, April 2013, 1013 . 1015 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1016 "Transport Layer Security (TLS) Application-Layer Protocol 1017 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1018 July 2014, . 1020 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 1021 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 1022 August 2015, . 1024 [TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 1025 Encrypted Client Hello", Work in Progress, Internet-Draft, 1026 draft-ietf-tls-esni-07, 1 June 2020, . 1029 [TMA-QOF] Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data 1030 Integrity Signals for Passive Measurement (in Proc. TMA 1031 2014)", April 2014. 1033 [WIRE-IMAGE] 1034 Trammell, B. and M. Kuehlewind, "The Wire Image of a 1035 Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 1036 2019, . 1038 Authors' Addresses 1040 Mirja Kuehlewind 1041 Ericsson 1043 Email: mirja.kuehlewind@ericsson.com 1045 Brian Trammell 1046 Google 1047 Gustav-Gull-Platz 1 1048 CH- 8004 Zurich 1049 Switzerland 1051 Email: ietf@trammell.ch