idnits 2.17.1 draft-ietf-quic-manageability-06.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 (6 January 2020) is 1572 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Ding2015' is defined on line 889, but no explicit reference was found in the text == Unused Reference: 'IPIM' is defined on line 895, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-quic-applicability-05 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-24 == Outdated reference: A later version (-13) exists of draft-ietf-quic-invariants-07 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-24 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-24 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-05 Summary: 0 errors (**), 0 flaws (~~), 9 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 July 2020 Google 6 6 January 2020 8 Manageability of the QUIC Transport Protocol 9 draft-ietf-quic-manageability-06 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 July 2020. 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 . . . . . . . . . . . . . . . . . . . . . 17 79 4.3. Server cooperation with load balancers . . . . . . . . . 18 80 4.4. DDoS Detection and Mitigation . . . . . . . . . . . . . . 18 81 4.5. Distinguishing acknowledgment traffic . . . . . . . . . . 18 82 4.6. QoS support and ECMP . . . . . . . . . . . . . . . . . . 19 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 86 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 89 9.2. Informative References . . . . . . . . . . . . . . . . . 20 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Introduction 94 QUIC [QUIC-TRANSPORT] is a new transport protocol currently under 95 development in the IETF QUIC working group, focusing on support of 96 semantics as needed for HTTP/2 [QUIC-HTTP]. Based on current 97 deployment practices, QUIC is encapsulated in UDP and encrypted by 98 default. The current version of QUIC integrates TLS [QUIC-TLS] to 99 encrypt all payload data and most control information. 101 Given that QUIC is an end-to-end transport protocol, all information 102 in the protocol header, even that which can be inspected, is not 103 meant to be mutable by the network, and is therefore integrity- 104 protected. While less information is visible to the network than for 105 TCP, integrity protection can also simplify troubleshooting because 106 none of the nodes on the network path can modify the transport layer 107 information. 109 This document provides guidance for network operation on the 110 management of QUIC traffic. This includes guidance on how to 111 interpret and utilize information that is exposed by QUIC to the 112 network as well as explaining requirement and assumptions that the 113 QUIC protocol design takes toward the expected network treatment. It 114 also discusses how common network management practices will be 115 impacted by QUIC. 117 Since QUIC's wire image [WIRE-IMAGE] is integrity protected and not 118 modifiable on path, in-network operations are not possible without 119 terminating the QUIC connection, for instance using a back-to-back 120 proxy. Proxy operations are not in scope for this document. QUIC 121 proxies must be fully-fledged QUIC endpoints, implementing the 122 transport as defined in [QUIC-TRANSPORT] and [QUIC-TLS] as well as 123 proxy-relevant semantics for the application(s) running over QUIC 124 (e.g. HTTP/3 as defined in [QUIC-HTTP]). 126 Network management is not a one-size-fits-all endeavour: practices 127 considered necessary or even mandatory within enterprise networks 128 with certain compliance requirements, for example, would be 129 impermissible on other networks without those requirements. This 130 document therefore does not make any specific recommendations as to 131 which practices should or should not be applied; for each practice, 132 it describes what is and is not possible with the QUIC transport 133 protocol as defined. 135 QUIC is at the moment very much a moving target. This document 136 refers the state of the QUIC working group drafts as well as to 137 changes under discussion, via issues and pull requests in GitHub 138 current as of the time of writing. 140 1.1. Notational Conventions 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 2. Features of the QUIC Wire Image 150 In this section, we discusses those aspects of the QUIC transport 151 protocol that have an impact on the design and operation of devices 152 that forward QUIC packets. Here, we are concerned primarily with the 153 unencrypted part of QUIC's wire image [WIRE-IMAGE], which we define 154 as the information available in the packet header in each QUIC 155 packet, and the dynamics of that information. Since QUIC is a 156 versioned protocol, the wire image of the header format can also 157 change from version to version. However, at least the mechanism by 158 which a receiver can determine which version is used and the meaning 159 and location of fields used in the version negotiation process is 160 invariant [QUIC-INVARIANTS]. 162 This document is focused on the protocol as presently defined in 163 [QUIC-TRANSPORT] and [QUIC-TLS], and will change to track those 164 documents. 166 2.1. QUIC Packet Header Structure 168 QUIC packets may have either a long header, or a short header. The 169 first bit of the QUIC header indicates which type of header is 170 present. 172 The long header exposes more information. It is used during 173 connection establishment, including version negotiation, retry, and 174 0-RTT data. It contains a version number, as well as source and 175 destination connection IDs for grouping packets belonging to the same 176 flow. The definition and location of these fields in the QUIC long 177 header are invariant for future versions of QUIC, although future 178 versions of QUIC may provide additional fields in the long header 179 [QUIC-INVARIANTS]. 181 Short headers are used after connection establishment, and contain 182 only an optional destination connection ID and the spin bit for RTT 183 measurement. 185 The following information is exposed in QUIC packet headers: 187 * demux bit: the second most significant bit of the first octet 188 every QUIC packet of the current version is set to 1, for 189 demultiplexing with other UDP-encapsulated protocols. 191 * latency spin bit: the third most significant bit of first octet in 192 the short packet header. The spin bit is set by endpoints such 193 that tracking edge transitions can be used to passively observe 194 end-to-end RTT. See Section 3.7.2 for further details. 196 * header type: the long header has a 2 bit packet type field 197 following the Header Form bit. Header types correspond to stages 198 of the handshake; see Section 17.2 of [QUIC-TRANSPORT]. 200 * version number: the version number present in the long header, and 201 identifies the version used for that packet. Note that during 202 Version Negotiation (see Section 2.8, and Section 17.2.1 of 203 [QUIC-TRANSPORT], the version number field has a special value 204 (0x00000000) that identifies the packet as a Version Negotiation 205 packet. 207 * source and destination connection ID: short and long packet 208 headers carry a destination connection ID, a variable-length field 209 that can be used to identify the connection associated with a QUIC 210 packet, for load-balancing and NAT rebinding purposes; see 211 Section 4.3 and Section 2.6. Long packet headers additionally 212 carry a source connection ID. The source connection ID 213 corresponds to the destination connection ID the source would like 214 to have on packets sent to it, and is only present on long packet 215 headers. On long header packets, the length of the connection IDs 216 is also present; on short header packets, the length of the 217 destination connection ID is implicit. 219 * length: the length of the remaining QUIC packet after the length 220 field, present on long headers. This field is used to implement 221 coalesced packets during the handshake (see Section 2.2). 223 * token: Initial packets may contain a token, a variable-length 224 opaque value optionally sent from client to server, used for 225 validating the client's address. Retry packets also contain a 226 token, which can be used by the client in an Initial packet on a 227 subsequent connection attempt. The length of the token is 228 explicit in both cases. 230 Retry and Version Negotiation packets are not encrypted or obfuscated 231 in any way. For other kinds of packets, other information in the 232 packet headers is cryptographically obfuscated: 234 * packet number: Most packets (with the exception of Version 235 Negotiation and Retry packets) have an associated packet number; 236 however, this packet number is encrypted, and therefore not of use 237 to on-path observers. The offset of the packet number is encoded 238 in the header for packets with long headers, while it is implicit 239 (depending on Destination Connection ID length) in short header 240 packets. The length of the packet number is cryptographically 241 obfuscated. 243 * key phase: The Key Phase bit, present in short headers, specifies 244 the keys used to encrypt the packet, supporting key rotation. The 245 Key Phase bit is cryptographically obfuscated. 247 2.2. Coalesced Packets 249 Multiple QUIC packets may be coalesced into a UDP datagram, with a 250 datagram carrying one or more long header packets followed by zero or 251 one short header packets. When packets are coalesced, the Length 252 fields in the long headers are used to separate QUIC packets. The 253 length header field is variable length and its position in the header 254 is also variable depending on the length of the source and 255 destination connection ID. See Section 4.6 of [QUIC-TRANSPORT]. 257 2.3. Use of Port Numbers 259 Applications that have a mapping for TCP as well as QUIC are expected 260 to use the same port number for both services. However, as with TCP- 261 based services, especially when application layer information is 262 encrypted, there is no guarantee that a specific application will use 263 the registered port, or the used port is carrying traffic belonging 264 to the respective registered service. For example, [QUIC-TRANSPORT] 265 specifies the use of Alt-Svc for discovery of QUIC/HTTP services on 266 other ports. 268 Further, as QUIC has a connection ID, it is also possible to maintain 269 multiple QUIC connections over one 5-tuple. However, if the 270 connection ID is not present in the packet header, all packets of the 271 5-tuple belong to the same QUIC connection. 273 2.4. The QUIC handshake 275 New QUIC connections are established using a handshake, which is 276 distinguishable on the wire and contains some information that can be 277 passively observed. 279 To illustrate the information visible in the QUIC wire image during 280 the handshake, we first show the general communication pattern 281 visible in the UDP datagrams containing the QUIC handshake, then 282 examine each of the datagrams in detail. 284 In the nominal case, the QUIC handshake can be recognized on the wire 285 through at least four datagrams we'll call "QUIC Client Hello", "QUIC 286 Server Hello", and "Initial Completion", and "Handshake Completion", 287 for purposes of this illustration, as shown in Figure 1. 289 Packets in the handshake belong to three separate cryptographic and 290 transport contexts ("Initial", which contains observable payload, and 291 "Handshake" and "1-RTT", which do not). QUIC packets in separate 292 contexts during the handshake are generally coalesced (see 293 Section 2.2) in order to reduce the number of UDP datagrams sent 294 during the handshake. 296 As shown here, the client can send 0-RTT data as soon as it has sent 297 its Client Hello, and the server can send 1-RTT data as soon as it 298 has sent its Server Hello. 300 Client Server 301 | | 302 +----QUIC Client Hello-------------------->| 303 +----(zero or more 0RTT)------------------>| 304 | | 305 |<--------------------QUIC Server Hello----+ 306 |<---------(1RTT encrypted data starts)----+ 307 | | 308 +----Initial Completion------------------->| 309 +----(1RTT encrypted data starts)--------->| 310 | | 311 |<-----------------Handshake Completion----+ 312 | | 314 Figure 1: General communication pattern visible in the QUIC handshake 316 A typical handshake starts with the client sending of a QUIC Client 317 Hello datagram as shown in Figure 2, which elicits a QUIC Server 318 Hello datagram as shown in Figure 3 typically containing three 319 packets: an Initial packet with the Server Hello, a Handshake packet 320 with the rest of the server's side of the TLS handshake, and initial 321 1-RTT data, if present. 323 The content of QUIC Initial packets are encrypted using Initial 324 Secrets, which are derived from a per-version constant and the 325 client's destination connection ID; they are therefore observable by 326 any on-path device that knows the per-version constant; we therefore 327 consider these as visible in our illustration. The content of QUIC 328 Handshake packets are encrypted using keys established during the 329 initial handshake exchange, and are therefore not visible. 331 Initial, Handshake, and the Short Header packets transmitted after 332 the handshake belong to cryptographic and transport contexts. The 333 Initial Completion Figure 4 and the Handshake Completion Figure 5 334 datagrams finish these first two contexts, by sending the final 335 acknowledgment and finishing the transmission of CRYPTO frames. 337 +----------------------------------------------------------+ 338 | UDP header (source and destination UDP ports) | 339 +----------------------------------------------------------+ 340 | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 341 +----------------------------------------------------------+ | 342 | QUIC CRYPTO frame header | | 343 +----------------------------------------------------------+ | 344 | TLS Client Hello (incl. TLS SNI) | | 345 +----------------------------------------------------------+ | 346 | QUIC PADDING frame | | 347 +----------------------------------------------------------+<-+ 349 Figure 2: Typical 1-RTT QUIC Client Hello datagram pattern 351 The Client Hello datagram exposes version number, source and 352 destination connection IDs, and information in the TLS Client Hello 353 message, including any TLS Server Name Indication (SNI) present, in 354 the clear. The QUIC PADDING frame shown here may be present to 355 ensure the Client Hello datagram has a minimum size of 1200 octets, 356 to mitigate the possibility of handshake amplification. Note that 357 the location of PADDING is implementation-dependent, and PADDING 358 frames may not appear in the Initial packet in a coalesced packet. 360 +------------------------------------------------------------+ 361 | UDP header (source and destination UDP ports) | 362 +------------------------------------------------------------+ 363 | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 364 +------------------------------------------------------------+ | 365 | QUIC CRYPTO frame header | | 366 +------------------------------------------------------------+ | 367 | TLS Server Hello | | 368 +------------------------------------------------------------+ | 369 | QUIC ACK frame (acknowledging client hello) | | 370 +------------------------------------------------------------+<-+ 371 | QUIC long header (type = Handshake, Version, DCID, SCID) (Length) 372 +------------------------------------------------------------+ | 373 | encrypted payload (presumably CRYPTO frames) | | 374 +------------------------------------------------------------+<-+ 375 | QUIC short header | 376 +------------------------------------------------------------+ 377 | 1-RTT encrypted payload | 378 +------------------------------------------------------------+ 380 Figure 3: Typical QUIC Server Hello datagram pattern 382 The Server Hello datagram exposes version number, source and 383 destination connection IDs, and information in the TLS Server Hello 384 message. 386 +------------------------------------------------------------+ 387 | UDP header (source and destination UDP ports) | 388 +------------------------------------------------------------+ 389 | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 390 +------------------------------------------------------------+ | 391 | QUIC ACK frame (acknowledging Server Hello Initial) | | 392 +------------------------------------------------------------+<-+ 393 | QUIC long header (type = Handshake, Version, DCID, SCID) (Length) 394 +------------------------------------------------------------+ | 395 | encrypted payload (presumably CRYPTO/ACK frames) | | 396 +------------------------------------------------------------+<-+ 397 | QUIC short header | 398 +------------------------------------------------------------+ 399 | 1-RTT encrypted payload | 400 +------------------------------------------------------------+ 402 Figure 4: Typical QUIC Initial Completion datagram pattern 404 The Initial Completion datagram does not expose any additional 405 information; however, recognizing it can be used to determine that a 406 handshake has completed (see Section 3.2), and for three-way 407 handshake RTT estimation as in Section 3.7. 409 +------------------------------------------------------------+ 410 | UDP header (source and destination UDP ports) | 411 +------------------------------------------------------------+ 412 | QUIC long header (type = Handshake, Version, DCID, SCID) (Length) 413 +------------------------------------------------------------+ | 414 | encrypted payload (presumably ACK frame) | | 415 +------------------------------------------------------------+<-+ 416 | QUIC short header | 417 +------------------------------------------------------------+ 418 | 1-RTT encrypted payload | 419 +------------------------------------------------------------+ 421 Figure 5: Typical QUIC Handshake Completion datagram pattern 423 Similar to Initial Completion, Handshake Completion also exposes no 424 additional information; observing it serves only to determine that 425 the handshake has completed. 427 When the client uses 0-RTT connection resumption, 0-RTT data may also 428 be seen in the QUIC Client Hello datagram, as shown in Figure 6. 430 +----------------------------------------------------------+ 431 | UDP header (source and destination UDP ports) | 432 +----------------------------------------------------------+ 433 | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 434 +----------------------------------------------------------+ | 435 | QUIC CRYPTO frame header | | 436 +----------------------------------------------------------+ | 437 | TLS Client Hello (incl. TLS SNI) | | 438 +----------------------------------------------------------+<-+ 439 | QUIC long header (type = 0RTT, Version, DCID, SCID) (Length) 440 +----------------------------------------------------------+ | 441 | 0-rtt encrypted payload | | 442 +----------------------------------------------------------+<-+ 444 Figure 6: Typical 0-RTT QUIC Client Hello datagram pattern 446 In a 0-RTT QUIC Client Hello datagram, the PADDING frame is only 447 present if necessary to increase the size of the datagram with 0RTT 448 data to at least 1200 bytes. Additional datagrams containing only 449 0-RTT protected long header packets may be sent from the client to 450 the server after the Client Hello datagram, containing the rest of 451 the 0-RTT data. The amount of 0-RTT protected data is limited by the 452 initial congestion window, typically around 10 packets [RFC6928]. 454 2.5. Integrity Protection of the Wire Image 456 As soon as the cryptographic context is established, all information 457 in the QUIC header, including information exposed in the packet 458 header, is integrity protected. Further, information that was sent 459 and exposed in handshake packets sent before the cryptographic 460 context was established are validated later during the cryptographic 461 handshake. Therefore, devices on path MUST NOT change any 462 information or bits in QUIC packet headers, since alteration of 463 header information will lead to a failed integrity check at the 464 receiver, and can even lead to connection termination. 466 2.6. Connection ID and Rebinding 468 The connection ID in the QUIC packet headers allows routing of QUIC 469 packets at load balancers on other than five-tuple information, 470 ensuring that related flows are appropriately balanced together; and 471 to allow rebinding of a connection after one of the endpoint's 472 addresses changes - usually the client's, in the case of the HTTP 473 binding. Client and server negotiate connection IDs during the 474 handshake; typically, however, only the server will request a 475 connection ID for the lifetime of the connection. Connection IDs for 476 either endpoint may change during the lifetime of a connection, with 477 the new connection ID being negotiated via encrypted frames. See 478 Section 5.1 of [QUIC-TRANSPORT]. 480 2.7. Packet Numbers 482 The packet number field is always present in the QUIC packet header; 483 however, it is always encrypted. The encryption key for packet 484 number protection on handshake packets sent before cryptographic 485 context establishment is specific to the QUIC version, while packet 486 number protection on subsequent packets uses secrets derived from the 487 end-to-end cryptographic context. Packet numbers are therefore not 488 part of the wire image that is visible to on-path observers. 490 2.8. Version Negotiation and Greasing 492 Version negotiation is not protected, given the used protection 493 mechanism can change with the version. However, the choices provided 494 in the list of version in the Version Negotiation packet will be 495 validated as soon as the cryptographic context has been established. 496 Therefore any manipulation of this list will be detected and will 497 cause the endpoints to terminate the connection. 499 Also note that the list of versions in the Version Negotiation packet 500 may contain reserved versions. This mechanism is used to avoid 501 ossification in the implementation on the selection mechanism. 503 Further, a client may send a Initial Client packet with a reserved 504 version number to trigger version negotiation. In the Version 505 Negotiation packet the connection ID and packet number of the Client 506 Initial packet are reflected to provide a proof of return- 507 routability. Therefore changing these information will also cause 508 the connection to fail. 510 QUIC is expected to evolve rapidly, so new versions, both 511 experimental and IETF standard versions, will be deployed in the 512 Internet more often than with traditional Internet- and transport- 513 layer protocols. Using a particular version number to recognize 514 valid QUIC traffic is likely to persistently miss a fraction of QUIC 515 flows and completely fail in the multi-year timeframe so therefore 516 not recommended. 518 3. Network-visible information about QUIC flows 520 This section addresses the different kinds of observations and 521 inferences that can be made about QUIC flows by a passive observer in 522 the network based on the wire image in Section 2. Here we assume a 523 bidirectional observer (one that can see packets in both directions 524 in the sequence in which they are carried on the wire) unless noted. 526 3.1. Identifying QUIC traffic 528 The QUIC wire image is not specifically designed to be 529 distinguishable from other UDP traffic. 531 The only application binding currently defined for QUIC is HTTP 532 [QUIC-HTTP]. HTTP over QUIC uses UDP port 443 by default, although 533 URLs referring to resources available over HTTP over QUIC may specify 534 alternate port numbers. Simple assumptions about whether a given 535 flow is using QUIC based upon a UDP port number may therefore not 536 hold; see also [RFC7605] section 5. 538 While the second most significant bit (0x40) of the first octet is 539 always set to 1 in QUIC packets of the current version, this is not a 540 recommended method of recognizing QUIC traffic, as it only provides 541 one bit of information and is quite prone to collide with UDP-based 542 protocols other than those that this static bit is meant to allow 543 multiplexing with. 545 3.1.1. Identifying Negotiated Version 547 An in-network observer assuming that a set of packets belongs to a 548 QUIC flow can infer the version number in use by observing the 549 handshake: an Initial packet with a given version from a client to 550 which a server responds with an Initial packet with the same version 551 implies acceptance of that version. 553 Negotiated version cannot be identified for flows for which a 554 handshake is not observed, such as in the case of connection 555 migration; however, these flows can be associated with flows for 556 which a version has been identified; see Section 3.4. 558 In the rest of this section, we discuss only packets belonging to 559 Version 1 QUIC flows, and assume that these packets have been 560 identified as such through the observation of a version negotiation. 562 3.1.2. Rejection of Garbage Traffic 564 A related question is whether a first packet of a given flow on known 565 QUIC-associated port is a valid QUIC packet, in order to support in- 566 network filtering of garbage UDP packets (reflection attacks, random 567 backscatter). While heuristics based on the first byte of the packet 568 (packet type) could be used to separate valid from invalid first 569 packet types, the deployment of such heuristics is not recommended, 570 as packet types may have different meanings in future versions of the 571 protocol. 573 3.2. Connection confirmation 575 Connection establishment uses Initial, Handshake, and Retry packets 576 containing a TLS handshake. Connection establishment can therefore 577 be detected using heuristics similar to those used to detect TLS over 578 TCP. A client using 0-RTT connection may also send data packets in 579 0-RTT Protected packets directly after the Initial packet containing 580 the TLS Client Hello. Since these packets may be reordered in the 581 network, note that 0-RTT Protected data packets may be seen before 582 the Initial packet. 584 Note that clients send Initial packets before servers do, servers 585 send Handshake packets before clients do, and only clients send 586 Initial packets with tokens, so the sides of a connection can be 587 generally be confirmed by an on-path observer. An attempted 588 connection after Retry can be detected by correlating the token on 589 the Retry with the token on the subsequent Initial packet. 591 3.3. Application Identification 593 The cleartext TLS handshake may contain Server Name Indication (SNI) 594 [RFC6066], by which the client reveals the name of the server it 595 intends to connect to, in order to allow the server to present a 596 certificate based on that name. It may also contain information from 597 Application-Layer Protocol Negotiation (ALPN) [RFC7301], by which the 598 client exposes the names of application-layer protocols it supports; 599 an observer can deduce that one of those protocols will be used if 600 the connection continues. 602 Work is currently underway in the TLS working group to encrypt the 603 SNI in TLS 1.3 [TLS-ESNI]. If used with QUIC, this would make SNI- 604 based application identification impossible through passive 605 measurement. 607 3.4. Flow association 609 The QUIC Connection ID (see Section 2.6) is designed to allow an on- 610 path device such as a load-balancer to associate two flows as 611 identified by five-tuple when the address and port of one of the 612 endpoints changes; e.g. due to NAT rebinding or server IP address 613 migration. An observer keeping flow state can associate a connection 614 ID with a given flow, and can associate a known flow with a new flow 615 when when observing a packet sharing a connection ID and one endpoint 616 address (IP address and port) with the known flow. 618 However, since the connection ID may change multiple times during the 619 lifetime of a flow, and the negotiation of connection ID changes is 620 encrypted, packets with the same 5-tuple but different connection IDs 621 may or may not belong to the same connection. 623 The connection ID value should be treated as opaque; see Section 4.3 624 for caveats regarding connection ID selection at servers. 626 3.5. Flow teardown 628 QUIC does not expose the end of a connection; the only indication to 629 on-path devices that a flow has ended is that packets are no longer 630 observed. Stateful devices on path such as NATs and firewalls must 631 therefore use idle timeouts to determine when to drop state for QUIC 632 flows. 634 Changes to this behavior have been discussed in the working group, 635 but there is no current proposal to implement these changes: see 636 https://github.com/quicwg/base-drafts/issues/602. 638 3.6. Flow symmetry measurement 640 QUIC explicitly exposes which side of a connection is a client and 641 which side is a server during the handshake. In addition, the 642 symmetry of a flow (whether primarily client-to-server, primarily 643 server-to-client, or roughly bidirectional, as input to basic traffic 644 classification techniques) can be inferred through the measurement of 645 data rate in each direction. While QUIC traffic is protected and 646 ACKs may be padded, padding is not required. 648 3.7. Round-Trip Time (RTT) Measurement 650 Round-trip time of QUIC flows can be inferred by observation once per 651 flow, during the handshake, as in passive TCP measurement; this 652 requires parsing of the QUIC packet header and recognition of the 653 handshake, as illustrated in Section 2.4. It can also be inferred 654 during the flow's lifetime, if the endpoints use the spin bit 655 facility described below and in [QUIC-TRANSPORT], section 17.3.1. 657 3.7.1. Measuring initial RTT 659 In the common case, the delay between the Initial packet containing 660 the TLS Client Hello and the Handshake packet containing the TLS 661 Server Hello represents the RTT component on the path between the 662 observer and the server. The delay between the TLS Server Hello and 663 the Handshake packet containing the TLS Finished message sent by the 664 client represents the RTT component on the path between the observer 665 and the client. While the client may send 0-RTT Protected packets 666 after the Initial packet during 0-RTT connection re-establishment, 667 these can be ignored for RTT measurement purposes. 669 Handshake RTT can be measured by adding the client-to-observer and 670 observer-to-server RTT components together. This measurement 671 necessarily includes any transport and application layer delay (the 672 latter mainly caused by the asymmetric crypto operations associated 673 with the TLS handshake) at both sides. 675 3.7.2. Using the Spin Bit for Passive RTT Measurement 677 The spin bit provides an additional method to measure per-flow RTT 678 from observation points on the network path throughout the duration 679 of a connection. Endpoint participation in spin bit signaling is 680 optional in QUIC. That is, while its location is fixed in this 681 version of QUIC, an endpoint can unilaterally choose to not support 682 "spinning" the bit. Use of the spin bit for RTT measurement by 683 devices on path is only possible when both endpoints enable it. Some 684 endpoints may disable use of the spin bit by default, others only in 685 specific deployment scenarios, e.g. for servers and clients where the 686 RTT would reveal the presence of a VPN or proxy. To avoid making 687 these connections identifiable based on the usage of the spin bit, it 688 is recommended that all endpoints randomly disable "spinning" for at 689 least one eighth of connections, even if otherwise enabled by 690 default. An endpoint not participating in spin bit signaling for a 691 given connection can use a fixed spin value for the duration of the 692 connection, or can set the bit randomly on each packet sent. 694 When in use and a QUIC flow sends data continuously, the latency spin 695 bit in each direction changes value once per round-trip time (RTT). 696 An on-path observer can observe the time difference between edges 697 (changes from 1 to 0 or 0 to 1) in the spin bit signal in a single 698 direction to measure one sample of end-to-end RTT. 700 Note that this measurement, as with passive RTT measurement for TCP, 701 includes any transport protocol delay (e.g., delayed sending of 702 acknowledgements) and/or application layer delay (e.g., waiting for a 703 response to be generated). It therefore provides devices on path a 704 good instantaneous estimate of the RTT as experienced by the 705 application. A simple linear smoothing or moving minimum filter can 706 be applied to the stream of RTT information to get a more stable 707 estimate. 709 However, application-limited and flow-control-limited senders can 710 have application and transport layer delay, respectively, that are 711 much greater than network RTT. When the sender is application- 712 limited and e.g. only sends small amount of periodic application 713 traffic, where that period is longer than the RTT, measuring the spin 714 bit provides information about the application period, not the 715 network RTT. 717 Since the spin bit logic at each endpoint considers only samples from 718 packets that advance the largest packet number, signal generation 719 itself is resistant to reordering. However, reordering can cause 720 problems at an observer by causing spurious edge detection and 721 therefore inaccurate (i.e., lower) RTT estimates, if reordering 722 occurs across a spin-bit flip in the stream. 724 Simple heuristics based on the observed data rate per flow or changes 725 in the RTT series can be used to reject bad RTT samples due to lost 726 or reordered edges in the spin signal, as well as application or flow 727 control limitation; for example, QoF [TMA-QOF] rejects component RTTs 728 significantly higher than RTTs over the history of the flow. These 729 heuristics may use the handshake RTT as an initial RTT estimate for a 730 given flow. Usually such heuristics would also detect if the spin is 731 either constant or randomly set for a connection. 733 An on-path observer that can see traffic in both directions (from 734 client to server and from server to client) can also use the spin bit 735 to measure "upstream" and "downstream" component RTT; i.e, the 736 component of the end-to-end RTT attributable to the paths between the 737 observer and the server and the observer and the client, 738 respectively. It does this by measuring the delay between a spin 739 edge observed in the upstream direction and that observed in the 740 downstream direction, and vice versa. 742 4. Specific Network Management Tasks 744 In this section, we review specific network management and 745 measurement techniques and how QUIC's design impacts them. 747 4.1. Stateful treatment of QUIC traffic 749 Stateful treatment of QUIC traffic (e.g., at a firewall or NAT 750 middlebox) is possible through QUIC traffic and version 751 identification (Section 3.1) and observation of the handshake for 752 connection confirmation (Section 3.2). The lack of any visible end- 753 of-flow signal (Section 3.5) means that this state must be purged 754 either through timers or through least-recently-used eviction, 755 depending on application requirements. 757 The QUIC header optionally contains a Connection ID which can be used 758 as additional entropy beyond the 5-tuple, if needed. The QUIC 759 handshake needs to be observed in order to understand whether the 760 Connection ID is present and what length it has. However, Connection 761 IDs may be renegotiated during a connection, and this renegotiation 762 is not visible to the path. Keying state off the Connection ID may 763 therefore cause undetectable and unrecoverable loss of state in the 764 middle of a connection. Use of Connection ID specifically 765 discouraged for NAT applications. 767 4.2. Passive network performance measurement and troubleshooting 769 Limited RTT measurement is possible by passive observation of QUIC 770 traffic; see Section 3.7. No passive measurement of loss is possible 771 with the present wire image. Extremely limited observation of 772 upstream congestion may be possible via the observation of CE 773 markings on ECN-enabled QUIC traffic. 775 4.3. Server cooperation with load balancers 777 In the case of content distribution networking architectures 778 including load balancers, the connection ID provides a way for the 779 server to signal information about the desired treatment of a flow to 780 the load balancers. Guidance on assigning connection IDs is given in 781 [QUIC-APPLICABILITY]. 783 4.4. DDoS Detection and Mitigation 785 Current practices in detection and mitigation of Distributed Denial 786 of Service (DDoS) attacks generally involve passive measurement using 787 network flow data [RFC7011], classification of traffic into "good" 788 (productive) and "bad" (DoS) flows, and filtering of these bad flows 789 in a "scrubbing" environment. Key to successful DDoS mitigation is 790 efficient classification of this traffic. 792 Limited first-packet garbage detection as in Section 3.1.2 and 793 stateful tracking of QUIC traffic as in Section 4.1 above can be used 794 in this classification step. 796 Note that the use of a connection ID to support connection migration 797 renders 5-tuple based filtering insufficient, and requires more state 798 to be maintained by DDoS defense systems, and linkability resistance 799 in connection ID update mechanisms means that a connection ID aware 800 DDoS defense system must have the same information about flows as the 801 load balancer. 803 However, it is questionable if connection migrations needs to be 804 supported in a DDOS attack. If the connection migration is not 805 visible to the network that performs the DDoS detection, an active, 806 migrated QUIC connection may be blocked by such a system under 807 attack. However, a defense system might simply rely on the fast 808 resumption mechanism provided by QUIC. 810 4.5. Distinguishing acknowledgment traffic 812 Some deployed in-network functions distinguish pure-acknowledgment 813 (ACK) packets from packets carrying upper-layer data in order to 814 attempt to enhance performance, for example by queueing ACKs 815 differently or manipulating ACK signaling. Distinguishing ACK 816 packets is trivial in TCP, but not supported by QUIC, since 817 acknowledgment signaling is carried inside QUIC's encrypted payload, 818 and ACK manipulation is impossible. Specifically, heuristics 819 attempting to distinguish ACK-only packets from payload-carrying 820 packets based on packet size are likely to fail, and are emphatically 821 NOT RECOMMENDED. 823 4.6. QoS support and ECMP 825 [EDITOR'S NOTE: this is a bit speculative; keep?] 827 QUIC does not provide any additional information on requirements on 828 Quality of Service (QoS) provided from the network. QUIC assumes 829 that all packets with the same 5-tuple {dest addr, source addr, 830 protocol, dest port, source port} will receive similar network 831 treatment. That means all stream that are multiplexed over the same 832 QUIC connection require the same network treatment and are handled by 833 the same congestion controller. If differential network treatment is 834 desired, multiple QUIC connections to the same server might be used, 835 given that establishing a new connection using 0-RTT support is cheap 836 and fast. 838 QoS mechanisms in the network MAY also use the connection ID for 839 service differentiation, as a change of connection ID is bound to a 840 change of address which anyway is likely to lead to a re-route on a 841 different path with different network characteristics. 843 Given that QUIC is more tolerant of packet re-ordering than TCP (see 844 Section 2.7), Equal-cost multi-path routing (ECMP) does not 845 necessarily need to be flow based. However, 5-tuple (plus eventually 846 connection ID if present) matching is still beneficial for QoS given 847 all packets are handled by the same congestion controller. 849 5. IANA Considerations 851 This document has no actions for IANA. 853 6. Security Considerations 855 Supporting manageability of QUIC traffic inherently involves 856 tradeoffs with the confidentiality of QUIC's control information; 857 this entire document is therefore security-relevant. 859 7. Contributors 861 Dan Druta contributed text to Section 4.4. Igor Lubashev contributed 862 text to Section 4.3 on the use of the connection ID for load 863 balancing. Marcus Ilhar contributed text to Section 3.7 on the use 864 of the spin bit. 866 8. Acknowledgments 868 This work is partially supported by the European Commission under 869 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 870 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 871 for Education, Research, and Innovation under contract no. 15.0268. 872 This support does not imply endorsement. 874 9. References 876 9.1. Normative References 878 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 879 Requirement Levels", BCP 14, RFC 2119, 880 DOI 10.17487/RFC2119, March 1997, 881 . 883 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 884 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 885 May 2017, . 887 9.2. Informative References 889 [Ding2015] Ding, H. and M. Rabinovich, "TCP Stretch Acknowledgments 890 and Timestamps - Findings and Impliciations for Passive 891 RTT Measurement (ACM Computer Communication Review)", July 892 2015, . 895 [IPIM] Allman, M., Beverly, R., and B. Trammell, "In-Protocol 896 Internet Measurement (arXiv preprint 1612.02902)", 9 897 December 2016, . 899 [QUIC-APPLICABILITY] 900 Kuehlewind, M. and B. Trammell, "Applicability of the QUIC 901 Transport Protocol", Work in Progress, Internet-Draft, 902 draft-ietf-quic-applicability-05, 5 July 2019, 903 . 906 [QUIC-HTTP] 907 Bishop, M., "Hypertext Transfer Protocol Version 3 908 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 909 quic-http-24, 4 November 2019, . 912 [QUIC-INVARIANTS] 913 Thomson, M., "Version-Independent Properties of QUIC", 914 Work in Progress, Internet-Draft, draft-ietf-quic- 915 invariants-07, 11 September 2019, . 918 [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 919 Work in Progress, Internet-Draft, draft-ietf-quic-tls-24, 920 3 November 2019, . 923 [QUIC-TRANSPORT] 924 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 925 and Secure Transport", Work in Progress, Internet-Draft, 926 draft-ietf-quic-transport-24, 3 November 2019, 927 . 930 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 931 Extensions: Extension Definitions", RFC 6066, 932 DOI 10.17487/RFC6066, January 2011, 933 . 935 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 936 "Increasing TCP's Initial Window", RFC 6928, 937 DOI 10.17487/RFC6928, April 2013, 938 . 940 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 941 "Specification of the IP Flow Information Export (IPFIX) 942 Protocol for the Exchange of Flow Information", STD 77, 943 RFC 7011, DOI 10.17487/RFC7011, September 2013, 944 . 946 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 947 "Transport Layer Security (TLS) Application-Layer Protocol 948 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 949 July 2014, . 951 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 952 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 953 August 2015, . 955 [TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 956 "Encrypted Server Name Indication for TLS 1.3", Work in 957 Progress, Internet-Draft, draft-ietf-tls-esni-05, 4 958 November 2019, . 961 [TMA-QOF] Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data 962 Integrity Signals for Passive Measurement (in Proc. TMA 963 2014)", April 2014. 965 [WIRE-IMAGE] 966 Trammell, B. and M. Kuehlewind, "The Wire Image of a 967 Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 968 2019, . 970 Authors' Addresses 972 Mirja Kuehlewind 973 Ericsson 975 Email: mirja.kuehlewind@ericsson.com 977 Brian Trammell 978 Google 979 Gustav-Gull-Platz 1 980 CH- 8004 Zurich 981 Switzerland 983 Email: ietf@trammell.ch