idnits 2.17.1 draft-deconinck-quic-multipath-01.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 (September 4, 2018) is 2032 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 1169, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-quic-invariants-01 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-14 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-14 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-14 -- 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: March 8, 2019 September 4, 2018 7 Multipath Extension for QUIC 8 draft-deconinck-quic-multipath-01 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 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 March 8, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 4 58 3.3. Establishment of a Multipath QUIC Connection . . . . . . 6 59 3.4. Architecture of Multipath QUIC . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . 9 64 3.9. Path Migration . . . . . . . . . . . . . . . . . . . . . 10 65 3.10. Congestion Control . . . . . . . . . . . . . . . . . . . 11 66 4. Mapping Path ID to Connection IDs . . . . . . . . . . . . . . 11 67 5. Using Multiple Paths . . . . . . . . . . . . . . . . . . . . 11 68 5.1. Multipath Negotiation . . . . . . . . . . . . . . . . . . 12 69 5.1.1. Transport Parameter Definition . . . . . . . . . . . 12 70 5.2. Coping with Additional Remote Addresses . . . . . . . . . 12 71 5.3. Path State . . . . . . . . . . . . . . . . . . . . . . . 13 72 5.4. Dynamic Management of Paths . . . . . . . . . . . . . . . 15 73 5.5. Loosing Addresses . . . . . . . . . . . . . . . . . . . . 16 74 5.6. Scheduling Strategies . . . . . . . . . . . . . . . . . . 16 75 6. Modifications to QUIC frames . . . . . . . . . . . . . . . . 17 76 6.1. NEW_CONNECTION_ID Frame . . . . . . . . . . . . . . . . . 17 77 6.2. ACK Frame . . . . . . . . . . . . . . . . . . . . . . . . 18 78 7. New Frames . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 7.1. MAX_PATHS Frame . . . . . . . . . . . . . . . . . . . . . 19 80 7.2. PATH_UPDATE Frame . . . . . . . . . . . . . . . . . . . . 19 81 7.3. ADD_ADDRESS Frame . . . . . . . . . . . . . . . . . . . . 20 82 7.4. REMOVE_ADDRESS Frame . . . . . . . . . . . . . . . . . . 21 83 7.5. PATHS Frame . . . . . . . . . . . . . . . . . . . . . . . 22 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 85 8.1. Nonce Computation . . . . . . . . . . . . . . . . . . . . 23 86 8.2. Validation of Exchanged Addresses . . . . . . . . . . . . 24 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 88 9.1. QUIC Transport Parameter Registry . . . . . . . . . . . . 24 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 92 11.2. Informative References . . . . . . . . . . . . . . . . . 25 93 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26 94 A.1. Since draft-deconinck-quic-multipath-00 . . . . . . . . . 26 95 A.2. Since draft-deconinck-multipath-quic-00 . . . . . . . . . 27 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 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 two Connection 113 IDs. 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]. 158 3. Overview 160 The current design of QUIC [I-D.ietf-quic-transport] provides 161 reliable transport with multiplexing and security. A wide range of 162 devices on today's Internet are multihomed. Examples include 163 smartphones equipped with both WiFi and cellular interfaces, but also 164 regular dual-stack hosts that use both IPv4 and IPv6. Experience 165 with Multipath TCP has shown that the ability to combine different 166 paths during the lifetime of a connection provides various benefits 167 including bandwidth aggregation or seamless handovers 168 [RFC8041],[IETFJ]. 170 The current design of QUIC does not enable multihomed devices to 171 efficiently use different paths. We first explain why a multipath 172 extension would be beneficial to QUIC and then describe it at a high 173 level. 175 3.1. What is a Path? 177 Before going into details, let us first define what is called a 178 "path". A path is a UDP flow between two hosts denoted by a 4-tuple 179 (source IP address, destination IP address, source port, destination 180 port). On a smartphone interacting with a single-homed server, the 181 mobile device might want to use one path over the WiFi network and 182 another over the cellular one. Those paths are not necessarily 183 disjoint. For example, when interacting with a dual-stack server, a 184 smartphone may create two paths over the WiFi network, one over IPv4 185 and the other over IPv6. 187 3.2. Beyond Connection Migration 189 Unlike TCP [RFC0793], QUIC is not bound to a particular 4-tuple 190 during the lifetime of a connection. A QUIC connection is identified 191 by a Connection ID, placed in the public header of each QUIC packet. 192 This enables hosts to continue the connection even if the 4-tuple 193 changes due to, e.g., NAT rebinding. This ability to shift a 194 connection from one 4-tuple to another is called Connection 195 Migration. Another of its use cases is fail-over when the address in 196 use fails but another one is available. A mobile device loosing the 197 WiFi connectivity can then continue the connection over its cellular 198 interface. 200 A QUIC connection can thus start on a given path and end on another 201 one. However, the current QUIC design [I-D.ietf-quic-transport] 202 assumes that only one path is in use for a given connection. Instead 203 of switching the 4-tuple for the whole connection, this draft first 204 proposes mechanisms to communicate endhost addresses to the peer. It 205 then leverage the address validation process with the PATH_CHALLENGE 206 and PATH_RESPONSE frames proposed in [I-D.ietf-quic-transport] to 207 verify if additional addresses advertised by the communicating host 208 are available and actually belong to it. In this case, those 209 addresses can be used to create new paths to spread packets over 210 several networks. The example of Figure 1 shows a possible data 211 exchange between a dual-homed client performing a request fitting in 212 two packets and a single-homed server. 214 Server Phone Server 215 via WiFi via LTE 216 ------- ------- ----- 217 | Pkt(DCID=B,PN=1,frames=[ | | 218 | STREAM("Request (1/2)")]) | Pkt(DCID=D,PN=1,frames=[ | 219 |<-------------------------------| STREAM("Request (2/2)")]) | 220 | Pkt(DCID=A,PN=1,frames=[ |-------- | 221 | ACK(PID=1,LargestAcked=1)]) | |---------- | 222 |------------------------------->| |---------- | 223 | Pkt(DCID=B,PN=2,frames=[ | |--->| 224 | STREAM("Response 1")]) | Pkt(DCID=C,PN=1,frames=[ | 225 |------------------------------->| ACK(PID=2,LargestAcked=1), | 226 | | STREAM("Response 2")]) -----| 227 | Pkt(DCID=A,PN=2,frames=[ | ----------| | 228 | ACK(PID=1, LargestAcked=2), | ----------| | 229 | ACK(PID=2, LargestAcked=1)]) |<------| | 230 |<-------------------------------| | 231 | Pkt(DCID=B,PN=3,frames=[ | Pkt(DCID=D,PN=2,frames=[ | 232 | STREAM("Response 3")]) | STREAM("Response 4")]) | 233 |------------------------------->| ----| 234 | | ---------| | 235 | ... | ... <---------| | 237 Figure 1: Dataflow with Multipath QUIC 239 The remaining of this section focuses on providing a high-level 240 overview of the multipath operations in QUIC. 242 3.3. Establishment of a Multipath QUIC Connection 244 A Multipath QUIC connection starts like a regular QUIC connection. A 245 cryptographic handshake takes place with CRYPTO frames and follows 246 the classical process [I-D.ietf-quic-transport] [I-D.ietf-quic-tls]. 247 It is during that process that the multipath capability is negotiated 248 between hosts. This is performed using the max_paths transport 249 parameter, where both hosts advertise their support for the multipath 250 extension, by indicating how many paths can be simultaneously in use. 251 Any value different from 0 indicates that the host wants to support 252 multipath over the connection. If one of the hosts does not 253 advertise the max_paths transport parameter, the negotiated value is 254 0, meaning that the QUIC connection will not use the multipath 255 extension presented in this draft. 257 The handshake is performed on a given path. This path is called the 258 Initial path and is identified by Path ID 0. 260 3.4. Architecture of Multipath QUIC 262 Once established, a Multipath QUIC connection is composed of one or 263 more paths. Each path is associated with a different four-tuple and 264 identified by a Path ID, as shown in Figure 2. 266 +-----------------------------------------------+ 267 | Connection (MSCID, MDCID) | 268 | +---------+ +---------+ ... +------------+ | 269 | | Path 0 | | Path 1 | | Path N - 1 | | 270 | | Tuple | | Tuple' | ... | Tuple" | | 271 | | PSCID | | PSCID' | | PSCID" | | 272 | | PDCID | | PDCID' | ... | PDCID" | | 273 | | PN | | PN' | | PN" | | 274 | +---------+ +---------+ ... +------------+ | 275 +-----------------------------------------------+ 277 Figure 2: Architectural view of Multipath QUIC 279 As described before, a Multipath QUIC connection starts on the 280 Initial Path, identified by Path ID 0. For Multipath QUIC, this 281 draft proposes two levels of asymetric Connection IDs. The first 282 ones are the Master Connection IDs (MCIDs). Both the Master Source 283 Connection ID (MSCID) and the Master Destination Connection ID 284 (MDCID) uniquely identify the connection, as with the current QUIC 285 design. The second ones are the Path Connection IDs (PCIDs). 286 Packets belonging to a given path share the same Path Source 287 Connection ID (PSCID) and Path Destination Connection ID (PDCID) 288 written in the Connection ID field of the public header. The PCIDs 289 act as the implicit path identifiers for packets. Preventing the 290 linkability of different paths is an important requirement for the 291 multipath extension [I-D.huitema-quic-mpath-req]. Using PCIDs as 292 implicit path identifier makes this linkability harder than having 293 explicit signaling as in the early version of this draft and does not 294 require public header change to keep invariants 295 [I-D.ietf-quic-invariants]. The MCIDs of a connection will be the 296 PCIDs of the Initial Path. In the example of Figure 1, if the 297 connection started on the WiFi network, then the Source Connection ID 298 A is both the PSCID of the WiFi path and the MSCID of the connection. 300 In addition to the PCIDs, some additional information is kept for 301 each path. The Path ID identifies the path at the frame level and 302 ensures uniqueness of the nonce (see Section 8.1 for details). A 303 congestion window is maintained for each path. Hosts can also 304 collect network measurements on a per-path basis, such as round-trip- 305 time measurements and lost packets. 307 3.5. Path Establishment 309 The max_paths transport parameter exchanged during the cryptographic 310 handshake determines how many paths can be simultaneously used. The 311 lowest advertised value is the negotiated one. Then, hosts must 312 agree on which paths can be used, and with which Path Connection IDs. 313 Unlike Multipath TCP [RFC6824], both hosts dynamically control how 314 many paths can currently be in use, i.e., the handshake only defines 315 the initial value. This can be done using a new MAX_PATHS frame 316 indicating how many paths can be simultaneously in use. 318 Hosts propose new paths with an extended version of the 319 NEW_CONNECTION_ID frame (see Section 6.1). This frame proposes an 320 PDCID for a given Path ID. Once both hosts proposed a PDCID to their 321 peer and received the acknowledgment for the related 322 NEW_CONNECTION_ID, the path ID can be used to send packets. Both 323 hosts store the NEW_CONNECTION_ID information in order to cope with 324 the remote trying to use a new path. As frames are encrypted, the 325 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 PCIDs 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 Hosts are not able to create new paths as long as the peer does not 340 send NEW_CONNECTION_ID and MAX_PATHS frames. To limit the latency of 341 the path handshake, hosts should send those frames as soon as 342 possible, i.e., just 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 different 375 Path Connection IDs 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^62 * 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 DCID C) can be 390 acknowledged on another path (here, path 1 with DCID A) to limit the 391 latency due to ACK transmissions on high-latency paths. Such 392 scheduling decision would not have been possible in Multipath TCP 393 [RFC6824] which must 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 Connection ID on the 465 cellular network. This can be done using the PATH_UPDATE frame. It 466 can indicate that the host stopped to use the Initial Path to use 467 Path ID 42 instead. This frame is placed in the first packet sent to 468 the new path with its corresponding PCID. The client can then send 469 the REMOVE_ADDRESS and PATHS frames on this new path. Compared to 470 the previous case, it is harder to link the paths with the IP 471 addresses to observe that they belong to the same Multipath QUIC 472 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 IDs 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 IDs in addition 501 to Master Connection IDs. 503 The Master Connection IDs is determined during the cryptographic 504 handshake and actually corresponds to both Connection IDs in the 505 current QUIC design [I-D.ietf-quic-transport]. The Path Connection 506 IDs of the Initial path (with Path ID 0) are equal to the Master 507 Connection IDs. The Path Connection IDs 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 a 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 Destination Path 520 Connection ID and the Path ID of the proposed path. It MUST ensure 521 that it can receive packets coming from the server using the PCID and 522 associate it with 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_paths transport parameter. A QUIC connection 533 is initially single-path in QUIC, and all packets prior to handshake 534 completion MUST be exchanged over the Initial Path. During this 535 process, hosts advertise their support for multipath operations. Any 536 value different from 0 indicates that the host supports multipath 537 operations over the connection. If one host does not send the 538 max_paths transport parameter during the cryptographic handshake, the 539 remote MUST assume a value of 0, leading to a single-path connection 540 over the Initial Path. NEW_CONNECTION_ID frames can later propose 541 Path IDs that can then be used for the connection. 543 5.1.1. Transport Parameter Definition 545 An endhost MAY use the following transport parameter: 547 max_paths (0x0020): The maximum number of paths that can be 548 simultaneously active, encoded as an unsigned 16-bit integer. The 549 default value for this parameter is 0, meaning that a host 550 omitting this transport parameter does not agree to use the 551 multipath extension over the connection. 553 5.2. Coping with Additional Remote Addresses 555 The usage of multiple networks paths is often done using multiple IP 556 addresses. For instance, a smartphone willing to use both WiFi and 557 LTE will use the corresponding addresses provided by the networks. 558 It can then safely send packets to a previously-used IP address of a 559 server. The server can receive packets with different IPs, but it 560 MUST first validate the new remote IP addresses before starting 561 sending packets to those addresses. 563 Similarly, additional addresses could be communicated using 564 ADD_ADDRESS frames. Such addresses MUST be validated before starting 565 to send packets to them. This requirement is explained in 566 Section 8.2. 568 The validation of an address could be performed with PATH_CHALLENGE 569 and PATH_RESPONSE frames as described in [I-D.ietf-quic-transport]. 570 A validated address MAY be cached for a given host for a limited 571 amount of time. 573 5.3. Path State 575 During the Multipath QUIC connection, hosts maintain some state for 576 paths. Information about the path that hosts are required to store 577 depends on its state. The possible path states are depicted in 578 Figure 3. 580 +----------+ 581 | PROPOSED | 582 +----------+ 583 | both hosts exchanged PCIDs for the path 584 v 585 +----------+ 586 | READY | 587 +----------+ 588 | 589 | path usage 590 | 591 | restricted by MAX_PATHS 592 v or affected by REMOVE_ADDRESS 593 +--------+ --------------------------> +----------+ 594 | ACTIVE | reusing path | UNUSABLE | 595 +--------+ <-------------------------- +----------+ 596 | | 597 | PATH_UPDATE | 598 +---------------------------------------+ 599 | 600 v 601 +--------+ 602 | CLOSED | 603 +--------+ 605 Figure 3: Finite-State Machine of paths 607 Once a path has been proposed in a NEW_CONNECTION_ID frame, either 608 sent or received, it is in the PROPOSED state. In this situation, 609 hosts MUST keep the following path information: 611 o Path ID: encoded as a 4-byte integer. It uniquely identifies the 612 path in the connection. This value is immutable. 614 o Master Connection IDs: they make the link between the path and the 615 QUIC 616 connection it belongs to. These values are immutable. 618 o Path Connection IDs: they make the link between the packet's 619 Connection ID field and the path. This value can be updated with 620 subsequent NEW_CONNECTION_ID frames. 622 o Path State: the current state of the path, one of the values 623 presented in Figure 3. 625 Once both hosts exchanged both asymetric PCIDs for a given Path ID, 626 the path enters the READY state. In this state, hosts MUST ensure 627 that they can associate a packet with the PCIDs and its corresponding 628 path at any time, as they must be ready to figure out the path used 629 by the remote host. 631 Either the host received a packet with the corresponding PCIDs coming 632 from a validated address or it wants to start using the path to a 633 validated address, the path goes to the ACTIVE state. This is the 634 state where a path can be used to send and receive packets. In 635 addition to the fields required in the PROPOSED state, the following 636 elements MUST be tracked: 638 o Packet Number Space: each path is associated with its own 639 monotonically increasing packet number space. Each endpoint 640 maintains a separate packet number for sending and receiving 641 packets. Packet number considerations described in 642 [I-D.ietf-quic-transport] apply within a given path. 644 o Current 4-tuple: the tuple (sIP, dIP, sport, dport) used to send 645 or receive 646 packets over this path. This value is mutable, either because the 647 host decides to change its local address and/or port, or because 648 it receives a packet with a different validated remote address 649 and/or port than the one currently recorded. A host that changes 650 the 4-tuple of a path SHOULD migrate it. 652 o Current (local Address ID, remote Address ID) tuple: those 653 identifiers come from the ADD_ADDRESS sent (local) and received 654 (remote). This enables a host to mark a path as UNUSABLE when, 655 e.g., the remote Address ID is declared as lost in a 656 REMOVE_ADDRESS. The addresses on which the connection was 657 established have Address ID 0. The reception of PATHS frames 658 helps hosts to associate the remote Address ID used by the path. 660 o Performance metrics: basic statistics such as round-trip-time or 661 number of packets sent and received can be collected on a per-path 662 basis. This information can be useful when a host needs to 663 perform packet scheduling decisions and flow control management. 665 It might happen that a path is temporarily unavailable, because one 666 of the endpoint's addresses is no more available or because the 667 server decided to decrease the number of active paths. In such 668 cases, the path is in UNUSABLE state and the host MUST NOT send 669 packets on it. The host keeps the same information as in the ACTIVE 670 state for the path. It might happen that packets are received on 671 that path. If the path is in UNUSABLE state because of a decrease of 672 the active paths, packets MUST be discarded silently. If it is 673 because a REMOVE_ADDRESS was received for the remote Address ID of 674 the path, the host SHOULD validate the remote address first before 675 reusing it. If this validation suceeds, or the number of paths 676 increased again, a path in the UNUSABLE state can go into ACTIVE 677 state, but its congestion window MUST be restarted and its 678 performance metrics SHOULD be reset. 680 Eventually, a path may either be migrated to another one or closed. 681 This is signalled by the PATH_UPDATE frame. In that case, the path 682 is in CLOSED state. In that state, packets MUST NOT be sent or 683 received over it. A host MUST keep the same path state field as in 684 the PROPOSED state, to avoid ambiguities and CLOSED path reuse. 686 5.4. Dynamic Management of Paths 688 Both hosts determine how many paths can be used over a Multipath QUIC 689 connection. It is their reponsibility to propose Path IDs with 690 corresponding PCIDs that could be used by the peer. In addition, 691 they dynamically control the number of active paths that can be used 692 for the connection, initially determined during the handshake with 693 the max_paths transport parameter. This is performed by sending 694 MAX_PATHS frames that set an upper limit on the number of active 695 paths. At any time, the maximum number of active paths that could be 696 present over a connection is the minimum value advertised by peers. 697 A host can propose more Path IDs with NEW_CONNECTION_ID frames than 698 the number of paths it agrees to use simultaneously. This can be 699 useful in migration scenarios, where the host wants to share a pool 700 of Path IDs that can be directly used to migrate paths. 702 A host can also decrease the number of paths that can be used over a 703 connection. If this value decreases below the current number of 704 active paths, hosts MUST put in UNUSABLE state the paths in the 705 ACTIVE state with the highest Path IDs. Server and client MUST stop 706 sending packets over UNUSABLE paths once the MAX_PATHS has been sent 707 or received. The host restricting the number of paths SHOULD allow 708 receiving packets on newly UNUSABLE paths for one round-trip-time. 709 After this delay, hosts SHOULD silently discard received packets. 711 When the server proposes more Path IDs than the negotiated maximum 712 number of ACTIVE paths, it might happen that both hosts decide at the 713 same time to create paths with different Path IDs, such as there are 714 more created paths than the negotiated maximum value. In this case, 715 the hosts MUST only keep as ACTIVE the paths with the lowest Path 716 IDs. Paths with the highest Path IDs are in the UNUSABLE state and 717 packets SHOULD be silently discarded. 719 5.5. Loosing Addresses 721 During the lifetime of a connection, a host might lose addresses, 722 e.g., a network interface that was shut down. All the ACTIVE paths 723 that were using that local address MUST be set in the UNUSABLE state. 724 To advertise the address loss to the peer, the host MUST send a 725 REMOVE_ADDRESS frame indicating which Address IDs has been lost. The 726 host MUST also send a PATHS frame indicating the status of the 727 remaining ACTIVE paths. 729 Upon reception of the REMOVE_ADDRESS, the receiving host MUST set the 730 ACTIVE paths affected by the address removal into the UNUSABLE state. 732 The host that locally lost the address MAY reuse one of these paths 733 by changing the assigned 4-tuple. In this case, it MUST send a PATHS 734 frame describing that change. 736 5.6. Scheduling Strategies 738 The current QUIC design [I-D.ietf-quic-transport] offers a two- 739 dimensional scheduling space, i.e., which frames will be packed 740 inside a given packet. With the use of multiple paths, a third 741 dimension is added, i.e., the path on which the packet will be sent. 742 This dimension can have a non negligible impact on the operations of 743 Multipath QUIC, especially if the available paths exhibit very 744 different network characteristics. 746 The progression of the data flow depends on the reception of the 747 MAX_DATA and MAX_STREAM_DATA frames. Those frames SHOULD be 748 duplicated on several or all paths in use. This would limit the 749 head-of-line blocking issue due to the transmission of the frames 750 over a slow path. 752 The path on which ACK frames are sent impacts the peer. The ACK 753 frame is notably used to determine the latency of a path. If the ACK 754 frame is sent on the path it acknowledges, then the peer can compute 755 the round-trip-time of that path. Otherwise, the peer would compute 756 the latency as the sum of the foward delay of the acknowledged path 757 and the return delay of the path used to send the ACK frame. 758 Choosing between acknowledging packets on the same path or on a 759 specific path is up to the implementation. However, hosts SHOULD 760 keep a consistent acknowledgement strategy. Selecting a random path 761 to acknowledge packets will possibly increase the variability of the 762 latency estimation, especially if paths exhibit very different 763 network characteristics. Unlike MAX_DATA and MAX_STREAM_DATA, ACK 764 frames SHOULD NOT be systematically duplicated on several paths as 765 they can induce a large network overhead. 767 6. Modifications to QUIC frames 769 The multipath extension allows hosts to send packets over multiple 770 paths. Since nearly all QUIC frames are independent of packets, no 771 change is required for most of them. The only exceptions are the 772 NEW_CONNECTION_ID and the ACK frames. The NEW_CONNECTION_ID is 773 modified to provide Path Connection ID negotiation for each path. 774 The ACK frame contains packet-level information with the Largest 775 Acknowledged field. Since the Packet Numbers are now associated to 776 paths, the ACK frame must contain the Path ID it acknowledges. 778 6.1. NEW_CONNECTION_ID Frame 780 The NEW_CONNECTION_ID frame (type=0x0b) as defined by 781 [I-D.ietf-quic-transport] keeps its ability to provide the client 782 with alternative connection IDs that can be used to break linkability 783 when migrating connections. It also allows the server to indicate 784 which connection IDs the client must use to take advantage of 785 multiple paths. 787 The NEW_CONNECTION_ID is as follows: 789 0 1 2 3 790 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 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Path ID (i) ... 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Sequence (i) ... 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Length (8) | Connection ID (32..144) ... 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | | 799 + + 800 | | 801 + Stateless Reset Token (128) + 802 | | 803 + + 804 | | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 Figure 4: NEW_CONNECTION_ID adapted to Multipath QUIC 809 Compared to the frame specified in [I-D.ietf-quic-transport], a Path 810 ID field of variable size is prefixed to associate the Path ID with 811 the Connection ID. If the multipath extension was not negotiated 812 during the connection establishment, the NEW_CONNECTION_ID frame is 813 the same as the one presented in [I-D.ietf-quic-transport]. This 814 frame can be sent by both hosts. Upon reception of the frame with a 815 specified path ID, the peer can update the related path state either 816 to PROPOSED or READY and store the communicated Connection ID as the 817 Destination Connection ID of the path. 819 A host MUST NOT start using a path as long as both peers have not 820 proposed their Destination Connection ID with NEW_CONNECTION_ID 821 frames. To limit the delay of the multipath usage upon handshake 822 completion, hosts SHOULD send NEW_CONNECTION_ID frames for paths they 823 allow using as soon the connection establishment completes. 825 To cope with privacy issues, it should be hard to make the link 826 between two different connections or two different paths of a same 827 connection by just looking at the Connection ID contained in packets. 828 Therefore, Path Connection IDs chosen by hosts MUST be random. 830 6.2. ACK Frame 832 The format of the modified ACK frame is shown below. 834 0 1 2 3 835 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 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Path ID (i) ... 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Largest Acknowledged (i) ... 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | ACK Delay (i) ... 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | ACK Block Count (i) ... 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | ACK Blocks (*) ... 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 Figure 5: ACK Frame adapted to Multipath 850 Compared to the ACK frame in the current QUIC design 851 [I-D.ietf-quic-transport], the ACK frame is prefixed by a variable 852 size Path ID field indicating to which path the acknowledged PSNs 853 relate to. Notice that if the multipath extension was not negotiated 854 during the connection handshake, the ACK frame is the same as the one 855 presented in [I-D.ietf-quic-transport]. 857 Since frames are independent of packets, and the path notion relates 858 to the packets, the ACK frames can be sent on any path, unlike 859 Multipath TCP [RFC6824] which is constrained to send ACKs on the same 860 path. 862 Although not defined in this document, a similar adaptation for the 863 ACK_ECN frame is also possible. 865 7. New Frames 867 To support the multipath operations, new frames have been defined to 868 coordinate hosts. This draft uses a type field containing 0x20 to 869 indicate that the frame is related to multipath operations. 871 7.1. MAX_PATHS Frame 873 The MAX_PATHS frame is used by hosts to control the number of paths 874 that can be simultaneously in the ACTIVE state on a given connection. 875 The proposed type for the MAX_PATHS frame is 0x20. A MAX_PATHS frame 876 is shown below. 878 0 1 2 3 879 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 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Sequence (i) ... 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Num Additional Active Paths (i) ... 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 Figure 6: MAX_PATHS Frame 888 The MAX_PATHS frame contains the following fields: 890 o Sequence: A variable-length integer. This value starts at 0 and 891 increases by 1 for each change of number of active paths that is 892 provided by the host. 894 o Num Additional Active Paths: A variable-length integer indicating 895 how many additional paths can be used over the connection. The 896 number of paths that can be in ACTIVE state is thus (Num 897 Additional Active Paths + 1). 899 Once the connection is established, hosts MUST assume that the server 900 sent a MAX_PATHS frame with sequence -1 and number of additional 901 active paths equal to 0 and the client sent a MAX_PATHS frame with 902 sequence -1 and number of additional active paths equal to the 903 negotiated max_path_id value. 905 7.2. PATH_UPDATE Frame 907 The PATH_UPDATE frame is used by a host either to migrate a path or 908 to close it. This indicates to the remote that the closed path MUST 909 NOT be used anymore and it can use the proposed one instead, if any. 911 The proposed type for the PATH_UPDATE is 0x21. A PATH_UPDATE frame 912 is shown below. 914 0 1 2 3 915 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 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Closed Path ID (i) ... 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Proposed Path ID (i) ... 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 Figure 7: MIGRATE_PATH Frame 924 The MIGRATE_PATH frame contains the following fields: 926 o Closed Path ID: A variable-length integer corresponding to the 927 Path ID of the path that is closed. 929 o Proposed Path ID: A variable-length integer corresponding to the 930 Path ID of the path that substitutes the closed path. If the 931 value is 0, no path is proposed. 933 Upon the transmission or the reception of the PATH_UPDATE frame, the 934 path with the Path ID referenced in Closed Path ID MUST be in the 935 CLOSED state. If the proposed Path ID is different of 0, the path 936 MUST have been either in the PROPOSED or in the UNUSABLE state and 937 MUST now be considered as ACTIVE. 939 7.3. ADD_ADDRESS Frame 941 The ADD_ADDRESS frame is used by a host to advertise its currently 942 reachable addresses. The proposed type for the ADD_ADDRESS frame is 943 0x22. An ADD_ADDRESS frame is shown below. 945 0 1 2 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 |0|0|0|P|IPVers.|Address ID (8) | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | IP Address (32/128) ... 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | [Port (16)] | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 Figure 8: ADD_ADDRESS Frame 957 The ADD_ADDRESS frame contains the following fields: 959 o Reserved bits: the three most-significant bits of the first byte 960 are set to 0, and are reserved for future use. 962 o P bit: the fourth most-significant bit of the first byte 963 indicates, if set, the presence of the Port field. 965 o IPVers.: the remaining four least-significant bits of the first 966 byte contain the version of the IP address contained in the IP 967 Address field. 969 o Address ID: an unique identifier for the advertised address for 970 tracking and removal purposes. This is needed when, e.g., a NAT 971 changes the IP address such that both hosts see different IP 972 addresses for a same path endpoint. 974 o IP Address: the advertised IP address, in network order. 976 o Port: this optional field indicates the port number related to the 977 advertised IP address. When this field is present, it indicates 978 that a path can use the 2-tuple (IP addr, port). 980 Upon reception of an ADD_ADDRESS frame, the receiver SHOULD store the 981 communicated address for future use. The receiver MUST NOT send 982 packets others than validation ones to the communicated address 983 without having validated it. ADD_ADDRESS frames SHOULD contain 984 globally reachable addresses. Link-local and possibly private 985 addresses SHOULD NOT be exchanged. 987 7.4. REMOVE_ADDRESS Frame 989 The REMOVE_ADDRESS frame is used by a host to signal that a 990 previously announced address was lost. The proposed type for the 991 REMOVE_ADDRESS frame is 0x23. A REMOVE_ADDRESS frame is shown below. 993 0 1 2 3 994 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 995 +-+-+-+-+-+-+-+-+ 996 |Address ID (8) | 997 +-+-+-+-+-+-+-+-+ 999 Figure 9: REMOVE_ADDRESS Frame 1001 The frame contains only one field, Address ID, being the identifier 1002 of the address to remove. A host SHOULD stop using paths using the 1003 removed address and set them in the UNUSABLE state. If the 1004 REMOVE_ADDRESS contains an Address ID that was not previously 1005 announced, the receiver MUST silently ignore the frame. 1007 7.5. PATHS Frame 1009 The PATHS frame communicates the paths state of the sending host to 1010 the peer. It allows the sender to communicate its active paths to 1011 the peer in order to detect potential connectivity issue over paths. 1012 Its proposed type is 0x24. The format of the PATHS frame is shown 1013 below. 1015 0 1 2 3 1016 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 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Sequence (i) ... 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | ActivePaths (i) ... 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | Path Info Section (*) ... 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 Figure 10: PATHS Frame 1027 The PATHS frame contains the following fields: 1029 o Sequence: A variable-length integer. This value starts at 0 and 1030 increases by 1 for each PATHS frame sent by the host. It allows 1031 identifying the most recent PATHS frame. 1033 o ActivePaths: the current number of additional paths considered as 1034 being active from the sender point of view, i.e., (the number of 1035 active paths - 1). ActivePaths MUST be lower or equal to the last 1036 value advertised by MAX_PATHS frame. 1038 o Path Info Section: contains information about all the active paths 1039 (i.e., there are ActivePaths + 1 entries). The format of this 1040 section is shown below. 1042 0 1 2 3 1043 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 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | Path ID 0 (i) ... 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 |LocAddrID 0 (8)| 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 ... 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Path ID N (i) ... 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 |LocAddrID N (8)| 1054 +-+-+-+-+-+-+-+-+ 1056 Figure 11: Path Info Section 1058 The fields in the Path Info Section are: 1060 o Path ID: the Path ID of the active path the sending host provides 1061 information about. 1063 o LocAddrID: the local Address ID of the address currently used by 1064 the path. 1066 The Path Info section only contains the Local Address ID so far, but 1067 this section can be extended later with other potentially useful 1068 information. 1070 8. Security Considerations 1072 8.1. Nonce Computation 1074 With Multipath QUIC, each path has its own packet number space. With 1075 the current nonce computation [I-D.ietf-quic-tls], using twice the 1076 same packet number over two different paths leads to the same 1077 cryptographic nonce. Depending on the size of the Initial Value (and 1078 hence the nonce), there are two ways to mitigate this issue. 1080 If the Initial Value has a length of 8 bytes, then a packet number 1081 used on a given path MUST NOT be reused on another path of the 1082 connection, and therefore at most 2^64 packets can be sent on a QUIC 1083 connection. This means there will be packet number skipping at path 1084 level, but the packet number will remain monotonically increasing on 1085 each path. 1087 If the Initial Value has a length of 9 or more, then the 1088 cryptographic nonce computation is now performed as follows. The 1089 nonce, N, is formed by combining the packet protection IV (either 1090 client_pp_iv_n or server_pp_iv_n) with the Path ID and the packet 1091 number. The 64 bits of the reconstructed QUIC packet number in 1092 network byte order is left-padded with zeros to the size of the IV. 1093 The Path ID encoded in its variable-length format is right-padded 1094 with zeros to the size of the IV. The Path IV is computed as the 1095 exclusive OR of the padded Path ID and the IV. The exclusive OR of 1096 the padded packet number and the Path IV forms the AEAD nonce. 1098 8.2. Validation of Exchanged Addresses 1100 To use addresses communicated by the peer through ADD_ADDRESS frames, 1101 hosts are required to validate them before using paths to these 1102 addresses. The main reason for this validation is that the remote 1103 host might have sent, purposely or not, a packet with a source IP 1104 that does not correspond to the IP of the remote interface. This 1105 could lead to amplification attacks where the client start using a 1106 new path with a source IP corresponding to the victim's one. Without 1107 validation, the server might then flood the victim. Similarly for 1108 ADD_ADDRESS frames, a malicious server might advertise the IP address 1109 of a victim, hoping that the client will use it without validating it 1110 before. 1112 9. IANA Considerations 1114 9.1. QUIC Transport Parameter Registry 1116 This document defines a new transport parameter for the negotiation 1117 of multiple paths. The following entry in Table 1 should be added to 1118 the "QUIC Transport Parameters" registry under the "QUIC Protocol" 1119 heading. 1121 +--------+----------------+---------------+ 1122 | Value | Parameter Name | Specification | 1123 +--------+----------------+---------------+ 1124 | 0x0020 | max_paths | Section 5.1.1 | 1125 +--------+----------------+---------------+ 1127 Table 1: Addition to QUIC Transport Parameters Entries 1129 10. Acknowledgements 1131 We would like to thanks Masahiro Kozuka and Kazuho Oku for their 1132 numerous comments on the first version of this draft. We also thanks 1133 Philipp Tiesel for his early comments that led to the current design, 1134 and Ian Swett for later feedbacks. We also want to thanks Christian 1135 Huitema for his draft about multipath requirements to identify 1136 critical elements about the multipath feature. 1138 11. References 1140 11.1. Normative References 1142 [I-D.ietf-quic-invariants] 1143 Thomson, M., "Version-Independent Properties of QUIC", 1144 draft-ietf-quic-invariants-01 (work in progress), March 1145 2018. 1147 [I-D.ietf-quic-recovery] 1148 Iyengar, J. and I. Swett, "QUIC Loss Detection and 1149 Congestion Control", draft-ietf-quic-recovery-14 (work in 1150 progress), August 2018. 1152 [I-D.ietf-quic-tls] 1153 Thomson, M. and S. Turner, "Using Transport Layer Security 1154 (TLS) to Secure QUIC", draft-ietf-quic-tls-14 (work in 1155 progress), August 2018. 1157 [I-D.ietf-quic-transport] 1158 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1159 and Secure Transport", draft-ietf-quic-transport-14 (work 1160 in progress), August 2018. 1162 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1163 Requirement Levels", BCP 14, RFC 2119, 1164 DOI 10.17487/RFC2119, March 1997, 1165 . 1167 11.2. Informative References 1169 [Cellnet] Paasch, C., Detal, G., Duchene, F., Raiciu, C., and O. 1170 Bonaventure, "Exploring Mobile/WiFi Handover with 1171 Multipath TCP", ACM SIGCOMM workshop on Cellular Networks 1172 (Cellnet'12) , 2012. 1174 [I-D.huitema-quic-mpath-req] 1175 Huitema, C., "QUIC Multipath Requirements", draft-huitema- 1176 quic-mpath-req-01 (work in progress), January 2018. 1178 [IETFJ] Bonaventure, O. and S. Seo, "Multipath TCP Deployments", 1179 IETF Journal , November 2016. 1181 [MPQUIC] De Coninck, Q. and O. Bonaventure, "Multipath QUIC: Design 1182 and Evaluation", 13th International Conference on emerging 1183 Networking EXperiments and Technologies (CoNEXT 2017). 1184 http://multipath-quic.org , December 2017. 1186 [MPRTP] Singh, V., Ahsan, S., and J. Ott, "MPRTP: Multipath 1187 considerations for real-time media", Proceedings of the 1188 4th ACM Multimedia Systems Conference , 2013. 1190 [OLIA] Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J. 1191 Le Boudec, "MPTCP is not pareto-optimal: performance 1192 issues and a possible solution", Proceedings of the 8th 1193 international conference on Emerging networking 1194 experiments and technologies, ACM , 2012. 1196 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1197 RFC 793, DOI 10.17487/RFC0793, September 1981, 1198 . 1200 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 1201 Congestion Control for Multipath Transport Protocols", 1202 RFC 6356, DOI 10.17487/RFC6356, October 2011, 1203 . 1205 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1206 "TCP Extensions for Multipath Operation with Multiple 1207 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1208 . 1210 [RFC8041] Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and 1211 Operational Experience with Multipath TCP", RFC 8041, 1212 DOI 10.17487/RFC8041, January 2017, 1213 . 1215 [SCTPCMT] Iyengar, J., Amer, P., and R. Stewart, "Concurrent 1216 multipath transfer using SCTP multihoming over independent 1217 end-to-end paths", IEEE/ACM Transactions on networking, 1218 Vol. 14, no 5 , 2006. 1220 Appendix A. Change Log 1222 A.1. Since draft-deconinck-quic-multipath-00 1224 o Comply with asymetric Connection IDs 1226 o Add max_paths transport paramter to negotiate initial number of 1227 active paths 1229 o Path ID as a regular varint 1231 o Remove max_path_id transport parameter 1233 o Updated text to match draft-ietf-quic-transport-14 1235 A.2. Since draft-deconinck-multipath-quic-00 1237 o Added PATH_UPDATE frame 1239 o Added MAX_PATHS frame 1241 o No more packet header change 1243 o Implicit Path ID notification using Connection ID and 1244 NEW_CONNECTION_ID 1245 frames 1247 o Variable-length encoding for Path ID 1249 o Updated text to match draft-ietf-quic-transport-10 1251 o Fixed various typos 1253 Authors' Addresses 1255 Quentin De Coninck 1256 UCLouvain 1258 Email: quentin.deconinck@uclouvain.be 1260 Olivier Bonaventure 1261 UCLouvain 1263 Email: Olivier.Bonaventure@uclouvain.be