idnits 2.17.1 draft-ietf-tsvwg-multipath-dccp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 November 2021) is 899 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Nonce 0' is mentioned on line 439, but not defined == Missing Reference: 'Nonce 1' is mentioned on line 441, but not defined == Missing Reference: 'Tbd' is mentioned on line 1170, but not defined == Unused Reference: 'I-D.muley-network-based-bonding-hybrid-access' is defined on line 1223, but no explicit reference was found in the text == Unused Reference: 'RFC5596' is defined on line 1281, but no explicit reference was found in the text == Unused Reference: 'RFC6824' is defined on line 1307, but no explicit reference was found in the text -- 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 Transport Area Working Group M. Amend, Ed. 3 Internet-Draft DT 4 Intended status: Experimental A. Brunstrom 5 Expires: 13 May 2022 A. Kassler 6 Karlstad University 7 V. Rakocevic 8 City University of London 9 S. Johnson 10 BT 11 9 November 2021 13 DCCP Extensions for Multipath Operation with Multiple Addresses 14 draft-ietf-tsvwg-multipath-dccp-02 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 13 May 2022. 57 Copyright Notice 59 Copyright (c) 2021 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 Simplified BSD License text 68 as described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Simplified 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. Differences from Multipath TCP . . . . . . . . . . . . . 5 78 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 7 79 2. Operation Overview . . . . . . . . . . . . . . . . . . . . . 8 80 3. MP-DCCP Protocol . . . . . . . . . . . . . . . . . . . . . . 8 81 3.1. Multipath Capable Feature . . . . . . . . . . . . . . . . 12 82 3.2. Multipath Option . . . . . . . . . . . . . . . . . . . . 13 83 3.2.1. MP_CONFIRM . . . . . . . . . . . . . . . . . . . . . 14 84 3.2.2. MP_JOIN . . . . . . . . . . . . . . . . . . . . . . . 15 85 3.2.3. MP_FAST_CLOSE . . . . . . . . . . . . . . . . . . . . 15 86 3.2.4. MP_KEY . . . . . . . . . . . . . . . . . . . . . . . 15 87 3.2.5. MP_SEQ . . . . . . . . . . . . . . . . . . . . . . . 17 88 3.2.6. MP_HMAC . . . . . . . . . . . . . . . . . . . . . . . 17 89 3.2.7. MP_RTT . . . . . . . . . . . . . . . . . . . . . . . 17 90 3.2.8. MP_ADDADDR . . . . . . . . . . . . . . . . . . . . . 18 91 3.2.9. MP_REMOVEADDR . . . . . . . . . . . . . . . . . . . . 20 92 3.2.10. MP_PRIO . . . . . . . . . . . . . . . . . . . . . . . 21 93 3.3. MP-DCCP Handshaking Procedure . . . . . . . . . . . . . . 22 94 3.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 23 95 4. Security Considerations . . . . . . . . . . . . . . . . . . . 24 96 5. Interactions with Middleboxes . . . . . . . . . . . . . . . . 25 97 6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 25 98 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 100 9. Informative References . . . . . . . . . . . . . . . . . . . 28 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 103 1. Introduction 105 Multipath DCCP (MP-DCCP) is a set of extensions to regular DCCP 106 [RFC4340], i.e., the Datagram Congestion Control Protocol denoting a 107 transport protocol that provides bidirectional unicast connections of 108 congestion-controlled unreliable datagrams. A multipath extension to 109 DCCP enables the transport of user data across multiple paths 110 simultaneously. This is beneficial to applications that transfer 111 fairly large amounts of data, due to the possibility to aggregate 112 capacity of the multiple paths. In addition, it enables to tradeoff 113 timeliness and reliability, which is important for low latency 114 applications that do not require guaranteed delivery services such as 115 Audio/Video streaming. DCCP multipath operation is suggested in the 116 context of ongoing 3GPP work on 5G multi-access solutions 117 [I-D.amend-tsvwg-multipath-framework-mpdccp] and for hybrid access 118 networks [I-D.lhwxz-hybrid-access-network-architecture][I-D.muley-net 119 work-based-bonding-hybrid-access]. It can be applied for load- 120 balancing, seamless session handover, and aggregation purposes 121 (referred to as ATSSS; Access steering, switching, and splitting in 122 3GPP terminology [TS23.501]). 124 This document presents the protocol changes required to add multipath 125 capability to DCCP; specifically, those for signaling and setting up 126 multiple paths ("subflows"), managing these subflows, reordering of 127 data, and termination of sessions. DCCP, as stated in [RFC4340] does 128 not provide reliable and ordered delivery. Consequently, multiple 129 application subflows may be multiplexed over a single DCCP connection 130 with no inherent performance penalty for flows that do not require 131 in-ordered delivery. DCCP does not provide built-in support for 132 those multiple application subflows. 134 In the following, use of the term subflow will refer to physical 135 separate DCCP subflows transmitted via different paths, but not to 136 application subflows. Application subflows are differing content- 137 wise by source and destination port per application as, for example, 138 enabled by Service Codes introduced to DCCP in [RFC5595], and those 139 subflows can be multiplexed over a single DCCP connection. For sake 140 of consistency we assume that only a single application is served by 141 a DCCP connection here as shown in Figure 1 while use of that feature 142 should not impact DCCP operation on each single path as noted in 143 ([RFC5595], sect. 2.4). 145 1.1. Multipath DCCP in the Networking Stack 147 MP-DCCP operates at the transport layer and aims to be transparent to 148 both higher and lower layers. It is a set of additional features on 149 top of standard DCCP; Figure 1 illustrates this layering. MP-DCCP is 150 designed to be used by applications in the same way as DCCP with no 151 changes to the application itself. 153 +-------------------------------+ 154 | Application | 155 +---------------+ +-------------------------------+ 156 | Application | | MP-DCCP | 157 +---------------+ + - - - - - - - + - - - - - - - + 158 | DCCP | |Subflow (DCCP) |Subflow (DCCP) | 159 +---------------+ +-------------------------------+ 160 | IP | | IP | IP | 161 +---------------+ +-------------------------------+ 163 Figure 1: Comparison of Standard DCCP and MP-DCCP Protocol Stacks 165 1.2. Terminology 167 Throughout this document we make use of terms that are either 168 specific for multipath transport or are defined in the context of MP- 169 DCCP, similar to [RFC8684], as follows: 171 Path: A sequence of links between a sender and a receiver, defined in 172 this context by a 4-tuple of source and destination address/ port 173 pairs. 175 Subflow: A flow of DCCP segments operating over an individual path, 176 which forms part of a larger MP-DCCP connection. A subflow is 177 started and terminated similar to a regular (single-path) DCCP 178 connection. 180 (MP-DCCP) Connection: A set of one or more subflows, over which an 181 application can communicate between two hosts. There is a one-to-one 182 mapping between a connection and an application socket. 184 Token: A locally unique identifier given to a multipath connection by 185 a host. May also be referred to as a "Connection ID". 187 Host: An end host operating an MP-DCCP implementation, and either 188 initiating or accepting an MP-DCCP connection. In addition to these 189 terms, within framework of MP-DCCP the interpretation of, and effect 190 on, regular single-path DCCP semantics is discussed in Section 3. 192 1.3. MP-DCCP Concept 194 Host A Host B 195 ------------------------ ------------------------ 196 Address A1 Address A2 Address B1 Address B2 197 ---------- ---------- ---------- ---------- 198 | | | | 199 | (DCCP flow setup) | | 200 |----------------------------------->| | 201 |<-----------------------------------| | 202 | | | | 203 | | (DCCP flow setup) | | 204 | |--------------------->| | 205 | |<---------------------| | 206 | merge individual DCCP flows to one multipath connection 207 | | | | 209 Figure 2: Example MP-DCCP Usage Scenario 211 1.4. Differences from Multipath TCP 213 Multipath DCCP is similar to Multipath TCP [RFC8684], in that it 214 extends the related basic DCCP transport protocol [RFC4340] with 215 multipath capabilities in the same way as Multipath TCP extends TCP 216 [RFC0793]. However, because of the differences between the 217 underlying TCP and DCCP protocols, the transport characteristics of 218 MPTCP and MP-DCCP are different. 220 Table 1 compares the protocol characteristics of TCP and DCCP, which 221 are by nature inherited by their respective multipath extensions. A 222 major difference lies in the delivery of payload, which is for TCP an 223 exact copy of the generated byte-stream. DCCP behaves in a different 224 way and does not guarantee to deliver any payload nor the order of 225 delivery. Since this is mainly affecting the receiving endpoint of a 226 TCP or DCCP communication, many similarities on the sender side can 227 be identified. Both transport protocols share the 3-way initiation 228 of a communication and both employ congestion control to adapt the 229 sending rate to the path characteristics. 231 +=======================+=================+======================+ 232 | Feature | TCP | DCCP | 233 +=======================+=================+======================+ 234 | Full-Duplex | yes | yes | 235 +-----------------------+-----------------+----------------------+ 236 | Connection-Oriented | yes | yes | 237 +-----------------------+-----------------+----------------------+ 238 | Header option space | 40 bytes | < 1008 bytes or PMTU | 239 +-----------------------+-----------------+----------------------+ 240 | Data transfer | reliable | unreliable | 241 +-----------------------+-----------------+----------------------+ 242 | Packet-loss handling | re-transmission | report only | 243 +-----------------------+-----------------+----------------------+ 244 | Ordered data delivery | yes | no | 245 +-----------------------+-----------------+----------------------+ 246 | Sequence numbers | one per byte | one per PDU | 247 +-----------------------+-----------------+----------------------+ 248 | Flow control | yes | no | 249 +-----------------------+-----------------+----------------------+ 250 | Congestion control | yes | yes | 251 +-----------------------+-----------------+----------------------+ 252 | ECN support | yes | yes | 253 +-----------------------+-----------------+----------------------+ 254 | Selective ACK | yes | depends on | 255 | | | congestion control | 256 +-----------------------+-----------------+----------------------+ 257 | Fix message | no | yes | 258 | boundaries | | | 259 +-----------------------+-----------------+----------------------+ 260 | Path MTU discovery | yes | yes | 261 +-----------------------+-----------------+----------------------+ 262 | Fragmentation | yes | no | 263 +-----------------------+-----------------+----------------------+ 264 | SYN flood protection | yes | no | 265 +-----------------------+-----------------+----------------------+ 266 | Half-open connections | yes | no | 267 +-----------------------+-----------------+----------------------+ 269 Table 1: TCP and DCCP protocol comparison 271 Consequently, the multipath features, shown in Table 2, are the same, 272 supporting volatile paths having varying capacity and latency, 273 session handover and path aggregation capabilities. All of them 274 profit by the existence of congestion control. 276 +==================+=======================+====================+ 277 | Feature | MPTCP | MP-DCCP | 278 +==================+=======================+====================+ 279 | Volatile paths | yes | yes | 280 +------------------+-----------------------+--------------------+ 281 | Session handover | yes | yes | 282 +------------------+-----------------------+--------------------+ 283 | Path aggregation | yes | yes | 284 +------------------+-----------------------+--------------------+ 285 | Data reordering | yes | optional / modular | 286 +------------------+-----------------------+--------------------+ 287 | Expandability | limited by TCP header | flexible | 288 +------------------+-----------------------+--------------------+ 290 Table 2: MPTCP and MP-DCCP protocol comparison 292 Therefore, the sender logic is not much different between MP-DCCP and 293 MPTCP. 295 The receiver side for MP-DCCP has to deal with the unreliable 296 transport character of DCCP, and can provide flexible handling for 297 data stream packet reordering for those applications where it is 298 beneficial. However, many applications that use unreliable transport 299 protocols can inherently deal with out-of-sequence data (e.g., 300 through adaptive audio and video buffers), and so additional 301 reordering support may not be necessary. The optional reordering 302 mechanisms in MP-DCCP are most likely to be required when the 303 different DCCP subflows are routed across paths with different 304 latencies. In theory, applications using DCCP are aware that packet 305 reordering might happen, since DCCP has no mechanisms to prevent it. 307 The receiving process for MPTCP is on the other hand a rigid "just 308 wait" approach, since TCP guarantees reliable delivery. 310 1.5. Requirements Language 312 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 313 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 314 document are to be interpreted as described in [RFC2119]. 316 2. Operation Overview 318 DCCP according to RFC 4340 [RFC4340] allows multiple application 319 subflows to be multiplexed over a single DCCP connection with 320 potentially same performance. However, DCCP does not provide built- 321 in support for multiple subflows and the Congestion Manager (CM) 322 [RFC3124], as a generic multiplexing facility, can not fully support 323 multiple congestion control mechanisms for multiple DCCP flows 324 between same source and destination addresses. 326 The proposed extension of DCCP towards Multipath-DCCP (MP-DCCP) is 327 described in detail in Section 3. 329 As a high level overview on the key functionality of MP-DCCP the data 330 stream from a DCCP application is split by MP-DCCP operation into one 331 or more subflows which can be transmitted via different also 332 physically isolated paths. Corresponding control information does 333 allow received data to be re-assembled and delivered in right order 334 to the recipient application. The following sections define this 335 behavior in detail. 337 The Multipath Capability for MP-DCCP can be negotiated with a new 338 DCCP feature, as described and fully specified in Section 3. Once 339 negotiated, all subsequent MP-DCCP operations are signalled with a 340 variable length multipath-related option, as described in 341 Section 3.1. 343 A Multipath DCCP connection provides a bidirectional byte-stream 344 between two hosts exchanging data as in standard DCCP manner thus not 345 requiring any change to the applications. However, Multipath DCCP 346 enables the hosts to use different paths with different IP addresses 347 to transport the packets of the MP-DCCP connection. MP-DCCP manages 348 the request, set-up, authentication, prioritization, modification, 349 and removal of the DCCP subflows on different paths as well as 350 exchange of performance parameters. The number of concurrent DCCP 351 subflows can vary during the lifetime of the Multipath DCCP 352 connection. All MP-DCCP operations are signaled with MP-DCCP options 353 described in detail in {#MP_OPT}. 355 3. MP-DCCP Protocol 357 The DCCP protocol feature list ([RFC4340] section 6.4) will be 358 enhanced by a new Multipath related feature with Feature number 10, 359 as shown in Table 3. 361 +=========+===================+======+=============+===============+ 362 | Number | Meaning | Rule | Rec'n Value | Initial Req'd | 363 +=========+===================+======+=============+===============+ 364 | 0 | Reserved | | | | 365 +---------+-------------------+------+-------------+---------------+ 366 | 1 | Congestion | SP | 2 | Y | 367 | | Control ID (CCID) | | | | 368 +---------+-------------------+------+-------------+---------------+ 369 | 2 | Allow Short | SP | 0 | Y | 370 | | Seqnos | | | | 371 +---------+-------------------+------+-------------+---------------+ 372 | 3 | Sequence Window | NN | 100 | Y | 373 +---------+-------------------+------+-------------+---------------+ 374 | 4 | ECN Incapable | SP | 0 | N | 375 +---------+-------------------+------+-------------+---------------+ 376 | 5 | Ack Ratio | NN | 2 | N | 377 +---------+-------------------+------+-------------+---------------+ 378 | 6 | Send Ack Vector | SP | 0 | N | 379 +---------+-------------------+------+-------------+---------------+ 380 | 7 | Send NDP Count | SP | 0 | N | 381 +---------+-------------------+------+-------------+---------------+ 382 | 8 | Minimum Checksum | SP | 0 | N | 383 | | Coverage | | | | 384 +---------+-------------------+------+-------------+---------------+ 385 | 9 | Check Data | SP | 0 | N | 386 | | Checksum | | | | 387 +---------+-------------------+------+-------------+---------------+ 388 | 10 | Multipath Capable | SP | 0 | N | 389 +---------+-------------------+------+-------------+---------------+ 390 | 11-127 | Reserved | | | | 391 +---------+-------------------+------+-------------+---------------+ 392 | 128-255 | CCID-specific | | | | 393 | | features | | | | 394 +---------+-------------------+------+-------------+---------------+ 396 Table 3: Proposed Feature Set 398 Rec'n Rule: The reconciliation rule used for the feature. SP means 399 server-priority, NN means non-negotiable. 401 Initial Value: The initial value for the feature. Every feature has 402 a known initial value. 404 Req'd: This column is "Y" if and only if every DCCP implementation 405 MUST understand the feature. If it is "N", then the feature 406 behaves like an extension (see Section 15), and it is safe to 407 respond to Change options for the feature with empty Confirm 408 options. Of course, a CCID might require the feature; a DCCP that 409 implements CCID 2 MUST support Ack Ratio and Send Ack Vector, for 410 example. 412 The DCCP protocol options as defined in ([RFC4340] section 5.8) and 413 ([RFC5634] section 2.2.1) will be enhanced by a new Multipath related 414 variable-length option with option type 46, as shown in Table 4. 416 +=========+===============+=======================+============+ 417 | Type | Option Length | Meaning | DCCP-Data? | 418 +=========+===============+=======================+============+ 419 | 0 | 1 | Padding | Y | 420 +---------+---------------+-----------------------+------------+ 421 | 1 | 1 | Mandatory | N | 422 +---------+---------------+-----------------------+------------+ 423 | 2 | 1 | Slow Receiver | Y | 424 +---------+---------------+-----------------------+------------+ 425 | 3-31 | 1 | Reserved | | 426 +---------+---------------+-----------------------+------------+ 427 | 32 | variable | Change L | N | 428 +---------+---------------+-----------------------+------------+ 429 | 33 | variable | Confirm L | N | 430 +---------+---------------+-----------------------+------------+ 431 | 34 | variable | Change R | N | 432 +---------+---------------+-----------------------+------------+ 433 | 35 | variable | Confirm R | N | 434 +---------+---------------+-----------------------+------------+ 435 | 36 | variable | Init Cookie | N | 436 +---------+---------------+-----------------------+------------+ 437 | 37 | 3-8 | NDP Count | Y | 438 +---------+---------------+-----------------------+------------+ 439 | 38 | variable | Ack Vector [Nonce 0] | N | 440 +---------+---------------+-----------------------+------------+ 441 | 39 | variable | Ack Vector [Nonce 1] | N | 442 +---------+---------------+-----------------------+------------+ 443 | 40 | variable | Data Dropped | N | 444 +---------+---------------+-----------------------+------------+ 445 | 41 | 6 | Timestamp | Y | 446 +---------+---------------+-----------------------+------------+ 447 | 42 | 6/8/10 | Timestamp Echo | Y | 448 +---------+---------------+-----------------------+------------+ 449 | 43 | 4/6 | Elapsed Time | N | 450 +---------+---------------+-----------------------+------------+ 451 | 44 | 6 | Data Checksum | Y | 452 +---------+---------------+-----------------------+------------+ 453 | 45 | 8 | Quick-Start Response | ? | 454 +---------+---------------+-----------------------+------------+ 455 | 46 | variable | Multipath | Y | 456 +---------+---------------+-----------------------+------------+ 457 | 47-127 | variable | Reserved | | 458 +---------+---------------+-----------------------+------------+ 459 | 128-255 | variable | CCID-specific options | - | 460 +---------+---------------+-----------------------+------------+ 462 Table 4: Proposed Option Set 464 [Tbd/tbv] In addition to the multipath option, MP-DCCP requires 465 particular considerations for: 467 * The minimum PMTU of the individual paths must be announced to the 468 application. Changes of individual path PMTUs must be re- 469 announced to the application if they result in a value lower than 470 the currently announced PMTU. 472 * Overall sequencing for optional reordering procedure 474 * Congestion control covering specific mechanisms as, e.g., for 475 detecting and reporting congestion occurrence on per-path level 476 and for individual adaptation of path-specific transmission rates 477 (up to zero rate) 479 3.1. Multipath Capable Feature 481 DCCP endpoints are multipath-disabled by default and multipath 482 capability can be negotiated with the Multipath Capable Feature. 484 Multipath Capable has feature number 10 and has length of one-byte. 485 The leftmost four bits are used to specify a compatible version of 486 the MP-DCCP implementation (0 for this specification). The following 487 four bits are reserved for further use. 489 0 1 2 3 4 5 6 7 490 +------------------------+ 491 | Version | Reserved | 492 +------------------------+ 493 '0000'->v0 494 '0001'->v1 495 ........ 497 Multipath Capable follows the server-priority reconciliation rule 498 described in ([RFC4340] section 6.3.1), which allows multiple 499 versions to be specified in order of priority. 501 The negotiation MUST be done as part of the initial handshake 502 procedure as described in Section 3.3, and no subsequent re- 503 negotiation of the Multipath Capable feature is allowed on the same 504 MP connection. 506 Client MUST include a Change R option during the initial handshake 507 request to supply a list of supported protocol versions, ordered by 508 preference. 510 Server MUST include a Confirm L option in the subsequent response to 511 agree on a version to be used chosen from the Client list, followed 512 by its own supported version(s) ordered by preference. 514 For example: 516 Client Server 517 ------ ------ 518 DCCP-Req + Change R(CAPABLE, 1 0) 519 -----------------------------------> 521 DCCP-Resp + Confirm L(CAPABLE, 1, 2 1 0) 522 <----------------------------------- 524 * agreement on version = 1 * 526 1. Client indicates support for both versions 1 and 0, with 527 preference for version 1 529 2. Server agrees on using version 1, and supply its own preference 530 list. 532 If no agreement can be found, the Server MUST reply with an empty 533 Confirm L option with feature number 10 and no values. 535 Any subflow addition to an existing MP connection MUST use the same 536 version negotiated for the first flow. 538 3.2. Multipath Option 540 +--------+--------+--------+--------+-------- 541 |00101110| Length | MP_OPT | Value(s) ... 542 +--------+--------+--------+--------+-------- 543 Type=46 544 +======+========+================+================================+ 545 | Type | Option | MP_OPT | Meaning | 546 | | Length | | | 547 +======+========+================+================================+ 548 | 46 | var | 0 =MP_CONFIRM | Confirm reception and | 549 | | | | processing of an MP_OPT option | 550 +------+--------+----------------+--------------------------------+ 551 | 46 | 11 | 1 =MP_JOIN | Join path to an existing MP- | 552 | | | | DCCP flow | 553 +------+--------+----------------+--------------------------------+ 554 | 46 | 3 | 2 | Close MP-DCCP flow | 555 | | | =MP_FAST_CLOSE | | 556 +------+--------+----------------+--------------------------------+ 557 | 46 | var | 3 =MP_KEY | Exchange key material for | 558 | | | | MP_HMAC | 559 +------+--------+----------------+--------------------------------+ 560 | 46 | 7 | 4 =MP_SEQ | Multipath Sequence Number | 561 +------+--------+----------------+--------------------------------+ 562 | 46 | 23 | 5 =MP_HMAC | HMA Code for authentication | 563 +------+--------+----------------+--------------------------------+ 564 | 46 | 12 | 6 =MP_RTT | Transmit RTT values | 565 +------+--------+----------------+--------------------------------+ 566 | 46 | var | 7 =MP_ADDADDR | Advertise additional Address | 567 +------+--------+----------------+--------------------------------+ 568 | 46 | var | 8 | Remove Address | 569 | | | =MP_REMOVEADDR | | 570 +------+--------+----------------+--------------------------------+ 571 | 46 | 4 | 9 =MP_PRIO | Change Subflow Priority | 572 +------+--------+----------------+--------------------------------+ 574 Table 5: MP_OPT Option Types 576 3.2.1. MP_CONFIRM 578 +--------+--------+--------+--------+--------+--------+--------+ 579 |00101110| Length |00000000| List of options ... 580 +--------+--------+--------+--------+--------+--------+--------+ 581 Type=46 MP_OPT=0 583 MP_CONFIRM is used to send confirmation of reception and processing 584 of the multipath options that require it (see Table 6). Such options 585 will be retransmitted by the sender until this receives the 586 corresponding MP_CONFIRM. The length and sending path of the 587 MP_CONFIRM are dependent on the confirmed options, which will be 588 copied verbatim and appended as list of options. 590 +======+===============+==================+=========================+ 591 | Type | Option Length | MP_OPT | MP_CONFIRM Sending path | 592 +======+===============+==================+=========================+ 593 | 46 | var | 7 =MP_ADDADDR | Any available | 594 +------+---------------+------------------+-------------------------+ 595 | 46 | var | 8 | Any available | 596 | | | =MP_REMOVEADDR | | 597 +------+---------------+------------------+-------------------------+ 598 | 46 | 4 | 9 =MP_PRIO | Any available | 599 +------+---------------+------------------+-------------------------+ 601 Table 6: Multipath options requiring confirmation 603 [Tbd] Encoding "list of options" 605 3.2.2. MP_JOIN 607 +--------+--------+--------+--------+--------+--------+--------+ 608 |00101110|00001011|00000001| Path Token | 609 +--------+--------+--------+--------+--------+--------+--------+ 610 | Nonce | 611 +--------+--------+--------+--------+ 612 Type=46 Length=11 MP_OPT=1 614 The MP_JOIN option is used to add a new path to an existing MP-DCCP 615 flow. The Path Token is the SHA256 hash of the derived key (d-key), 616 which was previously exchanged with the MP_KEY option. MP_HMAC MUST 617 be set when using MP_JOIN to provide authentication (See MP_HMAC for 618 details). Also MP_KEY MUST be set to provide key material for 619 authentication purposes. 621 3.2.3. MP_FAST_CLOSE 623 +--------+--------+--------+ 624 |00101110|00000011|00000010| 625 +--------+--------+--------+ 626 Type=46 Length=3 MP_OPT=2 628 MP_FAST_CLOSE terminates the MP-DCCP flow and all corresponding 629 subflows. 631 3.2.4. MP_KEY 632 +--------+--------+--------+-----------+-------------+ 633 |00101110| Length |00000011|Key Type(1)| Key Data(1) | -> 634 +--------+--------+--------+-----------+-------------+ 635 Type=46 MP_OPT=3 637 +-----------+-------------+----- 638 -> |Key Type(2)| Key Data(2) | .... 639 +-----------+-------------+----- 641 The MP_KEY suboption is used to exchange key material between hosts. 642 The Length varies between 12 and 68 Bytes for a single-key message, 643 and up to 110 Bytes when all specified Key Types 0-2 are provided. 644 The Key Type field is used to specify the type of the following key 645 data. Key types are shown in Table 7. 647 +========================+====================+===================+ 648 | Key Type | Key Length (Bytes) | Meaning | 649 +========================+====================+===================+ 650 | 0 =Plain Text | 8 | Plain Text Key | 651 +------------------------+--------------------+-------------------+ 652 | 1 =ECDHE-C25519-SHA256 | 32 | ECDHE with SHA256 | 653 | | | and Curve25519 | 654 +------------------------+--------------------+-------------------+ 655 | 2 =ECDHE-C25519-SHA512 | 64 | ECDHE with SHA512 | 656 | | | and Curve25519 | 657 +------------------------+--------------------+-------------------+ 658 | 3-255 | | Reserved | 659 +------------------------+--------------------+-------------------+ 661 Table 7: MP_KEY Key Types 663 Plain Text 664 Key Material is exchanged in plain text between hosts, and the key 665 parts (key-a, key-b) are used by each host to generate the derived 666 key (d-key) by concatenating the two parts with the local key in 667 front (e.g. hostA d-key(A)=(key-a+key-b), hostB d-key(B)=(key- 668 b+key-a)). 670 ECDHE-SHA256-C25519 671 Key Material is exchanged via ECDHE key exchange with SHA256 and 672 Curve 25519 to generate the derived key (d-key). 674 ECDHE-SHA512-C25519 675 Key Material is exchanged via ECDHE key exchange with SHA512 and 676 Curve 25519 to generate the derived key (d-key). 678 Providing multiple keys is only permitted in the DCCP-Request message 679 of the handshake procedure for the first flow, and allows the hosts 680 to agree on a single key type to be used as described in Section 3.3 682 3.2.5. MP_SEQ 684 +--------+--------+--------+--------+--------+--------+--------+ 685 |00101110|00000111|00000100| Multipath Sequence Number | 686 +--------+--------+--------+--------+--------+--------+--------+ 687 Type=46 Length=7 MP_OPT=4 689 The MP_SEQ option is used for end-to-end datagram-based sequence 690 numbers of an MP-DCCP connection. The initial data sequence number 691 (IDSN) SHOULD be set randomly. The MP_SEQ number space is different 692 from the path individual sequence number space. 694 3.2.6. MP_HMAC 696 +--------+--------+--------+--------+--------+--------+ 697 |00101110|00001011|00000101| HMAC-SHA256 (20 bytes) ... 698 +--------+--------+--------+--------+--------+--------+ 699 Type=46 Length=23 MP_OPT=5 701 The MP_HMAC option is used to provide authentication for the MP_JOIN 702 option. The HMAC code is generated according to [RFC2104] in 703 combination with the SHA256 hash algorithm described in [RFC6234], 704 with the output truncated to the leftmost 160 bits (20 bytes). 706 The "Key" used for the HMAC computation is the derived key (d-key) 707 described in Section 3.2.4, while the HMAC "Message" is a 708 concatenation of the token and nonce of the MP_JOIN for which 709 authentication shall be performed. 711 3.2.7. MP_RTT 713 +--------+--------+--------+--------+--------+--------+--------+ 714 |00101110|00001100|00000110|RTT Type| RTT 715 +--------+--------+--------+--------+--------+--------+--------+ 716 | | Age | 717 +--------+--------+--------+--------+--------+ 718 Type=46 Length=12 MP_OPT=6 720 The MP_RTT option is used to transmit RTT values in milliseconds and 721 MUST belong to the path over which this information is transmitted. 722 Additionally, the age of the measurement is specified in 723 milliseconds. 725 Raw RTT (=0) 726 Raw RTT value of the last Datagram Round-Trip. The Age parameter 727 is set to the age of when the Ack for the datagram was received. 729 Min RTT (=1) 730 Min RTT value. The period for computing the Minimum can be 731 specified by the Age parameter. 733 Max RTT (=2) 734 Max RTT value. The period for computing the Maximum can be 735 specified by the Age parameter. 737 Smooth RTT (=3) 738 Averaged RTT value. The period for computing the smoothed RTT can 739 be specified by the Age parameter. 741 Age (=4) 742 The Age parameter is a 4-byte value which is set to the age or 743 timestamp when the Ack for the datagram was received in case of 744 RTT type = 0 and may contain the periods for computing of derived 745 RTT values depending on other RTT types, i.e., the Minimum (=1) 746 and Maximum (=2) as well as the averaged smoothed RTT value (=3). 748 [TBD/TBV] 750 3.2.8. MP_ADDADDR 752 The MP_ADDADDR option announces additional addresses (and, 753 optionally, ports) on which a host can be reached. This option can 754 be used at any time during an existing DCCP connection, when the 755 sender wishes to enable multiple paths and/or when additional paths 756 become available. Length is variable depending on IPv4 or IPv6 and 757 whether port number is used and is in range between 28 and 42 bytes. 759 1 2 3 760 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 761 +---------------+---------------+-------+-------+---------------+ 762 | Type | Length |Subtype| IPVer | Address ID | 763 +---------------+---------------+-------+-------+---------------+ 764 | Address (IPv4 - 4 bytes / IPv6 - 16 bytes) | 765 +-------------------------------+-------------------------------+ 766 | Port (2 bytes, optional) | | 767 +-------------------------------+ | 768 | HMAC (20 bytes) | 769 | | 770 | | 771 | | 772 | | 773 | +-------------------------------+ 774 | | 775 +-------------------------------+ 777 Every address has an Address ID that can be used for uniquely 778 identifying the address within a connection for address removal. The 779 Address ID is also used to identify MP_JOIN options (see 780 Section 3.2.2) relating to the same address, even when address 781 translators are in use. The Address ID MUST uniquely identify the 782 address for the sender of the option (within the scope of the 783 connection); the mechanism for allocating such IDs is implementation 784 specific. 786 All Address IDs learned via either MP_JOIN or ADD_ADDR SHOULD be 787 stored by the receiver in a data structure that gathers all the 788 Address-ID-to-address mappings for a connection (identified by a 789 token pair). In this way, there is a stored mapping between the 790 Address ID, observed source address, and token pair for future 791 processing of control information for a connection. 793 Ideally, ADD_ADDR and REMOVE_ADDR options would be sent reliably, and 794 in order, to the other end. This would ensure that this address 795 management does not unnecessarily cause an outage in the connection 796 when remove/add addresses are processed in reverse order, and also to 797 ensure that all possible paths are used. Note, however, that losing 798 reliability and ordering will not break the multipath connections, it 799 will just reduce the opportunity to open new paths and to survive 800 different patterns of path failures. 802 Therefore, implementing reliability signals for these DCCP options is 803 not necessary. In order to minimize the impact of the loss of these 804 options, however, it is RECOMMENDED that a sender should send these 805 options on all available subflows. If these options need to be 806 received in-order, an implementation SHOULD only send one ADD_ADDR/ 807 REMOVE_ADDR option per RTT, to minimize the risk of misordering. A 808 host that receives an ADD_ADDR but finds a connection set up to that 809 IP address and port number is unsuccessful SHOULD NOT perform further 810 connection attempts to this address/port combination for this 811 connection. A sender that wants to trigger a new incoming connection 812 attempt on a previously advertised address/port combination can 813 therefore refresh ADD_ADDR information by sending the option again. 815 [TBD/TBV] 817 3.2.9. MP_REMOVEADDR 819 If, during the lifetime of an MP-DCCP connection, a previously 820 announced address becomes invalid (e.g., if the interface 821 disappears), the affected host SHOULD announce this so that the peer 822 can remove subflows related to this address. 824 This is achieved through the Remove Address (REMOVE_ADDR) option 825 which will remove a previously added address (or list of addresses) 826 from a connection and terminate any subflows currently using that 827 address. 829 For security purposes, if a host receives a REMOVE_ADDR option, it 830 must ensure the affected path(s) are no longer in use before it 831 instigates closure. Typical DCCP validity tests on the subflow 832 (e.g., packet type specific sequence and acknowledgement number 833 check) MUST also be undertaken. An implementation can use 834 indications of these test failures as part of intrusion detection or 835 error logging. 837 The sending and receipt of this message SHOULD trigger the sending of 838 DCCP-Close and DCCP-Reset by client and server, respectively on the 839 affected subflow(s) (if possible), as a courtesy to cleaning up 840 middlebox state, before cleaning up any local state. 842 Address removal is undertaken by ID, so as to permit the use of NATs 843 and other middleboxes that rewrite source addresses. If there is no 844 address at the requested ID, the receiver will silently ignore the 845 request. 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 = 3+n |Subtype|(resvd)| Address ID |... 851 +---------------+---------------+-------+-------+---------------+ 852 (followed by n-1 Address IDs, if required) 854 Minimum length of this option is 4 bytes (for one address to remove). 856 [TBD/TBV] 858 3.2.10. MP_PRIO 860 In the event that a single specific path out of the set of available 861 paths shall be treated with higher priority compared to the others, a 862 host may wish to signal such change in priority to the peer. One 863 reason for such behavior is due to the different costs involved in 864 using different paths (e.g., WiFi is free while cellular has limit on 865 volume, 5G has higher energy consumption). Also, the priority of a 866 path may be subject to dynamic changes, for example when the mobile 867 runs out of battery only a single path may be preferred. Therefore, 868 the path priority should be considered when making packet scheduling 869 decisions. 871 The MP_PRIO option, shown below, can be used to set a priority flag 872 for the path which is specified by the AddrID field that uniquely 873 identifies the path. The option can be sent over any path. 875 1 2 3 876 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 877 +---------------+---------------+-------+-------+--------------+ 878 | Type | Length |Subtype| Prio | AddrID | 879 +---------------+---------------+-------+-------+--------------+ 881 The following values are available for Prio field: 883 * 0: Do not use. The path is not available. 885 * 1: Standby: do not use this path for traffic scheduling, if 886 another path (secondary or primary) is available. 888 * 2: Secondary: do not use this path for traffic scheduling, if the 889 other paths are good enough. The path will be used occasionally, 890 e.g. when primary paths are congested or become not available.. 892 * 3: Always: can use the path in any way deemed reasonable by peer. 893 Will always be used for packet scheduling decisions. 895 * 4 - 15: relative priority of one path over the other to give 896 relative path priority for primary paths. The peer should 897 consider sending more traffic over higher priority path. 899 Example use cases include: 1) Setting Wi-Fi path to Always and 900 Cellular paths to Secondary. In this case Wi-Fi will be used and 901 Cellular only if the Wi-Fi path is congested or not available. 2) 902 Setting Wi-Fi path to Always and Cellular to Standby. In this case 903 Wi-Fi will be used and Cellular only if the Wi-Fi is not available. 905 3) Setting Wi-Fi path to Always and Cellular path to Always. In this 906 case, all packets can be scheduled over all paths leading to high 907 capacity and and high energy efficiency. 909 [TBD/TBV also consider rate limiting a given path] 911 3.3. MP-DCCP Handshaking Procedure 913 Host A Host B 914 ------------------------ ---------- 915 Address A1 Address A2 Address B1 916 ---------- ---------- ---------- 917 | | | 918 | DCCP-Request + MP_CAPABLE | 919 |------- MP_KEY(Key-A(1), Key-A(2),...) ------------->| 920 |<---------------------- MP_KEY(Key-B) ---------------| 921 | DCCP-Response + MP_CAPABLE | 922 | | | 923 | DCCP-Ack | | 924 |--------- MP_KEY(Key-A) + MP_KEY(Key-B) ------------>| 925 |<----------------------------------------------------| 926 | DCCP-Ack | | 927 | | | 928 | | DCCP-Request + MP_CAPABLE | 929 | |--- MP_JOIN(TB,RA) ------------------->| 930 | |<------MP_JOIN(TB,RB) + MP_HMAC(A)-----| 931 | |DCCP-Response + MP_CAPABLE | 932 | | | 933 | |DCCP-Ack | 934 | |-------- MP_HMAC(B) ------------------>| 935 | |<--------------------------------------| 936 | |DCCP-ACK | 938 Figure 3: Example MP-DCCP Handshake 940 The basic initial handshake for the first flow is as follows: 942 * Host A sends a DCCP-Request with the MP-Capable feature Change 943 request and the MP_KEY option with an Host-specific Key-A for each 944 of supported types as described in Section 3.2.4 946 * Host B sends a DCCP-Response with Confirm feature for MP-Capable 947 and the MP_Key option with a single Host-specific Key-B. The type 948 of the key MUST be chosen from the list of supported types from 949 the previous request 951 * Host A sends a DCCP-Ack with both Keys echoed to Host B. 953 * Host B sends a DCCP-Ack to confirm both keys and conclude the 954 handshaking. 956 Host A MUST wait the final DCCP-Ack from host B before starting any 957 establishment of additional subflow connections. 959 The handshake for subsequent flows based on a successful initial 960 handshake is as follows: 962 * Host A sends a DCCP-Request with the MP-Capable feature Change 963 request and the MP_JOIN option with Host B's Token TB, generated 964 from the derived key by applying a SHA256 hash and truncating to 965 the first 32 bits. Additionally, an own random nonce RA is 966 transmitted with the MP_JOIN. 968 * Host B computes the HMAC of the DCCP-Request and sends a DCCP- 969 Response with Confirm feature option for MP-Capable and the 970 MP_JOIN option with the Token TB and a random nonce RB together 971 with the computed MP_HMAC. The HMAC is calculated by taking the 972 leftmost 20 bytes from the SHA256 hash of a HMAC code created by 973 using token and nonce received with MP_JOIN(A) as message and the 974 derived key described in Section 3.2.4 as key: 976 MP_HMAC(A) = HMAC-SHA256(Key=d-key(B), Msg=TB+RA) 978 * Host A sends a DCCP-Ack with the HMAC computed for the DCCP- 979 Response. The HMAC is calculated by taking the leftmost 20 bytes 980 from the SHA256 hash of a HMAC code created by using token and 981 nonce received with MP_JOIN(B) as message and the derived key 982 described in Section 3.2.4 as key: 984 MP_HMAC(A) = HMAC-SHA256(Key=d-key(A), Msg=TB+RB) 986 * Host B sends a DCCP-Ack to confirm the HMAC and to conclude the 987 handshaking. 989 3.4. Fallback 991 When a subflow fails to operate within the MP-DCCP requirements, it 992 is necessary to fall back to the safe operation. This may be either 993 falling back to regular DCCP, or removing a problematic subflow. The 994 main reason for subflow failing is loss of MP-DCCP options. 996 At the start of the MP-DCCP connection, the handshake ensures 997 exchange of MP-DCCP options and thus ensures that the path is fully 998 MP-DCCP capable. If during the handshake procedure it appears that 999 DCCP-Request or DCCP-Response or DCCP-Ack messages don't have the MP- 1000 DCCP options, the MP-DCCP connection will not be established and the 1001 handshake should fall back to regular DCCP. The same fallback should 1002 take place if the endpoints fail to agree on a protocol version to 1003 use during the Multipath Capable feature negotiation. 1005 If a subflow attempts to join an existing MP-DCCP connection, but MP- 1006 DCCP options are not present in the handshake messages or the 1007 protocol version doesn't match the value negotiated for the first 1008 flow, that subflow will be closed. 1010 4. Security Considerations 1012 Similar to DCCP, MP-DCCP does not provide cryptographic security 1013 guarantees inherently. Thus, if applications need cryptographic 1014 security (integrity, authentication, confidentiality, access control, 1015 and anti-replay protection) the use of IPsec or some other kind of 1016 end-to-end security is recommended; Secure Real-time Transport 1017 Protocol (SRTP) [RFC3711] is one candidate protocol for 1018 authentication. Together with Encryption of Header Extensions in 1019 SRTP, as provided by [RFC6904], also integrity would be provided. 1021 As described in [RFC4340], DCCP provides protection against hijacking 1022 and limits the potential impact of some denial-of-service attacks, 1023 but DCCP provides no inherent protection against attackers' snooping 1024 on data packets. Regarding the security of MP-DCCP no additional 1025 risks should be introduced compared to regular DCCP of today. 1026 Thereof derived are the following key security requirements to be 1027 fulfilled by MP-DCCP: 1029 * Provide a mechanism to confirm that parties involved in a subflow 1030 handshake are identical to those in the original connection setup. 1032 * Provide verification that the new address to be included in a MP 1033 connection is valid for a peer to receive traffic at before using 1034 it. 1036 * Provide replay protection, i.e., ensure that a request to add/ 1037 remove a subflow is 'fresh'. 1039 In order to achieve these goals, MP-DCCP includes a hash-based 1040 handshake algorithm documented in Sections Section 3.2.4 and 1041 Section 3.3. The security of the MP-DCCP connection depends on the 1042 use of keys that are shared once at the start of the first subflow 1043 and are never sent again over the network. To ease demultiplexing 1044 while not giving away any cryptographic material, future subflows use 1045 a truncated cryptographic hash of this key as the connection 1046 identification "token". The keys are concatenated and used as keys 1047 for creating Hash-based Message Authentication Codes (HMACs) used on 1048 subflow setup, in order to verify that the parties in the handshake 1049 are the same as in the original connection setup. It also provides 1050 verification that the peer can receive traffic at this new address. 1051 Replay attacks would still be possible when only keys are used; 1052 therefore, the handshakes use single-use random numbers (nonces) at 1053 both ends -- this ensures that the HMAC will never be the same on two 1054 handshakes. Guidance on generating random numbers suitable for use 1055 as keys is given in [RFC4086]. During normal operation, regular DCCP 1056 protection mechanisms (such as header checksum to protect DCCP 1057 headers against corruption) will provide the same level of protection 1058 against attacks on individual DCCP subflows as exists for regular 1059 DCCP today. 1061 5. Interactions with Middleboxes 1063 Issues from interaction with on-path middleboxes such as NATs, 1064 firewalls, proxies, intrusion detection systems (IDSs), and others 1065 have to be considered for all extensions to standard protocols since 1066 otherwise unexpected reactions of middleboxes may hinder its 1067 deployment. DCCP already provides means to mitigate the potential 1068 impact of middleboxes, also in comparison to TCP (see [RFC4043], 1069 sect. 16). In case, however, both hosts are located behind a NAT or 1070 firewall entity, specific measures have to be applied such as the 1071 [RFC5596]-specified simultaneous-open technique that update the 1072 (traditionally asymmetric) connection-establishment procedures for 1073 DCCP. Further standardized technologies addressing NAT type 1074 middleboxes are covered by [RFC5597]. 1076 [RFC6773] specifies UDP Encapsulation for NAT Traversal of DCCP 1077 sessions, similar to other UDP encapsulations such as for SCTP 1078 [RFC6951]. The alternative U-DCCP approach proposed in 1079 [I-D.amend-tsvwg-dccp-udp-header-conversion] would reduce tunneling 1080 overhead. The handshaking procedure for DCCP-UDP header conversion 1081 or use of a DCCP-UDP negotiation procedure to signal support for 1082 DCCP-UDP header conversion would require encapsulation during the 1083 handshakes and use of two additional port numbers out of the UDP port 1084 number space, but would require zero overhead afterwards. 1086 6. Implementation 1088 The approach described above has been implemented in open source 1089 across different testbeds and a new scheduling algorithm has been 1090 extensively tested. Also demonstrations of a laboratory setup have 1091 been executed and have been published at [website]. 1093 7. Acknowledgments 1095 1. Notes 1096 This document is inspired by Multipath TCP [RFC6824]/[RFC8684] and 1097 some text passages for the -00 version of the draft are copied almost 1098 unmodified. 1100 8. IANA Considerations 1102 This document defines one new value to DCCP feature list and one new 1103 DCCP Option with ten corresponding Subtypes as follows. This 1104 document defines a new DCCP feature parameter for negotiating the 1105 support of multipath capability for DCCP sessions between hosts as 1106 described in Section 3. The following entry in Table 8 should be 1107 added to the "Feature Numbers Registry" according to [RFC4340], 1108 Section 19.4. under the "DCCP Protocol" heading. 1110 +=======+============================+===============+ 1111 | Value | Feature Name | Specification | 1112 +=======+============================+===============+ 1113 | 0x10 | MP-DCCP capability feature | Section 3.1 | 1114 +-------+----------------------------+---------------+ 1116 Table 8: Addition to DCCP Feature list Entries 1118 This document defines a new DCCP protocol option of type=46 as 1119 described in Section 3.2 together with 10 additional sub-options. 1120 The following entries in Table 9 should be added to the "DCCP 1121 Protocol options" and assigned as "MP-DCCP sub-options", 1122 respectively. 1124 +==========+===============+=====================+===========+ 1125 | Value | Symbol | Name | Reference | 1126 +==========+===============+=====================+===========+ 1127 | TBD or | MP_OPT | DCCP Multipath | Section | 1128 | Type=46 | | option | 3.2 | 1129 +----------+---------------+---------------------+-----------+ 1130 | TBD or | MP_CONFIRM | Confirm reception/ | Section | 1131 | MP_OPT=0 | | processing of an | 3.2.1 | 1132 | | | MP_OPT option | | 1133 +----------+---------------+---------------------+-----------+ 1134 | TBD or | MP_JOIN | Join path to | Section | 1135 | MP_OPT=1 | | existing MP-DCCP | 3.2.2 | 1136 | | | flow | | 1137 +----------+---------------+---------------------+-----------+ 1138 | TBD or | MP_FAST_CLOSE | Close MP-DCCP flow | Section | 1139 | MP_OPT=2 | | | 3.2.3 | 1140 +----------+---------------+---------------------+-----------+ 1141 | TBD or | MP_KEY | Exchange key | Section | 1142 | MP_OPT=3 | | material for | 3.2.4 | 1143 | | | MP_HMAC | | 1144 +----------+---------------+---------------------+-----------+ 1145 | TBD or | MP_SEQ | Multipath Sequence | Section | 1146 | MP_OPT=4 | | Number | 3.2.5 | 1147 +----------+---------------+---------------------+-----------+ 1148 | TBD or | MP_HMAC | Hash-based Message | Section | 1149 | MP_OPT=5 | | Auth. Code for MP- | 3.2.6 | 1150 | | | DCCP | | 1151 +----------+---------------+---------------------+-----------+ 1152 | TBD or | MP_RTT | Transmit RTT values | Section | 1153 | MP_OPT=6 | | and calculation | 3.2.7 | 1154 | | | parameters | | 1155 +----------+---------------+---------------------+-----------+ 1156 | TBD or | MP_ADDADDR | Advertise | Section | 1157 | MP_OPT=7 | | additional | 3.2.8 | 1158 | | | Address(es)/Port(s) | | 1159 +----------+---------------+---------------------+-----------+ 1160 | TBD or | MP_REMOVEADDR | Remove Address(es)/ | Section | 1161 | MP_OPT=8 | | Port(s) | 3.2.9 | 1162 +----------+---------------+---------------------+-----------+ 1163 | TBD or | MP_PRIO | Change Subflow | Section | 1164 | MP_OPT=9 | | Priority | 3.2.10 | 1165 +----------+---------------+---------------------+-----------+ 1167 Table 9: Addition to DCCP Protocol options and 1168 corresponding sub-options 1170 [Tbd], must include options for: 1172 * handshaking procedure to indicate MP support 1174 * handshaking procedure to indicate JOINING of an existing MP 1175 connection 1177 * signaling of new or changed addresses 1179 * setting handover or aggregation mode 1181 * setting reordering on/off 1183 * MP-specific congestion mechanisms 1185 should include options carrying: 1187 * overall sequence number for restoring/re-assembly/re-ordering 1188 purposes 1190 * sender time measurements for restoring/re-assembly/re-ordering 1191 purposes 1193 * scheduler preferences 1195 * reordering preferences 1197 9. Informative References 1199 [I-D.amend-tsvwg-dccp-udp-header-conversion] 1200 Amend, M., Brunstrom, A., Kassler, A., and V. Rakocevic, 1201 "Lossless and overhead free DCCP - UDP header conversion 1202 (U-DCCP)", Work in Progress, Internet-Draft, draft-amend- 1203 tsvwg-dccp-udp-header-conversion-01, 8 July 2019, 1204 . 1207 [I-D.amend-tsvwg-multipath-framework-mpdccp] 1208 Amend, M., Bogenfeld, E., Brunstrom, A., Kassler, A., and 1209 V. Rakocevic, "A multipath framework for UDP traffic over 1210 heterogeneous access networks", Work in Progress, 1211 Internet-Draft, draft-amend-tsvwg-multipath-framework- 1212 mpdccp-01, 8 July 2019, . 1215 [I-D.lhwxz-hybrid-access-network-architecture] 1216 Leymann, N., Heidemann, C., Wesserman, M., Xue, L., and M. 1217 Zhang, "Hybrid Access Network Architecture", Work in 1218 Progress, Internet-Draft, draft-lhwxz-hybrid-access- 1219 network-architecture-02, 13 January 2015, 1220 . 1223 [I-D.muley-network-based-bonding-hybrid-access] 1224 Muley, P., Henderickx, W., Liang, G., Liu, H., Cardullo, 1225 L., Newton, J., Seo, S., Draznin, S., and B. Patil, 1226 "Network based Bonding solution for Hybrid Access", Work 1227 in Progress, Internet-Draft, draft-muley-network-based- 1228 bonding-hybrid-access-03, 22 October 2018, 1229 . 1232 [paper] Amend, M., Bogenfeld, E., Cvjetkovic, M., Rakocevic, V., 1233 Pieska, M., Kassler, A., and A. Brunstrom, "A Framework 1234 for Multiaccess Support for Unreliable Internet Traffic 1235 using Multipath DCCP", DOI 10.1109/LCN44214.2019.8990746, 1236 October 2019, 1237 . 1239 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1240 RFC 793, DOI 10.17487/RFC0793, September 1981, 1241 . 1243 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1244 Hashing for Message Authentication", RFC 2104, 1245 DOI 10.17487/RFC2104, February 1997, 1246 . 1248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1249 Requirement Levels", BCP 14, RFC 2119, 1250 DOI 10.17487/RFC2119, March 1997, 1251 . 1253 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 1254 RFC 3124, DOI 10.17487/RFC3124, June 2001, 1255 . 1257 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1258 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1259 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1260 . 1262 [RFC4043] Pinkas, D. and T. Gindin, "Internet X.509 Public Key 1263 Infrastructure Permanent Identifier", RFC 4043, 1264 DOI 10.17487/RFC4043, May 2005, 1265 . 1267 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1268 "Randomness Requirements for Security", BCP 106, RFC 4086, 1269 DOI 10.17487/RFC4086, June 2005, 1270 . 1272 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1273 Congestion Control Protocol (DCCP)", RFC 4340, 1274 DOI 10.17487/RFC4340, March 2006, 1275 . 1277 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 1278 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 1279 September 2009, . 1281 [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol 1282 (DCCP) Simultaneous-Open Technique to Facilitate NAT/ 1283 Middlebox Traversal", RFC 5596, DOI 10.17487/RFC5596, 1284 September 2009, . 1286 [RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) 1287 Behavioral Requirements for the Datagram Congestion 1288 Control Protocol", BCP 150, RFC 5597, 1289 DOI 10.17487/RFC5597, September 2009, 1290 . 1292 [RFC5634] Fairhurst, G. and A. Sathiaseelan, "Quick-Start for the 1293 Datagram Congestion Control Protocol (DCCP)", RFC 5634, 1294 DOI 10.17487/RFC5634, August 2009, 1295 . 1297 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1298 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1299 DOI 10.17487/RFC6234, May 2011, 1300 . 1302 [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A 1303 Datagram Congestion Control Protocol UDP Encapsulation for 1304 NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 1305 2012, . 1307 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1308 "TCP Extensions for Multipath Operation with Multiple 1309 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1310 . 1312 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 1313 Real-time Transport Protocol (SRTP)", RFC 6904, 1314 DOI 10.17487/RFC6904, April 2013, 1315 . 1317 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 1318 Control Transmission Protocol (SCTP) Packets for End-Host 1319 to End-Host Communication", RFC 6951, 1320 DOI 10.17487/RFC6951, May 2013, 1321 . 1323 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 1324 Paasch, "TCP Extensions for Multipath Operation with 1325 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 1326 2020, . 1328 [slide] Amend, M., "MP-DCCP for enabling transfer of UDP/IP 1329 traffic over multiple data paths in multi-connectivity 1330 networks", IETF105 , n.d., 1331 . 1335 [TS23.501] 3GPP, "System architecture for the 5G System; Stage 2; 1336 Release 16", December 2020, 1337 . 1340 [website] "Multipath extension for DCCP", n.d., 1341 . 1343 Authors' Addresses 1345 Markus Amend (editor) 1346 Deutsche Telekom 1347 Deutsche-Telekom-Allee 9 1348 64295 Darmstadt 1349 Germany 1351 Email: Markus.Amend@telekom.de 1352 Anna Brunstrom 1353 Karlstad University 1354 Universitetsgatan 2 1355 SE-651 88 Karlstad 1356 Sweden 1358 Email: anna.brunstrom@kau.se 1360 Andreas Kassler 1361 Karlstad University 1362 Universitetsgatan 2 1363 SE-651 88 Karlstad 1364 Sweden 1366 Email: andreas.kassler@kau.se 1368 Veselin Rakocevic 1369 City University of London 1370 Northampton Square 1371 London 1372 United Kingdom 1374 Email: veselin.rakocevic.1@city.ac.uk 1376 Stephen Johnson 1377 BT 1378 Adastral Park 1379 Martlesham Heath 1380 IP5 3RE 1381 United Kingdom 1383 Email: stephen.h.johnson@bt.com