idnits 2.17.1 draft-deconinck-quic-multipath-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 (March 5, 2018) is 2244 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 1217, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-quic-invariants-00 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-09 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-10 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-10 -- 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 6, 2018 March 5, 2018 7 Multipath Extension for QUIC 8 draft-deconinck-quic-multipath-00 10 Abstract 12 This document proposes extensions to the QUIC protocol to enable the 13 usage of multiple paths over a single connection. Those changes 14 remain compliant with the current single-path QUIC design. They 15 allow devices to benefit from multiple network paths while preserving 16 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 http://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 6, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://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 . . . . . . . . . . . . . . . . . . . 7 61 3.6. Exchanging Data over Multiple Paths . . . . . . . . . . . 8 62 3.7. Exchanging Addresses . . . . . . . . . . . . . . . . . . 9 63 3.8. Coping with Address Removals . . . . . . . . . . . . . . 10 64 3.9. Path Migration . . . . . . . . . . . . . . . . . . . . . 10 65 3.10. Congestion Control . . . . . . . . . . . . . . . . . . . 11 66 4. Mapping Path ID to Connection ID . . . . . . . . . . . . . . 11 67 5. Using Multiple Paths . . . . . . . . . . . . . . . . . . . . 12 68 5.1. Multipath Negotiation . . . . . . . . . . . . . . . . . . 12 69 5.1.1. Transport Parameter Definition . . . . . . . . . . . 13 70 5.2. Variable-Length Encoding of the Path ID . . . . . . . . . 13 71 5.3. Coping with Additional Remote Addresses . . . . . . . . . 13 72 5.4. Path State . . . . . . . . . . . . . . . . . . . . . . . 14 73 5.5. Dynamic Management of Paths . . . . . . . . . . . . . . . 16 74 5.6. Loosing Addresses . . . . . . . . . . . . . . . . . . . . 17 75 5.7. Scheduling Strategies . . . . . . . . . . . . . . . . . . 17 76 6. Modifications to QUIC frames . . . . . . . . . . . . . . . . 18 77 6.1. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 18 78 6.2. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 20 79 7. New Frames . . . . . . . . . . . . . . . . . . . . . . . . . 20 80 7.1. MAX_PATHS Frame . . . . . . . . . . . . . . . . . . . . . 20 81 7.2. PATH_UPDATE Frame . . . . . . . . . . . . . . . . . . . . 21 82 7.3. ADD_ADDRESS Frame . . . . . . . . . . . . . . . . . . . . 22 83 7.4. REMOVE_ADDRESS Frame . . . . . . . . . . . . . . . . . . 23 84 7.5. PATHS Frame . . . . . . . . . . . . . . . . . . . . . . . 23 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 86 8.1. Nonce Computation . . . . . . . . . . . . . . . . . . . . 25 87 8.2. Validation of Exchanged Addresses . . . . . . . . . . . . 25 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 89 9.1. QUIC Transport Parameter Registry . . . . . . . . . . . . 26 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 93 11.2. Informative References . . . . . . . . . . . . . . . . . 27 94 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28 95 A.1. Since draft-deconinck-multipath-quic-00 . . . . . . . . . 28 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 98 1. Introduction 100 Endhosts have evolved. Today's endhosts are equipped with several 101 network interfaces and users expect to be able to seamlessly switch 102 from one to another or use them simultaneously to aggregate 103 bandwidth. During the last years, several multipath extensions to 104 transport protocols have been proposed [RFC6824],[MPRTP],[SCTPCMT]. 105 Multipath TCP [RFC6824] is the most mature one. It is already 106 deployed on popular smartphones and for other use cases [RFC8041]. 108 With regular TCP and UDP, all the packets that belong to a given flow 109 contain the same 5-tuple that acts as an identifier for this flow. 110 This prevents such flows from using multiple paths. QUIC 111 [I-D.ietf-quic-transport] does not use the 5-tuple as an implicit 112 connection identifier. A QUIC flow is identified by its Connection 113 ID. This enables QUIC flows to cope with events affecting the 114 5-tuple, such as NAT rebinding or IP address changes. The QUIC 115 connection migration feature, described in more details in 116 [I-D.ietf-quic-transport], is key to migrate a flow from one 5-tuple 117 to another one. This migration feature offers the opportunity for 118 QUIC to use multiple paths. Use cases such as bandwidth aggregation 119 or seamless network handovers would be applicable to QUIC, as they 120 are now with Multipath TCP. A first performance evaluation of such 121 use cases and a comparison between Multipath QUIC and Multipath TCP 122 may be found in [MPQUIC]. 124 In this draft, we leverage many of the lessons learned from the 125 design of Multipath TCP and comments received on the first version of 126 this draft to propose extensions to the current QUIC design to enable 127 it to simultaneously use several paths. This document is organized 128 as follows. It first provides in Section 3 an overview of the 129 operation of Multipath QUIC. It then states changes required in the 130 current QUIC design [I-D.ietf-quic-transport] and specifies in 131 Section 5 the usage of multiple paths. Finally, it discusses some 132 security considerations. 134 2. Conventions and Definitions 136 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this 137 document. It's not shouting; when they are capitalized, they have 138 the special meaning defined in [RFC2119]. 140 We assume that the reader is familiar with the terminology used in 141 the QUIC documents [I-D.ietf-quic-transport]. In addition, we 142 define: 144 o Path: A logical association between two hosts over which packets 145 can be sent. A path is internally identified by a Path ID and 146 uses a potentially changing Connection ID in packets exchanged on 147 that path. 149 o Initial Path: The path used for the establishment of the QUIC 150 connection. The cryptographic handshake is done on this path. It 151 is identified by Path ID 0. 153 2.1. Notational Conventions 155 Packet and frame diagrams use the format described in Section 2.1 of 156 [I-D.ietf-quic-transport], with the following additional convention: 158 x (j) ... Indicates that x uses the variable-length encoding scheme 159 described in Section 5.2. 161 3. Overview 163 The current design of QUIC [I-D.ietf-quic-transport] provides 164 reliable transport with multiplexing and security. A wide range of 165 devices on today's Internet are multihomed. Examples include 166 smartphones equipped with both WiFi and cellular interfaces, but also 167 regular dual-stack hosts that use both IPv4 and IPv6. Experience 168 with Multipath TCP has shown that the ability to combine different 169 paths during the lifetime of a connection provides various benefits 170 including bandwidth aggregation or seamless handovers 171 [RFC8041],[IETFJ]. 173 The current design of QUIC does not enable multihomed devices to 174 efficiently use different paths. We first explain why a multipath 175 extension would be beneficial to QUIC and then describe it at a high 176 level. 178 3.1. What is a Path? 180 Before going into details, let us first define what is called a 181 "path". A path is a UDP flow between two hosts denoted by a 4-tuple 182 (source IP address, destination IP address, source port, destination 183 port). On a smartphone interacting with a single-homed server, the 184 mobile device might want to use one path over the WiFi network and 185 another over the cellular one. Those paths are not necessarily 186 disjoint. For example, when interacting with a dual-stack server, a 187 smartphone may create two paths over the WiFi network, one over IPv4 188 and the other over IPv6. 190 3.2. Beyond Connection Migration 192 Unlike TCP [RFC0793], QUIC is not bound to a particular 4-tuple 193 during the lifetime of a connection. A QUIC connection is identified 194 by a Connection ID, placed in the public header of each QUIC packet. 195 This enables hosts to continue the connection even if the 4-tuple 196 changes due to, e.g., NAT rebinding. This ability to shift a 197 connection from one 4-tuple to another is called Connection 198 Migration. Another of its use cases is fail-over when the address in 199 use fails but another one is available. A mobile device loosing the 200 WiFi connectivity can then continue the connection over its cellular 201 interface. 203 A QUIC connection can thus start on a given path and end on another 204 one. However, the current QUIC design [I-D.ietf-quic-transport] 205 assumes that only one path is in use for a given connection. Instead 206 of switching the 4-tuple for the whole connection, this draft first 207 proposes mechanisms to communicate endhost addresses to the peer. It 208 then leverage the address validation process with the PATH_CHALLENGE 209 and PATH_RESPONSE frames proposed in [I-D.ietf-quic-transport] to 210 verify if additional addresses advertised by the communicating host 211 are available and actually belong to it. In this case, those 212 addresses can be used to create new paths to spread packets over 213 several networks. The example of Figure 1 shows a possible data 214 exchange between a dual-homed client performing a request fitting in 215 two packets and a single-homed server. 217 Server Phone Server 218 via WiFi via LTE 219 ------- ------- ----- 220 | Pkt(CID=A,PN=1,frames=[ | | 221 | STREAM("Request (1/2)")]) | Pkt(CID=B,PN=1,frames=[ | 222 |<------------------------------| STREAM("Request (2/2)")]) | 223 | Pkt(CID=A,PN=1,frames=[ |-------- | 224 | ACK(PID=1,LargestAcked=1)]) | |---------- | 225 |------------------------------>| |---------- | 226 | Pkt(CID=A,PN=2,frames=[ | |-->| 227 | STREAM("Response 1")]) | Pkt(CID=B,PN=1,frames=[ | 228 |------------------------------>| ACK(PID=2,LargestAcked=1), | 229 | | STREAM("Response 2")]) ----| 230 | Pkt(CID=A,PN=2,frames=[ | ----------| | 231 | ACK(PID=1, LargestAcked=2), | ----------| | 232 | ACK(PID=2, LargestAcked=1)]) |<------| | 233 |<------------------------------| | 234 | Pkt(CID=A,PN=3,frames=[ | Pkt(CID=B,PN=2,frames=[ | 235 | STREAM("Response 3")]) | STREAM("Response 4")]) | 236 |------------------------------>| ----| 237 | | ----------| | 238 | ... | ... <---------| | 240 Figure 1: Dataflow with Multipath QUIC 242 The remaining of this section focuses on providing a high-level 243 overview of the multipath operations in QUIC. 245 3.3. Establishment of a Multipath QUIC Connection 247 A Multipath QUIC connection starts like a regular QUIC connection. A 248 cryptographic handshake takes place over Stream ID 0 and follows the 249 classical process [I-D.ietf-quic-transport] [I-D.ietf-quic-tls]. It 250 is during that process that the multipath capability is negotiated 251 between hosts. This is performed using the max_path_id 252 transportparameter, where both hosts advertise the maximum number of 253 paths, in addition to the first one, that they are able to use over 254 the connection. The negotiated value will determine how many bytes 255 will be used to encode the Path ID in frames. If one of the hosts 256 does not advertise the max_path_id transport parameter, the 257 negotiated value is 0, meaning that the QUIC connection will remain 258 single-path. 260 The handshake is performed on a given path. This path is called the 261 Initial path and is identified by Path ID 0. 263 3.4. Architecture of Multipath QUIC 265 Once established, a Multipath QUIC connection is composed of one or 266 more paths. Each path is associated with a different four-tuple and 267 identified by a Path ID, as shown in Figure 2. 269 +---------------------------------------------+ 270 | Connection (MCID) | 271 | +--------+ +--------+ ... +------------+ | 272 | | Path 0 | | Path 1 | | Path N - 1 | | 273 | | Tuple | | Tuple' | ... | Tuple" | | 274 | | PCID | | PCID' | | PCID" | | 275 | | PN | | PN' | | PN" | | 276 | +--------+ +--------+ ... +------------+ | 277 +---------------------------------------------+ 279 Figure 2: Architectural view of Multipath QUIC 281 As described before, a Multipath QUIC connection starts on the 282 Initial Path, identified by Path ID 0. For Multipath QUIC, this 283 draft proposes two levels of Connection IDs. The first one is the 284 Master Connection ID (MCID). It uniquely identifies the connection, 285 as with the current QUIC design. The second one is the Path 286 Connection ID (PCID). Packets belonging to a given path share the 287 same PCID written in the Connection ID field of the public header. 288 The PCID acts as an implicit path identifier for packets. Preventing 289 the linkability of different paths is an important requirement for 290 the multipath extension [I-D.huitema-quic-mpath-req]. Using PCID as 291 implicit path identifier makes this linkability harder than having 292 explicit signaling as in the previous version of this draft and does 293 not require public header change to keep invariants 294 [I-D.ietf-quic-invariants]. The MCID of a connection will be the 295 PCID of the Initial Path. In the example of Figure 1, if the 296 connection started on the WiFi network, then Connection ID A is both 297 the PCID of the WiFi path and the MCID of the connection. 299 In addition to the PCID, some additional information is kept for each 300 path. The Path ID identifies the path at the frame level and ensures 301 uniqueness of the nonce (see Section 8.1 for details). A congestion 302 window is maintained for each path. Hosts can also collect network 303 measurements on a per-path basis, such as round-trip-time 304 measurements and lost packets. 306 3.5. Path Establishment 308 The max_path_id transport parameter exchanged during the 309 cryptographic handshake determines an upper bound on the number of 310 paths that can be created over the connection, in addition to the 311 Initial one. Then, hosts must agree on which paths can be used, and 312 with which Path Connection IDs. Unlike Multipath TCP [RFC6824], the 313 server dynamically controls how many paths can currently be in use. 314 This can be done using a new MAX_PATHS frame indicating how many 315 additional paths can be simultaneously in use. 317 The server proposes new paths with an extended version of the 318 NEW_CONNECTION_ID frame (see Section 6.1). That frame proposes a 319 PCID for a given Path ID. Once the client receives and acknowledges 320 the frame, it can start using the new path by placing the PCID in the 321 Connection ID field of the packets. The server can start using a 322 path once the corresponding NEW_CONNECTION_ID has been acknowledged. 323 Both hosts store the NEW_CONNECTION_ID information in order to cope 324 with the remote trying to use a new path. As frames are encrypted, 325 the establishment of new paths does not leak cleartext identifiers 326 [I-D.huitema-quic-mpath-req]. 328 A server might provide more Path IDs with NEW_CONNECTION_ID frames 329 than the value advertised in the MAX_PATHS frame. This can be useful 330 to cope with migration cases, as described in Section 3.9. In such 331 cases, hosts can only use a subset of the proposed Path IDs. 332 Multipath QUIC is fully symmetrical. Both the client and the server 333 can start using new paths once their corresponding PCID have been 334 negotiated. It might happen that both hosts try to create paths with 335 different Path IDs, such that there are more paths than the 336 advertised number in MAX_PATHS frame. In that case, the paths with 337 the lowest Path IDs will be used while the others will stop. 339 The client is not able to create new paths as long as the server does 340 not send NEW_CONNECTION_ID and MAX_PATHS frames. To limit the 341 latency of the path handshake, the server can send those frames just 342 after the 0-RTT handshake packet. 344 Although a path can be first used by any host, it might not be 345 practical for one of the peers to send an initial packet on new 346 paths. A possible cause is when a server wants to initiate a new 347 path to a client behind a NAT. The client would possibly never 348 receive this packet, leading to connectivity issues on that path. To 349 avoid such issues, a remote address MUST have been validated as 350 described in [I-D.ietf-quic-transport] before sending packets on a 351 path using it. 353 3.6. Exchanging Data over Multiple Paths 355 A QUIC packet acts as a container for one of more frames. Multipath 356 QUIC uses the same STREAM frames as QUIC to carry data. A byte 357 offset is associated to the data payload. One of the key design 358 decision of (Multipath) QUIC is that frames are independent of the 359 packets carrying them. This implies that a frame transmitted over 360 one path could be retransmitted later on another path without any 361 change. 363 The path on which data is sent is a packet-level information. This 364 means a frame can be sent regardless of the path of the packet 365 carrying it. Furthermore, because the data offset is a frame-level 366 information, there is no need to define additional sequence numbers 367 to cope with reordering across paths, unlike Multipath TCP [RFC6824] 368 that uses a Data Sequence Number at the MPTCP level. Other flow 369 control considerations like the stream receive window advertised by 370 the MAX_STREAM_DATA frame remain unchanged when there are multiple 371 paths. 373 However, Multipath QUIC might face reordering at packet-level when 374 using paths having different latencies. The presence of the Path ID 375 in the public header ensures that the packets sent over a given path 376 will contain monotonically increasing packet numbers. To ensure more 377 flexibility and potentially to reduce the ACK block section of the 378 ACK frame when aggregating bandwidth of paths exhibiting different 379 network characteristics, each path keeps its own monotonically 380 increasing Packet Number space. This potentially allows sending up 381 to 2^32 * 2^62 packets on a QUIC connection since each path has its 382 own packet number space. 384 The ACK frame is also modified to allow per-path packet 385 acknowledgments. This remains compliant with the independence 386 between packets and frames while providing more flexibility to hosts 387 to decide on which path they want to send path acknowledgments. 388 Looking again at Figure 1, packets that were sent over a given path 389 (e.g., the response2 packet on path 2 with CID B) can be acknowledged 390 on another path (here, path 1 with CID A) to limit the latency due to 391 ACK transmissions on high-latency paths. Such scheduling decision 392 would not have been possible in Multipath TCP [RFC6824] which must 393 acknowledge data on the path is was received on. 395 3.7. Exchanging Addresses 397 When a multi-homed mobile device connects to a dual-stacked server on 398 its IPv4 address, it is aware of its local addresses (e.g., the WiFi 399 and the cellular ones) and the IPv4 remote address used to establish 400 the QUIC connection. If the client wants to create new paths over 401 IPv6, it needs to learn the other addresses of the remote peer. 403 This is possible with the ADD_ADDRESS frames that are sent by a 404 Multipath QUIC host to advertise its current addresses. Each 405 advertised address is identified by an Address ID. The addresses 406 attached to a host can vary during the lifetime of a Multipath QUIC 407 connection. A new ADD_ADDRESS frame is transmitted when a host has a 408 new address. This ADD_ADDRESS frame is protected as other QUIC 409 control frames, which implies that it cannot be spoofed by attackers. 410 The communicated address is first validated by the receiving host 411 before it starts using it. This ensures that the address actually 412 belongs to the peer and that the peer can send and receive packets on 413 that address. It also prevents hosts from launching amplification 414 attacks to a victim address. 416 If the client is behind a NAT, it could announce a private address in 417 an ADD_ADDRESS frame. In such situations, the server would not be 418 able to validate the communicated address. The client might still 419 use its NATed address to start a new path. To enable the server to 420 make the link between the private and the public addresses, Multipath 421 QUIC provides the PATHS frame that lists current active Path IDs of 422 the sending host. A path is called active when it was created over a 423 validated 4-tuple and is still in use. The frame indicates the local 424 Address ID that the path uses. With this information, the server can 425 then validate the public address and associate the advertised with 426 the perceived addresses. 428 3.8. Coping with Address Removals 430 During the lifetime of a QUIC connection, a host might lose some of 431 its addresses. A concrete example is a smartphone going out of 432 reachability of a WiFi network or shutting off one of its network 433 interfaces. Such address removals are advertised by using 434 REMOVE_ADDRESS frames. The REMOVE_ADDRESS frame contains the Address 435 ID of the lost address previously communicated through ADD_ADDRESS. 437 3.9. Path Migration 439 At a given time, a Multipath QUIC connection gathers a set of paths, 440 each using a 4-tuple. To address privacy issues due to the 441 linkability of addresses with Connection IDs, hosts should avoid 442 changing the 4-tuple used by a path. There remain situations where 443 this change is unavoidable. These can be categorized into two 444 groups: host-aware changes (e.g., network handover from WiFi to 445 cellular) and host-unaware changes (e.g., NAT rebinding). 447 For the host-aware case, let us consider the case of a Multipath QUIC 448 connection where the client is a smartphone with both WiFi and 449 cellular. It advertised both addresses and the server currently 450 enables only one path, the Initial one. The Initial Path uses the 451 WiFi address. Then, for some reason, the WiFi address becomes 452 unusable. To preserve connectivity, the client might then decide to 453 use the cellular address for the Initial Path. It thus sends a 454 REMOVE_ADDRESS announcing the loss of the WiFi address and a PATHS 455 frame to inform that the Initial Path is now using the cellular 456 address. If the cellular address validation succeeds (which could 457 have been done as soon as the cellular address was advertised), the 458 server can continue exchanging data through the cellular address. 460 However, both server and client might want to change the path used on 461 the cellular address for privacy concerns. If the server provides an 462 additional path (e.g., Path ID 42) through NEW_CONNECTION_ID frame at 463 the beginning of the connection, the client can perform the path 464 change directly and avoid using the Initial Path Path Connection ID 465 on the cellular network. This can be done using the PATH_UPDATE 466 frame. It can indicate that the host stopped to use the Initial Path 467 to use Path ID 42 instead. This frame is placed in the first packet 468 sent to the new path with its corresponding PCID. The client can 469 then send the REMOVE_ADDRESS and PATHS frames on this new path. 470 Compared to the previous case, it is harder to link the paths with 471 the IP addresses to observe that they belong to the same Multipath 472 QUIC connection. 474 For the host-unaware case, the situation is similar. In case of NAT 475 rebinding, the server will observe a change in the 2-tuple (source 476 IP, source port) of the packet. The server first validates that the 477 2-tuple actually belongs to the client [I-D.ietf-quic-transport]. If 478 it is the case, the server can send a PATH_UPDATE frame on a 479 previously communicated but unused Path ID. The client might have 480 sent some packets with a given PCID on a different 4-tuple, but the 481 server did not use the given PCID on that 4-tuple. 483 3.10. Congestion Control 485 The QUIC congestion control scheme is defined in 486 [I-D.ietf-quic-recovery]. This congestion control scheme is not 487 suitable when several paths are active. Using the congestion control 488 scheme defined in [I-D.ietf-quic-recovery] with Multipath QUIC would 489 result in unfairness. Each path of a Multipath QUIC connection MUST 490 have its own congestion window. The windows of the different paths 491 MUST be coupled together. Multipath TCP uses the LIA congestion 492 control scheme specified in [RFC6356]. This scheme can immediately 493 be adapted to Multipath QUIC. Other coupled congestion control 494 schemes have been proposed for Multipath TCP such as [OLIA]. 496 4. Mapping Path ID to Connection ID 498 As described in the overview section, hosts need to identify on which 499 path packets are sent. The Path ID must then be inferred from the 500 public header. This is done by using Path Connection ID in addition 501 to the connection Master Connection ID. 503 The Master Connection ID is determined during the cryptographic 504 handshake and actually corresponds to the Connection ID in the 505 current QUIC design [I-D.ietf-quic-transport]. The Path Connection 506 ID of the Initial path (with Path ID 0) is equal to the Master 507 Connection ID. The Path Connection ID of the other paths are 508 determined when the NEW_CONNECTION_ID frames are exchanged. 510 The server MUST ensure that all advertised Path Connection IDs are 511 available for the whole connection lifetime. Once it sends a 512 NEW_CONNECTION_ID frame containing the PCID, the server can start 513 receiving packets with the advertised Connection ID as belonging to 514 the corresponding path. The server MUST wait until the reception of 515 the frame acknowledgment before starting to send packets on that 516 path. 518 Upon reception of the NEW_CONNECTION_ID frame, the client MUST 519 acknowledge it and MUST store the advertised Path Connection ID and 520 the Path ID of the proposed path. It MUST ensure that it can receive 521 packets coming from the server using the PCID and associate it with 522 the corresponding Path ID. 524 5. Using Multiple Paths 526 This section describes in details the multipath operations with the 527 QUIC protocol. 529 5.1. Multipath Negotiation 531 The Multipath Negotiation takes place during the cryptographic 532 handshake with the max_path_id transport parameter. A QUIC 533 connection is initially single-path in QUIC, and all packets prior to 534 handshake completion MUST be exchanged over the Initial Path. During 535 this process, hosts advertise the maximum path ID they are willing to 536 use. The maximum path ID that can be used over a connection is the 537 minimum of both advertised values. If one host does not send the 538 max_path_id transport parameter during the cryptographic handshake, 539 the remote MUST assume a value of 0, leading to a single-path 540 connection over the Initial Path. NEW_CONNECTION_ID frames can later 541 propose Path IDs in the range of max_path_id inclusive. If a client 542 receives a NEW_CONNECTION_ID proposing a Path ID greater than the 543 negotiated maximum value, it MUST trigger a CONNECTION_CLOSE frame 544 with an error code set to 0x10b with a reason phrase describing this 545 issue. 547 5.1.1. Transport Parameter Definition 549 An endhost MAY use the following transport parameter: 551 max_path_id (0x0020): The maximum path ID transport parameter 552 indicates the number of paths in addition to the Initial Path that 553 the host agrees to support over the connection, encoded as an 554 unsigned 32-bit integer. This sets a upper bound on the Path IDs 555 that can be used. The default value for this parameter is 0, 556 meaning that a host omitting this transport parameter does not 557 agree to use multiple paths over the connection. 559 5.2. Variable-Length Encoding of the Path ID 561 From the negotiated maximum Path ID, hosts can infer the amount of 562 bits required to encode the Path ID. If the maximum Path ID is 255, 563 only one byte suffices. Similarly, if one of the hosts wants a 564 single-path connection, either by advertising a max_path_id of 0 or 565 by omitting it, the Path ID field should not be present. 567 +------------------------------+------------------------------+ 568 | Negotiated Max Path ID Range | Path ID Field Length (Bytes) | 569 +------------------------------+------------------------------+ 570 | 0 | 0 | 571 | | | 572 | 1-255 | 1 | 573 | | | 574 | 256-65535 | 2 | 575 | | | 576 | 65536-4294967295 | 4 | 577 +------------------------------+------------------------------+ 579 Table 1: Summary of Path ID Encodings 581 The proposed encoding is summarized in Table 1. 583 Because of security considerations described in Section 8.1, a host 584 reusing packet numbers across paths must limit the number of 585 advertised paths depending on the size of the Initial Value. In 586 particular, a host MUST NOT advertise a max_path_id whose field 587 length exceeds (Initial Value Length) - 8. 589 5.3. Coping with Additional Remote Addresses 591 The usage of multiple networks paths if often done using multiple IP 592 addresses. For instance, a smartphone willing to use both WiFi and 593 LTE will use the corresponding addresses provided by the networks. 594 It can then safely send packets to a previously-used IP address of a 595 server. The server can receive packets with different IPs, but it 596 MUST first validate the new remote IP addresses before starting 597 sending packets to those addresses. 599 Similarly, additional addresses could be communicated using 600 ADD_ADDRESS frames. Such addresses MUST be validated before starting 601 to send packets to them. This requirement is explained in 602 Section 8.2. 604 The validation of an address could be performed with PATH_CHALLENGE 605 and PATH_RESPONSE frames as described in [I-D.ietf-quic-transport]. 606 A validated address MAY be cached for a given host for a limited 607 amount of time. 609 5.4. Path State 611 During the Multipath QUIC connection, hosts maintain some state for 612 paths. Information about the path that hosts are required to store 613 depends on its state. The possible path states are depicted in 614 Figure 3. 616 +----------+ 617 | PROPOSED | 618 +----------+ 619 | 620 | path usage 621 | 622 | restricted by MAX_PATHS 623 v or affected by REMOVE_ADDRESS 624 +--------+ --------------------------> +----------+ 625 | ACTIVE | reusing path | UNUSABLE | 626 +--------+ <-------------------------- +----------+ 627 | | 628 | PATH_UPDATE | 629 +---------------------------------------+ 630 | 631 v 632 +--------+ 633 | CLOSED | 634 +--------+ 636 Figure 3: Finite-State Machine of paths 638 Once a path has been proposed in a NEW_CONNECTION_ID frame, it is in 639 the PROPOSED state. In this situation, hosts MUST keep the following 640 path information: 642 o Path ID: encoded as a 4-byte integer. It uniquely identifies the 643 path in the connection. This value is immutable. 645 o Master Connection ID: encoded as a 8-byte number. It makes the 646 link between the path and the QUIC connection it belongs to. This 647 value is immutable. 649 o Path Connection ID: encoded as a 8-byte integer. It makes the 650 link between the packet's Connection ID field and the path. This 651 value can be updated with subsequent NEW_CONNECTION_ID frames. 653 o Path State: the current state of the path, one of the values 654 presented in Figure 3. 656 Hosts MUST ensure that they can associate a packet with the PCID and 657 its corresponding path at any time, as they must be ready to figure 658 out the path used by the remote host. 660 Either the host received a packet with the corresponding PCID coming 661 from a validated address or it wants to start using the path to a 662 validated address, the path goes to the ACTIVE state. This is the 663 state where a path can be used to send and receive packets. In 664 addition to the fields required in the PROPOSED state, the following 665 elements MUST be tracked: 667 o Packet Number Space: each path is associated with its own 668 monotonically increasing packet number space. Each endpoint 669 maintains a separate packet number for sending and receiving 670 packets. Packet number considerations described in 671 [I-D.ietf-quic-transport] apply within a given path. 673 o Current 4-tuple: the tuple (sIP, dIP, sport, dport) used to send 674 or receive 675 packets over this path. This value is mutable, either because the 676 host decides to change its local address and/or port, or because 677 it receives a packet with a different validated remote address 678 and/or port than the one currently recorded. A host that changes 679 the 4-tuple of a path SHOULD migrate it. 681 o Current (local Address ID, remote Address ID) tuple: those 682 identifiers come from the ADD_ADDRESS sent (local) and received 683 (remote). This enables a host to mark a path as UNUSABLE when, 684 e.g., the remote Address ID is declared as lost in a 685 REMOVE_ADDRESS. The addresses on which the connection was 686 established have Address ID 0. The reception of PATHS frames 687 helps hosts to associate the remote Address ID used by the path. 689 o Performance metrics: basic statistics such as round-trip-time or 690 number of packets sent and received can be collected on a per-path 691 basis. This information can be useful when a host needs to 692 perform packet scheduling decisions and flow control management. 694 It might happen that a path is temporarily unavailable, because one 695 of the endpoint's addresses is no more available or because the 696 server decided to decrease the number of active paths. In such 697 cases, the path is in UNUSABLE state and the host MUST NOT send 698 packets on it. The host keeps the same information as in the ACTIVE 699 state for the path. It might happen that packets are received on 700 that path. If the path is in UNUSABLE state because of a decrease of 701 the active paths, packets MUST be discarded silently. If it is 702 because a REMOVE_ADDRESS was received for the remote Address ID of 703 the path, the host SHOULD validate the remote address first before 704 reusing it. If this validation suceeds, or the number of paths 705 increased again, a path in the UNUSABLE state can go into ACTIVE 706 state, but its congestion window MUST be restarted and its 707 performance metrics SHOULD be reset. 709 Eventually, a path may either be migrated to another one or closed. 710 This is signalled by the PATH_UPDATE frame. In that case, the path 711 is in CLOSED state. In that state, packets MUST NOT be sent or 712 received over it. A host MUST keep the same path state field as in 713 the PROPOSED state, to avoid ambiguities and CLOSED path reuse. 715 5.5. Dynamic Management of Paths 717 The server is the main protagonist in determining how many paths can 718 be used over a Multipath QUIC connection. It is its reponsibility to 719 propose Path IDs with corresponding PCIDs that could be used by the 720 client. In addition, it dynamically controls the number of active 721 paths that can be used for the connection. This is performed by 722 sending the MAX_PATHS frame that sets an upper limit on the number of 723 additional active paths. A host can propose more Path IDs with 724 NEW_CONNECTION_ID frames than the number of additional paths it 725 agrees to use simultaneously. This can be useful in migration 726 scenarios, where the server wants to share a pool of Path IDs that 727 can be directly used to migrate paths. 729 As long as no MAX_PATHS frame was received from the server, the 730 client MUST assume that only one path can be used. At the beginning 731 of the QUIC connection, this means that only the Initial Path can be 732 used. In this case however, during the connection, another path can 733 be used, but the Initial Path MUST have been migrated to it. The 734 server can then increase the value advertised in the MAX_PATHS frame 735 to allow hosts to use new paths among the proposed Path ID pool. 737 By default, the client does not set any limit to the number of paths 738 which can be used. If a client wants to limit the number of 739 (additional) paths the server can use, it can also send a MAX_PATHS 740 frame. In this case, the number of additional paths that can be used 741 over the connection is the minimum between last advertised value from 742 both sides. 744 A host can also decrease the number of paths that can be used over a 745 connection. If this value decreases below the current number of 746 active paths, hosts MUST put in UNUSABLE state the paths in the 747 ACTIVE state with the highest Path IDs. Server and client MUST stop 748 sending packets over UNUSABLE paths once the MAX_PATHS has been sent 749 or received. The host restricting the number of paths SHOULD allow 750 receiving packets on newly UNUSABLE paths for one round-trip-time. 751 After this delay, hosts SHOULD silently discard received packets. 753 When the server proposes more Path IDs than the negotiated maximum 754 number of ACTIVE paths, it might happen that both hosts decide at the 755 same time to create paths with different Path IDs, such as there are 756 more created paths than the negotiated maximum value. In this case, 757 the hosts MUST only keep as ACTIVE the paths with the lowest Path 758 IDs. Paths with the highest Path IDs are in the UNUSABLE state and 759 packets SHOULD be silently discarded. 761 5.6. Loosing Addresses 763 During the lifetime of a connection, a host might lose addresses, 764 e.g., a network interface that was shut down. All the ACTIVE paths 765 that were using that local address MUST be set in the UNUSABLE state. 766 To advertise the address loss to the peer, the host MUST send a 767 REMOVE_ADDRESS frame indicating which Address IDs has been lost. The 768 host MUST also send a PATHS frame indicating the status of the 769 remaining ACTIVE paths. 771 Upon reception of the REMOVE_ADDRESS, the receiving host MUST set the 772 ACTIVE paths affected by the address removal into the UNUSABLE state. 774 The host that locally lost the address MAY reuse one of these paths 775 by changing the assigned 4-tuple. In this case, it MUST send a PATHS 776 frame describing that change. 778 5.7. Scheduling Strategies 780 The current QUIC design [I-D.ietf-quic-transport] offers a two- 781 dimensional scheduling space, i.e., which frames will be packed 782 inside a given packet. With the use of multiple paths, a third 783 dimension is added, i.e., the path on which the packet will be sent. 784 This dimension can have a non negligible impact on the operations of 785 Multipath QUIC, especially if the available paths exhibit very 786 different network characteristics. 788 The progression of the data flow depends on the reception of the 789 MAX_DATA and MAX_STREAM_DATA frames. Those frames SHOULD be 790 duplicated on several or all paths in use. This would limit the 791 head-of-line blocking issue due to the transmission of the frames 792 over a slow path. 794 The path on which ACK frames are sent impacts the peer. The ACK 795 frame is notably used to determine the latency of a path. If the ACK 796 frame is sent on the path it acknowledges, then the peer can compute 797 the round-trip-time of that path. Otherwise, the peer would compute 798 the latency as the sum of the foward delay of the acknowledged path 799 and the return delay of the path used to send the ACK frame. 800 Choosing between acknowledging packets on the same path or on a 801 specific path is up to the implementation. However, hosts SHOULD 802 keep a consistent acknowledgement strategy. Selecting a random path 803 to acknowledge packets will possibly increase the variability of the 804 latency estimation, especially if paths exhibit very different 805 network characteristics. Unlike MAX_DATA and MAX_STREAM_DATA, ACK 806 frames SHOULD NOT be systematically duplicated on several paths as 807 they can induce a large network overhead. 809 6. Modifications to QUIC frames 811 The multipath extension allows hosts to send packets over multiple 812 paths. Since nearly all QUIC frames are independent of packets, no 813 change is required for most of them. The only exceptions are the 814 NEW_CONNECTION_ID and the ACK frames. The NEW_CONNECTION_ID is 815 modified to provide Path Connection ID negotiation for each path. 816 The ACK frame contains packet-level information with the Largest 817 Acknowledged field. Since the Packet Numbers are now associated to 818 paths, the ACK frame must contain the Path ID it acknowledges. 820 6.1. NEW_CONNECTION_ID Frame 822 The NEW_CONNECTION_ID frame (type=0x0b) as defined by 823 [I-D.ietf-quic-transport] keeps its ability to provide the client 824 with alternative connection IDs that can be used to break linkability 825 when migrating connections. It also allows the server to indicate 826 which connection IDs the client must use to take advantage of 827 multiple paths. 829 The NEW_CONNECTION_ID is as follows: 831 0 1 2 3 832 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 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Path ID (j) ... 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Sequence (i) ... 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | | 839 + Connection ID (64) + 840 | | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | | 843 + + 844 | | 845 + Stateless Reset Token (128) + 846 | | 847 + + 848 | | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 Figure 4: NEW_CONNECTION_ID adapted to Multipath QUIC 853 Compared to the frame specified in [I-D.ietf-quic-transport], a Path 854 ID field of variable size is prefixed to associate the Path ID with 855 the Connection ID. If the multipath extension was not negotiated 856 during the connection establishment, the NEW_CONNECTION_ID frame is 857 the same as the one presented in [I-D.ietf-quic-transport]. This 858 frame MUST only be sent by the server. Upon reception of the frame 859 with a specified path ID, the client can start using the new path 860 with the matching Connection ID. 862 A host MUST NOT start using a path if no related NEW_CONNECTION_ID 863 frame has been received (at client side) or acknowledged (at server 864 side). To limit the delay of the multipath usage upon handshake 865 completion, the server SHOULD send NEW_CONNECTION_ID frames for paths 866 it allows using as soon the connection establishment completes. 868 To cope with privacy issues, it should be hard to make the link 869 between two different connections or two different paths of a same 870 connection by just looking at the Connection ID contained in packets. 871 Therefore, Path Connection IDs chosen by the server MUST be random. 873 It might happen that a server proposes a Connection ID in a 874 NEW_CONNECTION_ID frame that is already in use by the client for 875 another connection with another server. In such cases, the client 876 MUST warn the server that this Connection ID is not available and ask 877 for another Connection ID. This request for asking another 878 Connection ID for a particular path will follow the same mechanism as 879 described in [I-D.ietf-quic-transport]. 881 6.2. ACK Frame 883 The format of the modified ACK frame is shown below. 885 0 1 2 3 886 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 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Path ID (j) ... 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Largest Acknowledged (i) ... 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | ACK Delay (i) ... 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | ACK Block Count (i) ... 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | ACK Blocks (*) ... 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 Figure 5: ACK Frame adapted to Multipath 901 Compared to the ACK frame in the current QUIC design 902 [I-D.ietf-quic-transport], the ACK frame is prefixed by a variable 903 size Path ID field indicating to which path the acknowledged PSNs 904 relate to. Notice that if the multipath extension was not negotiated 905 during the connection handshake, the ACK frame is the same as the one 906 presented in [I-D.ietf-quic-transport]. 908 Since frames are independent of packets, and the path notion relates 909 to the packets, the ACK frames can be sent on any path, unlike 910 Multipath TCP [RFC6824] which is constrained to send ACKs on the same 911 path. 913 7. New Frames 915 To support the multipath operations, new frames have been defined to 916 coordinate hosts. This draft uses a type field containing 0x20 to 917 indicate that the frame is related to multipath operations. 919 7.1. MAX_PATHS Frame 921 The MAX_PATHS frame is used by hosts to control the number of paths 922 that can be simultaneously in the ACTIVE state on a given connection. 923 The proposed type for the MAX_PATHS frame is 0x20. A MAX_PATHS frame 924 is shown below. 926 0 1 2 3 927 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 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Sequence (i) ... 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | Num Additional Active Paths (j) ... 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 Figure 6: MAX_PATHS Frame 936 The MAX_PATHS frame contains the following fields: 938 o Sequence: A variable-length integer. This value starts at 0 and 939 increases by 1 for each change of number of active paths that is 940 provided by the host. 942 o Num Additional Active Paths: A variable-length integer indicating 943 how many additional paths can be used over the connection. The 944 number of paths that can be in ACTIVE state is thus (Num 945 Additional Active Paths + 1). 947 Once the connection is established, hosts MUST assume that the server 948 sent a MAX_PATHS frame with sequence -1 and number of additional 949 active paths equal to 0 and the client sent a MAX_PATHS frame with 950 sequence -1 and number of additional active paths equal to the 951 negotiated max_path_id value. 953 7.2. PATH_UPDATE Frame 955 The PATH_UPDATE frame is used by a host either to migrate a path or 956 to close it. This indicates to the remote that the closed path MUST 957 NOT be used anymore and it can use the proposed one instead, if any. 958 The proposed type for the PATH_UPDATE is 0x21. A PATH_UPDATE frame 959 is shown below. 961 0 1 2 3 962 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 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Closed Path ID (j) ... 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Proposed Path ID (j) ... 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 Figure 7: MIGRATE_PATH Frame 971 The MIGRATE_PATH frame contains the following fields: 973 o Closed Path ID: A variable-length integer corresponding to the 974 Path ID of the path that is closed. 976 o Proposed Path ID: A variable-length integer corresponding to the 977 Path ID of the path that substitutes the closed path. If the 978 value is 0, no path is proposed. 980 Upon the transmission or the reception of the PATH_UPDATE frame, the 981 path with the Path ID referenced in Closed Path ID MUST be in the 982 CLOSED state. If the proposed Path ID is different of 0, the path 983 MUST have been either in the PROPOSED or in the UNUSABLE state and 984 MUST now be considered as ACTIVE. 986 7.3. ADD_ADDRESS Frame 988 The ADD_ADDRESS frame is used by a host to advertise its currently 989 reachable addresses. The proposed type for the ADD_ADDRESS frame is 990 0x22. An ADD_ADDRESS frame is shown below. 992 0 1 2 3 993 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 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 |0|0|0|P|IPVers.|Address ID (8) | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | IP Address (32/128) ... 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | [Port (16)] | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 Figure 8: ADD_ADDRESS Frame 1004 The ADD_ADDRESS frame contains the following fields: 1006 o Reserved bits: the three most-significant bits of the first byte 1007 are set to 0, and are reserved for future use. 1009 o P bit: the fourth most-significant bit of the first byte 1010 indicates, if set, the presence of the Port field. 1012 o IPVers.: the remaining four least-significant bits of the first 1013 byte contain the version of the IP address contained in the IP 1014 Address field. 1016 o Address ID: an unique identifier for the advertised address for 1017 tracking and removal purposes. This is needed when, e.g., a NAT 1018 changes the IP address such that both hosts see different IP 1019 addresses for a same path endpoint. 1021 o IP Address: the advertised IP address, in network order. 1023 o Port: this optional field indicates the port number related to the 1024 advertised IP address. When this field is present, it indicates 1025 that a path can use the 2-tuple (IP addr, port). 1027 Upon reception of an ADD_ADDRESS frame, the receiver SHOULD store the 1028 communicated address for future use. The receiver MUST NOT send 1029 packets others than validation ones to the communicated address 1030 without having validated it. ADD_ADDRESS frames SHOULD contain 1031 globally reachable addresses. Link-local and possibly private 1032 addresses SHOULD NOT be exchanged. 1034 7.4. REMOVE_ADDRESS Frame 1036 The REMOVE_ADDRESS frame is used by a host to signal that a 1037 previously announced address was lost. The proposed type for the 1038 REMOVE_ADDRESS frame is 0x23. A REMOVE_ADDRESS frame is shown below. 1040 0 1 2 3 1041 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 1042 +-+-+-+-+-+-+-+-+ 1043 |Address ID (8) | 1044 +-+-+-+-+-+-+-+-+ 1046 Figure 9: REMOVE_ADDRESS Frame 1048 The frame contains only one field, Address ID, being the identifier 1049 of the address to remove. A host SHOULD stop using paths using the 1050 removed address and set them in the UNUSABLE state. If the 1051 REMOVE_ADDRESS contains an Address ID that was not previously 1052 announced, the receiver MUST silently ignore the frame. 1054 7.5. PATHS Frame 1056 The PATHS frame communicates the paths state of the sending host to 1057 the peer. It allows the sender to communicate its active paths to 1058 the peer in order to detect potential connectivity issue over paths. 1059 Its proposed type is 0x24. The format of the PATHS frame is shown 1060 below. 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Sequence (i) ... 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | ActivePaths (j) ... 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Path Info Section (*) ... 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 Figure 10: PATHS Frame 1074 The PATHS frame contains the following fields: 1076 o Sequence: A variable-length integer. This value starts at 0 and 1077 increases by 1 for each PATHS frame sent by the host. It allows 1078 identifying the most recent PATHS frame. 1080 o ActivePaths: the current number of additional paths considered as 1081 being active from the sender point of view, i.e., (the number of 1082 active paths - 1). ActivePaths MUST be lower or equal to the last 1083 value advertised by MAX_PATHS frame. 1085 o Path Info Section: contains information about all the active paths 1086 (i.e., there are ActivePaths + 1 entries). The format of this 1087 section is shown below. 1089 0 1 2 3 1090 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 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | Path ID 0 (j) ... 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 |LocAddrID 0 (8)| 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 ... 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Path ID N (j) ... 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 |LocAddrID N (8)| 1101 +-+-+-+-+-+-+-+-+ 1103 Figure 11: Path Info Section 1105 The fields in the Path Info Section are: 1107 o Path ID: the Path ID of the active path the sending host provides 1108 information about. 1110 o LocAddrID: the local Address ID of the address currently used by 1111 the path. 1113 The Path Info section only contains the Local Address ID so far, but 1114 this section can be extended later with other potentially useful 1115 information. 1117 8. Security Considerations 1119 8.1. Nonce Computation 1121 With Multipath QUIC, each path has its own packet number space. With 1122 the current nonce computation [I-D.ietf-quic-tls], using twice the 1123 same packet number over two different paths leads to the same 1124 cryptographic nonce. Depending on the size of the Initial Value (and 1125 hence the nonce), there are two ways to mitigate this issue. 1127 If the Initial Value has a length of 8 bytes, then a packet number 1128 used on a given path MUST NOT be reused on another path of the 1129 connection, and therefore at most 2^64 packets can be sent on a QUIC 1130 connection. This means there will be packet number skipping at path 1131 level, but the packet number will remain monotonically increasing on 1132 each path. 1134 If the Initial Value has a length of 9 or more, then the 1135 cryptographic nonce computation is now performed as follows. The 1136 nonce, N, is formed by combining the packet protection IV (either 1137 client_pp_iv_n or server_pp_iv_n) with the Path ID and the packet 1138 number. The 64 bits of the reconstructed QUIC packet number in 1139 network byte order is left-padded with zeros to the size of the IV. 1140 The Path ID encoded in its variable-length format described in 1141 Section 5.2 is right-padded with zeros to the size of the IV. The 1142 Path IV is computed as the exclusive OR of the padded Path ID and the 1143 IV. The exclusive OR of the padded packet number and the Path IV 1144 forms the AEAD nonce. 1146 8.2. Validation of Exchanged Addresses 1148 To use addresses communicated by the peer through ADD_ADDRESS frames, 1149 hosts are required to validate them before using paths to these 1150 addresses. The main reason for this validation is that the remote 1151 host might have sent, purposely or not, a packet with a source IP 1152 that does not correspond to the IP of the remote interface. This 1153 could lead to amplification attacks where the client start using a 1154 new path with a source IP corresponding to the victim's one. Without 1155 validation, the server might then flood the victim. Similarly for 1156 ADD_ADDRESS frames, a malicious server might advertise the IP address 1157 of a victim, hoping that the client will use it without validating it 1158 before. 1160 9. IANA Considerations 1162 9.1. QUIC Transport Parameter Registry 1164 This document defines a new transport parameter for the negotiation 1165 of multiple paths. The following entry in Table 2 should be added to 1166 the "QUIC Transport Parameters" registry under the "QUIC Protocol" 1167 heading. 1169 +--------+----------------+---------------+ 1170 | Value | Parameter Name | Specification | 1171 +--------+----------------+---------------+ 1172 | 0x0020 | max_path_id | Section 5.1.1 | 1173 +--------+----------------+---------------+ 1175 Table 2: Addition to QUIC Transport Parameters Entries 1177 10. Acknowledgements 1179 We would like to thanks Masahiro Kozuka and Kazuho Oku for their 1180 numerous comments on the first version of this draft. We also thanks 1181 Philipp Tiesel for his early comments that led to the current design. 1182 We also want to thanks Christian Huitema for his draft about 1183 multipath requirements to identify critical elements about the 1184 multipath feature. 1186 11. References 1188 11.1. Normative References 1190 [I-D.ietf-quic-invariants] 1191 Thomson, M., "Version-Independent Properties of QUIC", 1192 draft-ietf-quic-invariants-00 (work in progress), February 1193 2018. 1195 [I-D.ietf-quic-recovery] 1196 Iyengar, J. and I. Swett, "QUIC Loss Detection and 1197 Congestion Control", draft-ietf-quic-recovery-09 (work in 1198 progress), January 2018. 1200 [I-D.ietf-quic-tls] 1201 Thomson, M. and S. Turner, "Using Transport Layer Security 1202 (TLS) to Secure QUIC", draft-ietf-quic-tls-10 (work in 1203 progress), March 2018. 1205 [I-D.ietf-quic-transport] 1206 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1207 and Secure Transport", draft-ietf-quic-transport-10 (work 1208 in progress), March 2018. 1210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1211 Requirement Levels", BCP 14, RFC 2119, 1212 DOI 10.17487/RFC2119, March 1997, . 1215 11.2. Informative References 1217 [Cellnet] Paasch, C., Detal, G., Duchene, F., Raiciu, C., and O. 1218 Bonaventure, "Exploring Mobile/WiFi Handover with 1219 Multipath TCP", ACM SIGCOMM workshop on Cellular Networks 1220 (Cellnet'12) , 2012. 1222 [I-D.huitema-quic-mpath-req] 1223 Huitema, C., "QUIC Multipath Requirements", draft-huitema- 1224 quic-mpath-req-01 (work in progress), January 2018. 1226 [IETFJ] Bonaventure, O. and S. Seo, "Multipath TCP Deployments", 1227 IETF Journal , November 2016. 1229 [MPQUIC] De Coninck, Q. and O. Bonaventure, "Multipath QUIC: Design 1230 and Evaluation", 13th International Conference on emerging 1231 Networking EXperiments and Technologies (CoNEXT 2017). 1232 http://multipath-quic.org , December 2017. 1234 [MPRTP] Singh, V., Ahsan, S., and J. Ott, "MPRTP: Multipath 1235 considerations for real-time media", Proceedings of the 1236 4th ACM Multimedia Systems Conference , 2013. 1238 [OLIA] Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J. 1239 Le Boudec, "MPTCP is not pareto-optimal: performance 1240 issues and a possible solution", Proceedings of the 8th 1241 international conference on Emerging networking 1242 experiments and technologies, ACM , 2012. 1244 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1245 RFC 793, DOI 10.17487/RFC0793, September 1981, 1246 . 1248 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 1249 Congestion Control for Multipath Transport Protocols", 1250 RFC 6356, DOI 10.17487/RFC6356, October 2011, 1251 . 1253 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1254 "TCP Extensions for Multipath Operation with Multiple 1255 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1256 . 1258 [RFC8041] Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and 1259 Operational Experience with Multipath TCP", RFC 8041, 1260 DOI 10.17487/RFC8041, January 2017, . 1263 [SCTPCMT] Iyengar, J., Amer, P., and R. Stewart, "Concurrent 1264 multipath transfer using SCTP multihoming over independent 1265 end-to-end paths", IEEE/ACM Transactions on networking, 1266 Vol. 14, no 5 , 2006. 1268 Appendix A. Change Log 1270 A.1. Since draft-deconinck-multipath-quic-00 1272 o Added PATH_UPDATE frame 1274 o Added MAX_PATHS frame 1276 o No more packet header change 1278 o Implicit Path ID notification using Connection ID and 1279 NEW_CONNECTION_ID 1280 frames 1282 o Variable-length encoding for Path ID 1284 o Updated text to match draft-ietf-quic-transport-10 1286 o Fixed various typos 1288 Authors' Addresses 1290 Quentin De Coninck 1291 UCLouvain 1293 Email: quentin.deconinck@uclouvain.be 1295 Olivier Bonaventure 1296 UCLouvain 1298 Email: Olivier.Bonaventure@uclouvain.be