idnits 2.17.1 draft-deconinck-quic-multipath-02.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 (March 7, 2019) is 1875 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Cellnet' is defined on line 1277, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-quic-invariants-03 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-18 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-18 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-18 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC Working Group Q. De Coninck 3 Internet-Draft O. Bonaventure 4 Intended status: Standards Track UCLouvain 5 Expires: September 8, 2019 March 7, 2019 7 Multipath Extensions for QUIC (MP-QUIC) 8 draft-deconinck-quic-multipath-02 10 Abstract 12 This document specifies extensions to the QUIC protocol to enable, 13 other than connection migration, simultaneous usage of multiple paths 14 for a single connection. Those extensions remain compliant with the 15 current single-path QUIC design. They allow devices to benefit from 16 multiple network paths while preserving the privacy features of QUIC. 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 September 8, 2019. 35 Copyright Notice 37 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 54 2.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 55 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. What is a Path? . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. Beyond Connection Migration . . . . . . . . . . . . . . . 5 58 3.3. Establishment of a Multipath QUIC Connection . . . . . . 6 59 3.4. Architecture of Multipath QUIC . . . . . . . . . . . . . 7 60 3.5. Path Establishment . . . . . . . . . . . . . . . . . . . 8 61 3.6. Exchanging Data over Multiple Paths . . . . . . . . . . . 9 62 3.7. Exchanging Addresses . . . . . . . . . . . . . . . . . . 10 63 3.8. Coping with Address Removals . . . . . . . . . . . . . . 11 64 3.9. Path Migration . . . . . . . . . . . . . . . . . . . . . 11 65 3.10. Sharing Path Policies . . . . . . . . . . . . . . . . . . 12 66 3.11. Congestion Control . . . . . . . . . . . . . . . . . . . 12 67 4. Mapping Path ID to Connection IDs . . . . . . . . . . . . . . 13 68 5. Using Multiple Paths . . . . . . . . . . . . . . . . . . . . 13 69 5.1. Multipath Negotiation . . . . . . . . . . . . . . . . . . 13 70 5.1.1. Transport Parameter Definition . . . . . . . . . . . 14 71 5.2. Coping with Additional Remote Addresses . . . . . . . . . 14 72 5.3. Path State . . . . . . . . . . . . . . . . . . . . . . . 14 73 5.4. Dynamic Management of Paths . . . . . . . . . . . . . . . 17 74 5.5. Losing Addresses . . . . . . . . . . . . . . . . . . . . 17 75 5.6. Scheduling Strategies . . . . . . . . . . . . . . . . . . 18 76 6. Modifications to QUIC frames . . . . . . . . . . . . . . . . 18 77 6.1. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 19 78 6.2. RETIRE_CONNECTION_ID Frame . . . . . . . . . . . . . . . 20 79 6.3. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 20 80 7. New Frames . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 7.1. MAX_PATHS Frame . . . . . . . . . . . . . . . . . . . . . 21 82 7.2. PATH_UPDATE Frame . . . . . . . . . . . . . . . . . . . . 22 83 7.3. ADD_ADDRESS Frame . . . . . . . . . . . . . . . . . . . . 23 84 7.4. REMOVE_ADDRESS Frame . . . . . . . . . . . . . . . . . . 24 85 7.5. PATHS Frame . . . . . . . . . . . . . . . . . . . . . . . 24 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 87 8.1. Nonce Computation . . . . . . . . . . . . . . . . . . . . 26 88 8.2. Validation of Exchanged Addresses . . . . . . . . . . . . 26 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 90 9.1. QUIC Transport Parameter Registry . . . . . . . . . . . . 27 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 27 94 11.2. Informative References . . . . . . . . . . . . . . . . . 28 95 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29 96 A.1. Since draft-deconinck-quic-multipath-01 . . . . . . . . . 29 97 A.2. Since draft-deconinck-quic-multipath-00 . . . . . . . . . 29 98 A.3. Since draft-deconinck-multipath-quic-00 . . . . . . . . . 30 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 101 1. Introduction 103 Endhosts have evolved. Today's endhosts are equipped with several 104 network interfaces and users expect to be able to seamlessly switch 105 from one to another or use them simultaneously to aggregate or grab 106 bandwidth whenever needed. During the last years, several multipath 107 extensions to transport protocols have been proposed 108 [RFC6824],[MPRTP], [SCTPCMT]. Multipath TCP [RFC6824] is the most 109 mature one. It is already deployed on popular smartphones, but also 110 for other use cases [RFC8041]. 112 With regular TCP and UDP, all the packets that belong to a given flow 113 share the same 5-tuple that acts as an identifier for this flow. 114 Such characterization prevents these flows from using multiple paths. 115 QUIC [I-D.ietf-quic-transport] does not use the 5-tuple as an 116 implicit connection identifier. A QUIC flow is identified by two 117 Connection IDs (Source and Destination). This enables QUIC flows to 118 cope with events affecting the 5-tuple, such as NAT rebinding or IP 119 address changes. The QUIC connection migration feature, described in 120 more details in [I-D.ietf-quic-transport], is key to migrate a flow 121 from one 5-tuple to another one. This migration feature offers the 122 opportunity for QUIC to sustain a connection over multiple paths, but 123 still there is a void to specify simultaneous usage of available 124 paths for a single connection. Use cases such as bandwidth 125 aggregation or seamless network handovers would be applicable to 126 QUIC, as they are now with Multipath TCP. An early performance 127 evaluation of such use cases and a comparison between Multipath QUIC 128 and Multipath TCP may be found in [MPQUIC]. 130 In this document, we leverage many of the lessons learned from the 131 design of Multipath TCP and the comments received on the first 132 versions of this draft to propose extensions to the current QUIC 133 design to enable it to simultaneously use several paths. This 134 document focuses mainly on paths that are locally visible to an 135 endpoint. This document is organized as follows. It first provides 136 in Section 3 an overview of the operation of Multipath QUIC. It then 137 states changes required in the current QUIC design 138 [I-D.ietf-quic-transport] and specifies in Section 5 the usage of 139 multiple paths. Finally, it discusses some security considerations. 141 2. Conventions and Definitions 143 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 144 document. It's not shouting; when they are capitalized, they have 145 the special meaning defined in [RFC2119]. 147 We assume that the reader is familiar with the terminology used in 148 [I-D.ietf-quic-transport]. In addition, we define the following 149 terms: 151 o Path: A logical association within a QUIC connection between two 152 hosts over which packets can be sent. It is typically 153 characterized by (Source IP Address, Source Port Number, 154 Destination IP Address, Destination Port Number). A path is 155 internally identified by endpoints using a Path ID and uses a 156 potentially changing Connection ID identifying the parent 157 connection in packets exchanged on that path. 159 o Initial Path: The path used for the establishment of the QUIC 160 connection. The cryptographic handshake is done on this path. It 161 is identified by Path ID 0. 163 2.1. Notational Conventions 165 Packet and frame diagrams use the format described in Section 2.1 of 166 [I-D.ietf-quic-transport]. 168 3. Overview 170 The current design of QUIC [I-D.ietf-quic-transport] provides 171 reliable transport with multiplexing and security. A wide range of 172 devices on today's Internet are multihomed. Examples include 173 smartphones equipped with both WLAN and cellular interfaces, but also 174 regular dual-stack hosts that use both IPv4 and IPv6. Experience 175 with Multipath TCP has shown that the ability to combine different 176 paths during the lifetime of a connection provides various benefits 177 including bandwidth aggregation or seamless handovers 178 [RFC8041],[IETFJ]. 180 The current design of QUIC does not enable multihomed devices to 181 efficiently use different paths simultaneously. We first explain why 182 a multipath extension would be beneficial to QUIC and then describe 183 it at a high level. 185 3.1. What is a Path? 187 Before going into details, let us first define what is called a 188 "path". A path is a UDP flow between two hosts denoted by a 4-tuple 189 (source IP address, destination IP address, source port, destination 190 port). Considering a smartphone interacting with a single-homed 191 server, the smartphone might want to use one path over the WLAN 192 network and another over the cellular one. Those paths are not 193 necessarily disjoint. For example, when interacting with a dual- 194 stack server, a smartphone may create two paths over the Wi-Fi 195 network, one over IPv4 and the other over IPv6. 197 3.2. Beyond Connection Migration 199 Unlike TCP [RFC0793], QUIC is not bound to a particular 4-tuple 200 during the lifetime of a connection. A QUIC connection is identified 201 by a Connection ID, placed in the public header of each QUIC packet. 202 This enables hosts to continue the connection even if the 4-tuple 203 changes due to, e.g., NAT rebinding. This ability to shift a 204 connection from one 4-tuple to another is called Connection 205 Migration. One of its use cases is fail-over when the IP address in 206 use fails but another one is available. A device losing the WLAN 207 connectivity can then continue the connection over its cellular 208 interface, for instance. 210 A QUIC connection can thus start on a given path, denoted as the 211 initial path, and end on another one. However, the current QUIC 212 design [I-D.ietf-quic-transport] assumes that only one path is in use 213 for a given connection. The specification does not support means to 214 distinguish path migration from simultaneous usage of available paths 215 for a given connection. 217 This document fills that void. Concretely, instead of switching the 218 4-tuple for the whole connection, this draft first proposes 219 mechanisms to communicate endhost addresses to the peer. It then 220 leverages the address validation process with the PATH_CHALLENGE and 221 PATH_RESPONSE frames proposed in [I-D.ietf-quic-transport] to verify 222 if additional addresses advertised by the communicating host are 223 available and actually belong to it. In this case, those addresses 224 can be used to create new paths to spread packets over several 225 networks following a traffic distribution policy that is out of scope 226 of this document. 228 When multiple paths are available, different delays may be 229 experienced as a function of the initial path selected for the 230 establishment of the QUIC connection. The first version of the 231 specification does not discuss considerations related to the 232 selection of the initial path to place the connection. 234 The example of Figure 1 shows a possible data exchange between a 235 dual-homed client performing a request fitting in two packets and a 236 single-homed server. 238 Server Phone Server 239 via WLAN via LTE 240 ------- ------- ----- 241 | Pkt(DCID=B,PN=1,frames=[ | | 242 | STREAM("Request (1/2)")]) | Pkt(DCID=D,PN=1,frames=[ | 243 |<-------------------------------| STREAM("Request (2/2)")]) | 244 | Pkt(DCID=A,PN=1,frames=[ |-------- | 245 | ACK(PID=1,LargestAcked=1)]) | |---------- | 246 |------------------------------->| |---------- | 247 | Pkt(DCID=B,PN=2,frames=[ | |--->| 248 | STREAM("Response 1")]) | Pkt(DCID=C,PN=1,frames=[ | 249 |------------------------------->| ACK(PID=2,LargestAcked=1), | 250 | | STREAM("Response 2")]) -----| 251 | Pkt(DCID=A,PN=2,frames=[ | ----------| | 252 | ACK(PID=1, LargestAcked=2), | ----------| | 253 | ACK(PID=2, LargestAcked=1)]) |<------| | 254 |<-------------------------------| | 255 | Pkt(DCID=B,PN=3,frames=[ | Pkt(DCID=D,PN=2,frames=[ | 256 | STREAM("Response 3")]) | STREAM("Response 4")]) | 257 |------------------------------->| ----| 258 | | ---------| | 259 | ... | ... <---------| | 261 Figure 1: Dataflow with Multipath QUIC 263 The remaining of this section focuses on providing a high-level 264 overview of the multipath operations in QUIC. 266 3.3. Establishment of a Multipath QUIC Connection 268 A Multipath QUIC connection starts like a regular QUIC connection. A 269 cryptographic handshake takes place with CRYPTO frames and follows 270 the classical process [I-D.ietf-quic-transport] [I-D.ietf-quic-tls]. 271 It is during that process that the multipath capability is negotiated 272 between hosts. This is performed using the max_paths transport 273 parameter, where both hosts advertise their support for the multipath 274 extension, by indicating how many paths can be simultaneously in use. 275 Any value different from 0 indicates that the host wants to support 276 multipath over the connection. If one of the hosts does not 277 advertise the max_paths transport parameter, the negotiated value is 278 0, meaning that the QUIC connection will not use the multipath 279 extensions presented in this document. 281 The handshake is performed on a given path. This path is called the 282 Initial path and is identified by Path ID 0. 284 Because attaching to new networks may be volatile and an endpoint 285 does not have full visibility on multiple paths that may be available 286 (e.g., hosts connected to a CPE), an MP-QUIC capable endhost SHOULD 287 set max_paths to at least 4. 289 3.4. Architecture of Multipath QUIC 291 Once established, a Multipath QUIC connection is composed of one or 292 more paths. Each path is associated with a different four-tuple and 293 identified by a Path ID, as shown in Figure 2. 295 +-----------------------------------------------+ 296 | Connection (MSCID, MDCID) | 297 | +---------+ +---------+ ... +------------+ | 298 | | Path 0 | | Path 1 | | Path N - 1 | | 299 | | Tuple | | Tuple' | ... | Tuple" | | 300 | | PSCID | | PSCID' | | PSCID" | | 301 | | PDCID | | PDCID' | ... | PDCID" | | 302 | | PN | | PN' | | PN" | | 303 | +---------+ +---------+ ... +------------+ | 304 +-----------------------------------------------+ 306 Figure 2: Architectural view of Multipath QUIC 308 As described before, a Multipath QUIC connection starts on the 309 Initial Path, identified by Path ID 0. For Multipath QUIC, this 310 document proposes two levels of asymmetric Connection IDs. The first 311 ones are the Main (or Primary) Connection IDs (MCIDs). Both the Main 312 Source Connection ID (MSCID) and the Main Destination Connection ID 313 (MDCID) uniquely identify the connection, as with the current QUIC 314 design. The second ones are the Path Connection IDs (PCIDs). 315 Packets belonging to a given path share the same Path Source 316 Connection ID (PSCID) and Path Destination Connection ID (PDCID) 317 written in the Connection ID field of the public header. The PCIDs 318 act as the path identifiers for packets. Preventing the linkability 319 of different paths is an important requirement for the multipath 320 extension [I-D.huitema-quic-mpath-req]. Using PCIDs as implicit path 321 identifier makes this linkability harder than having explicit 322 signaling as in the early version of this draft and does not require 323 public header change to keep invariants [I-D.ietf-quic-invariants]. 324 The MCIDs of a connection will be the PCIDs of the Initial Path. In 325 the example of Figure 1, if the connection started using WLAN, then 326 the Source Connection ID A is both the PSCID of the WLAN path and the 327 MSCID of the connection. 329 In addition to the PCIDs, some additional information is kept for 330 each path. The Path ID identifies the path at the frame level and 331 ensures uniqueness of the nonce (see Section 8.1 for details). A 332 congestion window is maintained for each path. Hosts can also 333 collect network measurements on a per-path basis, such as round-trip- 334 time measurements and lost packets. 336 3.5. Path Establishment 338 The max_paths transport parameter exchanged during the cryptographic 339 handshake determines how many paths can be simultaneously used. The 340 lowest advertised value is the negotiated one. Then, hosts must 341 agree on which paths can be used, and with which Path Connection IDs. 342 Unlike Multipath TCP [RFC6824], both hosts dynamically control how 343 many paths can currently be in use, i.e., the handshake only defines 344 the initial value. This can be done using a new MAX_PATHS frame 345 indicating how many paths can be simultaneously in use. MAX_PATHS 346 frames can be exchanged during the lifetime of a connection. 348 Hosts propose new paths with an extended version of the 349 NEW_CONNECTION_ID frame (see Section 6.1). This frame proposes a 350 PDCID for a given path. Once both hosts proposed a PDCID to their 351 peer and received the acknowledgment for the related 352 NEW_CONNECTION_ID, the Path ID can be used to send packets. Both 353 hosts store the NEW_CONNECTION_ID information in order to cope with 354 the remote trying to use a new path. As frames are encrypted, adding 355 new paths does not leak cleartext identifiers 356 [I-D.huitema-quic-mpath-req]. 358 A server might provide more Path IDs with NEW_CONNECTION_ID frames 359 than the value advertised in the MAX_PATHS frame. This can be useful 360 to cope with migration cases, as described in Section 3.9. In such 361 cases, hosts can only use a subset of the proposed Path IDs. 362 Multipath QUIC is fully symmetrical. Both the client and the server 363 can start using new paths once their corresponding PCIDs have been 364 negotiated. It might happen that both hosts try to create paths with 365 different Path IDs, such that there are more paths than the 366 advertised number in MAX_PATHS frame. In that case, the paths with 367 the lowest Path IDs will be used while the others will stop. 369 Hosts are not able to create new paths as long as the peer does not 370 send NEW_CONNECTION_ID and MAX_PATHS frames. To limit the latency of 371 the path handshake, hosts should send those frames as soon as 372 possible, i.e., just after the 0-RTT handshake packet. 374 Although a path can be first used by any host, it might not be 375 practical for one of the peers to send an initial packet on new 376 paths. A possible cause is when a server wants to initiate a new 377 path to a client behind a NAT. The client would possibly never 378 receive this packet, leading to connectivity issues on that path. To 379 avoid such issues, a remote address MUST have been validated as 380 described in [I-D.ietf-quic-transport] before sending packets on a 381 path using it. A host MUST be prepared to receive packets on paths 382 it advertised. Peers MUST NOT require to first receive data from the 383 peer which advertised a path to make use of an available path. 385 3.6. Exchanging Data over Multiple Paths 387 A QUIC packet acts as a container for one of more frames. Multipath 388 QUIC uses the same STREAM frames as QUIC to carry data. A byte 389 offset is associated to the data payload. One of the key design 390 decision of (Multipath) QUIC is that frames are independent of the 391 packets carrying them. This implies that a frame transmitted over 392 one path could be retransmitted later on another path without any 393 change. 395 The path on which data is sent is a packet-level information. This 396 means a frame can be sent regardless of the path of the packet 397 carrying it. Furthermore, because the data offset is a frame-level 398 information, there is no need to define additional sequence numbers 399 to cope with reordering across paths, unlike Multipath TCP [RFC6824] 400 that uses a Data Sequence Number at the MPTCP level. Other flow 401 control considerations like the stream receive window advertised by 402 the MAX_STREAM_DATA frame remain unchanged when there are multiple 403 paths. 405 However, Multipath QUIC might face reordering at packet-level when 406 using paths having different latencies. The presence of different 407 Path Connection IDs ensures that the packets sent over a given path 408 will contain monotonically increasing packet numbers. To ensure more 409 flexibility and potentially to reduce the ACK block section of the 410 ACK frame when aggregating bandwidth of paths exhibiting different 411 network characteristics, each path keeps its own monotonically 412 increasing Packet Number space. This potentially allows sending up 413 to 2^62 * 2^62 packets on a QUIC connection since each path has its 414 own packet number space. 416 The ACK frame is also modified to allow per-path packet 417 acknowledgments. This remains compliant with the independence 418 between packets and frames while providing more flexibility to hosts 419 to decide on which path they want to send path acknowledgments. 420 Looking again at Figure 1, packets that were sent over a given path 421 (e.g., the response2 packet on path 2 with DCID C) can be 422 acknowledged on another path (here, path 1 with DCID A) to limit the 423 latency due to ACK transmissions on high-latency paths. Such 424 scheduling decision would not have been possible in Multipath TCP 425 [RFC6824] which must acknowledge data on the path it was received on. 427 3.7. Exchanging Addresses 429 When a multi-homed mobile device connects to a dual-stacked server 430 using its IPv4 address, it is aware of its local addresses (e.g., the 431 Wi-Fi and the cellular ones) and the IPv4 remote address used to 432 establish the QUIC connection. If the client wants to create new 433 paths over IPv6, it needs to learn the other addresses of the remote 434 peer. 436 This is possible with the ADD_ADDRESS frames that are sent by a 437 Multipath QUIC host to advertise its current addresses. Each 438 advertised address is identified by an Address ID. The addresses 439 attached to a host can vary during the lifetime of a Multipath QUIC 440 connection. A new ADD_ADDRESS frame is transmitted when a host has a 441 new address. This ADD_ADDRESS frame is protected as other QUIC 442 control frames, which implies that it cannot be spoofed by attackers. 443 The communicated address is first validated by the receiving host 444 before it starts using it. This ensures that the address actually 445 belongs to the peer and that the peer can send and receive packets on 446 that address. It also prevents hosts from launching amplification 447 attacks to a victim address. 449 If the client is behind a NAT, it could announce a private address in 450 an ADD_ADDRESS frame. In such situations, the server would not be 451 able to validate the communicated address. The client might still 452 use its NATed address to start a new path. To enable the server to 453 make the link between the private and the public addresses, Multipath 454 QUIC provides the PATHS frame that lists current active Path IDs of 455 the sending host. 457 Likewise, the client may be located behind a NAT64. As such it may 458 announce an IPv6 address in an ADD_ADDRESS frame, that will be 459 received over IPv4 by an IPv4-only server. The server should not 460 discard that address, even if it is not IPv6-capable. 462 An IPv6-only client may also receive from the server an ADD_ADDRESS 463 frame which may contain an IPv4 address. The client should rely on 464 means, such as [RFC7050] or [RFC7225], to learn the IPv6 prefix to 465 build an IPv4-converted IPv6 address. 467 A path is called active when it was created over a validated 4-tuple 468 and is still in use. The frame indicates the local Address ID that 469 the path uses. With this information, the server can then validate 470 the public address and associate the advertised with the perceived 471 addresses. 473 Hosts that are connected behind an address sharing mechanism may 474 collect the external IP address and port numbers assigned to the 475 hosts and then use there addresses in the ADD_ADDRESS. Means to 476 gather such information include, but not limited to, UPnP IGD, PCP, 477 or STUN. 479 3.8. Coping with Address Removals 481 During the lifetime of a QUIC connection, a host might lose some of 482 its addresses. A concrete example is a smartphone going out of 483 reachability of a Wi-Fi network or shutting off one of its network 484 interfaces. Such address removals are advertised by using 485 REMOVE_ADDRESS frames. The REMOVE_ADDRESS frame contains the Address 486 ID of the lost address previously communicated through ADD_ADDRESS. 488 3.9. Path Migration 490 At a given time, a Multipath QUIC endpoint gathers a set of paths, 491 each using a 4-tuple. To address privacy issues due to the 492 linkability of addresses with Connection IDs, hosts should avoid 493 changing the 4-tuple used by a path. There remain situations where 494 this change is unavoidable. These can be categorized into two 495 groups: host-aware changes (e.g., network handover from Wi-Fi to 496 cellular) and host-unaware changes (e.g., NAT rebinding). 498 For the host-aware case, let us consider the case of a Multipath QUIC 499 connection where the client is a smartphone with both Wi-Fi and 500 cellular. It advertised both addresses and the server currently 501 enables only one path, the initial one. The Initial Path uses the 502 Wi-Fi address. Then, for some reason, the Wi-Fi address becomes 503 unusable. To preserve connectivity, the client might then decide to 504 use the cellular address for the Initial Path. It thus sends a 505 REMOVE_ADDRESS announcing the loss of the Wi-Fi address and a PATHS 506 frame to inform that the Initial Path is now using the cellular 507 address. If the cellular address validation succeeds (which could 508 have been done as soon as the cellular address was advertised), the 509 server can continue exchanging data through the cellular address. 511 However, both server and client might want to change the path used on 512 the cellular address for privacy concerns. If the server provides an 513 additional path (e.g., Path ID 42) through NEW_CONNECTION_ID frame at 514 the beginning of the connection, the client can perform the path 515 change directly and avoid using the Initial Path Connection ID on the 516 cellular network. This can be done using the PATH_UPDATE frame. It 517 can indicate that the host stopped to use the Initial Path to use 518 Path ID 42 instead. This frame is placed in the first packet sent to 519 the new path with its corresponding PCID. The client can then send 520 the REMOVE_ADDRESS and PATHS frames on this new path. Compared to 521 the previous case, it is harder to link the paths with the IP 522 addresses to observe that they belong to the same Multipath QUIC 523 connection. 525 For the host-unaware case, the situation is similar. In case of NAT 526 rebinding, the server will observe a change in the 2-tuple (source 527 IP, source port) of the packet. The server first validates that the 528 2-tuple actually belongs to the client [I-D.ietf-quic-transport]. If 529 it is the case, the server can send a PATH_UPDATE frame on a 530 previously communicated but unused Path ID. The client might have 531 sent some packets with a given PCID on a different 4-tuple, but the 532 server did not use the given PCID on that 4-tuple. Because some on- 533 path devices may rewrite the source IP address to forward packets via 534 the available network attachments (e.g., an host located behind a 535 multi-homed CPE), the server may inadvertently conclude that a path 536 is not anymore valid leading thus to frequently sending PATH_UPDATE 537 frames as a function of the traffic distribution scheme enforced by 538 the on-path device. To prevent such behavior, the server SHOULD wait 539 for at least X seconds to ensure this is about a connection migration 540 and not a side effect of an on-path multi-interfaced device. 542 3.10. Sharing Path Policies 544 Some access networks are subject to a volume quota. To prevent a 545 peer from aggressively using a given path while available resources 546 can be freely grabbed using existing paths, it is desirable to 547 support a signal to indicate to a remote peer how it must place data 548 into available paths. An approach may consist in indicating in an 549 ADD_ADDRESS the type of the interface (e.g., cellular, WLAN, fixed): 550 interface-type. The remote peer may rely on interface-type to select 551 the path to be used for sending data. For example, fixed interfaces 552 will be preferred over WLAN and cellular interfaces, and WLAN 553 interface will be preferred over cellular interface. 555 This information might also be used to avoid draining battery for 556 some devices. 558 3.11. Congestion Control 560 The QUIC congestion control scheme is defined in 561 [I-D.ietf-quic-recovery]. This congestion control scheme is not 562 suitable when several paths are active. Using the congestion control 563 scheme defined in [I-D.ietf-quic-recovery] with Multipath QUIC would 564 result in unfairness. Each path of a Multipath QUIC connection MUST 565 have its own congestion window. The windows of the different paths 566 MUST be coupled together. Multipath TCP uses the LIA congestion 567 control scheme specified in [RFC6356]. This scheme can immediately 568 be adapted to Multipath QUIC. Other coupled congestion control 569 schemes have been proposed for Multipath TCP such as [OLIA]. 571 4. Mapping Path ID to Connection IDs 573 As described in the overview section, hosts need to identify on which 574 path packets are sent. The Path ID must then be inferred from the 575 public header. This is done by using Path Connection IDs in addition 576 to Main Connection IDs. 578 The Master Connection IDs is determined during the cryptographic 579 handshake and actually corresponds to both Connection IDs in the 580 current QUIC design [I-D.ietf-quic-transport]. The Path Connection 581 IDs of the Initial Path (with Path ID 0) are equal to the Main 582 Connection IDs. The Path Connection IDs of the other paths are 583 determined when the NEW_CONNECTION_ID frames are exchanged. 585 The server MUST ensure that all advertised Path Connection IDs are 586 available for the whole connection lifetime. Once it sends a 587 NEW_CONNECTION_ID frame containing a PCID, the server can start 588 receiving packets with the advertised Connection ID as belonging to 589 the corresponding path. The server MUST wait until the reception of 590 the frame acknowledgment before starting to send packets on that 591 path. 593 Upon reception of the NEW_CONNECTION_ID frame, the client MUST 594 acknowledge it and MUST store the advertised Destination Path 595 Connection ID and the Path ID of the proposed path. It MUST ensure 596 that it can receive packets coming from the server using the PCID and 597 associate it with the corresponding Path ID. 599 5. Using Multiple Paths 601 This section describes in details the multipath QUIC operations. 603 5.1. Multipath Negotiation 605 The Multipath Negotiation takes place during the cryptographic 606 handshake with the max_paths transport parameter. A QUIC connection 607 is initially single-path in QUIC, and all packets prior to handshake 608 completion MUST be exchanged over the Initial Path. During this 609 process, hosts advertise their support for multipath operations. Any 610 value different from 0 indicates that the host supports multipath 611 operations over the connection, i.e., the extensions defined in this 612 document (not to be mixed with the availability of local multiple 613 paths). If a host does not send the max_paths transport parameter 614 during the cryptographic handshake, the remote MUST assume a value of 615 0, leading to a single-path connection over the Initial Path. If 616 both hosts advertise their support of the multipath extensions, 617 NEW_CONNECTION_ID frames can later propose Path IDs that can then be 618 used for the connection. 620 5.1.1. Transport Parameter Definition 622 An endhost MAY use the following transport parameter: 624 max_paths (0x0020): The maximum number of paths that can be 625 simultaneously active, encoded as an unsigned 16-bit integer. If 626 absent, the value for this parameter is 0, meaning that a host 627 omitting this transport parameter does not agree to use the 628 multipath extension over the connection. 630 5.2. Coping with Additional Remote Addresses 632 The usage of multiple networks paths is often done using multiple IP 633 addresses. For instance, a smartphone willing to use both Wi-Fi and 634 LTE will use the corresponding addresses assigned by these networks. 635 It can then safely send packets to a previously-used IP address of a 636 server. The server can receive packets sourced with different IP 637 addresses, but it MUST first validate the new remote IP addresses 638 before starting sending packets to those addresses. 640 Similarly, additional addresses could be communicated using 641 ADD_ADDRESS frames. Such addresses MUST be validated before starting 642 to send packets to them. This requirement is explained in 643 Section 8.2. 645 The validation of an address could be performed with PATH_CHALLENGE 646 and PATH_RESPONSE frames as described in [I-D.ietf-quic-transport]. 647 A validated address MAY be cached for a given host for a limited 648 amount of time. 650 5.3. Path State 652 During the Multipath QUIC connection, hosts maintain some state for 653 paths. Information about the path that hosts are required to store 654 depends on its state. The possible path states are depicted in 655 Figure 3. 657 +----------+ 658 | PROPOSED | 659 +----------+ 660 | both hosts exchanged PCIDs for the path 661 v 662 +----------+ 663 | READY | 664 +----------+ 665 | 666 | path usage 667 | 668 | restricted by negotiated MAX_PATHS 669 v or affected by REMOVE_ADDRESS 670 +--------+ --------------------------> +----------+ 671 | ACTIVE | reusing path | UNUSABLE | 672 +--------+ <-------------------------- +----------+ 673 | | 674 | PATH_UPDATE | 675 +---------------------------------------+ 676 | 677 v 678 +--------+ 679 | CLOSED | 680 +--------+ 682 Figure 3: Finite-State Machine of paths 684 Once a path has been proposed in a NEW_CONNECTION_ID frame, either 685 sent or received, it is in the PROPOSED state. In this situation, 686 hosts MUST keep the following path information: 688 o Path ID: encoded as a 4-byte integer. It uniquely identifies the 689 path in the connection. This value is immutable. 691 o Main Connection IDs: they make the link between the path and the 692 QUIC 693 connection it belongs to. These values are immutable. 695 o Path Connection IDs: they make the link between the packet's 696 Connection ID field and the path. This value can be updated with 697 subsequent NEW_CONNECTION_ID frames. 699 o Path State: the current state of the path, one of the values 700 presented in Figure 3. 702 Once both hosts exchanged both asymmetric PCIDs for a given Path ID, 703 the path enters the READY state. In this state, hosts MUST ensure 704 that they can associate a packet with the PCIDs and its corresponding 705 path at any time, as they must be ready to figure out the path used 706 by the remote host. 708 Either the host received a packet with the corresponding PCIDs coming 709 from a validated address or it wants to start using the path to a 710 validated address, the path goes to the ACTIVE state. This is the 711 state where a path can be used to send and receive packets. In 712 addition to the fields required in the PROPOSED state, the following 713 elements MUST be tracked: 715 o Packet Number Space: each path is associated with its own 716 monotonically increasing packet number space. Each endpoint 717 maintains a separate packet number for sending and receiving 718 packets. Packet number considerations described in 719 [I-D.ietf-quic-transport] apply within a given path. 721 o Current 4-tuple: the tuple (sIP, dIP, sport, dport) used to send 722 or receive 723 packets over this path. This value is mutable, either because the 724 host decides to change its local address and/or port, or because 725 it receives a packet with a different validated remote address 726 and/or port than the one currently recorded. A host that changes 727 the 4-tuple of a path SHOULD migrate it. 729 o Current (local Address ID, remote Address ID) tuple: those 730 identifiers come from the ADD_ADDRESS sent (local) and received 731 (remote). This enables a host to mark a path as UNUSABLE when, 732 e.g., the remote Address ID is declared as lost in a 733 REMOVE_ADDRESS. The addresses on which the connection was 734 established have Address ID 0. The reception of PATHS frames 735 helps hosts to associate the remote Address ID used by the path. 737 o Performance metrics: basic statistics such as round-trip-time or 738 number of packets sent and received can be collected on a per-path 739 basis. This information can be useful when a host needs to 740 perform packet scheduling decisions and flow control management. 742 It might happen that a path is temporarily unavailable, because one 743 of the endpoint's addresses is no more available or because the 744 server decided to decrease the number of active paths. In such 745 cases, the path is in UNUSABLE state and the host MUST NOT send 746 packets on it. The host keeps the same information as in the ACTIVE 747 state for the path. It might happen that packets are received on 748 that path. If the path is in UNUSABLE state because of a decrease of 749 the active paths, packets MUST be discarded silently. If it is 750 because a REMOVE_ADDRESS was received for the remote Address ID of 751 the path, the host SHOULD validate the remote address first before 752 reusing it. If this validation succeeds, or the number of paths 753 increased again, a path in the UNUSABLE state can go into ACTIVE 754 state, but its congestion window MUST be restarted and its 755 performance metrics SHOULD be reset. 757 Eventually, a path may either be migrated to another one or closed. 758 This is signaled by the PATH_UPDATE frame. In that case, the path is 759 in CLOSED state. In that state, packets MUST NOT be sent or received 760 over it. A host MUST keep the same path state field as in the 761 PROPOSED state, to avoid ambiguities and CLOSED path reuse. 763 5.4. Dynamic Management of Paths 765 Both hosts determine how many paths can be used over a Multipath QUIC 766 connection. It is their responsibility to propose Path IDs with 767 corresponding PCIDs that could be used by the peer. In addition, 768 they dynamically control the number of active paths that can be used 769 for the connection, initially determined during the handshake with 770 the max_paths transport parameter. This is performed by sending 771 MAX_PATHS frames that set an upper limit on the number of active 772 paths. At any time, the maximum number of active paths that could be 773 present over a connection is the minimum value advertised by peers. 774 A host can propose more Path IDs with NEW_CONNECTION_ID frames than 775 the number of paths it agrees to use simultaneously. This can be 776 useful in migration scenarios, where the host wants to share a pool 777 of Path IDs that can be directly used to migrate paths. 779 A host can also decrease the number of paths that can be used over a 780 connection. If this value decreases below the current number of 781 active paths, hosts MUST put in UNUSABLE state the paths in the 782 ACTIVE state with the highest Path IDs. Server and client MUST stop 783 sending packets over UNUSABLE paths once the MAX_PATHS has been sent 784 or received. The host restricting the number of paths SHOULD allow 785 receiving packets on newly UNUSABLE paths for one round-trip-time. 786 After this delay, hosts SHOULD silently discard received packets. 788 When the server proposes more Path IDs than the negotiated maximum 789 number of ACTIVE paths, it might happen that both hosts decide at the 790 same time to create paths with different Path IDs, such as there are 791 more created paths than the negotiated maximum value. In this case, 792 the hosts MUST only keep as ACTIVE the paths with the lowest Path 793 IDs. Paths with the highest Path IDs are in the UNUSABLE state and 794 packets SHOULD be silently discarded. 796 5.5. Losing Addresses 798 During the lifetime of a connection, a host might lose addresses, 799 e.g., a network interface that was shut down. All the ACTIVE paths 800 that were using that local address MUST be set in the UNUSABLE state. 802 To advertise the address loss to the peer, the host MUST send a 803 REMOVE_ADDRESS frame indicating which Address IDs has been lost. The 804 host MUST also send a PATHS frame indicating the status of the 805 remaining ACTIVE paths. 807 Upon reception of the REMOVE_ADDRESS, the receiving host MUST set the 808 ACTIVE paths affected by the address removal into the UNUSABLE state. 810 The host that locally lost the address MAY reuse one of these paths 811 by changing the assigned 4-tuple. In this case, it MUST send a PATHS 812 frame describing that change. 814 5.6. Scheduling Strategies 816 The current QUIC design [I-D.ietf-quic-transport] offers a two- 817 dimensional scheduling space, i.e., which frames will be packed 818 inside a given packet. With the use of multiple paths, a third 819 dimension is added, i.e., the path on which the packet will be sent. 820 This dimension can have a non negligible impact on the operations of 821 Multipath QUIC, especially if the available paths exhibit very 822 different network characteristics. 824 The progression of the data flow depends on the reception of the 825 MAX_DATA and MAX_STREAM_DATA frames. Those frames SHOULD be 826 duplicated on several or all paths in use. This would limit the 827 head-of-line blocking issue due to the transmission of the frames 828 over a slow path. 830 The path on which ACK frames are sent impacts the peer. The ACK 831 frame is notably used to determine the latency of a path. If the ACK 832 frame is sent on the path it acknowledges, then the peer can compute 833 the round-trip-time of that path. Otherwise, the peer would compute 834 the latency as the sum of the forward delay of the acknowledged path 835 and the return delay of the path used to send the ACK frame. 836 Choosing between acknowledging packets on the same path or on a 837 specific path is up to the implementation. However, hosts SHOULD 838 keep a consistent acknowledgement strategy. Selecting a random path 839 to acknowledge packets will possibly increase the variability of the 840 latency estimation, especially if paths exhibit very different 841 network characteristics. Unlike MAX_DATA and MAX_STREAM_DATA, ACK 842 frames SHOULD NOT be systematically duplicated on several paths as 843 they can induce a large network overhead. 845 6. Modifications to QUIC frames 847 The multipath extension allows hosts to send packets over multiple 848 paths. Since nearly all QUIC frames are independent of packets, no 849 change is required for most of them. The only exceptions are the 850 NEW_CONNECTION_ID and the ACK frames. The NEW_CONNECTION_ID is 851 modified to provide Path Connection ID negotiation for each path. 852 The ACK frame contains packet-level information with the Largest 853 Acknowledged field. Since the Packet Numbers are now associated to 854 paths, the ACK frame must contain the Path ID it acknowledges. 856 6.1. NEW_CONNECTION_ID Frame 858 The NEW_CONNECTION_ID frame (type=0x0b) as defined by 859 [I-D.ietf-quic-transport] keeps its ability to provide the client 860 with alternative connection IDs that can be used to break linkability 861 when migrating connections. It also allows the server to indicate 862 which connection IDs the client must use to take advantage of 863 multiple paths. 865 The NEW_CONNECTION_ID is as follows: 867 0 1 2 3 868 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Path ID (i) ... 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Sequence (i) ... 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Length (8) | | 875 +-+-+-+-+-+-+-+-+ Connection ID (32..144) + 876 | ... 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | | 879 + + 880 | | 881 + Stateless Reset Token (128) + 882 | | 883 + + 884 | | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 Figure 4: NEW_CONNECTION_ID frame adapted to Multipath QUIC 889 Compared to the frame specified in [I-D.ietf-quic-transport], a Path 890 ID field of variable size is prefixed to associate the Path ID with 891 the Connection ID. If the multipath extension was not negotiated 892 during the connection establishment, the NEW_CONNECTION_ID frame is 893 the same as the one presented in [I-D.ietf-quic-transport]. This 894 frame can be sent by both hosts. Upon reception of the frame with a 895 specified path ID, the peer can update the related path state either 896 to PROPOSED or READY and store the communicated Connection ID as the 897 Destination Connection ID of the path. 899 A host MUST NOT start using a path as long as both peers have not 900 proposed their Destination Connection ID with NEW_CONNECTION_ID 901 frames. To limit the delay of the multipath usage upon handshake 902 completion, hosts SHOULD send NEW_CONNECTION_ID frames for paths they 903 allow using as soon the connection establishment completes. 905 To cope with privacy issues, it should be hard to make the link 906 between two different connections or two different paths of a same 907 connection by just looking at the Connection ID contained in packets. 908 Therefore, Path Connection IDs chosen by hosts MUST be random. 910 6.2. RETIRE_CONNECTION_ID Frame 912 The RETIRE_CONNECTION_ID frame (type=0x19) as defined by 913 [I-D.ietf-quic-transport] still allows an endpoint to indicate that 914 it will no longer use a connection ID that was issued by its peer. 915 The multipath extensions link Connection IDs to paths. Therefore, 916 this frame should contains the Path ID on which it applies. 918 The format of the adapted RETIRE_CONNECTION_ID is shown below. 920 0 1 2 3 921 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | Path ID (i) ... 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Sequence Number (i) ... 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 Figure 5: RETIRE_CONNECTION_ID frame adapted to Multipath QUIC 930 The frame is handled as described in [I-D.ietf-quic-transport] on a 931 path basis. 933 6.3. ACK Frame 935 The format of the modified ACK frame is shown below. 937 0 1 2 3 938 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Path ID (i) ... 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Largest Acknowledged (i) ... 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | ACK Delay (i) ... 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | ACK Range Count (i) ... 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | First ACK Range (i) ... 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | ACK Ranges (*) ... 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | [ECN Counts] ... 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 Figure 6: ACK frame adapted to Multipath 957 Compared to the ACK frame in the current QUIC design 958 [I-D.ietf-quic-transport], the ACK frame is prefixed by a variable 959 size Path ID field indicating to which path the acknowledged PSNs 960 relate to. Notice that if the multipath extension was not negotiated 961 during the connection handshake, the ACK frame is the same as the one 962 presented in [I-D.ietf-quic-transport]. 964 Since frames are independent of packets, and the path notion relates 965 to the packets, the ACK frames can be sent on any path, unlike 966 Multipath TCP [RFC6824] which is constrained to send ACKs on the same 967 path. 969 7. New Frames 971 To support the multipath operations, new frames have been defined to 972 coordinate hosts. This draft uses a type field containing 0x20 to 973 indicate that the frame is related to multipath operations. 975 7.1. MAX_PATHS Frame 977 The MAX_PATHS frame is used by hosts to control the number of paths 978 that can be simultaneously in the ACTIVE state on a given connection. 979 The proposed type for the MAX_PATHS frame is 0x20. A MAX_PATHS frame 980 is shown below. 982 0 1 2 3 983 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | Sequence (i) ... 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Num Additional Active Paths (i) ... 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 Figure 7: MAX_PATHS Frame 992 The MAX_PATHS frame contains the following fields: 994 o Sequence: A variable-length integer. This value starts at 0 and 995 increases by 1 for each change of number of active paths that is 996 provided by the host. 998 o Num Additional Active Paths: A variable-length integer indicating 999 how many additional paths can be used over the connection. The 1000 number of paths that can be in ACTIVE state is thus (Num 1001 Additional Active Paths + 1). 1003 Once the connection is established, hosts MUST assume that the server 1004 sent a MAX_PATHS frame with sequence -1 and number of additional 1005 active paths equal to 0 and the client sent a MAX_PATHS frame with 1006 sequence -1 and number of additional active paths equal to the 1007 negotiated max_path_id value. 1009 7.2. PATH_UPDATE Frame 1011 The PATH_UPDATE frame is used by a host either to migrate a path or 1012 to close it. This indicates to the remote that the closed path MUST 1013 NOT be used anymore and it can use the proposed one instead, if any. 1014 The proposed type for the PATH_UPDATE is 0x21. A PATH_UPDATE frame 1015 is shown below. 1017 0 1 2 3 1018 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Closed Path ID (i) ... 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | Proposed Path ID (i) ... 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 Figure 8: PATH_UPDATE Frame 1027 The PATH_UPDATE frame contains the following fields: 1029 o Closed Path ID: A variable-length integer corresponding to the 1030 Path ID of the path that is closed. 1032 o Proposed Path ID: A variable-length integer corresponding to the 1033 Path ID of the path that substitutes the closed path. If the 1034 value is 0, no path is proposed. 1036 Upon the transmission or the reception of the PATH_UPDATE frame, the 1037 path with the Path ID referenced in Closed Path ID MUST be in the 1038 CLOSED state. If the proposed Path ID is different of 0, the path 1039 MUST have been either in the PROPOSED or in the UNUSABLE state and 1040 MUST now be considered as ACTIVE. 1042 7.3. ADD_ADDRESS Frame 1044 The ADD_ADDRESS frame is used by a host to advertise its currently 1045 reachable addresses. The proposed type for the ADD_ADDRESS frame is 1046 0x22. An ADD_ADDRESS frame is shown below. 1048 0 1 2 3 1049 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 |0|0|0|P|IPVers.|Address ID (8) |Interface T.(8)| 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | IP Address (32/128) ... 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | [Port (16)] | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 Figure 9: ADD_ADDRESS Frame 1060 The ADD_ADDRESS frame contains the following fields: 1062 o Reserved bits: the three most-significant bits of the first byte 1063 are set to 0, and are reserved for future use. 1065 o P bit: the fourth most-significant bit of the first byte 1066 indicates, if set, the presence of the Port field. 1068 o IPVers.: the remaining four least-significant bits of the first 1069 byte contain the version of the IP address contained in the IP 1070 Address field. 1072 o Address ID: an unique identifier for the advertised address for 1073 tracking and removal purposes. This is needed when, e.g., a NAT 1074 changes the IP address such that both hosts see different IP 1075 addresses for a same path endpoint. 1077 o Interface Type: used to provide an indication about the interface 1078 type to which this address is bound. The following values are 1079 defined: o 0: fixed. Used as default value. o 1: WLAN o 2: 1080 cellular 1082 o IP Address: the advertised IP address, in network order. 1084 o Port: this optional field indicates the port number related to the 1085 advertised IP address. When this field is present, it indicates 1086 that a path can use the 2-tuple (IP addr, port). 1088 Upon reception of an ADD_ADDRESS frame, the receiver SHOULD store the 1089 communicated address for future use. The receiver MUST NOT send 1090 packets others than validation ones to the communicated address 1091 without having validated it. ADD_ADDRESS frames SHOULD contain 1092 globally reachable addresses. Link-local and possibly private 1093 addresses SHOULD NOT be exchanged. 1095 7.4. REMOVE_ADDRESS Frame 1097 The REMOVE_ADDRESS frame is used by a host to signal that a 1098 previously announced address was lost. The proposed type for the 1099 REMOVE_ADDRESS frame is 0x23. A REMOVE_ADDRESS frame is shown below. 1101 0 1 2 3 1102 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1103 +-+-+-+-+-+-+-+-+ 1104 |Address ID (8) | 1105 +-+-+-+-+-+-+-+-+ 1107 Figure 10: REMOVE_ADDRESS Frame 1109 The frame contains only one field, Address ID, being the identifier 1110 of the address to remove. A host SHOULD stop using paths using the 1111 removed address and set them in the UNUSABLE state. If the 1112 REMOVE_ADDRESS contains an Address ID that was not previously 1113 announced, the receiver MUST silently ignore the frame. 1115 7.5. PATHS Frame 1117 The PATHS frame communicates the paths state of the sending host to 1118 the peer. It allows the sender to communicate its active paths to 1119 the peer in order to detect potential connectivity issue over paths. 1120 Its proposed type is 0x24. The format of the PATHS frame is shown 1121 below. 1123 0 1 2 3 1124 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | Sequence (i) ... 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | ActivePaths (i) ... 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | Path Info Section (*) ... 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 Figure 11: PATHS Frame 1135 The PATHS frame contains the following fields: 1137 o Sequence: A variable-length integer. This value starts at 0 and 1138 increases by 1 for each PATHS frame sent by the host. It allows 1139 identifying the most recent PATHS frame. 1141 o ActivePaths: the current number of additional paths considered as 1142 being active from the sender point of view, i.e., (the number of 1143 active paths - 1). ActivePaths MUST be smaller or equal to the 1144 last value advertised by MAX_PATHS frame. 1146 o Path Info Section: contains information about all the active paths 1147 (i.e., there are ActivePaths + 1 entries). The format of this 1148 section is shown below. 1150 0 1 2 3 1151 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Path ID 0 (i) ... 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 |LocAddrID 0 (8)| 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 ... 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | Path ID N (i) ... 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 |LocAddrID N (8)| 1162 +-+-+-+-+-+-+-+-+ 1164 Figure 12: Path Info Section 1166 The fields in the Path Info Section are: 1168 o Path ID: the Path ID of the active path the sending host provides 1169 information about. 1171 o LocAddrID: the local Address ID of the address currently used by 1172 the path. 1174 The Path Info section only contains the Local Address ID so far, but 1175 this section can be extended later with other potentially useful 1176 information. 1178 8. Security Considerations 1180 8.1. Nonce Computation 1182 With Multipath QUIC, each path has its own packet number space. With 1183 the current nonce computation [I-D.ietf-quic-tls], using twice the 1184 same packet number over two different paths leads to the same 1185 cryptographic nonce. Depending on the size of the Initial Value (and 1186 hence the nonce), there are two ways to mitigate this issue. 1188 If the Initial Value has a length of 8 bytes, then a packet number 1189 used on a given path MUST NOT be reused on another path of the 1190 connection, and therefore at most 2^64 packets can be sent on a QUIC 1191 connection. This means there will be packet number skipping at path 1192 level, but the packet number will remain monotonically increasing on 1193 each path. 1195 If the Initial Value has a length of 9 or more, then the 1196 cryptographic nonce computation is now performed as follows. The 1197 nonce, N, is formed by combining the packet protection IV (either 1198 client_pp_iv_n or server_pp_iv_n) with the Path ID and the packet 1199 number. The 64 bits of the reconstructed QUIC packet number in 1200 network byte order is left-padded with zeros to the size of the IV. 1201 The Path ID encoded in its variable-length format is right-padded 1202 with zeros to the size of the IV. The Path IV is computed as the 1203 exclusive OR of the padded Path ID and the IV. The exclusive OR of 1204 the padded packet number and the Path IV forms the AEAD nonce. 1206 8.2. Validation of Exchanged Addresses 1208 To use addresses communicated by the peer through ADD_ADDRESS frames, 1209 hosts are required to validate them before using paths to these 1210 addresses. The main reason for this validation is that the remote 1211 host might have sent, purposely or not, a packet with a source IP 1212 that does not correspond to the IP of the remote interface. This 1213 could lead to amplification attacks where the client start using a 1214 new path with a source IP corresponding to the victim's one. Without 1215 validation, the server might then flood the victim. Similarly for 1216 ADD_ADDRESS frames, a malicious server might advertise the IP address 1217 of a victim, hoping that the client will use it without validating it 1218 before. 1220 9. IANA Considerations 1222 9.1. QUIC Transport Parameter Registry 1224 This document defines a new transport parameter for the negotiation 1225 of multiple paths. The following entry in Table 1 should be added to 1226 the "QUIC Transport Parameters" registry under the "QUIC Protocol" 1227 heading. 1229 +--------+----------------+---------------+ 1230 | Value | Parameter Name | Specification | 1231 +--------+----------------+---------------+ 1232 | 0x0020 | max_paths | Section 5.1.1 | 1233 +--------+----------------+---------------+ 1235 Table 1: Addition to QUIC Transport Parameters Entries 1237 10. Acknowledgements 1239 We would like to thanks Masahiro Kozuka and Kazuho Oku for their 1240 numerous comments on the first version of this draft. We also thanks 1241 Philipp Tiesel for his early comments that led to the current design, 1242 and Ian Swett for later feedbacks. We also want to thank Christian 1243 Huitema for his draft about multipath requirements to identify 1244 critical elements about the multipath feature. Mohamed Boucadair 1245 provided lot of useful inputs on the second version of this document. 1247 11. References 1249 11.1. Normative References 1251 [I-D.ietf-quic-invariants] 1252 Thomson, M., "Version-Independent Properties of QUIC", 1253 draft-ietf-quic-invariants-03 (work in progress), October 1254 2018. 1256 [I-D.ietf-quic-recovery] 1257 Iyengar, J. and I. Swett, "QUIC Loss Detection and 1258 Congestion Control", draft-ietf-quic-recovery-18 (work in 1259 progress), January 2019. 1261 [I-D.ietf-quic-tls] 1262 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 1263 draft-ietf-quic-tls-18 (work in progress), January 2019. 1265 [I-D.ietf-quic-transport] 1266 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1267 and Secure Transport", draft-ietf-quic-transport-18 (work 1268 in progress), January 2019. 1270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1271 Requirement Levels", BCP 14, RFC 2119, 1272 DOI 10.17487/RFC2119, March 1997, 1273 . 1275 11.2. Informative References 1277 [Cellnet] Paasch, C., Detal, G., Duchene, F., Raiciu, C., and O. 1278 Bonaventure, "Exploring Mobile/Wi-Fi Handover with 1279 Multipath TCP", ACM SIGCOMM workshop on Cellular Networks 1280 (Cellnet'12) , 2012. 1282 [I-D.huitema-quic-mpath-req] 1283 Huitema, C., "QUIC Multipath Requirements", draft-huitema- 1284 quic-mpath-req-01 (work in progress), January 2018. 1286 [IETFJ] Bonaventure, O. and S. Seo, "Multipath TCP Deployments", 1287 IETF Journal , November 2016. 1289 [MPQUIC] De Coninck, Q. and O. Bonaventure, "Multipath QUIC: Design 1290 and Evaluation", 13th International Conference on emerging 1291 Networking EXperiments and Technologies (CoNEXT 2017). 1292 http://multipath-quic.org , December 2017. 1294 [MPRTP] Singh, V., Ahsan, S., and J. Ott, "MPRTP: Multipath 1295 considerations for real-time media", Proceedings of the 1296 4th ACM Multimedia Systems Conference , 2013. 1298 [OLIA] Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J. 1299 Le Boudec, "MPTCP is not pareto-optimal: performance 1300 issues and a possible solution", Proceedings of the 8th 1301 international conference on Emerging networking 1302 experiments and technologies, ACM , 2012. 1304 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1305 RFC 793, DOI 10.17487/RFC0793, September 1981, 1306 . 1308 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 1309 Congestion Control for Multipath Transport Protocols", 1310 RFC 6356, DOI 10.17487/RFC6356, October 2011, 1311 . 1313 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1314 "TCP Extensions for Multipath Operation with Multiple 1315 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1316 . 1318 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1319 the IPv6 Prefix Used for IPv6 Address Synthesis", 1320 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1321 . 1323 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 1324 Port Control Protocol (PCP)", RFC 7225, 1325 DOI 10.17487/RFC7225, May 2014, 1326 . 1328 [RFC8041] Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and 1329 Operational Experience with Multipath TCP", RFC 8041, 1330 DOI 10.17487/RFC8041, January 2017, 1331 . 1333 [SCTPCMT] Iyengar, J., Amer, P., and R. Stewart, "Concurrent 1334 multipath transfer using SCTP multihoming over independent 1335 end-to-end paths", IEEE/ACM Transactions on networking, 1336 Vol. 14, no 5 , 2006. 1338 Appendix A. Change Log 1340 A.1. Since draft-deconinck-quic-multipath-01 1342 o Include path policies considerations 1344 o Add practical considerations thanks to Mohamed Boucadair inputs 1346 o Adapt the RETIRE_CONNECTION_ID frame 1348 o Updated text to match draft-ietf-quic-transport-18 1350 A.2. Since draft-deconinck-quic-multipath-00 1352 o Comply with asymmetric Connection IDs 1354 o Add max_paths transport parameter to negotiate initial number of 1355 active paths 1357 o Path ID as a regular varint 1359 o Remove max_path_id transport parameter 1360 o Updated text to match draft-ietf-quic-transport-14 1362 A.3. Since draft-deconinck-multipath-quic-00 1364 o Added PATH_UPDATE frame 1366 o Added MAX_PATHS frame 1368 o No more packet header change 1370 o Implicit Path ID notification using Connection ID and 1371 NEW_CONNECTION_ID 1372 frames 1374 o Variable-length encoding for Path ID 1376 o Updated text to match draft-ietf-quic-transport-10 1378 o Fixed various typos 1380 Authors' Addresses 1382 Quentin De Coninck 1383 UCLouvain 1385 Email: quentin.deconinck@uclouvain.be 1387 Olivier Bonaventure 1388 UCLouvain 1390 Email: Olivier.Bonaventure@uclouvain.be