idnits 2.17.00 (12 Aug 2021) /tmp/idnits59031/draft-ietf-tsvwg-multipath-dccp-04.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 document date (7 March 2022) is 68 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Nonce 0' is mentioned on line 384, but not defined == Missing Reference: 'Nonce 1' is mentioned on line 386, but not defined == Missing Reference: 'Tbd' is mentioned on line 1208, but not defined == Unused Reference: 'I-D.muley-network-based-bonding-hybrid-access' is defined on line 1262, but no explicit reference was found in the text == Unused Reference: 'RFC5596' is defined on line 1326, but no explicit reference was found in the text == Unused Reference: 'RFC6824' is defined on line 1357, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group M. Amend, Ed. 3 Internet-Draft DT 4 Intended status: Experimental A. Brunstrom 5 Expires: 8 September 2022 A. Kassler 6 Karlstad University 7 V. Rakocevic 8 City University of London 9 S. Johnson 10 BT 11 7 March 2022 13 DCCP Extensions for Multipath Operation with Multiple Addresses 14 draft-ietf-tsvwg-multipath-dccp-04 16 Abstract 18 DCCP communication is currently restricted to a single path per 19 connection, yet multiple paths often exist between peers. The 20 simultaneous use of these multiple paths for a DCCP session could 21 improve resource usage within the network and, thus, improve user 22 experience through higher throughput and improved resilience to 23 network failures. Use cases for a Multipath DCCP (MP-DCCP) are 24 mobile devices (handsets, vehicles) and residential home gateways 25 simultaneously connected to distinct paths as, e.g., a cellular link 26 and a WiFi link or to a mobile radio station and a fixed access 27 network. Compared to existing multipath protocols such as MPTCP, MP- 28 DCCP provides specific support for non-TCP user traffic as UDP or 29 plain IP. More details on potential use cases are provided in 30 [website], [slide], and [paper]. All these use cases profit from an 31 Open Source Linux reference implementation provided under [website]. 33 This document presents a set of extensions to traditional DCCP to 34 support multipath operation. Multipath DCCP provides the ability to 35 simultaneously use multiple paths between peers. The protocol offers 36 the same type of service to applications as DCCP and it provides the 37 components necessary to establish and use multiple DCCP flows across 38 potentially disjoint paths. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on 8 September 2022. 57 Copyright Notice 59 Copyright (c) 2022 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 64 license-info) in effect on the date of publication of this document. 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. Code Components 67 extracted from this document must include Revised BSD License text as 68 described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Revised BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Multipath DCCP in the Networking Stack . . . . . . . . . 4 75 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.3. MP-DCCP Concept . . . . . . . . . . . . . . . . . . . . . 5 77 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 6 78 2. Operation Overview . . . . . . . . . . . . . . . . . . . . . 6 79 3. MP-DCCP Protocol . . . . . . . . . . . . . . . . . . . . . . 7 80 3.1. Multipath Capable Feature . . . . . . . . . . . . . . . . 11 81 3.2. Multipath Option . . . . . . . . . . . . . . . . . . . . 12 82 3.2.1. MP_CONFIRM . . . . . . . . . . . . . . . . . . . . . 13 83 3.2.2. MP_JOIN . . . . . . . . . . . . . . . . . . . . . . . 14 84 3.2.3. MP_FAST_CLOSE . . . . . . . . . . . . . . . . . . . . 15 85 3.2.4. MP_KEY . . . . . . . . . . . . . . . . . . . . . . . 15 86 3.2.5. MP_SEQ . . . . . . . . . . . . . . . . . . . . . . . 16 87 3.2.6. MP_HMAC . . . . . . . . . . . . . . . . . . . . . . . 17 88 3.2.7. MP_RTT . . . . . . . . . . . . . . . . . . . . . . . 17 89 3.2.8. MP_ADDADDR . . . . . . . . . . . . . . . . . . . . . 18 90 3.2.9. MP_REMOVEADDR . . . . . . . . . . . . . . . . . . . . 19 91 3.2.10. MP_PRIO . . . . . . . . . . . . . . . . . . . . . . . 20 92 3.2.11. MP_CLOSE . . . . . . . . . . . . . . . . . . . . . . 21 93 3.3. MP-DCCP Handshaking Procedure . . . . . . . . . . . . . . 22 94 3.4. Close a MP-DCCP connection . . . . . . . . . . . . . . . 23 95 3.5. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 24 96 3.6. Congestion Control Considerations . . . . . . . . . . . . 24 97 3.7. Maximum Packet Size Considerations . . . . . . . . . . . 24 99 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25 100 5. Interactions with Middleboxes . . . . . . . . . . . . . . . . 26 101 6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 26 102 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 104 9. Informative References . . . . . . . . . . . . . . . . . . . 29 105 Appendix A. Differences from Multipath TCP . . . . . . . . . . . 33 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 108 1. Introduction 110 Multipath DCCP (MP-DCCP) is a set of extensions to regular DCCP 111 [RFC4340], i.e., the Datagram Congestion Control Protocol denoting a 112 transport protocol that provides bidirectional unicast connections of 113 congestion-controlled unreliable datagrams. A multipath extension to 114 DCCP enables the transport of user data across multiple paths 115 simultaneously. This is beneficial to applications that transfer 116 fairly large amounts of data, due to the possibility to aggregate 117 capacity of the multiple paths. In addition, it enables to tradeoff 118 timeliness and reliability, which is important for low latency 119 applications that do not require guaranteed delivery services such as 120 Audio/Video streaming. DCCP multipath operation is suggested in the 121 context of ongoing 3GPP work on 5G multi-access solutions 122 [I-D.amend-tsvwg-multipath-framework-mpdccp] and for hybrid access 123 networks [I-D.lhwxz-hybrid-access-network-architecture][I-D.muley-net 124 work-based-bonding-hybrid-access]. It can be applied for load- 125 balancing, seamless session handover, and aggregation purposes 126 (referred to as ATSSS; Access steering, switching, and splitting in 127 3GPP terminology [TS23.501]). 129 This document presents the protocol changes required to add multipath 130 capability to DCCP; specifically, those for signaling and setting up 131 multiple paths ("subflows"), managing these subflows, reordering of 132 data, and termination of sessions. DCCP, as stated in [RFC4340] does 133 not provide reliable and ordered delivery. Consequently, multiple 134 application subflows may be multiplexed over a single DCCP connection 135 with no inherent performance penalty for flows that do not require 136 in-ordered delivery. DCCP does not provide built-in support for 137 those multiple application subflows. 139 In the following, use of the term subflow will refer to physical 140 separate DCCP subflows transmitted via different paths, but not to 141 application subflows. Application subflows are differing content- 142 wise by source and destination port per application as, for example, 143 enabled by Service Codes introduced to DCCP in [RFC5595], and those 144 subflows can be multiplexed over a single DCCP connection. For sake 145 of consistency we assume that only a single application is served by 146 a DCCP connection here as shown in Figure 1 while use of that feature 147 should not impact DCCP operation on each single path as noted in 148 ([RFC5595], sect. 2.4). 150 1.1. Multipath DCCP in the Networking Stack 152 MP-DCCP operates at the transport layer and aims to be transparent to 153 both higher and lower layers. It is a set of additional features on 154 top of standard DCCP; Figure 1 illustrates this layering. MP-DCCP is 155 designed to be used by applications in the same way as DCCP with no 156 changes to the application itself. 158 +-------------------------------+ 159 | Application | 160 +---------------+ +-------------------------------+ 161 | Application | | MP-DCCP | 162 +---------------+ + - - - - - - - + - - - - - - - + 163 | DCCP | |Subflow (DCCP) |Subflow (DCCP) | 164 +---------------+ +-------------------------------+ 165 | IP | | IP | IP | 166 +---------------+ +-------------------------------+ 168 Figure 1: Comparison of Standard DCCP and MP-DCCP Protocol Stacks 170 1.2. Terminology 172 Throughout this document we make use of terms that are either 173 specific for multipath transport or are defined in the context of MP- 174 DCCP, similar to [RFC8684], as follows: 176 Path: A sequence of links between a sender and a receiver, defined in 177 this context by a 4-tuple of source and destination address/ port 178 pairs. 180 Subflow: A flow of DCCP segments operating over an individual path, 181 which forms part of a larger MP-DCCP connection. A subflow is 182 started and terminated similar to a regular (single-path) DCCP 183 connection. 185 (MP-DCCP) Connection: A set of one or more subflows, over which an 186 application can communicate between two hosts. There is a one-to-one 187 mapping between a connection and an application socket. 189 Token: A locally unique identifier given to a multipath connection by 190 a host. May also be referred to as a "Connection ID". 192 Host: An end host operating an MP-DCCP implementation, and either 193 initiating or accepting an MP-DCCP connection. In addition to these 194 terms, within framework of MP-DCCP the interpretation of, and effect 195 on, regular single-path DCCP semantics is discussed in Section 3. 197 1.3. MP-DCCP Concept 199 Figure 2 provides a general overview of the MP-DCCP working mode, 200 whose main characteristics are summarized within this section. 202 Host A Host B 203 ------------------------ ------------------------ 204 Address A1 Address A2 Address B1 Address B2 205 ---------- ---------- ---------- ---------- 206 | | | | 207 | (DCCP flow setup) | | 208 |----------------------------------->| | 209 |<-----------------------------------| | 210 | | | | 211 | | (DCCP flow setup) | | 212 | |--------------------->| | 213 | |<---------------------| | 214 | merge individual DCCP flows to one multipath connection 215 | | | | 217 Figure 2: Example MP-DCCP Usage Scenario 219 * An MPDCCP connection begins with a 4-way handshaking procedure, 220 between 2 hosts as described in Section 3.3. In Figure 2 an 221 MPDCCP connection is established between addresses A1 and B1 on 222 Hosts A and B, respectively. 224 * If extra paths are available, additional DCCP subflows are created 225 on these paths and are attached to the existing MPDCCP session, 226 which continues to appear as a single connection to the 227 applications at both ends. The creation of an additional DCCP 228 subflow is illustrated between Address A2 on Host A and Address B1 229 on Host B. 231 * MPDCCP identifies multiple paths by the presence of multiple 232 addresses at hosts. Combinations of these multiple addresses 233 equate to the additional paths. In the example, other potential 234 paths that could be set up are A1<->B2 and A2<->B2. Although this 235 additional session is shown as being initiated from A2, it could 236 equally have been initiated from B1 or B2. 238 * The discovery and setup of additional subflows will be achieved 239 through a path management method; this document describes 240 supportive measures by which a host can initiate new subflows and 241 available addresses can be signaled between peers. The definition 242 of a path management method is however out of scope of this 243 document. 245 * MPDCCP adds connection-level sequence numbers and exchange of RTT 246 information to enable optional reordering functionalities. 248 * Subflows are terminated as regular DCCP connections, as described 249 in ([RFC4340] section 8.3). The MPDCCP connection is terminated 250 by a connection-level DCCP-CloseReq or DCCP-Close message. 252 1.4. Requirements Language 254 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 255 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 256 document are to be interpreted as described in [RFC2119]. 258 2. Operation Overview 260 DCCP according to RFC 4340 [RFC4340] allows multiple application 261 subflows to be multiplexed over a single DCCP connection with 262 potentially same performance. However, DCCP does not provide built- 263 in support for multiple subflows and the Congestion Manager (CM) 264 [RFC3124], as a generic multiplexing facility, can not fully support 265 multiple congestion control mechanisms for multiple DCCP flows 266 between same source and destination addresses. 268 The proposed extension of DCCP towards Multipath-DCCP (MP-DCCP) is 269 described in detail in Section 3. 271 As a high level overview on the key functionality of MP-DCCP, the 272 data stream from a DCCP application is split by MP-DCCP operation 273 into one or more subflows which can be transmitted via different also 274 physically isolated paths. The corresponding control information 275 allows the receiver to optionally re-assemble and deliver the 276 received data in the right order to the recipient application. The 277 details of the transmission scheduling mechanism and optional 278 reordering mechanism are up to the sender and receiver, respectively, 279 and are outside the scope of the MP-DCCP protocol. The following 280 sections define MP-DCCP behavior in detail. 282 The Multipath Capability for MP-DCCP can be negotiated with a new 283 DCCP feature, as described and fully specified in Section 3. Once 284 negotiated, all subsequent MP-DCCP operations are signalled with a 285 variable length multipath-related option, as described in 286 Section 3.1. 288 A Multipath DCCP connection provides a bidirectional byte-stream 289 between two hosts exchanging data as in standard DCCP manner thus not 290 requiring any change to the applications. However, Multipath DCCP 291 enables the hosts to use different paths with different IP addresses 292 to transport the packets of the MP-DCCP connection. MP-DCCP manages 293 the request, set-up, authentication, prioritization, modification, 294 and removal of the DCCP subflows on different paths as well as 295 exchange of performance parameters. The number of concurrent DCCP 296 subflows can vary during the lifetime of the Multipath DCCP 297 connection. All MP-DCCP operations are signaled with MP-DCCP options 298 described in detail in {#MP_OPT}. 300 3. MP-DCCP Protocol 302 The DCCP protocol feature list ([RFC4340] section 6.4) will be 303 enhanced by a new Multipath related feature with Feature number 10, 304 as shown in Table 1. 306 +=========+===================+======+=============+===============+ 307 | Number | Meaning | Rule | Rec'n Value | Initial Req'd | 308 +=========+===================+======+=============+===============+ 309 | 0 | Reserved | | | | 310 +---------+-------------------+------+-------------+---------------+ 311 | 1 | Congestion | SP | 2 | Y | 312 | | Control ID (CCID) | | | | 313 +---------+-------------------+------+-------------+---------------+ 314 | 2 | Allow Short | SP | 0 | Y | 315 | | Seqnos | | | | 316 +---------+-------------------+------+-------------+---------------+ 317 | 3 | Sequence Window | NN | 100 | Y | 318 +---------+-------------------+------+-------------+---------------+ 319 | 4 | ECN Incapable | SP | 0 | N | 320 +---------+-------------------+------+-------------+---------------+ 321 | 5 | Ack Ratio | NN | 2 | N | 322 +---------+-------------------+------+-------------+---------------+ 323 | 6 | Send Ack Vector | SP | 0 | N | 324 +---------+-------------------+------+-------------+---------------+ 325 | 7 | Send NDP Count | SP | 0 | N | 326 +---------+-------------------+------+-------------+---------------+ 327 | 8 | Minimum Checksum | SP | 0 | N | 328 | | Coverage | | | | 329 +---------+-------------------+------+-------------+---------------+ 330 | 9 | Check Data | SP | 0 | N | 331 | | Checksum | | | | 332 +---------+-------------------+------+-------------+---------------+ 333 | 10 | Multipath Capable | SP | 0 | N | 334 +---------+-------------------+------+-------------+---------------+ 335 | 11-127 | Reserved | | | | 336 +---------+-------------------+------+-------------+---------------+ 337 | 128-255 | CCID-specific | | | | 338 | | features | | | | 339 +---------+-------------------+------+-------------+---------------+ 341 Table 1: Proposed Feature Set 343 Rec'n Rule: The reconciliation rule used for the feature. SP means 344 server-priority, NN means non-negotiable. 346 Initial Value: The initial value for the feature. Every feature has 347 a known initial value. 349 Req'd: This column is "Y" if and only if every DCCP implementation 350 MUST understand the feature. If it is "N", then the feature 351 behaves like an extension (see Section 15), and it is safe to 352 respond to Change options for the feature with empty Confirm 353 options. Of course, a CCID might require the feature; a DCCP that 354 implements CCID 2 MUST support Ack Ratio and Send Ack Vector, for 355 example. 357 The DCCP protocol options as defined in ([RFC4340] section 5.8) and 358 ([RFC5634] section 2.2.1) will be enhanced by a new Multipath related 359 variable-length option with option type 46, as shown in Table 2. 361 +=========+===============+=======================+============+ 362 | Type | Option Length | Meaning | DCCP-Data? | 363 +=========+===============+=======================+============+ 364 | 0 | 1 | Padding | Y | 365 +---------+---------------+-----------------------+------------+ 366 | 1 | 1 | Mandatory | N | 367 +---------+---------------+-----------------------+------------+ 368 | 2 | 1 | Slow Receiver | Y | 369 +---------+---------------+-----------------------+------------+ 370 | 3-31 | 1 | Reserved | | 371 +---------+---------------+-----------------------+------------+ 372 | 32 | variable | Change L | N | 373 +---------+---------------+-----------------------+------------+ 374 | 33 | variable | Confirm L | N | 375 +---------+---------------+-----------------------+------------+ 376 | 34 | variable | Change R | N | 377 +---------+---------------+-----------------------+------------+ 378 | 35 | variable | Confirm R | N | 379 +---------+---------------+-----------------------+------------+ 380 | 36 | variable | Init Cookie | N | 381 +---------+---------------+-----------------------+------------+ 382 | 37 | 3-8 | NDP Count | Y | 383 +---------+---------------+-----------------------+------------+ 384 | 38 | variable | Ack Vector [Nonce 0] | N | 385 +---------+---------------+-----------------------+------------+ 386 | 39 | variable | Ack Vector [Nonce 1] | N | 387 +---------+---------------+-----------------------+------------+ 388 | 40 | variable | Data Dropped | N | 389 +---------+---------------+-----------------------+------------+ 390 | 41 | 6 | Timestamp | Y | 391 +---------+---------------+-----------------------+------------+ 392 | 42 | 6/8/10 | Timestamp Echo | Y | 393 +---------+---------------+-----------------------+------------+ 394 | 43 | 4/6 | Elapsed Time | N | 395 +---------+---------------+-----------------------+------------+ 396 | 44 | 6 | Data Checksum | Y | 397 +---------+---------------+-----------------------+------------+ 398 | 45 | 8 | Quick-Start Response | ? | 399 +---------+---------------+-----------------------+------------+ 400 | 46 | variable | Multipath | Y | 401 +---------+---------------+-----------------------+------------+ 402 | 47-127 | variable | Reserved | | 403 +---------+---------------+-----------------------+------------+ 404 | 128-255 | variable | CCID-specific options | - | 405 +---------+---------------+-----------------------+------------+ 407 Table 2: Proposed Option Set 409 3.1. Multipath Capable Feature 411 DCCP endpoints are multipath-disabled by default and multipath 412 capability can be negotiated with the Multipath Capable Feature. 414 Multipath Capable has feature number 10 and has length of one-byte. 415 The leftmost four bits are used to specify a compatible version of 416 the MP-DCCP implementation (0 for this specification). The following 417 four bits are reserved for further use. 419 0 1 2 3 4 5 6 7 420 +------------------------+ 421 | Version | Reserved | 422 +------------------------+ 423 '0000'->v0 424 '0001'->v1 425 ........ 427 Multipath Capable follows the server-priority reconciliation rule 428 described in ([RFC4340] section 6.3.1), which allows multiple 429 versions to be specified in order of priority. 431 The negotiation MUST be done as part of the initial handshake 432 procedure as described in Section 3.3, and no subsequent re- 433 negotiation of the Multipath Capable feature is allowed on the same 434 MP connection. 436 Client MUST include a Change R option during the initial handshake 437 request to supply a list of supported protocol versions, ordered by 438 preference. 440 Server MUST include a Confirm L option in the subsequent response to 441 agree on a version to be used chosen from the Client list, followed 442 by its own supported version(s) ordered by preference. 444 For example: 446 Client Server 447 ------ ------ 448 DCCP-Req + Change R(CAPABLE, 1 0) 449 -----------------------------------> 451 DCCP-Resp + Confirm L(CAPABLE, 1, 2 1 0) 452 <----------------------------------- 454 * agreement on version = 1 * 456 1. Client indicates support for both versions 1 and 0, with 457 preference for version 1 459 2. Server agrees on using version 1, and supply its own preference 460 list. 462 If no agreement can be found, the Server MUST reply with an empty 463 Confirm L option with feature number 10 and no values. 465 Any subflow addition to an existing MP connection MUST use the same 466 version negotiated for the first flow. 468 3.2. Multipath Option 470 +--------+--------+--------+--------+-------- 471 |00101110| Length | MP_OPT | Value(s) ... 472 +--------+--------+--------+--------+-------- 473 Type=46 474 +======+========+================+================================+ 475 | Type | Option | MP_OPT | Meaning | 476 | | Length | | | 477 +======+========+================+================================+ 478 | 46 | var | 0 =MP_CONFIRM | Confirm reception and | 479 | | | | processing of an MP_OPT option | 480 +------+--------+----------------+--------------------------------+ 481 | 46 | 12 | 1 =MP_JOIN | Join path to an existing MP- | 482 | | | | DCCP flow | 483 +------+--------+----------------+--------------------------------+ 484 | 46 | 3 | 2 | Close MP-DCCP flow | 485 | | | =MP_FAST_CLOSE | unconditionally | 486 +------+--------+----------------+--------------------------------+ 487 | 46 | var | 3 =MP_KEY | Exchange key material for | 488 | | | | MP_HMAC | 489 +------+--------+----------------+--------------------------------+ 490 | 46 | 7 | 4 =MP_SEQ | Multipath Sequence Number | 491 +------+--------+----------------+--------------------------------+ 492 | 46 | 23 | 5 =MP_HMAC | HMA Code for authentication | 493 +------+--------+----------------+--------------------------------+ 494 | 46 | 12 | 6 =MP_RTT | Transmit RTT values | 495 +------+--------+----------------+--------------------------------+ 496 | 46 | var | 7 =MP_ADDADDR | Advertise additional Address | 497 +------+--------+----------------+--------------------------------+ 498 | 46 | var | 8 | Remove Address | 499 | | | =MP_REMOVEADDR | | 500 +------+--------+----------------+--------------------------------+ 501 | 46 | 4 | 9 =MP_PRIO | Change Subflow Priority | 502 +------+--------+----------------+--------------------------------+ 503 | 46 | 3 | 10 =MP_CLOSE | Close MP-DCCP flow | 504 +------+--------+----------------+--------------------------------+ 506 Table 3: MP_OPT Option Types 508 3.2.1. MP_CONFIRM 510 +--------+--------+--------+--------+--------+--------+--------+ 511 |00101110| Length |00000000| List of options ... 512 +--------+--------+--------+--------+--------+--------+--------+ 513 Type=46 MP_OPT=0 515 MP_CONFIRM is used to send confirmation of reception and processing 516 of the multipath options that require it (see Table 4). Such options 517 will be retransmitted by the sender until this receives the 518 corresponding MP_CONFIRM. The length and sending path of the 519 MP_CONFIRM are dependent on the confirmed options, which will be 520 copied verbatim and appended as list of options. 522 +======+===============+==================+=========================+ 523 | Type | Option Length | MP_OPT | MP_CONFIRM Sending path | 524 +======+===============+==================+=========================+ 525 | 46 | var | 7 =MP_ADDADDR | Any available | 526 +------+---------------+------------------+-------------------------+ 527 | 46 | var | 8 | Any available | 528 | | | =MP_REMOVEADDR | | 529 +------+---------------+------------------+-------------------------+ 530 | 46 | 4 | 9 =MP_PRIO | Any available | 531 +------+---------------+------------------+-------------------------+ 533 Table 4: Multipath options requiring confirmation 535 3.2.2. MP_JOIN 537 +--------+--------+--------+--------+ 538 |00101110|00001011|00000001| Addr ID| 539 +--------+--------+--------+--------+ 540 | Path Token | 541 +--------+--------+--------+--------+ 542 | Nonce | 543 +--------+--------+--------+--------+ 544 Type=46 Length=12 MP_OPT=1 546 The MP_JOIN option is used to add a new path to an existing MP-DCCP 547 flow. The Path Token is the SHA256 hash of the derived key (d-key), 548 which was previously exchanged with the MP_KEY option. MP_HMAC MUST 549 be set when using MP_JOIN to provide authentication (See MP_HMAC for 550 details). Also MP_KEY MUST be set to provide key material for 551 authentication purposes. 553 The Address IDs of the subflow used in the initial DCCP Request/ 554 Response exchange of the first subflow in the connection are 555 implicit, and have the value zero. A host MUST store the mappings 556 between Address IDs and addresses both for itself and the remote 557 host. An implementation will also need to know which local and 558 remote Address IDs are associated with which established subflows, 559 for when addresses are removed from a local or remote host. An 560 Address ID has always to be unique over the lifetime of a subflow and 561 can only be re-assigned if sender and receiver no longer have them in 562 use. 564 The Nonce is a 32-bit random value locally generated for every 565 MP_JOIN option. Together with the Token, the Nonce value builds the 566 basis to calculate the HMAC used in the handshaking process as 567 described in Section 3.3. 569 3.2.3. MP_FAST_CLOSE 571 Regular DCCP has the means of sending a Close or Reset signal to 572 abruptly close a connection. With MP-DCCP, a regular Close or Reset 573 only has the scope of the subflow; it will only close the applicable 574 subflow and will not affect the remaining subflows concurrently in 575 use on other paths. MP-DCCP's connection will stay alive at the data 576 level, in order to permit break-before-make handover between 577 subflows. It is therefore necessary to provide an MP-DCCP-level 578 "Reset" to allow the abrupt closure of the whole MP-DCCP connection; 579 this is done via the MP_FAST_CLOSE option. 581 +--------+--------+--------+--------+--------+ 582 |00101110| Length |00000010| Key Data ... 583 +--------+--------+--------+--------+--------+ 584 Type=46 MP_OPT=2 586 For being effective, the MP_FAST_CLOSE must be sent from an 587 initiating host on all subflows as part of a DCCP-Reset packet with 588 Reset Code 12. To protect unauthorized shutdown of a multi-path 589 connection, the selected Key Data of the peer host during the 590 handshaking procedure is carried by the MP_FAST_CLOSE option. With 591 completion of this step, the initiating host can tear down the 592 subflows and the multi-path connection immediately terminates. Upon 593 reception of the MP_FAST_CLOSE and validation of the Key Data at the 594 peer host, a DCCP Reset packet is replied on all subflows to the 595 initiating host again with Reset Code 12. The peer host can now 596 close the whole MP-DCCP connection (it transitions directly to CLOSED 597 state). 599 3.2.4. MP_KEY 601 +--------+--------+--------+-----------+-------------+ 602 |00101110| Length |00000011|Key Type(1)| Key Data(1) | -> 603 +--------+--------+--------+-----------+-------------+ 604 Type=46 MP_OPT=3 606 +-----------+-------------+----- 607 -> |Key Type(2)| Key Data(2) | .... 608 +-----------+-------------+----- 610 The MP_KEY suboption is used to exchange key material between hosts. 611 The Length varies between 12 and 68 Bytes for a single-key message, 612 and up to 110 Bytes when all specified Key Types 0-2 are provided. 613 The Key Type field is used to specify the type of the following key 614 data. Key types are shown in Table 5. 616 +========================+====================+===================+ 617 | Key Type | Key Length (Bytes) | Meaning | 618 +========================+====================+===================+ 619 | 0 =Plain Text | 8 | Plain Text Key | 620 +------------------------+--------------------+-------------------+ 621 | 1 =ECDHE-C25519-SHA256 | 32 | ECDHE with SHA256 | 622 | | | and Curve25519 | 623 +------------------------+--------------------+-------------------+ 624 | 2 =ECDHE-C25519-SHA512 | 64 | ECDHE with SHA512 | 625 | | | and Curve25519 | 626 +------------------------+--------------------+-------------------+ 627 | 3-255 | | Reserved | 628 +------------------------+--------------------+-------------------+ 630 Table 5: MP_KEY Key Types 632 Plain Text 633 Key Material is exchanged in plain text between hosts, and the key 634 parts (key-a, key-b) are used by each host to generate the derived 635 key (d-key) by concatenating the two parts with the local key in 636 front (e.g. hostA d-key(A)=(key-a+key-b), hostB d-key(B)=(key- 637 b+key-a)). 639 ECDHE-SHA256-C25519 640 Key Material is exchanged via ECDHE key exchange with SHA256 and 641 Curve 25519 to generate the derived key (d-key). 643 ECDHE-SHA512-C25519 644 Key Material is exchanged via ECDHE key exchange with SHA512 and 645 Curve 25519 to generate the derived key (d-key). 647 Providing multiple keys is only permitted in the DCCP-Request message 648 of the handshake procedure for the first flow, and allows the hosts 649 to agree on a single key type to be used as described in Section 3.3 651 3.2.5. MP_SEQ 653 +--------+--------+--------+--------+--------+--------+--------+ 654 |00101110|00000111|00000100| Multipath Sequence Number | 655 +--------+--------+--------+--------+--------+--------+--------+ 656 Type=46 Length=7 MP_OPT=4 658 The MP_SEQ option is used for end-to-end datagram-based sequence 659 numbers of an MP-DCCP connection. The initial data sequence number 660 (IDSN) SHOULD be set randomly. The MP_SEQ number space is different 661 from the path individual sequence number space and MUST be sent with 662 any DCCP-Data and DCCP-DataACK packet. 664 3.2.6. MP_HMAC 666 +--------+--------+--------+--------+--------+--------+ 667 |00101110|00001011|00000101| HMAC-SHA256 (20 bytes) ... 668 +--------+--------+--------+--------+--------+--------+ 669 Type=46 Length=23 MP_OPT=5 671 The MP_HMAC option is used to provide authentication for the MP_JOIN 672 option. The HMAC code is generated according to [RFC2104] in 673 combination with the SHA256 hash algorithm described in [RFC6234], 674 with the output truncated to the leftmost 160 bits (20 bytes). 676 The "Key" used for the HMAC computation is the derived key (d-key) 677 described in Section 3.2.4, while the HMAC "Message" is a 678 concatenation of the token and nonce of the MP_JOIN for which 679 authentication shall be performed. 681 3.2.7. MP_RTT 683 +--------+--------+--------+--------+--------+--------+--------+ 684 |00101110|00001100|00000110|RTT Type| RTT 685 +--------+--------+--------+--------+--------+--------+--------+ 686 | | Age | 687 +--------+--------+--------+--------+--------+ 688 Type=46 Length=12 MP_OPT=6 690 The MP_RTT option is used to transmit RTT values in milliseconds and 691 MUST belong to the path over which this information is transmitted. 692 Additionally, the age of the measurement is specified in 693 milliseconds. 695 The RTT and Age information is a 32-bit integer, which allows to 696 cover a period of approximately 1193 hours. 698 Raw RTT (=0) 699 Raw RTT value of the last Datagram Round-Trip. The Age parameter 700 MUST be set to 0. 702 Min RTT (=1) 703 Min RTT value. The period for computing the Minimum can be 704 specified by the Age parameter. 706 Max RTT (=2) 707 Max RTT value. The period for computing the Maximum can be 708 specified by the Age parameter. 710 Smooth RTT (=3) 711 Averaged RTT value. The period for computing the smoothed RTT can 712 be specified by the Age parameter. 714 Age 715 The Age parameter is set to a time and 716 contains the periods for computing of derived 717 RTT values for the Minimum (=1), Maximum (=2) as well as for the 718 averaged smoothed RTT value (=3). An Age parameter of zero MUST 719 NOT be interpreted by the receiver. 721 3.2.8. MP_ADDADDR 723 The MP_ADDADDR option announces additional addresses (and, 724 optionally, ports) on which a host can be reached. This option can 725 be used at any time during an existing DCCP connection, when the 726 sender wishes to enable multiple paths and/or when additional paths 727 become available. Length is variable depending on IPv4 or IPv6 and 728 whether port number is used and is in range between 28 and 42 bytes. 730 1 2 3 731 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 732 +---------------+---------------+-------+-------+---------------+ 733 | Type | Length |Subtype| IPVer | Address ID | 734 +---------------+---------------+-------+-------+---------------+ 735 | Address (IPv4 - 4 bytes / IPv6 - 16 bytes) | 736 +-------------------------------+-------------------------------+ 737 | Port (2 bytes, optional) | | 738 +-------------------------------+ | 739 | HMAC (20 bytes) | 740 | | 741 | | 742 | | 743 | | 744 | +-------------------------------+ 745 | | 746 +-------------------------------+ 748 Every address has an Address ID that can be used for uniquely 749 identifying the address within a connection for address removal. The 750 Address ID is also used to identify MP_JOIN options (see 751 Section 3.2.2) relating to the same address, even when address 752 translators are in use. The Address ID MUST uniquely identify the 753 address for the sender of the option (within the scope of the 754 connection); the mechanism for allocating such IDs is implementation 755 specific. 757 All Address IDs learned via either MP_JOIN or ADD_ADDR SHOULD be 758 stored by the receiver in a data structure that gathers all the 759 Address-ID-to-address mappings for a connection (identified by a 760 token pair). In this way, there is a stored mapping between the 761 Address ID, observed source address, and token pair for future 762 processing of control information for a connection. 764 Ideally, ADD_ADDR and REMOVE_ADDR options would be sent reliably, and 765 in order, to the other end. This would ensure that this address 766 management does not unnecessarily cause an outage in the connection 767 when remove/add addresses are processed in reverse order, and also to 768 ensure that all possible paths are used. Note, however, that losing 769 reliability and ordering will not break the multipath connections, it 770 will just reduce the opportunity to open new paths and to survive 771 different patterns of path failures. 773 Therefore, implementing reliability signals for these DCCP options is 774 not necessary. In order to minimize the impact of the loss of these 775 options, however, it is RECOMMENDED that a sender should send these 776 options on all available subflows. If these options need to be 777 received in-order, an implementation SHOULD only send one ADD_ADDR/ 778 REMOVE_ADDR option per RTT, to minimize the risk of misordering. A 779 host that receives an ADD_ADDR but finds a connection set up to that 780 IP address and port number is unsuccessful SHOULD NOT perform further 781 connection attempts to this address/port combination for this 782 connection. A sender that wants to trigger a new incoming connection 783 attempt on a previously advertised address/port combination can 784 therefore refresh ADD_ADDR information by sending the option again. 786 [TBD/TBV] 788 3.2.9. MP_REMOVEADDR 790 If, during the lifetime of an MP-DCCP connection, a previously 791 announced address becomes invalid (e.g., if the interface 792 disappears), the affected host SHOULD announce this so that the peer 793 can remove subflows related to this address. 795 This is achieved through the Remove Address (REMOVE_ADDR) option 796 which will remove a previously added address (or list of addresses) 797 from a connection and terminate any subflows currently using that 798 address. 800 For security purposes, if a host receives a REMOVE_ADDR option, it 801 must ensure the affected path(s) are no longer in use before it 802 instigates closure. Typical DCCP validity tests on the subflow 803 (e.g., packet type specific sequence and acknowledgement number 804 check) MUST also be undertaken. An implementation can use 805 indications of these test failures as part of intrusion detection or 806 error logging. 808 The sending and receipt of this message SHOULD trigger the sending of 809 DCCP-Close and DCCP-Reset by client and server, respectively on the 810 affected subflow(s) (if possible), as a courtesy to cleaning up 811 middlebox state, before cleaning up any local state. 813 Address removal is undertaken by ID, so as to permit the use of NATs 814 and other middleboxes that rewrite source addresses. If there is no 815 address at the requested ID, the receiver will silently ignore the 816 request. 818 1 2 3 819 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 820 +---------------+---------------+-------+-------+---------------+ 821 | Type | Length = 3+n |Subtype|(resvd)| Address ID |... 822 +---------------+---------------+-------+-------+---------------+ 823 (followed by n-1 Address IDs, if required) 825 Minimum length of this option is 4 bytes (for one address to remove). 827 [TBD/TBV] 829 3.2.10. MP_PRIO 831 In the event that a single specific path out of the set of available 832 paths shall be treated with higher priority compared to the others, a 833 host may wish to signal such change in priority to the peer. One 834 reason for such behavior is due to the different costs involved in 835 using different paths (e.g., WiFi is free while cellular has limit on 836 volume, 5G has higher energy consumption). Also, the priority of a 837 path may be subject to dynamic changes, for example when the mobile 838 runs out of battery only a single path may be preferred. Therefore, 839 the path priority should be considered as hints for the packet 840 scheduler when making decisions which path to use for user plane 841 traffic. 843 The MP_PRIO option, shown below, can be used to set a priority flag 844 for the path which is specified by the AddrID field that uniquely 845 identifies the path. The option can be sent over any path. 847 1 2 3 848 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 849 +---------------+---------------+-------+-------+--------------+ 850 | Type | Length |Subtype| Prio | AddrID | 851 +---------------+---------------+-------+-------+--------------+ 853 The following values are available for Prio field: 855 * 0: Do not use. The path is not available. 857 * 1: Standby: do not use this path for traffic scheduling, if 858 another path (secondary or primary) is available. 860 * 2: Secondary: do not use this path for traffic scheduling, if the 861 other paths are good enough. The path will be used occasionally, 862 e.g. when primary paths are congested or become not available. 864 * 3: Primary: can use the path in any way deemed reasonable by peer. 865 Will always be used for packet scheduling decisions. 867 * 4 - 15: relative priority of one path over the other to give 868 relative path priority for primary paths. The peer should 869 consider sending more traffic over higher priority path. Higher 870 numbers indicate higher priority. 872 Example use cases include: 1) Setting Wi-Fi path to Primary and 873 Cellular paths to Secondary. In this case Wi-Fi will be used and 874 Cellular only if the Wi-Fi path is congested or not available. Such 875 setting results in using the Cellular path only temporally, if more 876 capacity is needed than the WiFi path can provide, indicating a clear 877 priority of the Wi-Fi path over the Cellular due to e.g. cost 878 reasons. 880 2) Setting Wi-Fi path to Primary and Cellular to Standby. In this 881 case Wi-Fi will be used and Cellular only, if the Wi-Fi path is not 882 available. 3) Setting Wi-Fi path to Primary and Cellular path to 883 Primary. In this case, all packets can be scheduled over all paths 884 at all time. 886 The default behavior is, that a path can always be used for packet 887 scheduling decisions (MP_PRIO=3), if the path has been established 888 and added to an existing MP-DCCP connection. At least one path 889 should have a MP_PRIO value greater or equal to one for it to be 890 allowed to send on the connection. MP_PRIO is assumed to be 891 exchanged reliably using the MP_CONFIRM mechanisms (see Table 4). 893 3.2.11. MP_CLOSE 894 +--------+--------+--------+--------+--------+ 895 |00101110| Length |00001010| Key Data ... 896 +--------+--------+--------+--------+--------+ 897 Type=46 MP_OPT=2 899 If the MP_CLOSE is present in a DCCP-CloseReq or DCCP-Close, the MP- 900 DCCP connection is closed using the regular procedure of single-path 901 DCCP termination on all subflows. Only in case all subflows are 902 successfully terminated, the overall MP-DCCP connection passes to a 903 closed state. 905 Contrary to a MP_FAST_CLOSE Section 3.2.3, no single-sided abrupt 906 termination is applied. 908 3.3. MP-DCCP Handshaking Procedure 910 Host A Host B 911 ------------------------ ---------- 912 Address A1 Address A2 Address B1 913 ---------- ---------- ---------- 914 | | | 915 | DCCP-Request + MP_CAPABLE | 916 |------- MP_KEY(Key-A(1), Key-A(2),...) ------------->| 917 |<---------------------- MP_KEY(Key-B) ---------------| 918 | DCCP-Response + MP_CAPABLE | 919 | | | 920 | DCCP-Ack | | 921 |--------- MP_KEY(Key-A) + MP_KEY(Key-B) ------------>| 922 |<----------------------------------------------------| 923 | DCCP-Ack | | 924 | | | 925 | | DCCP-Request + MP_CAPABLE | 926 | |--- MP_JOIN(TB,RA) ------------------->| 927 | |<------MP_JOIN(TB,RB) + MP_HMAC(A)-----| 928 | |DCCP-Response + MP_CAPABLE | 929 | | | 930 | |DCCP-Ack | 931 | |-------- MP_HMAC(B) ------------------>| 932 | |<--------------------------------------| 933 | |DCCP-ACK | 935 Figure 3: Example MP-DCCP Handshake 937 The basic initial handshake for the first flow is as follows: 939 * Host A sends a DCCP-Request with the MP-Capable feature Change 940 request and the MP_KEY option with an Host-specific Key-A for each 941 of supported types as described in Section 3.2.4 943 * Host B sends a DCCP-Response with Confirm feature for MP-Capable 944 and the MP_Key option with a single Host-specific Key-B. The type 945 of the key MUST be chosen from the list of supported types from 946 the previous request 948 * Host A sends a DCCP-Ack with both Keys echoed to Host B. 950 * Host B sends a DCCP-Ack to confirm both keys and conclude the 951 handshaking. 953 Host A MUST wait the final DCCP-Ack from host B before starting any 954 establishment of additional subflow connections. 956 The handshake for subsequent flows based on a successful initial 957 handshake is as follows: 959 * Host A sends a DCCP-Request with the MP-Capable feature Change 960 request and the MP_JOIN option with Host B's Token TB, generated 961 from the derived key by applying a SHA256 hash and truncating to 962 the first 32 bits. Additionally, an own random nonce RA is 963 transmitted with the MP_JOIN. 965 * Host B computes the HMAC of the DCCP-Request and sends a DCCP- 966 Response with Confirm feature option for MP-Capable and the 967 MP_JOIN option with the Token TB and a random nonce RB together 968 with the computed MP_HMAC. The HMAC is calculated by taking the 969 leftmost 20 bytes from the SHA256 hash of a HMAC code created by 970 using token and nonce received with MP_JOIN(A) as message and the 971 derived key described in Section 3.2.4 as key: 973 MP_HMAC(A) = HMAC-SHA256(Key=d-key(B), Msg=TB+RA) 975 * Host A sends a DCCP-Ack with the HMAC computed for the DCCP- 976 Response. The HMAC is calculated by taking the leftmost 20 bytes 977 from the SHA256 hash of a HMAC code created by using token and 978 nonce received with MP_JOIN(B) as message and the derived key 979 described in Section 3.2.4 as key: 981 MP_HMAC(A) = HMAC-SHA256(Key=d-key(A), Msg=TB+RB) 983 * Host B sends a DCCP-Ack to confirm the HMAC and to conclude the 984 handshaking. 986 3.4. Close a MP-DCCP connection 988 [tbd] 990 3.5. Fallback 992 When a subflow fails to operate within the MP-DCCP requirements, it 993 is necessary to fall back to the safe operation. This may be either 994 falling back to regular DCCP, or removing a problematic subflow. The 995 main reason for subflow failing is loss of MP-DCCP options. 997 At the start of the MP-DCCP connection, the handshake ensures 998 exchange of MP-DCCP options and thus ensures that the path is fully 999 MP-DCCP capable. If during the handshake procedure it appears that 1000 DCCP-Request or DCCP-Response or DCCP-Ack messages don't have the MP- 1001 DCCP options, the MP-DCCP connection will not be established and the 1002 handshake should fall back to regular DCCP. The same fallback should 1003 take place if the endpoints fail to agree on a protocol version to 1004 use during the Multipath Capable feature negotiation. 1006 If a subflow attempts to join an existing MP-DCCP connection, but MP- 1007 DCCP options are not present in the handshake messages or the 1008 protocol version doesn't match the value negotiated for the first 1009 flow, that subflow will be closed. 1011 3.6. Congestion Control Considerations 1013 Senders MUST manage per-path congestion status, and SHOULD avoid to 1014 send more data on a given path than congestion control on that path 1015 allows. 1017 When a Multipath DCCP connection uses two or more paths, there is no 1018 guarantee that these paths are fully disjoint. When two (or more 1019 paths) share the same bottleneck, using a standard congestion control 1020 scheme could result in an unfair distribution of the bandwidth with 1021 the multipath connection getting more bandwidth than competing single 1022 path connections. Multipath TCP uses the coupled congestion control 1023 Linked Increases Algorithm (LIA) specified in [RFC6356] to solve this 1024 problem. This scheme can be adapted also for Multipath DCCP. The 1025 same applies to other coupled congestion control schemes, which have 1026 been proposed for Multipath TCP such as Opportunistic Linked 1027 Increases Algorithm [OLIA]. 1029 3.7. Maximum Packet Size Considerations 1031 A DCCP implementation MUST maintain the maximum packet size (MPS) 1032 during operation of a DCCP session. This procedure is specified for 1033 single-path DCCP in [RFC4340], Section 14. Without any restrictions, 1034 this is adopted for MP-DCCP operations, in particular the PMTU 1035 measurement and the Sender Behaviour. As per this definition a DCCP 1036 application interface SHOULD let the application discover the current 1037 MPS, this is subject to ambiguity with potential different path MPS 1038 in a multi-path system. For compatibility reasons, a MP-DCCP 1039 implementation SHOULD always announce the minimum MPS across all 1040 paths. 1042 4. Security Considerations 1044 Similar to DCCP, MP-DCCP does not provide cryptographic security 1045 guarantees inherently. Thus, if applications need cryptographic 1046 security (integrity, authentication, confidentiality, access control, 1047 and anti-replay protection) the use of IPsec or some other kind of 1048 end-to-end security is recommended; Secure Real-time Transport 1049 Protocol (SRTP) [RFC3711] is one candidate protocol for 1050 authentication. Together with Encryption of Header Extensions in 1051 SRTP, as provided by [RFC6904], also integrity would be provided. 1053 As described in [RFC4340], DCCP provides protection against hijacking 1054 and limits the potential impact of some denial-of-service attacks, 1055 but DCCP provides no inherent protection against attackers' snooping 1056 on data packets. Regarding the security of MP-DCCP no additional 1057 risks should be introduced compared to regular DCCP of today. 1058 Thereof derived are the following key security requirements to be 1059 fulfilled by MP-DCCP: 1061 * Provide a mechanism to confirm that parties involved in a subflow 1062 handshake are identical to those in the original connection setup. 1064 * Provide verification that the new address to be included in a MP 1065 connection is valid for a peer to receive traffic at before using 1066 it. 1068 * Provide replay protection, i.e., ensure that a request to add/ 1069 remove a subflow is 'fresh'. 1071 In order to achieve these goals, MP-DCCP includes a hash-based 1072 handshake algorithm documented in Sections Section 3.2.4 and 1073 Section 3.3. The security of the MP-DCCP connection depends on the 1074 use of keys that are shared once at the start of the first subflow 1075 and are never sent again over the network. To ease demultiplexing 1076 while not giving away any cryptographic material, future subflows use 1077 a truncated cryptographic hash of this key as the connection 1078 identification "token". The keys are concatenated and used as keys 1079 for creating Hash-based Message Authentication Codes (HMACs) used on 1080 subflow setup, in order to verify that the parties in the handshake 1081 are the same as in the original connection setup. It also provides 1082 verification that the peer can receive traffic at this new address. 1083 Replay attacks would still be possible when only keys are used; 1084 therefore, the handshakes use single-use random numbers (nonces) at 1085 both ends -- this ensures that the HMAC will never be the same on two 1086 handshakes. Guidance on generating random numbers suitable for use 1087 as keys is given in [RFC4086]. During normal operation, regular DCCP 1088 protection mechanisms (such as header checksum to protect DCCP 1089 headers against corruption) will provide the same level of protection 1090 against attacks on individual DCCP subflows as exists for regular 1091 DCCP today. 1093 5. Interactions with Middleboxes 1095 Issues from interaction with on-path middleboxes such as NATs, 1096 firewalls, proxies, intrusion detection systems (IDSs), and others 1097 have to be considered for all extensions to standard protocols since 1098 otherwise unexpected reactions of middleboxes may hinder its 1099 deployment. DCCP already provides means to mitigate the potential 1100 impact of middleboxes, also in comparison to TCP (see [RFC4043], 1101 sect. 16). In case, however, both hosts are located behind a NAT or 1102 firewall entity, specific measures have to be applied such as the 1103 [RFC5596]-specified simultaneous-open technique that update the 1104 (traditionally asymmetric) connection-establishment procedures for 1105 DCCP. Further standardized technologies addressing NAT type 1106 middleboxes are covered by [RFC5597]. 1108 [RFC6773] specifies UDP Encapsulation for NAT Traversal of DCCP 1109 sessions, similar to other UDP encapsulations such as for SCTP 1110 [RFC6951]. The alternative U-DCCP approach proposed in 1111 [I-D.amend-tsvwg-dccp-udp-header-conversion] would reduce tunneling 1112 overhead. The handshaking procedure for DCCP-UDP header conversion 1113 or use of a DCCP-UDP negotiation procedure to signal support for 1114 DCCP-UDP header conversion would require encapsulation during the 1115 handshakes and use of two additional port numbers out of the UDP port 1116 number space, but would require zero overhead afterwards. 1118 6. Implementation 1120 The approach described above has been implemented in open source 1121 across different testbeds and a new scheduling algorithm has been 1122 extensively tested. Also demonstrations of a laboratory setup have 1123 been executed and have been published at [website]. 1125 7. Acknowledgments 1127 Due to the great spearheading work of the Multipath TCP authors in 1128 [RFC6824]/[RFC8684], some text passages for the -00 version of the 1129 draft were copied almost unmodified. 1131 The authors gratefully acknowledge significant input into this 1132 document from Dirk von Hugo. 1134 8. IANA Considerations 1136 This document defines one new value to DCCP feature list and one new 1137 DCCP Option with ten corresponding Subtypes as follows. This 1138 document defines a new DCCP feature parameter for negotiating the 1139 support of multipath capability for DCCP sessions between hosts as 1140 described in Section 3. The following entry in Table 6 should be 1141 added to the "Feature Numbers Registry" according to [RFC4340], 1142 Section 19.4. under the "DCCP Protocol" heading. 1144 +=======+============================+===============+ 1145 | Value | Feature Name | Specification | 1146 +=======+============================+===============+ 1147 | 0x10 | MP-DCCP capability feature | Section 3.1 | 1148 +-------+----------------------------+---------------+ 1150 Table 6: Addition to DCCP Feature list Entries 1152 This document defines a new DCCP protocol option of type=46 as 1153 described in Section 3.2 together with 10 additional sub-options. 1154 The following entries in Table 7 should be added to the "DCCP 1155 Protocol options" and assigned as "MP-DCCP sub-options", 1156 respectively. 1158 +==========+===============+=====================+===========+ 1159 | Value | Symbol | Name | Reference | 1160 +==========+===============+=====================+===========+ 1161 | TBD or | MP_OPT | DCCP Multipath | Section | 1162 | Type=46 | | option | 3.2 | 1163 +----------+---------------+---------------------+-----------+ 1164 | TBD or | MP_CONFIRM | Confirm reception/ | Section | 1165 | MP_OPT=0 | | processing of an | 3.2.1 | 1166 | | | MP_OPT option | | 1167 +----------+---------------+---------------------+-----------+ 1168 | TBD or | MP_JOIN | Join path to | Section | 1169 | MP_OPT=1 | | existing MP-DCCP | 3.2.2 | 1170 | | | flow | | 1171 +----------+---------------+---------------------+-----------+ 1172 | TBD or | MP_FAST_CLOSE | Close MP-DCCP flow | Section | 1173 | MP_OPT=2 | | | 3.2.3 | 1174 +----------+---------------+---------------------+-----------+ 1175 | TBD or | MP_KEY | Exchange key | Section | 1176 | MP_OPT=3 | | material for | 3.2.4 | 1177 | | | MP_HMAC | | 1178 +----------+---------------+---------------------+-----------+ 1179 | TBD or | MP_SEQ | Multipath Sequence | Section | 1180 | MP_OPT=4 | | Number | 3.2.5 | 1181 +----------+---------------+---------------------+-----------+ 1182 | TBD or | MP_HMAC | Hash-based Message | Section | 1183 | MP_OPT=5 | | Auth. Code for MP- | 3.2.6 | 1184 | | | DCCP | | 1185 +----------+---------------+---------------------+-----------+ 1186 | TBD or | MP_RTT | Transmit RTT values | Section | 1187 | MP_OPT=6 | | and calculation | 3.2.7 | 1188 | | | parameters | | 1189 +----------+---------------+---------------------+-----------+ 1190 | TBD or | MP_ADDADDR | Advertise | Section | 1191 | MP_OPT=7 | | additional | 3.2.8 | 1192 | | | Address(es)/Port(s) | | 1193 +----------+---------------+---------------------+-----------+ 1194 | TBD or | MP_REMOVEADDR | Remove Address(es)/ | Section | 1195 | MP_OPT=8 | | Port(s) | 3.2.9 | 1196 +----------+---------------+---------------------+-----------+ 1197 | TBD or | MP_PRIO | Change Subflow | Section | 1198 | MP_OPT=9 | | Priority | 3.2.10 | 1199 +----------+---------------+---------------------+-----------+ 1201 Table 7: Addition to DCCP Protocol options and 1202 corresponding sub-options 1204 According to the definition of the MP_FAST_CLOSE option in 1205 Section 3.2.3, a new Reset Code value 12 with the name "Abrupt MP 1206 termination" should be added. 1208 [Tbd], must include options for: 1210 * handshaking procedure to indicate MP support 1212 * handshaking procedure to indicate JOINING of an existing MP 1213 connection 1215 * signaling of new or changed addresses 1217 * setting handover or aggregation mode 1219 * MP-specific congestion mechanisms 1221 should include options carrying: 1223 * overall sequence number for restoring/re-assembly/re-ordering 1224 purposes 1226 * sender time measurements for restoring/re-assembly/re-ordering 1227 purposes 1229 9. Informative References 1231 [I-D.amend-iccrg-multipath-reordering] 1232 Amend, M. and D. V. Hugo, "Multipath sequence 1233 maintenance", Work in Progress, Internet-Draft, draft- 1234 amend-iccrg-multipath-reordering-03, 25 October 2021, 1235 . 1238 [I-D.amend-tsvwg-dccp-udp-header-conversion] 1239 Amend, M., Brunstrom, A., Kassler, A., and V. Rakocevic, 1240 "Lossless and overhead free DCCP - UDP header conversion 1241 (U-DCCP)", Work in Progress, Internet-Draft, draft-amend- 1242 tsvwg-dccp-udp-header-conversion-01, 8 July 2019, 1243 . 1246 [I-D.amend-tsvwg-multipath-framework-mpdccp] 1247 Amend, M., Bogenfeld, E., Brunstrom, A., Kassler, A., and 1248 V. Rakocevic, "A multipath framework for UDP traffic over 1249 heterogeneous access networks", Work in Progress, 1250 Internet-Draft, draft-amend-tsvwg-multipath-framework- 1251 mpdccp-01, 8 July 2019, . 1254 [I-D.lhwxz-hybrid-access-network-architecture] 1255 Leymann, N., Heidemann, C., Wesserman, M., Xue, L., and M. 1256 Zhang, "Hybrid Access Network Architecture", Work in 1257 Progress, Internet-Draft, draft-lhwxz-hybrid-access- 1258 network-architecture-02, 13 January 2015, 1259 . 1262 [I-D.muley-network-based-bonding-hybrid-access] 1263 Muley, P., Henderickx, W., Liang, G., Liu, H., Cardullo, 1264 L., Newton, J., Seo, S., Draznin, S., and B. Patil, 1265 "Network based Bonding solution for Hybrid Access", Work 1266 in Progress, Internet-Draft, draft-muley-network-based- 1267 bonding-hybrid-access-03, 22 October 2018, 1268 . 1271 [OLIA] Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J.- 1272 Y. Le Boudec, "MPTCP is not pareto-optimal: performance 1273 issues and a possible solution", Proceedings of the 8th 1274 international conference on Emerging networking 1275 experiments and technologies, ACM , 2012. 1277 [paper] Amend, M., Bogenfeld, E., Cvjetkovic, M., Rakocevic, V., 1278 Pieska, M., Kassler, A., and A. Brunstrom, "A Framework 1279 for Multiaccess Support for Unreliable Internet Traffic 1280 using Multipath DCCP", DOI 10.1109/LCN44214.2019.8990746, 1281 October 2019, 1282 . 1284 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1285 RFC 793, DOI 10.17487/RFC0793, September 1981, 1286 . 1288 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1289 Hashing for Message Authentication", RFC 2104, 1290 DOI 10.17487/RFC2104, February 1997, 1291 . 1293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1294 Requirement Levels", BCP 14, RFC 2119, 1295 DOI 10.17487/RFC2119, March 1997, 1296 . 1298 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 1299 RFC 3124, DOI 10.17487/RFC3124, June 2001, 1300 . 1302 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1303 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1304 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1305 . 1307 [RFC4043] Pinkas, D. and T. Gindin, "Internet X.509 Public Key 1308 Infrastructure Permanent Identifier", RFC 4043, 1309 DOI 10.17487/RFC4043, May 2005, 1310 . 1312 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1313 "Randomness Requirements for Security", BCP 106, RFC 4086, 1314 DOI 10.17487/RFC4086, June 2005, 1315 . 1317 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1318 Congestion Control Protocol (DCCP)", RFC 4340, 1319 DOI 10.17487/RFC4340, March 2006, 1320 . 1322 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 1323 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 1324 September 2009, . 1326 [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol 1327 (DCCP) Simultaneous-Open Technique to Facilitate NAT/ 1328 Middlebox Traversal", RFC 5596, DOI 10.17487/RFC5596, 1329 September 2009, . 1331 [RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) 1332 Behavioral Requirements for the Datagram Congestion 1333 Control Protocol", BCP 150, RFC 5597, 1334 DOI 10.17487/RFC5597, September 2009, 1335 . 1337 [RFC5634] Fairhurst, G. and A. Sathiaseelan, "Quick-Start for the 1338 Datagram Congestion Control Protocol (DCCP)", RFC 5634, 1339 DOI 10.17487/RFC5634, August 2009, 1340 . 1342 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1343 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1344 DOI 10.17487/RFC6234, May 2011, 1345 . 1347 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 1348 Congestion Control for Multipath Transport Protocols", 1349 RFC 6356, DOI 10.17487/RFC6356, October 2011, 1350 . 1352 [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A 1353 Datagram Congestion Control Protocol UDP Encapsulation for 1354 NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 1355 2012, . 1357 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1358 "TCP Extensions for Multipath Operation with Multiple 1359 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1360 . 1362 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 1363 Real-time Transport Protocol (SRTP)", RFC 6904, 1364 DOI 10.17487/RFC6904, April 2013, 1365 . 1367 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 1368 Control Transmission Protocol (SCTP) Packets for End-Host 1369 to End-Host Communication", RFC 6951, 1370 DOI 10.17487/RFC6951, May 2013, 1371 . 1373 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 1374 Paasch, "TCP Extensions for Multipath Operation with 1375 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 1376 2020, . 1378 [slide] Amend, M., "MP-DCCP for enabling transfer of UDP/IP 1379 traffic over multiple data paths in multi-connectivity 1380 networks", IETF105 , n.d., 1381 . 1385 [TS23.501] 3GPP, "System architecture for the 5G System; Stage 2; 1386 Release 16", December 2020, 1387 . 1390 [website] "Multipath extension for DCCP", n.d., 1391 . 1393 Appendix A. Differences from Multipath TCP 1395 Multipath DCCP is similar to Multipath TCP [RFC8684], in that it 1396 extends the related basic DCCP transport protocol [RFC4340] with 1397 multipath capabilities in the same way as Multipath TCP extends TCP 1398 [RFC0793]. However, because of the differences between the 1399 underlying TCP and DCCP protocols, the transport characteristics of 1400 MPTCP and MP-DCCP are different. 1402 Table 8 compares the protocol characteristics of TCP and DCCP, which 1403 are by nature inherited by their respective multipath extensions. A 1404 major difference lies in the delivery of payload, which is for TCP an 1405 exact copy of the generated byte-stream. DCCP behaves in a different 1406 way and does not guarantee to deliver any payload nor the order of 1407 delivery. Since this is mainly affecting the receiving endpoint of a 1408 TCP or DCCP communication, many similarities on the sender side can 1409 be identified. Both transport protocols share the 3-way initiation 1410 of a communication and both employ congestion control to adapt the 1411 sending rate to the path characteristics. 1413 +=======================+=================+======================+ 1414 | Feature | TCP | DCCP | 1415 +=======================+=================+======================+ 1416 | Full-Duplex | yes | yes | 1417 +-----------------------+-----------------+----------------------+ 1418 | Connection-Oriented | yes | yes | 1419 +-----------------------+-----------------+----------------------+ 1420 | Header option space | 40 bytes | < 1008 bytes or PMTU | 1421 +-----------------------+-----------------+----------------------+ 1422 | Data transfer | reliable | unreliable | 1423 +-----------------------+-----------------+----------------------+ 1424 | Packet-loss handling | re-transmission | report only | 1425 +-----------------------+-----------------+----------------------+ 1426 | Ordered data delivery | yes | no | 1427 +-----------------------+-----------------+----------------------+ 1428 | Sequence numbers | one per byte | one per PDU | 1429 +-----------------------+-----------------+----------------------+ 1430 | Flow control | yes | no | 1431 +-----------------------+-----------------+----------------------+ 1432 | Congestion control | yes | yes | 1433 +-----------------------+-----------------+----------------------+ 1434 | ECN support | yes | yes | 1435 +-----------------------+-----------------+----------------------+ 1436 | Selective ACK | yes | depends on | 1437 | | | congestion control | 1438 +-----------------------+-----------------+----------------------+ 1439 | Fix message | no | yes | 1440 | boundaries | | | 1441 +-----------------------+-----------------+----------------------+ 1442 | Path MTU discovery | yes | yes | 1443 +-----------------------+-----------------+----------------------+ 1444 | Fragmentation | yes | no | 1445 +-----------------------+-----------------+----------------------+ 1446 | SYN flood protection | yes | no | 1447 +-----------------------+-----------------+----------------------+ 1448 | Half-open connections | yes | no | 1449 +-----------------------+-----------------+----------------------+ 1451 Table 8: TCP and DCCP protocol comparison 1453 Consequently, the multipath features, shown in Table 9, are the same, 1454 supporting volatile paths having varying capacity and latency, 1455 session handover and path aggregation capabilities. All of them 1456 profit by the existence of congestion control. 1458 +==================+=======================+==========+ 1459 | Feature | MPTCP | MP-DCCP | 1460 +==================+=======================+==========+ 1461 | Volatile paths | yes | yes | 1462 +------------------+-----------------------+----------+ 1463 | Session handover | yes | yes | 1464 +------------------+-----------------------+----------+ 1465 | Path aggregation | yes | yes | 1466 +------------------+-----------------------+----------+ 1467 | Data reordering | yes | optional | 1468 +------------------+-----------------------+----------+ 1469 | Expandability | limited by TCP header | flexible | 1470 +------------------+-----------------------+----------+ 1472 Table 9: MPTCP and MP-DCCP protocol comparison 1474 Therefore, the sender logic is not much different between MP-DCCP and 1475 MPTCP. 1477 The receiver side for MP-DCCP has to deal with the unreliable 1478 transport character of DCCP. The multipath sequence numbers included 1479 in MP-DCCP (see Section 3.2.5) facilitates adding optional mechanisms 1480 for data stream packet reordering at the receiver. Information from 1481 the MP_RTT multipath option (Section 3.2.7), DCCP path sequencing and 1482 the DCCP Timestamp Option provide further means for advanced 1483 reordering approaches, e.g., as described in 1484 [I-D.amend-iccrg-multipath-reordering]. Such mechanisms do, however, 1485 not affect interoperability and are not part of the MP-DCCP protocol. 1486 Many applications that use unreliable transport protocols can also 1487 inherently deal with out-of-sequence data (e.g., through adaptive 1488 audio and video buffers), and so additional reordering support may 1489 not be necessary. The addition of optional reordering mechanisms are 1490 most likely to be needed when the different DCCP subflows are routed 1491 across paths with different latencies. In theory, applications using 1492 DCCP are aware that packet reordering might happen, since DCCP has no 1493 mechanisms to prevent it. 1495 The receiving process for MPTCP is on the other hand a rigid "just 1496 wait" approach, since TCP guarantees reliable delivery. 1498 Authors' Addresses 1500 Markus Amend (editor) 1501 Deutsche Telekom 1502 Deutsche-Telekom-Allee 9 1503 64295 Darmstadt 1504 Germany 1505 Email: Markus.Amend@telekom.de 1506 Anna Brunstrom 1507 Karlstad University 1508 Universitetsgatan 2 1509 SE-651 88 Karlstad 1510 Sweden 1511 Email: anna.brunstrom@kau.se 1513 Andreas Kassler 1514 Karlstad University 1515 Universitetsgatan 2 1516 SE-651 88 Karlstad 1517 Sweden 1518 Email: andreas.kassler@kau.se 1520 Veselin Rakocevic 1521 City University of London 1522 Northampton Square 1523 London 1524 United Kingdom 1525 Email: veselin.rakocevic.1@city.ac.uk 1527 Stephen Johnson 1528 BT 1529 Adastral Park 1530 Martlesham Heath 1531 IP5 3RE 1532 United Kingdom 1533 Email: stephen.h.johnson@bt.com