idnits 2.17.1 draft-kuehlewind-quic-appman-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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: All information in the QUIC header, even if exposed to the network, is integrity protected, therefore a device on the network path MUST not change these information. Altering of header information would fail any integrity check, leading to packet drop at the receiver. -- The document date (January 11, 2017) is 2634 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-00 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-00 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-00 == Outdated reference: A later version (-04) exists of draft-trammell-plus-statefulness-02 Summary: 0 errors (**), 0 flaws (~~), 7 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: July 15, 2017 January 11, 2017 7 Applicability and Management of the QUIC Transport Protocol 8 draft-kuehlewind-quic-appman-00 10 Abstract 12 This document discusses the applicability and manageability of the 13 QUIC transport protocol, focusing on caveats impacting application 14 protocol development and deployment over QUIC, and network operations 15 involving QUIC traffic. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 15, 2017. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Internet-DrafApplicability and Management of the QUIC Trans January 2017 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 55 2. Applicability of QUIC . . . . . . . . . . . . . . . . . . . . 3 56 2.1. The Necessity of TCP Fallback . . . . . . . . . . . . . . 3 57 2.2. Zero RTT: Here There Be Dragons . . . . . . . . . . . . . 4 58 2.3. Stream versus Flow Multiplexing . . . . . . . . . . . . . 4 59 3. Manageability of QUIC . . . . . . . . . . . . . . . . . . . . 4 60 3.1. QUIC Public Header Structure . . . . . . . . . . . . . . 5 61 3.2. Integrity Protection of the Wire Image . . . . . . . . . 6 62 3.3. Connection ID and Rebinding . . . . . . . . . . . . . . . 6 63 3.4. Packet Numbers . . . . . . . . . . . . . . . . . . . . . 6 64 3.5. Stateful Treatment of QUIC Traffic . . . . . . . . . . . 6 65 3.6. Measuring QUIC Traffic . . . . . . . . . . . . . . . . . 6 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 7.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 QUIC [I-D.ietf-quic-transport] is a new transport protocol currently 77 under development in the IETF quic working group, focusing on support 78 of semantics as needed for HTTP/2 [I-D.ietf-quic-http] such as 79 stream-multiplexing to avoid head-of-line blocking. Based on current 80 deployment practices, QUIC is encapsulated in UDP and encrypted by 81 default. This means the version of QUIC that is currently under 82 development will integrate TLS 1.3 [I-D.ietf-quic-tls] to encrypt all 83 payload data including all header information needed for for stream- 84 multiplexing and most on the other header information. Given QUIC is 85 an end-to-end transport protocol, all information in the protocol 86 header is not meant to be mutable by the network, and will therefore 87 be integrity- protected to the extent possible. 89 This document serves two purposes: 91 1. It provides guidance for application developers that want to use 92 the QUIC protocol without implementing it on their own. This 93 includes general guidance for application use of HTTP/2 over QUIC 94 as well as the use of other application layer protocols over 95 QUIC. For specific guidance on how to integrate HTTP/2 with 96 QUIC, see [I-D.ietf-quic-http]. 98 Internet-DrafApplicability and Management of the QUIC Trans January 2017 100 2. It provides guidance for network operation and management of QUIC 101 traffic. This includes guidance on how to interpret and utilize 102 information that is exposed by QUIC to the network as well as 103 explaining requirement and assumption that the QUIC protocol 104 design takes toward the expected network treatment. 106 1.1. Notational Conventions 108 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 109 document. It's not shouting; when they are capitalized, they have 110 the special meaning defined in [RFC2119]. 112 2. Applicability of QUIC 114 In the following subsections we discuss specific caveats to QUIC's 115 applicability, and issues that application developers must consider 116 when using QUIC as a transport for their application. 118 2.1. The Necessity of TCP Fallback 120 QUIC uses UDP as a substrate for userspace implementation and port 121 numbers for NAT and middlebox traversal. While there is no evidence 122 of widespread, systematic disadvantage of UDP traffic compared to TCP 123 in the Internet [Edeline16], somewhere between three [Trammell16] and 124 five [Swett16] percent of networks simply block UDP traffic. All 125 applications running on top of QUIC must therefore either be prepared 126 to accept connectivity failure on such networks, or be engineered to 127 fall back to TLS, or TLS-equivalent crypto, over TCP. These 128 applications must operate, perhaps with impaired functionality, in 129 the absence of features provided by QUIC not present in TLS over TCP: 130 The most obvious difference is that TCP does not stream multiplexing 131 and there stream multiplex would need to be implemented in the 132 application layer if needed. Further, TCP by default does not 133 support 0-RTT session resumption. TCP Fast Open can be used but 134 might no be supported by the far end or could be blocked on the 135 network path. Note that there is at least evidence of middleboxes 136 blocking SYN data even if TFO was successfully negotiated. Moreover, 137 while encryption (in this case TLS) is inseparable integrated with 138 QUIC, TLS negotiation over TCP can be blocked. In case it is 139 RECOMMENDED to abort the connection. 141 We hope that the deployment of a proposed standard version of the 142 QUIC protocol will provide an incentive for these networks to permit 143 QUIC traffic. Indeed, the ability to treat QUIC traffic statefully 144 as in Section 3.5 removes one network management incentive to block 145 this traffic. 147 Internet-DrafApplicability and Management of the QUIC Trans January 2017 149 2.2. Zero RTT: Here There Be Dragons 151 QUIC provides for 0-RTT connection establishment (see section 3.2 of 152 [I-D.ietf-quic-transport]). However, data in the frames contained in 153 the first packet of a such a connection must be treated specially by 154 the application layer. Since a retransmission of these frames 155 resulting from a lost acknowledgment may cause the data to appear 156 twice, either the application- layer protocol has to be designed such 157 that all such data is treated as idempotent, or there must be some 158 application-layer mechanism for recognizing spuriously retransmitted 159 frame and dropping them. 161 [EDITOR'S NOTE: discuss defenses against replay attacks using 0-RTT 162 data.] 164 2.3. Stream versus Flow Multiplexing 166 QUIC's stream multiplexing feature allows applications to run 167 multiple streams over a single connection, without head-of-line 168 blocking between streams, associated at a point in time with a single 169 five-tuple. Streams are meaningful only to the application; since 170 stream information is carried inside QUIC's encryption boundary, no 171 information about the stream(s) whose frames are carried by a given 172 packet is visible to the network. 174 Stream multiplexing is not intended to be used for differentiating 175 streams in terms of network treatment. Application traffic requiring 176 different network treatment should therefore be carried over 177 different five-tuples (i.e. multiple QUIC connections). Given 178 QUIC's ability to send application data on the first packet of a 179 connection (if a previous connection to the same host has been 180 successfully established to provide the respective credentials), the 181 cost for establishing another connection are extremely low. 183 [EDITOR'S NOTE: For discussion: If establishing a new connection does 184 not seem to be sufficient, the protocol's rebinding functionality 185 (see section 3.7 of [I-D.ietf-quic-transport]) could be extended to 186 allow multiple five-tuples to share a connection ID simultaneously, 187 instead of sequentially.] 189 3. Manageability of QUIC 191 This section discusses those aspects of the QUIC transport protocol 192 that have an impact on the design and operation of devices that 193 forward QUIC packets. This section is concerned primarily with 194 QUIC's unencrypted wire image, which we define as the information 195 available in the packet header in each QUIC packet, and the dynamics 196 of that information. 198 Internet-DrafApplicability and Management of the QUIC Trans January 2017 200 QUIC is a versioned protocol. Everything about the header format can 201 change except the mechanism by which a receiver can determine whether 202 and where a version number is present, and the meaning of the version 203 number field itself. 205 The rest of this document is concerned with the public header 206 structure of the version of the QUIC transport document that is 207 current as of this writing. 209 3.1. QUIC Public Header Structure 211 In the current version of the QUIC protocol, the following 212 information are optionally exposed in the QUIC header: 214 o flags: All QUIC packets have one byte of flags at the beginning of 215 their header. The definition of these flags can change with the 216 version of QUIC, expect for the version flag that indicated that 217 the version number is present in the QUIC header. Other bits of 218 the flag field in the current version of QUIC are the connection 219 ID flag, the packet number size field, the public reset flag, and 220 the key phase flag. 222 o version number: The version number is present if the version bit 223 in the flags field is set. The version flag is always set in the 224 first packet of a connection but could also be set in other 225 packets. 227 o connection ID: The connection ID is present if the connection ID 228 bit in the flag field is set. The connection ID flag is always 229 set on the first packet of a connection and can be set on others. 230 Further the connection ID flag is always set when the public reset 231 bit is set as well. QUIC connections are resistant to IP address 232 changes. Therefore if exposed, the same connection ID can occur 233 in QUIC packet with different 5-tuples, indicating that this QUIC 234 packet belongs to the same connection. 236 o packet number: The packet number is variable length as indicated 237 by packet number size field. If the length is indicated as zero 238 the packet number is not present. If the public reset flag is 239 set, the packet number cannot be present. 241 o diversification nonce [EDITOR'S NOTE: talk about this once it's 242 clear what it will be...] 244 Internet-DrafApplicability and Management of the QUIC Trans January 2017 246 3.2. Integrity Protection of the Wire Image 248 All information in the QUIC header, even if exposed to the network, 249 is integrity protected, therefore a device on the network path MUST 250 not change these information. Altering of header information would 251 fail any integrity check, leading to packet drop at the receiver. 253 3.3. Connection ID and Rebinding 255 A flow might change one of its IP addresses but keep the same 256 connection ID, as discussed in Section 3.1. [EDITOR'S NOTE: What 257 does that mean for the network, if anything (given the connection ID 258 is only rarely present)?] 260 3.4. Packet Numbers 262 Packet numbers are monotonically increasing. Packets containing 263 retransmissions as well as packets containing only control 264 information, such as acknowledgments, will get a new packet numbers. 265 Therefore pure control and retransmission packets are impossible to 266 distinguish on the wire. 268 While loss detection in QUIC is still based on packet numbers, 269 congestion control by default provides richer information than 270 vanilla TCP does. Especially, QUIC does not rely on duplicated ACKs, 271 making it more tolerant of packet re-ordering. 273 3.5. Stateful Treatment of QUIC Traffic 275 Stateful network devices such as firewalls use exposed header 276 information to support state setup and tear-down. In-line with 277 [I-D.trammell-plus-statefulness] (which provides a general model for 278 in- network state management), the presence of a Connection ID on 279 QUIC traffic can be used as an association/confirmation signal; 280 QUIC's public reset may be used as a partial one-way stop signal. 282 [EDITOR'S NOTE: note public reset changes for state management may be 283 desirable: two-way stop as in [I-D.trammell-plus-statefulness] has 284 nice properties.] 286 3.6. Measuring QUIC Traffic 288 Given packet numbers can be expected to be exposed on most packets 289 (expect public reset but that terminates the connection anyway), 290 packet numbers can be used by the network to measure loss that 291 occurred between the sender and the measurement point in the network. 292 Similarly, out-of-order packets indicate upstream reordering. Unlike 294 Internet-DrafApplicability and Management of the QUIC Trans January 2017 296 with TCP, there is no way to measure downstream loss and RTT 297 passively. 299 [EDITOR'S NOTE: the addition of a simple packet number echo would 300 allow passive RTT measurement and partial passive downstream loss/ 301 reordering measurement. Packet number echo can be sampled at the 302 echo-side (i.e. one-in-N packets or 1/p packets can carry an echo) 303 for efficiency tradeoff, if necessary.] 305 [EDITOR'S NOTE: in-network devices can inspect and correlate 306 connection IDs for partial tracking of mobility events.] 308 4. IANA Considerations 310 This document has no actions for IANA. 312 5. Security Considerations 314 Especially security- and privacy-relevant applicability and 315 manageability considerations are given in Section 2.2, Section 3.2, 316 and Section 3.3. 318 6. Acknowledgments 320 This work is partially supported by the European Commission under 321 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 322 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 323 for Education, Research, and Innovation under contract no. 15.0268. 324 This support does not imply endorsement. 326 7. References 328 7.1. Normative References 330 [I-D.ietf-quic-transport] 331 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 332 and Secure Transport", draft-ietf-quic-transport-00 (work 333 in progress), November 2016. 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, 337 DOI 10.17487/RFC2119, March 1997, 338 . 340 Internet-DrafApplicability and Management of the QUIC Trans January 2017 342 7.2. Informative References 344 [Edeline16] 345 Edeline, K., Kuehlewind, M., Trammell, B., Aben, E., and 346 B. Donnet, "Using UDP for Internet Transport Evolution 347 (arXiv preprint 1612.07816)", December 2016. 349 [I-D.ietf-quic-http] 350 Bishop, M., "Hypertext Transfer Protocol (HTTP) over 351 QUIC", draft-ietf-quic-http-00 (work in progress), 352 November 2016. 354 [I-D.ietf-quic-tls] 355 Thomson, M. and (. (Unknown), "Using Transport Layer 356 Security (TLS) to Secure QUIC", draft-ietf-quic-tls-00 357 (work in progress), November 2016. 359 [I-D.trammell-plus-statefulness] 360 Kuehlewind, M., Trammell, B., and J. Hildebrand, 361 "Transport-Independent Path Layer State Management", 362 draft-trammell-plus-statefulness-02 (work in progress), 363 December 2016. 365 [Swett16] Swett, I., "QUIC Deployment Experience at Google (IETF96 366 QUIC BoF presentation)", July 2016. 368 [Trammell16] 369 Trammell, B. and M. Kuehlewind, "Internet Path 370 Transparency Measurements using RIPE Atlas (RIPE72 MAT 371 presentation)", May 2016. 373 Authors' Addresses 375 Mirja Kuehlewind 376 ETH Zurich 377 Gloriastrasse 35 378 8092 Zurich 379 Switzerland 381 Email: mirja.kuehlewind@tik.ee.ethz.ch 383 Internet-DrafApplicability and Management of the QUIC Trans January 2017 385 Brian Trammell 386 ETH Zurich 387 Gloriastrasse 35 388 8092 Zurich 389 Switzerland 391 Email: ietf@trammell.ch