idnits 2.17.1 draft-ietf-quic-manageability-03.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 22, 2018) is 2012 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Ding2015' is defined on line 772, but no explicit reference was found in the text == Unused Reference: 'IPIM' is defined on line 779, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-quic-applicability-02 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-15 == Outdated reference: A later version (-13) exists of draft-ietf-quic-invariants-03 == Outdated reference: A later version (-01) exists of draft-ietf-quic-spin-exp-00 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-15 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-15 == Outdated reference: A later version (-09) exists of draft-ietf-tls-sni-encryption-03 Summary: 0 errors (**), 0 flaws (~~), 11 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 B. Trammell 4 Intended status: Informational ETH Zurich 5 Expires: April 25, 2019 October 22, 2018 7 Manageability of the QUIC Transport Protocol 8 draft-ietf-quic-manageability-03 10 Abstract 12 This document discusses manageability of the QUIC transport protocol, 13 focusing on caveats impacting network operations involving QUIC 14 traffic. Its intended audience is network operators, as well as 15 content providers that rely on the use of QUIC-aware middleboxes, 16 e.g. for load balancing. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 25, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 54 2. Features of the QUIC Wire Image . . . . . . . . . . . . . . . 3 55 2.1. QUIC Packet Header Structure . . . . . . . . . . . . . . 4 56 2.2. Coalesced Packets . . . . . . . . . . . . . . . . . . . . 5 57 2.3. Use of Port Numbers . . . . . . . . . . . . . . . . . . . 5 58 2.4. The QUIC handshake . . . . . . . . . . . . . . . . . . . 5 59 2.5. Integrity Protection of the Wire Image . . . . . . . . . 10 60 2.6. Connection ID and Rebinding . . . . . . . . . . . . . . . 10 61 2.7. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 10 62 2.8. Version Negotiation and Greasing . . . . . . . . . . . . 10 63 3. Network-visible information about QUIC flows . . . . . . . . 11 64 3.1. Identifying QUIC traffic . . . . . . . . . . . . . . . . 11 65 3.1.1. Identifying Negotiated Version . . . . . . . . . . . 11 66 3.1.2. Rejection of Garbage Traffic . . . . . . . . . . . . 12 67 3.2. Connection confirmation . . . . . . . . . . . . . . . . . 12 68 3.3. Application Identification . . . . . . . . . . . . . . . 12 69 3.4. Flow association . . . . . . . . . . . . . . . . . . . . 12 70 3.5. Flow teardown . . . . . . . . . . . . . . . . . . . . . . 13 71 3.6. Round-trip time measurement . . . . . . . . . . . . . . . 13 72 3.7. Flow symmetry measurement . . . . . . . . . . . . . . . . 14 73 4. Specific Network Management Tasks . . . . . . . . . . . . . . 15 74 4.1. Stateful treatment of QUIC traffic . . . . . . . . . . . 15 75 4.2. Passive network performance measurement and 76 troubleshooting . . . . . . . . . . . . . . . . . . . . . 15 77 4.3. Server cooperation with load balancers . . . . . . . . . 15 78 4.4. DDoS Detection and Mitigation . . . . . . . . . . . . . . 15 79 4.5. QoS support and ECMP . . . . . . . . . . . . . . . . . . 16 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 83 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 86 9.2. Informative References . . . . . . . . . . . . . . . . . 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 89 1. Introduction 91 QUIC [QUIC-TRANSPORT] is a new transport protocol currently under 92 development in the IETF quic working group, focusing on support of 93 semantics as needed for HTTP/2 [QUIC-HTTP]. Based on current 94 deployment practices, QUIC is encapsulated in UDP and encrypted by 95 default. The current version of QUIC integrates TLS [QUIC-TLS] to 96 encrypt all payload data and most control information. Given QUIC is 97 an end-to-end transport protocol, all information in the protocol 98 header, even that which can be inspected, is is not meant to be 99 mutable by the network, and is therefore integrity-protected to the 100 extent possible. 102 This document provides guidance for network operation on the 103 management of QUIC traffic. This includes guidance on how to 104 interpret and utilize information that is exposed by QUIC to the 105 network as well as explaining requirement and assumptions that the 106 QUIC protocol design takes toward the expected network treatment. It 107 also discusses how common network management practices will be 108 impacted by QUIC. 110 Of course, network management is not a one-size-fits-all endeavour: 111 practices considered necessary or even mandatory within enterprise 112 networks with certain compliance requirements, for example, would be 113 impermissible on other networks without those requirements. This 114 document therefore does not make any specific recommendations as to 115 which practices should or should not be applied; for each practice, 116 it describes what is and is not possible with the QUIC transport 117 protocol as defined. 119 QUIC is at the moment very much a moving target. This document 120 refers the state of the QUIC working group drafts as well as to 121 changes under discussion, via issues and pull requests in GitHub 122 current as of the time of writing. 124 1.1. Notational Conventions 126 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 127 document. It's not shouting; when these words are capitalized, they 128 have a special meaning as defined in [RFC2119]. 130 2. Features of the QUIC Wire Image 132 In this section, we discusses those aspects of the QUIC transport 133 protocol that have an impact on the design and operation of devices 134 that forward QUIC packets. Here, we are concerned primarily with 135 QUIC's unencrypted wire image [WIRE-IMAGE], which we define as the 136 information available in the packet header in each QUIC packet, and 137 the dynamics of that information. Since QUIC is a versioned 138 protocol, the wire image of the header format can also change from 139 version to version. However, at least the mechanism by which a 140 receiver can determine which version is used and the meaning and 141 location of fields used in the version negotiation process is 142 invariant [QUIC-INVARIANTS]. 144 This document is focused on the protocol as presently defined in 145 [QUIC-TRANSPORT] and [QUIC-TLS], and will change to track those 146 documents. 148 2.1. QUIC Packet Header Structure 150 QUIC packets may have either a long header, or a short header. The 151 first bit of the QUIC header indicates which type of header is 152 present. 154 The long header exposes more information. It is used during 155 connection establishment, including version negotiation, server 156 retry, and 0-RTT data. It contains a version number, as well as 157 source and destination connection IDs for grouping packets belonging 158 to the same flow. The definition and location of these fields in the 159 QUIC long header are invariant for future versions of QUIC, although 160 future versions of QUIC may provide additional fields in the long 161 header [QUIC-INVARIANTS]. 163 Short headers are used after connection establishment. The only 164 information they contain for inspection on the path is an optional, 165 variable-length destination connection ID. 167 As of draft version 13 of the QUIC transport document, the following 168 information may be exposed in QUIC packet headers: 170 o header type: the long header has a 7-bit packet type field 171 following the Header Form bit. Header types correspond to stages 172 of the handshake; see Section 4.1 of [QUIC-TRANSPORT]. 174 o version number: The version number is present in the long header, 175 and identifies the version used for that packet. Note that during 176 Version Negotiation (see Section 2.8, and Section 4.3 of 177 [QUIC-TRANSPORT], the version number field has a special value 178 (0x00000000) that identifies the packet as a Version Negotiation 179 packet. 181 o source and destination connection ID: The source and destination 182 connection IDs are variable-length fields that can be used to 183 identify the connection associated with a QUIC packet, for load- 184 balancing and NAT rebinding purposes; see Section 4.3 and 185 Section 2.6. The source connection ID corresponds to the 186 destination connection ID the source would like to have on packets 187 sent to it, and is only present on long packet headers. The 188 destination connection ID, if present, is present on both long and 189 short header packets. On long header packets, the length of the 190 connection IDs is also present; on short header packets, the 191 length of the destination connection ID is implicit. 193 o length: the length of the remaining quic packet after the length 194 field, present on long headers. This field is used to implement 195 coalesced packets during the handshake (see Section 2.2). 197 o packet number: Every packet has an associated packet number; 198 however, this packet number is encrypted, and therefore not of use 199 to on-path observers. This packet number has a fixed location and 200 length in long headers, and an implicit location and encrypted 201 variable length in short headers. 203 o key phase: The Key Phase bit, present in short headers identifies 204 the key used to encrypt the packet during key rotation. 206 2.2. Coalesced Packets 208 Multiple QUIC packets may be coalesced into a UDP datagram, with a 209 datagram carrying one or more long header packets followed by zero or 210 one short header packets. When packets are coalesced, the Length 211 fields in the long headers are used to separate QUIC packets. The 212 length header field is variable length and its position in the header 213 is also variable depending on the length of the source and 214 destionation connection ID. See Section 4.6 of [QUIC-TRANSPORT]. 216 2.3. Use of Port Numbers 218 Applications that have a mapping for TCP as well as QUIC are expected 219 to use the same port number for both services. However, as with TCP- 220 based services, especially when application layer information is 221 encrypted, there is no guarantee that a specific application will use 222 the registered port, or the used port is carrying traffic belonging 223 to the respective registered service. For example, [QUIC-TRANSPORT] 224 specifies the use of Alt-Svc for discovery of QUIC/HTTP services on 225 other ports. 227 Further, as QUIC has a connection ID, it is also possible to maintain 228 multiple QUIC connections over one 5-tuple. However, if the 229 connection ID is not present in the packet header, all packets of the 230 5-tuple belong to the same QUIC connection. 232 2.4. The QUIC handshake 234 New QUIC connections are established using a handshake, which is 235 distinguishable on the wire and contains some information that can be 236 passively observed. 238 To illustrate the information visible in the QUIC wire image during 239 the handshake, we first show the general communication pattern 240 visible in the UDP datagams containing the QUIC handshake, then 241 examine each of the datagrams in detail. 243 In the nominal case, the QUIC handshake can be recognized on the wire 244 through at least four datagrams we'll call "QUIC Client Hello", "QUIC 245 Server Hello", and "Initial Completion", and "Handshake Completion", 246 for purposes of this illustration, as shown in Figure 1. 248 Packets in the handshake belong to three separate cryptographic and 249 transport contexts ("Initial", which contains observable payload, and 250 "Handshake" and "1-RTT", which do not). QUIC packets in separate 251 contexts during the handshake are generally coalesced (see 252 Section 2.2) in order to reduce the number of UDP datagrams sent 253 during the handshake. 255 As shown here, the client can send 0-RTT data as soon as it has sent 256 its Client Hello, and the server can send 1-RTT data as soon as it 257 has sent its Server Hello. 259 Client Server 260 | | 261 +----QUIC Client Hello-------------------->| 262 +----(zero or more 0RTT)------------------>| 263 | | 264 |<--------------------QUIC Server Hello----+ 265 |<---------(1RTT encrypted data starts)----+ 266 | | 267 +----Initial Completion------------------->| 268 +----(1RTT encrypted data starts)--------->| 269 | | 270 |<-----------------Handshake Completion----+ 271 | | 273 Figure 1: General communication pattern visible in the QUIC handshake 275 A typical handshake starts with the client sending of a QUIC Client 276 Hello datagram as shown in Figure 2, which elicits a QUIC Server 277 Hello datagram as shown in Figure 3 typically containing three 278 packets: an Initial packet with the Server Hello, a Handshake packet 279 with the rest of the server's side of the TLS handshake, and initial 280 1-RTT data, if present. 282 The content of QUIC Initial packets are encrypted using Initial 283 Secrets, which are derived from a per-version constant and the 284 client's destination connection ID; they are therefore observable by 285 any on-path device that knows the per-version constant; we therefore 286 consider these as visible in our illustration. The content of QUIC 287 Handshake packets are encrypted using keys established during the 288 initial handshake exchange, and are therefore not visible. 290 Initial, Handshake, and the Short Header packets transmitted after 291 the handshake belong to cryptographic and transport contexts. The 292 Initial Completion Figure 4 and the Handshake Completion Figure 5 293 datagrams finish these first two contexts, by sending the final 294 acknowledgment and finishing the transmission of CRYPTO frames. 296 +----------------------------------------------------------+ 297 | UDP header (source and destination UDP ports) | 298 +----------------------------------------------------------+ 299 | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 300 +----------------------------------------------------------+ | 301 | QUIC CRYPTO frame header | | 302 +----------------------------------------------------------+ | 303 | TLS Client Hello (incl. TLS SNI) | | 304 +----------------------------------------------------------+ | 305 | QUIC PADDING frame | | 306 +----------------------------------------------------------+<-+ 308 Figure 2: Typical 1-RTT QUIC Client Hello datagram pattern 310 The Client Hello datagram exposes version number, source and 311 destination connection IDs, and information in the TLS Client Hello 312 message, including any TLS Server Name Indication (SNI) present, in 313 the clear. The QUIC PADDING frame shown here may be present to 314 ensure the Client Hello datagram has a minumum size of 1200 octets, 315 to mitigate the possibility of handshake amplification. Note that 316 the location of PADDING is implementation-dependent, and PADDING 317 frames may not appear in the Initial packet in a coalesced packet. 319 +------------------------------------------------------------+ 320 | UDP header (source and destination UDP ports) | 321 +------------------------------------------------------------+ 322 | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 323 +------------------------------------------------------------+ | 324 | QUIC CRYPTO frame header | | 325 +------------------------------------------------------------+ | 326 | TLS Server Hello | | 327 +------------------------------------------------------------+ | 328 | QUIC ACK frame (acknowledging client hello) | | 329 +------------------------------------------------------------+<-+ 330 | QUIC long header (type = Handshake, Version, DCID, SCID) (Length) 331 +------------------------------------------------------------+ | 332 | encrypted payload (presumably CRYPTO frames) | | 333 +------------------------------------------------------------+<-+ 334 | QUIC short header | 335 +------------------------------------------------------------+ 336 | 1-RTT encrypted payload | 337 +------------------------------------------------------------+ 339 Figure 3: Typical QUIC Server Hello datagram pattern 341 The Server Hello datagram exposes version number, source and 342 destination connection IDs, and information in the TLS Server Hello 343 message. 345 +------------------------------------------------------------+ 346 | UDP header (source and destination UDP ports) | 347 +------------------------------------------------------------+ 348 | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 349 +------------------------------------------------------------+ | 350 | QUIC ACK frame (acknowledging Server Hello Initial) | | 351 +------------------------------------------------------------+<-+ 352 | QUIC long header (type = Handshake, Version, DCID, SCID) (Length) 353 +------------------------------------------------------------+ | 354 | encrypted payload (presumably CRYPTO/ACK frames) | | 355 +------------------------------------------------------------+<-+ 356 | QUIC short header | 357 +------------------------------------------------------------+ 358 | 1-RTT encrypted payload | 359 +------------------------------------------------------------+ 361 Figure 4: Typical QUIC Initial Completion datagram pattern 363 The Initial Completion datagram does not expose any additional 364 information; however, recognizing it can be used to determine that a 365 handshake has completed (see Section 3.2), and for three-way 366 handshake RTT estimation as in Section 3.6. 368 +------------------------------------------------------------+ 369 | UDP header (source and destination UDP ports) | 370 +------------------------------------------------------------+ 371 | QUIC long header (type = Handshake, Version, DCID, SCID) (Length) 372 +------------------------------------------------------------+ | 373 | encrypted payload (presumably ACK frame) | | 374 +------------------------------------------------------------+<-+ 375 | QUIC short header | 376 +------------------------------------------------------------+ 377 | 1-RTT encrypted payload | 378 +------------------------------------------------------------+ 380 Figure 5: Typical QUIC Handshake Completion datagram pattern 382 Similar to Initial Competion, Handshake Completion also exposes no 383 additional information; observing it serves only to determine that 384 the handshake has completed. 386 When the client uses 0-RTT connection resumption, 0-RTT data may also 387 be seen in the QUIC Client Hello datagram, as shown in Figure 6. 389 +----------------------------------------------------------+ 390 | UDP header (source and destination UDP ports) | 391 +----------------------------------------------------------+ 392 | QUIC long header (type = Initial, Version, DCID, SCID) (Length) 393 +----------------------------------------------------------+ | 394 | QUIC CRYPTO frame header | | 395 +----------------------------------------------------------+ | 396 | TLS Client Hello (incl. TLS SNI) | | 397 +----------------------------------------------------------+<-+ 398 | QUIC long header (type = 0RTT, Version, DCID, SCID) (Length) 399 +----------------------------------------------------------+ | 400 | 0-rtt encrypted payload | | 401 +----------------------------------------------------------+<-+ 403 Figure 6: Typical 0-RTT QUIC Client Hello datagram pattern 405 In a 0-RTT QUIC Client Hello datagram, the PADDING frame is only 406 present if necessary to increase the size of the datagram with 0RTT 407 data to at least 1200 bytes. Additional datagrams containing only 408 0-RTT protected long header packets may be sent from the client to 409 the server after the Client Hello datagram, containing the rest of 410 the 0-RTT data. The amount of 0-RTT protected data is limited by the 411 initial congestion window, typically around 10 packets [RFC6928]. 413 2.5. Integrity Protection of the Wire Image 415 As soon as the cryptographic context is established, all information 416 in the QUIC header, including information exposed in the packet 417 header, is integrity protected. Further, information that was sent 418 and exposed in handshake packets sent before the cryptographic 419 context was established are validated later during the cryptographic 420 handshake. Therefore, devices on path MUST NOT change any 421 information or bits in QUIC packet headers, since alteration of 422 header information will lead to a failed integrity check at the 423 receiver, and can even lead to connection termination. 425 2.6. Connection ID and Rebinding 427 The connection ID in the QUIC packet headers allows routing of QUIC 428 packets at load balancers on other than five-tuple information, 429 ensuring that related flows are appropriately balanced together; and 430 to allow rebinding of a connection after one of the endpoint's 431 addresses changes - usually the client's, in the case of the HTTP 432 binding. Client and server negotiate connection IDs during the 433 handshake; typically, however, only the server will request a 434 connection ID for the lifetime of the connection. Connection IDs for 435 either endpoint may change during the lifetime of a connection, with 436 the new connection ID being negotiated via encrypted frames. See 437 Section 6.1 of [QUIC-TRANSPORT]. 439 2.7. Packet Numbers 441 The packet number field is always present in the QUIC packet header; 442 however, it is always encrypted. The encryption key for packet 443 number protection on handshake packets sent before cryptographic 444 context establishment is specific to the QUIC version, while packet 445 number protection on subsequent packets uses secrets derived from the 446 end-to-end cryptographic context. Packet numbers are therefore not 447 part of the wire image that is useful to on-path observers. 449 2.8. Version Negotiation and Greasing 451 Version negotiation is not protected, given the used protection 452 mechanism can change with the version. However, the choices provided 453 in the list of version in the Version Negotiation packet will be 454 validated as soon as the cryptographic context has been established. 455 Therefore any manipulation of this list will be detected and will 456 cause the endpoints to terminate the connection. 458 Also note that the list of versions in the Version Negotiation packet 459 may contain reserved versions. This mechanism is used to avoid 460 ossification in the implementation on the selection mechanism. 462 Further, a client may send a Initial Client packet with a reserved 463 version number to trigger version negotiation. In the Version 464 Negotiation packet the connection ID and packet number of the Client 465 Initial packet are reflected to provide a proof of return- 466 routability. Therefore changing these information will also cause 467 the connection to fail. 469 3. Network-visible information about QUIC flows 471 This section addresses the different kinds of observations and 472 inferences that can be made about QUIC flows by a passive observer in 473 the network based on the wire image in Section 2. Here we assume a 474 bidirectional observer (one that can see packets in both directions 475 in the sequence in which they are carried on the wire) unless noted. 477 3.1. Identifying QUIC traffic 479 The QUIC wire image is not specifically designed to be 480 distinguishable from other UDP traffic. 482 The only application binding currently defined for QUIC is HTTP 483 [QUIC-HTTP]. HTTP over QUIC uses UDP port 443 by default, although 484 URLs referring to resources available over HTTP over QUIC may specify 485 alternate port numbers. Simple assumptions about whether a given 486 flow is using QUIC based upon a UDP port number may therefore not 487 hold; see also [RFC7605] section 5. 489 3.1.1. Identifying Negotiated Version 491 An in-network observer assuming that a set of packets belongs to a 492 QUIC flow can infer the version number in use by observing the 493 handshake: an Initial packet with a given version from a client to 494 which a server responds with an Initial packet with the same version 495 implies acceptance of that version. 497 Negotiated version cannot be identified for flows for which a 498 handshake is not observed, such as in the case of NAT rebinding; 499 however, these flows can be associated with flows for which a version 500 has been identified; see Section 3.4. 502 In the rest of this section, we discuss only packets belonging to 503 Version 1 QUIC flows, and assume that these packets have been 504 identified as such through the observation of a version negotiation. 506 3.1.2. Rejection of Garbage Traffic 508 A related question is whether a first packet of a given flow on known 509 QUIC-associated port is a valid QUIC packet, in order to support in- 510 network filtering of garbage UDP packets (reflection attacks, random 511 backscatter). While heuristics based on the first byte of the packet 512 (packet type) could be used to separate valid from invalid first 513 packet types, the deployment of such heuristics is not recommended, 514 as packet types may have different meanings in future versions of the 515 protocol. 517 3.2. Connection confirmation 519 Connection establishment uses Initial, Handshake, and Retry packets 520 containing a TLS handshake. Connection establishment can therefore 521 be detected using heuristics similar to those used to detect TLS over 522 TCP. A client using 0-RTT connection may also send data packets in 523 0-RTT Protected packets directly after the Initial packet containing 524 the TLS Client Hello. Since these packets may be reordered in the 525 network, note that 0-RTT Protected data packets may be seen before 526 the Initial packet. Note that only clients send Initial packets, so 527 the sides of a connection can be distinguished by QUIC packet type in 528 the handshake. 530 3.3. Application Identification 532 The cleartext TLS handshake may contain Server Name Indication (SNI) 533 [RFC6066], by which the client reveals the name of the server it 534 intends to connect to, in order to allow the server to present a 535 certificate based on that name. It may also contain information from 536 Application-Layer Protocol Negotiation (ALPN) [RFC7301], by which the 537 client exposes the names of application-layer protocols it supports; 538 an observer can deduce that one of those protocols will be used if 539 the connection continues. 541 Work is currently underway in the TLS working group to encrypt the 542 SNI in TLS 1.3 [TLS-ENCRYPT-SNI], reducing the information available 543 in the SNI to the name of a fronting service, which can generally be 544 identified by the IP address of the server anyway. If used with 545 QUIC, this would make SNI-based application identification impossible 546 through passive measurement. 548 3.4. Flow association 550 The QUIC Connection ID (see Section 2.6) is designed to allow an on- 551 path device such as a load-balancer to associate two flows as 552 identified by five-tuple when the address and port of one of the 553 endpoints changes; e.g. due to NAT rebinding or server IP address 554 migration. An observer keeping flow state can associate a connection 555 ID with a given flow, and can associate a known flow with a new flow 556 when when observing a packet sharing a connection ID and one endpoint 557 address (IP address and port) with the known flow. 559 The connection ID to be used for a long-running flow is chosen by the 560 server (see [QUIC-TRANSPORT] section 5.6) during the handshake. This 561 value should be treated as opaque; see Section 4.3 for caveats 562 regarding connection ID selection at servers. 564 3.5. Flow teardown 566 The QUIC does not expose the end of a connection; the only indication 567 to on-path devices that a flow has ended is that packets are no 568 longer observed. Stateful devices on path such as NATs and firewalls 569 must therefore use idle timeouts to determine when to drop state for 570 QUIC flows. 572 Changes to this behavior have been discussed in the working group, 573 but there is no current proposal to implement these changes: see 574 https://github.com/quicwg/base-drafts/issues/602. 576 3.6. Round-trip time measurement 578 Round-trip time of QUIC flows can be inferred by observation once per 579 flow, during the handshake, as in passive TCP measurement; this 580 requires parsing of the QUIC packet header and recognition of the 581 handshake, as illustrated in Section 2.4. 583 In the common case, the delay between the Initial packet containing 584 the TLS Client Hello and the Handshake packet containing the TLS 585 Server Hello represents the RTT component on the path between the 586 observer and the server. The delay between the TLS Server Hello and 587 the Handshake packet containing the TLS Finished message sent by the 588 client represents the RTT component on the path between the observer 589 and the client. While the client may send 0-RTT Protected packets 590 after the Initial packet during 0-RTT connection re-establishment, 591 these can be ignored for RTT measurement purposes. 593 Handshake RTT can be measured by adding the client-to-observer and 594 observer-to-server RTT components together. This measurement 595 necessarily includes any transport and application layer delay at 596 both sides. 598 The spin bit experiment, detailed in [QUIC-SPIN], provides an 599 additional method to measure intraflow per-flow RTT. When a QUIC 600 flow is sending at full rate (i.e., neither application nor flow 601 control limited), the latency spin bit described in that document 602 changes value once per round-trip time (RTT). An on-path observer 603 can observe the time difference between edges in the spin bit signal 604 in a single direction to measure one sample of end-to-end RTT. Note 605 that this measurement, as with passive RTT measurement for TCP, 606 includes any transport protocol delay (e.g., delayed sending of 607 acknowledgements) and/or application layer delay (e.g., waiting for a 608 request to complete). It therefore provides devices on path a good 609 instantaneous estimate of the RTT as experienced by the application. 610 A simple linear smoothing or moving minimum filter can be applied to 611 the stream of RTT information to get a more stable estimate. 613 An on-path observer that can see traffic in both directions (from 614 client to server and from server to client) can also use the spin bit 615 to measure "upstream" and "downstream" component RTT; i.e, the 616 component of the end-to-end RTT attributable to the paths between the 617 observer and the server and the observer and the client, 618 respectively. It does this by measuring the delay between a spin 619 edge observed in the upstream direction and that observed in the 620 downstream direction, and vice versa. 622 Application-limited and flow-control-limited senders can have 623 application and transport layer delay, respectively, that are much 624 greater than network RTT. Therefore, the spin bit provides network 625 latency information only when the sender is neither application nor 626 flow control limited. When the sender is application-limited by 627 periodic application traffic, where that period is longer than the 628 RTT, measuring the spin bit provides information about the 629 application period, not the RTT. Simple heuristics based on the 630 observed data rate per flow or changes in the RTT series can be used 631 to reject bad RTT samples due to application or flow control 632 limitation. 634 Since the spin bit logic at each endpoint considers only samples on 635 packets that advance the largest packet number seen, signal 636 generation itself is resistant to reordering. However, reordering 637 can cause problems at an observer by causing spurious edge detection 638 and therefore low RTT estimates, if reordering occurs across a spin 639 bit flip in the stream. This can be probabilistically mitigated by 640 the observer also tracking the low-order bits of the packet number, 641 and rejecting edges that appear out-of-order [RFC4737]. 643 3.7. Flow symmetry measurement 645 QUIC explicitly exposes which side of a connection is a client and 646 which side is a server during the handshake. In addition, the 647 symmerty of a flow (whether primarily client-to-server, primarily 648 server-to-client, or roughly bidirectional, as input to basic traffic 649 classification techniques) can be inferred through the measurement of 650 data rate in each direction. While QUIC traffic is protected and 651 ACKS may be padded, padding is not required. 653 4. Specific Network Management Tasks 655 In this section, we address specific network management and 656 measurement techniques and how QUIC's design impacts them. 658 4.1. Stateful treatment of QUIC traffic 660 Stateful treatment of QUIC traffic is possible through QUIC traffic 661 and version identification (Section 3.1) and observation of the 662 handshake for connection confirmation (Section 3.2). The lack of any 663 visible end-of-flow signal (Section 3.5) means that this state must 664 be purged either through timers or through least-recently-used 665 eviction, depending on application requirements. 667 4.2. Passive network performance measurement and troubleshooting 669 Limited RTT measurement is possible by passive observation of QUIC 670 traffic; see Section 3.6. No passive measurement of loss is possible 671 with the present wire image. Extremely limited observation of 672 upstream congestion may be possible via the observation of CE 673 markings on ECN-enabled QUIC traffic. 675 4.3. Server cooperation with load balancers 677 In the case of content distribution networking architectures 678 including load balancers, the connection ID provides a way for the 679 server to signal information about the desired treatment of a flow to 680 the load balancers. Guidance on assigning connection IDs is given in 681 [QUIC-APPLICABILITY]. 683 4.4. DDoS Detection and Mitigation 685 Current practices in detection and mitigation of Distributed Denial 686 of Service (DDoS) attacks generally involve passive measurement using 687 network flow data [RFC7011], classification of traffic into "good" 688 (productive) and "bad" (DoS) flows, and filtering of these bad flows 689 in a "scrubbing" environment. Key to successful DDoS mitigation is 690 efficient classification of this traffic. 692 Limited first-packet garbage detection as in Section 3.1.2 and 693 stateful tracking of QUIC traffic as in Section 4.1 above can be used 694 in this classification step. 696 Note that the use of a connection ID to support connection migration 697 renders 5-tuple based filtering insufficient, and requires more state 698 to be maintained by DDoS defense systems, and linkability resistance 699 in connection ID update mechanisms means that a connection ID aware 700 DDoS defense system must have the same information about flows as the 701 load balancer. 703 However, it is questionable if connection migrations needs to be 704 supported in a DDOS attack. If the connection migration is not 705 visible to the network that performs the DDoS detection, an active, 706 migrated QUIC connection may be blocked by such a system under 707 attack. However, a defense system might simply rely on the fast 708 resumption mechanism provided by QUIC. 710 4.5. QoS support and ECMP 712 [EDITOR'S NOTE: this is a bit speculative; keep?] 714 QUIC does not provide any additional information on requirements on 715 Quality of Service (QoS) provided from the network. QUIC assumes 716 that all packets with the same 5-tuple {dest addr, source addr, 717 protocol, dest port, source port} will receive similar network 718 treatment. That means all stream that are multiplexed over the same 719 QUIC connection require the same network treatment and are handled by 720 the same congestion controller. If differential network treatment is 721 desired, multiple QUIC connections to the same server might be used, 722 given that establishing a new connection using 0-RTT support is cheap 723 and fast. 725 QoS mechanisms in the network MAY also use the connection ID for 726 service differentiation, as a change of connection ID is bound to a 727 change of address which anyway is likely to lead to a re-route on a 728 different path with different network characteristics. 730 Given that QUIC is more tolerant of packet re-ordering than TCP (see 731 Section 2.7), Equal-cost multi-path routing (ECMP) does not 732 necessarily need to be flow based. However, 5-tuple (plus eventually 733 connection ID if present) matching is still beneficial for QoS given 734 all packets are handled by the same congestion controller. 736 5. IANA Considerations 738 This document has no actions for IANA. 740 6. Security Considerations 742 Supporting manageability of QUIC traffic inherently involves 743 tradeoffs with the confidentiality of QUIC's control information; 744 this entire document is therefore security-relevant. 746 7. Contributors 748 Dan Druta contributed text to Section 4.4. Igor Lubashev contributed 749 text to Section 4.3 on the use of the connection ID for load 750 balancing. Marcus Ilhar contributed text to Section 3.6 on the use 751 of the spin bit. 753 8. Acknowledgments 755 This work is partially supported by the European Commission under 756 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 757 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 758 for Education, Research, and Innovation under contract no. 15.0268. 759 This support does not imply endorsement. 761 9. References 763 9.1. Normative References 765 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 766 Requirement Levels", BCP 14, RFC 2119, 767 DOI 10.17487/RFC2119, March 1997, 768 . 770 9.2. Informative References 772 [Ding2015] 773 Ding, H. and M. Rabinovich, "TCP Stretch Acknowledgments 774 and Timestamps - Findings and Impliciations for Passive 775 RTT Measurement (ACM Computer Communication Review)", July 776 2015, . 779 [IPIM] Allman, M., Beverly, R., and B. Trammell, "In-Protocol 780 Internet Measurement (arXiv preprint 1612.02902)", 781 December 2016, . 783 [QUIC-APPLICABILITY] 784 Kuehlewind, M. and B. Trammell, "Applicability of the QUIC 785 Transport Protocol", draft-ietf-quic-applicability-02 786 (work in progress), July 2018. 788 [QUIC-HTTP] 789 Bishop, M., "Hypertext Transfer Protocol (HTTP) over 790 QUIC", draft-ietf-quic-http-15 (work in progress), October 791 2018. 793 [QUIC-INVARIANTS] 794 Thomson, M., "Version-Independent Properties of QUIC", 795 draft-ietf-quic-invariants-03 (work in progress), October 796 2018. 798 [QUIC-SPIN] 799 Trammell, B. and M. Kuehlewind, "The QUIC Latency Spin 800 Bit", draft-ietf-quic-spin-exp-00 (work in progress), 801 April 2018. 803 [QUIC-TLS] 804 Thomson, M. and S. Turner, "Using Transport Layer Security 805 (TLS) to Secure QUIC", draft-ietf-quic-tls-15 (work in 806 progress), October 2018. 808 [QUIC-TRANSPORT] 809 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 810 and Secure Transport", draft-ietf-quic-transport-15 (work 811 in progress), October 2018. 813 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 814 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 815 DOI 10.17487/RFC4737, November 2006, 816 . 818 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 819 Extensions: Extension Definitions", RFC 6066, 820 DOI 10.17487/RFC6066, January 2011, 821 . 823 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 824 "Increasing TCP's Initial Window", RFC 6928, 825 DOI 10.17487/RFC6928, April 2013, 826 . 828 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 829 "Specification of the IP Flow Information Export (IPFIX) 830 Protocol for the Exchange of Flow Information", STD 77, 831 RFC 7011, DOI 10.17487/RFC7011, September 2013, 832 . 834 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 835 "Transport Layer Security (TLS) Application-Layer Protocol 836 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 837 July 2014, . 839 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 840 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 841 August 2015, . 843 [TLS-ENCRYPT-SNI] 844 Huitema, C. and E. Rescorla, "Issues and Requirements for 845 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-03 846 (work in progress), May 2018. 848 [WIRE-IMAGE] 849 Trammell, B. and M. Kuehlewind, "The Wire Image of a 850 Network Protocol", draft-trammell-wire-image-04 (work in 851 progress), April 2018. 853 Authors' Addresses 855 Mirja Kuehlewind 856 ETH Zurich 857 Gloriastrasse 35 858 8092 Zurich 859 Switzerland 861 Email: mirja.kuehlewind@tik.ee.ethz.ch 863 Brian Trammell 864 ETH Zurich 865 Gloriastrasse 35 866 8092 Zurich 867 Switzerland 869 Email: ietf@trammell.ch