idnits 2.17.1 draft-ietf-quic-manageability-00.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 (July 03, 2017) is 2487 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-04 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-04 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-04 == Outdated reference: A later version (-04) exists of draft-trammell-plus-statefulness-03 Summary: 0 errors (**), 0 flaws (~~), 6 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: January 4, 2018 D. Druta 6 AT&T 7 July 03, 2017 9 Manageability of the QUIC Transport Protocol 10 draft-ietf-quic-manageability-00 12 Abstract 14 This document discusses manageability of the QUIC transport protocol, 15 focusing on caveats impacting network operations involving QUIC 16 traffic. Its intended audience is network operators, as well as 17 content providers that rely on the use of QUIC-aware middleboxes, 18 e.g. for load balancing. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 4, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 56 2. Features of the QUIC Wire Image . . . . . . . . . . . . . . . 3 57 2.1. QUIC Packet Header Structure . . . . . . . . . . . . . . 3 58 2.2. Integrity Protection of the Wire Image . . . . . . . . . 5 59 2.3. Connection ID and Rebinding . . . . . . . . . . . . . . . 5 60 2.4. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 5 61 2.5. Initial Handshake and PMTUD . . . . . . . . . . . . . . . 6 62 2.6. Version Negotiation and Greasing . . . . . . . . . . . . 6 63 3. Specific Network Management Tasks . . . . . . . . . . . . . . 6 64 3.1. Stateful Treatment of QUIC Traffic . . . . . . . . . . . 6 65 3.2. Measurement of QUIC Traffic . . . . . . . . . . . . . . . 7 66 3.3. DDoS Detection and Mitigation . . . . . . . . . . . . . . 8 67 3.4. QoS support and ECMP . . . . . . . . . . . . . . . . . . 8 68 3.5. Load Balancing using the Connection ID . . . . . . . . . 9 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 8.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 QUIC [QUIC] is a new transport protocol currently under development 81 in the IETF quic working group, focusing on support of semantics as 82 needed for HTTP/2 [QUIC-HTTP]. Based on current deployment 83 practices, QUIC is encapsulated in UDP and encrypted by default. The 84 current version of QUIC integrates TLS [QUIC-TLS] to encrypt all 85 payload data and most control information. Given QUIC is an end-to- 86 end transport protocol, all information in the protocol header, even 87 that which can be inspected, is is not meant to be mutable by the 88 network, and will therefore be integrity-protected to the extent 89 possible. 91 This document provides guidance for network operation on the 92 management of QUIC traffic. This includes guidance on how to 93 interpret and utilize information that is exposed by QUIC to the 94 network as well as explaining requirement and assumptions that the 95 QUIC protocol design takes toward the expected network treatment. It 96 also discusses how common network management practices will be 97 impacted by QUIC. 99 Of course, network management is not a one-size-fits-all endeavour: 100 practices considered necessary or even mandatory within enterprise 101 networks with certain compliance requirements, for example, would be 102 impermissible on other networks without those requirements. This 103 document therefore does not make any specific recommendations as to 104 which practices should or should not be applied; for each practice, 105 it describes what is and is not possible with the QUIC transport 106 protocol as defined. 108 QUIC is at the moment very much a moving target. This document 109 refers the state of the QUIC working group drafts as well as to 110 changes under discussion, via issues and pull requests in GitHub 111 current as of the time of writing. 113 1.1. Notational Conventions 115 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 116 document. It's not shouting; when these words are capitalized, they 117 have a special meaning as defined in [RFC2119]. 119 2. Features of the QUIC Wire Image 121 In this section, we discusses those aspects of the QUIC transport 122 protocol that have an impact on the design and operation of devices 123 that forward QUIC packets. Here, we are concerned primarily with 124 QUIC's unencrypted wire image, which we define as the information 125 available in the packet header in each QUIC packet, and the dynamics 126 of that information. Since QUIC is a versioned protocol, also the 127 wire image of the header format can change. However, at least the 128 mechanism by which a receiver can determine which version is used and 129 the meaning and location of fields used in the version negotiation 130 process need to be fixed. 132 This document is focused on the protocol as presently defined in 133 [QUIC] and [QUIC-TLS], and will change to track those documents. 135 2.1. QUIC Packet Header Structure 137 The QUIC packet header is under active development; see section 5 of 138 [QUIC] for the present header structure. 140 The first bit of the QUIC header indicates the present of a long 141 header that exposes more information than the short header. The long 142 header is typically used during connection start or for other control 143 processes while the short header will be used on most data packets to 144 limited unnecessary header overhead. The fields and location of 145 these fields as defined by the current version of QUIC for the long 146 header are fixed for all future version as well. However, note that 147 future versions of QUIC may provide additional fields. In the 148 current version of quic the long header for all header types has a 149 fixed length, containing, besides the Header Form bit, a 7-bit header 150 Type, a 64-bit Connection ID, a 32-bit Packet Number, and a 32-bit 151 Version. The short header is variable length where bits after the 152 Header Form bit indicate the present on the Connection ID, and the 153 length of the packet number. 155 The following information may be exposed in the packet header: 157 o header type: the long header has a 7-bit header type field 158 following the Header Form bit. The current version of QUIC 159 defines 7 header types, namely Version Negotiation, Client 160 Initial, Server Stateless Retry, Server Cleartext, Client 161 Cleartext, 0-RTT Protected, 1-RTT Protected (key phase 0), 1-RTT 162 Protected (key phase 1), and Public Reset. 164 o connection ID: The connection ID is always present on the long and 165 optionally present on the short header indicated by the Connection 166 ID Flag. If present at the short header it at the same position 167 then for the long header. The position and length pf the 168 congestion ID itself as well as the Connection ID flag in the 169 short header is fixed for all versions of QUIC. The connection ID 170 identifies the connection associated with a QUIC packet, for load- 171 balancing and NAT rebinding purposes; see Section 3.5 and 172 Section 2.3. Therefore it is also expected that the Connection ID 173 will either be present on all packets of a flow or none of the 174 short header packets. However, this field is under endpoint 175 control and there is protocol mechanism that hinders the sending 176 endpoint to revise its decision about exposing the Connection ID 177 at any time during the connection. 179 o packet number: Every packet has an associated packet number. The 180 packet number increases with each packet, and the least- 181 significant bits of the packet number are present on each packet. 182 In the short header the length of the exposed packet number field 183 is defined by the (short) header type and can either be 8, 16, or 184 32 bits. See Section 2.4. 186 o version number: The version number is present on the long headers 187 and identifies the version used for that packet, expect for the 188 Version negotiation packet. The version negotiation packet is 189 fixed for all version of QUIC and contains a lit of versions that 190 is supported by the sender. However the version in the version 191 field of the header is the reflected version of the clients 192 initial packet and is therefore explicitly not supported by the 193 sender. 195 o key phase: The short header further has a Key Phase flag that is 196 used by the endpoint identify the right key that was used to 197 encrypt the packet. Different key phases are indicated with the 198 use of the long header by using to different header types for 199 protected long header packets. 201 2.2. Integrity Protection of the Wire Image 203 As soon as the cryptographic context is established, all information 204 in the QUIC header, including those exposed in the packet header, is 205 integrity protected. Further, information that were sent and exposed 206 in previous packets when the cryptographic context was established 207 yet, e.g. for the cryptographic initial handshake itself, will be 208 validate later during the cryptographic handshake, such as the 209 version number. Therefore, devices on path MUST NOT change any 210 information or bits in QUIC packet headers. As alteration of header 211 information would cause packet drop due to a failed integrity check 212 at the receiver, or can even lead to connection termination. 214 2.3. Connection ID and Rebinding 216 The connection ID in the QUIC packer header is used to allow routing 217 of QUIC packets at load balancers on other than five-tuple 218 information, ensuring that related flows are appropriately balanced 219 together; and to allow rebinding of a connection after one of the 220 endpoint's addresses changes - usually the client's, in the case of 221 the HTTP binding. The connection ID is proposed by the server during 222 connection establishment, and a server might provide additional 223 connection IDs that can the used by the client at any time during the 224 connection. Therefore if a flow changes one of its IP addresses it 225 may keep the same connection ID, or the connection ID may also change 226 together with the IP address migration, avoiding linkability; see 227 Section 7.6 of [QUIC]. 229 2.4. Packet Numbers 231 The packet number field is always present in the QUIC packet header. 232 The packet number exposes the least significant 32, 16, or 8 bits of 233 an internal packet counter per flow direction that increments with 234 each packet sent. This packet counter is initialized with a random 235 31-bit initial value at the start of a connection. 237 Unlike TCP sequence numbers, this packet number increases with every 238 packet, including those containing only acknowledgment or other 239 control information. Indeed, whether a packet contains user data or 240 only control information is intentionally left unexposed to the 241 network. The packet number increases with every packet but they 242 sender may skip packet numbers. 244 While loss detection in QUIC is based on packet numbers, congestion 245 control by default provides richer information than vanilla TCP does. 246 Especially, QUIC does not rely on duplicated ACKs, making it more 247 tolerant of packet re-ordering. 249 2.5. Initial Handshake and PMTUD 251 [Editor's note: text needed.] 253 2.6. Version Negotiation and Greasing 255 Version negotiation is not protected, given the used protection 256 mechanism can change with the version. However, the choices provided 257 in the list of version in the Version Negotiation packet will be 258 validated as soon as the cryptographic context has been established. 259 Therefore any manipulation of this list will be detected and will 260 cause the endpoints to terminate the connection. 262 Also note that the list of versions in the Version Negotiation packet 263 may contain reserved versions. This mechanism is used to avoid 264 ossification in the implementation on the selection mechanism. 265 Further, a client may send a Initial Client packet with a reserved 266 version number to trigger version negotiation. In the Version 267 Negotiation packet the connection ID and packet number of the Client 268 Initial packet are reflected to provide a proof of return- 269 routability. Therefore changing these information will also cause 270 the connection to fail. 272 3. Specific Network Management Tasks 274 In this section, we address specific network management and 275 measurement techniques and how QUIC's design impacts them. 277 3.1. Stateful Treatment of QUIC Traffic 279 Stateful network devices such as firewalls use exposed header 280 information to support state setup and tear-down. [STATEFULNESS] 281 provides a general model for in-network state management on these 282 devices, independent of transport protocol. Features already present 283 in QUIC may be used for state maintenance in this model. Here, there 284 are two important goals: distinguishing valid QUIC connection 285 establishment from other traffic, in order to establish state; and 286 determining the end of a QUIC connection, in order to tear that state 287 down. 289 Both, 1-RTT and O-RTT connection establishment, using a TLS handshake 290 on stream 0, is detectable using heuristics similar to those used to 291 detect TLS over TCP. 0-RTT connection may additional also send data 292 packets, right after the client hello. These data may be reorder in 293 the network, therefore it may be possible that 0-RTT Protected data 294 packet are seen before the Client Initial packet. 296 Exposure of connection shutdown is currently under discussion; see 297 https://github.com/quicwg/base-drafts/issues/353 and 298 https://github.com/quicwg/base-drafts/pull/20. 300 3.2. Measurement of QUIC Traffic 302 Passive measurement of TCP performance parameters is commonly 303 deployed in access and enterprise networks to aid troubleshooting and 304 performance monitoring without requiring the generation of active 305 measurement traffic. 307 The presence of packet numbers on all QUIC packets allows the trivial 308 one-sided estimation of packet loss and reordering between the sender 309 and a given observation point. However, since retransmissions are 310 not identifiable as such, loss between an observation point and the 311 receiver cannot be reliably estimated. 313 The lack of any acknowledgement information or timestamping 314 information in the QUIC packet header makes running passive 315 estimation of latency via round trip time (RTT) impossible. RTT can 316 only be measured at connection establishment time, by observing the 317 Client Initial packet and the Server's reply to this packet which 318 maybe a Server Cleartext, Version Negotiation, or Server Stateless 319 Retry packet. 321 Note that adding a packet number echo (as in 322 https://github.com/quicwg/base-drafts/pull/367 or 323 https://github.com/quicwg/base-drafts/pull/368) to the public header 324 would allow passive RTT measurement at on-path observation points. 325 For efficiency purposes, this packet number echo need not be carried 326 on every packet, and could be made optional, allowing endpoints to 327 make a measurability/efficiency tradeoff; see section 4 of [IPIM]. 328 Note further that this facility would have significantly better 329 measurability characteristics than sequence-acknowledgement-based RTT 330 measurement currently available in TCP on typical asymmetric flows, 331 as adequate samples will be available in both directions, and packet 332 number echo would be decoupled from the underlying acknowledgment 333 machinery; see e.g. [Ding2015] 335 Note in-network devices can inspect and correlate connection IDs for 336 partial tracking of mobility events. 338 3.3. DDoS Detection and Mitigation 340 For enterprises and network operators one of the biggest management 341 challenges is dealing with Distributed Denial of Service (DDoS) 342 attacks. Some network operators offer Security as a Service (SaaS) 343 solutions that detect attacks by monitoring, analyzing and filtering 344 traffic. These approaches generally utilize network flow data 345 [RFC7011]. If any flows pose a threat, usually they are routed to a 346 "scrubbing environment" where the traffic is filtered, allowing the 347 remaining "good" traffic to continue to the customer environment. 349 This type of DDoS mitigation is fundamentally based on tracking state 350 for flows (see Section 3.1) that have receiver confirmation and a 351 proof of return-routability, and classifying flows as legitimate or 352 DoS traffic. The QUIC packet header currently does not support an 353 explicit mechanism to easily distinguish legitimate QUIC traffic from 354 other UDP traffic. However, the first packet in a QUIC connection 355 will usually be a Client Initial packet. This can be used to 356 identify the first packet of the connection. 358 If the QUIC handshake was not observed by the defense system, the 359 connection ID can be used as a confirmation signal as per 360 [STATEFULNESS] if present in both directions. 362 Further, the use of a connection ID to support connection migration 363 renders 5-tuple based filtering insufficient, and requires more state 364 to be maintained by DDoS defense systems. However, it is 365 questionable if connection migrations needs to be supported in a DDOS 366 attack. If the connection migration is not visible to the network 367 that performs the DDoS detection, an active, migrated QUIC connection 368 may be blocked by such a system under attack. However, a defense 369 system might simply rely on the fast resumption mechanism provided by 370 QUIC. This problem is also related to these issues under discussion: 371 https://github.com/quicwg/base-drafts/issues/203 373 3.4. QoS support and ECMP 375 QUIC does not provide any additional information on requirements on 376 Quality of Service (QoS) provided from the network. QUIC assumes 377 that all packets with the same 5-tuple {dest addr, source addr, 378 protocol, dest port, source port} will receive similar network 379 treatment. That means all stream that are multiplexed over the same 380 QUIC connection require the same network treatment and are handled by 381 the same congestion controller. If differential network treatment is 382 desired, multiple QUIC connection to the same server might be used, 383 given that establishing a new connection using 0-RTT support is cheap 384 and fast. 386 QoS mechanisms in the network MAY also use the connection ID for 387 service differentiation as usually a change of connection ID is bind 388 to a change of address which anyway is likely to lead to a re-route 389 on a different path with different network characteristics. 391 Given that QUIC is more tolerant of packet re-ordering than TCP (see 392 Section 2.4), Equal-cost multi-path routing (ECMP) does not 393 necessarily need to be flow based. However, 5-tuple (plus eventually 394 connection ID if present) matching is still beneficial for QoS given 395 all packets are handled by the same congestion controller. 397 3.5. Load Balancing using the Connection ID 399 The Connection ID is used in part to support load balancing in 400 content distribution networks (CDNs), which operate complex, 401 geographically distributed pools of back-end servers, fronted by load 402 balancing systems. These load balancers are responsible for 403 identifying the most appropriate server for each connection and for 404 routing all packets belonging to that connection to the chosen 405 server. 407 Load balancers are often deployed in pools for redundancy and load 408 sharing. For high availability, it is important that when packets 409 belonging to a flow start to arrive at a different load balancer in 410 the load balancer pool, the packets continue to be forwarded to the 411 original server in the server pool. 413 Support for seamless connection migration is an important design goal 414 of QUIC - a necessity due to the proliferation of mobile connected 415 devices. This connection persistence provides an additional 416 challenge for multi-homed anycast-based services often employed by 417 large content owners and CDNs. The challenge is that a migration to 418 a different network in the middle of the connection greatly increases 419 the chances of the packets routed to a different anycast point of 420 presence (POP) due to the new network's different connectivity and 421 Internet peering arrangements. The load balancer in the new POP, 422 potentially thousands of miles away, will not have information about 423 the established flow and would not be able to route it back to the 424 original POP. 426 Load balancers may cooperate with servers or server pools behind them 427 to use a server-generated Connection ID value, in order to support 428 stateless load balancing, even across NAT rebinding or other address 429 change events (see Section 2.3). See section 5.7 of [QUIC]. 431 Server-generated Connection IDs must not encode any information other 432 that that needed to route packets to the appropriate backend 433 server(s): typically the identity of the backend server or pool of 434 servers, if the data-center's load balancing system keeps "local" 435 state of all flows itself. Care must be exercised to ensure that the 436 information encoded in the Connection ID is not sufficient to 437 identify unique end users. Note that by encoding routing information 438 in the Connection ID, load balancers open up a new attack vector that 439 allows bad actors to direct traffic at a specific backend server or 440 pool. It is therefore recommended that Server-Generated Connection 441 ID includes a cryptographic MAC that the load balancer pool server 442 are able to identify and discard packets featuring an invalid MAC. 444 4. IANA Considerations 446 This document has no actions for IANA. 448 5. Security Considerations 450 Supporting manageability of QUIC traffic inherently involves 451 tradeoffs with the confidentiality of QUIC's control information; 452 this entire document is therefore security-relevant. 454 Some of the properties of the QUIC header used in network management 455 are irrelevant to application-layer protocol operation and/or user 456 privacy. For example, packet number exposure (and echo, as proposed 457 in this document), as well as connection establishment exposure for 458 1-RTT establishment, make no additional information about user 459 traffic available to devices on path. 461 At the other extreme, supporting current traffic classification 462 methods that operate through the deep packet inspection (DPI) of 463 application-layer headers are directly antithetical to QUIC's goal to 464 provide confidentiality to its application-layer protocol(s); in 465 these cases, alternatives must be found. 467 6. Contributors 469 Igor Lubashev contributed text to Section 3.5 on the use of the 470 connection ID for load balancing. 472 7. Acknowledgments 474 This work is partially supported by the European Commission under 475 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 476 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 477 for Education, Research, and Innovation under contract no. 15.0268. 478 This support does not imply endorsement. 480 8. References 482 8.1. Normative References 484 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 485 and Secure Transport", draft-ietf-quic-transport-04 (work 486 in progress), June 2017. 488 [QUIC-HTTP] 489 Bishop, M., "Hypertext Transfer Protocol (HTTP) over 490 QUIC", draft-ietf-quic-http-04 (work in progress), June 491 2017. 493 [QUIC-TLS] 494 Thomson, M. and S. Turner, "Using Transport Layer Security 495 (TLS) to Secure QUIC", draft-ietf-quic-tls-04 (work in 496 progress), June 2017. 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, 500 DOI 10.17487/RFC2119, March 1997, 501 . 503 8.2. Informative References 505 [Ding2015] 506 Ding, H. and M. Rabinovich, "TCP Stretch Acknowledgments 507 and Timestamps - Findings and Impliciations for Passive 508 RTT Measurement (ACM Computer Communication Review)", July 509 2015, . 512 [IPIM] Allman, M., Beverly, R., and B. Trammell, "In-Protocol 513 Internet Measurement (arXiv preprint 1612.02902)", 514 December 2016, . 516 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 517 "Specification of the IP Flow Information Export (IPFIX) 518 Protocol for the Exchange of Flow Information", STD 77, 519 RFC 7011, DOI 10.17487/RFC7011, September 2013, 520 . 522 [STATEFULNESS] 523 Kuehlewind, M., Trammell, B., and J. Hildebrand, 524 "Transport-Independent Path Layer State Management", 525 draft-trammell-plus-statefulness-03 (work in progress), 526 March 2017. 528 Authors' Addresses 530 Mirja Kuehlewind 531 ETH Zurich 532 Gloriastrasse 35 533 8092 Zurich 534 Switzerland 536 Email: mirja.kuehlewind@tik.ee.ethz.ch 538 Brian Trammell 539 ETH Zurich 540 Gloriastrasse 35 541 8092 Zurich 542 Switzerland 544 Email: ietf@trammell.ch 546 Dan Druta 547 AT&T 549 Email: dd5826@att.com