idnits 2.17.1 draft-ietf-tsvwg-multipath-dccp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (31 August 2021) is 969 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Nonce 0' is mentioned on line 418, but not defined == Missing Reference: 'Nonce 1' is mentioned on line 420, but not defined == Missing Reference: 'Tbd' is mentioned on line 994, but not defined == Unused Reference: 'I-D.muley-network-based-bonding-hybrid-access' is defined on line 1043, but no explicit reference was found in the text == Unused Reference: 'RFC5596' is defined on line 1096, but no explicit reference was found in the text == Unused Reference: 'RFC6824' is defined on line 1117, 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 D. Hugo 4 Intended status: Experimental DT 5 Expires: 4 March 2022 A. Brunstrom 6 A. Kassler 7 Karlstad University 8 V. Rakocevic 9 City University of London 10 S. Johnson 11 BT 12 31 August 2021 14 DCCP Extensions for Multipath Operation with Multiple Addresses 15 draft-ietf-tsvwg-multipath-dccp-00 17 Abstract 19 DCCP communication is currently restricted to a single path per 20 connection, yet multiple paths often exist between peers. The 21 simultaneous use of these multiple paths for a DCCP session could 22 improve resource usage within the network and, thus, improve user 23 experience through higher throughput and improved resilience to 24 network failures. Use cases for a Multipath DCCP (MP-DCCP) are 25 mobile devices (handsets, vehicles) and residential home gateways 26 simultaneously connected to distinct paths as, e.g., a cellular link 27 and a WiFi link or to a mobile radio station and a fixed access 28 network. Compared to existing multipath protocols such as MPTCP, MP- 29 DCCP provides specific support for non-TCP user traffic as UDP or 30 plain IP. More details on potential use cases are provided in 31 [website], [slide] and [paper]. All this use cases profit from an 32 Open Source Linux reference implementation provided under [website]. 34 This document presents a set of extensions to traditional DCCP to 35 support multipath operation. Multipath DCCP provides the ability to 36 simultaneously use multiple paths between peers. The protocol offers 37 the same type of service to applications as DCCP and it provides the 38 components necessary to establish and use multiple DCCP flows across 39 potentially disjoint paths. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on 4 March 2022. 58 Copyright Notice 60 Copyright (c) 2021 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Simplified BSD License text 69 as described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Multipath DCCP in the Networking Stack . . . . . . . . . 4 76 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.3. MP-DCCP Concept . . . . . . . . . . . . . . . . . . . . . 5 78 1.4. Differences from Multipath TCP . . . . . . . . . . . . . 5 79 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 9 80 2. Operation Overview . . . . . . . . . . . . . . . . . . . . . 9 81 3. MP-DCCP Protocol . . . . . . . . . . . . . . . . . . . . . . 9 82 3.1. Multipath Capable Feature . . . . . . . . . . . . . . . . 12 83 3.2. Multipath Option . . . . . . . . . . . . . . . . . . . . 12 84 3.2.1. MP_CONFIRM . . . . . . . . . . . . . . . . . . . . . 13 85 3.2.2. MP_JOIN . . . . . . . . . . . . . . . . . . . . . . . 13 86 3.2.3. MP_FAST_CLOSE . . . . . . . . . . . . . . . . . . . . 14 87 3.2.4. MP_KEY . . . . . . . . . . . . . . . . . . . . . . . 14 88 3.2.5. MP_SEQ . . . . . . . . . . . . . . . . . . . . . . . 15 89 3.2.6. MP_HMAC . . . . . . . . . . . . . . . . . . . . . . . 15 90 3.2.7. MP_RTT . . . . . . . . . . . . . . . . . . . . . . . 16 91 3.2.8. MP_ADDADDR . . . . . . . . . . . . . . . . . . . . . 17 92 3.2.9. MP_REMOVEADDR . . . . . . . . . . . . . . . . . . . . 18 93 3.2.10. MP_PRIO . . . . . . . . . . . . . . . . . . . . . . . 19 95 3.3. MP-DCCP Handshaking Procedure . . . . . . . . . . . . . . 19 96 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 97 5. Interactions with Middleboxes . . . . . . . . . . . . . . . . 22 98 6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 22 99 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 101 9. Informative References . . . . . . . . . . . . . . . . . . . 25 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 104 1. Introduction 106 Multipath DCCP (MP-DCCP) is a set of extensions to regular DCCP 107 [RFC4340], i.e. the Datagram Congestion Control Protocol denoting a 108 transport protocol that provides bidirectional unicast connections of 109 congestion-controlled unreliable datagrams. A multipath extension to 110 DCCP enables the transport of user data across multiple paths 111 simultaneously. This is beneficial to applications that transfer 112 fairly large amounts of data, due to the possibility to aggregate 113 capacity of the multiple paths. In addition, it enables to tradeoff 114 timeliness and reliability, which is important for low latency 115 applications that do not require guaranteed delivery services such as 116 Audio/Video streaming. DCCP multipath operation is suggested in the 117 context of ongoing 3GPP work on 5G multi-access solutions 118 [I-D.amend-tsvwg-multipath-framework-mpdccp] and for hybrid access 119 networks [I-D.lhwxz-hybrid-access-network-architecture][I-D.muley-net 120 work-based-bonding-hybrid-access]. It can be applied for load- 121 balancing, seamless session handover, and aggregation purposes 122 (referred to as ATSSS; Access steering, switching, and splitting in 123 3GPP terminology [TS23.501]). 125 This document presents the protocol changes required to add multipath 126 capability to DCCP; specifically, those for signaling and setting up 127 multiple paths ("subflows"), managing these subflows, re-assembly of 128 data, and termination of sessions. DCCP, as stated in [RFC4340] does 129 not provide reliable and ordered delivery. Consequently, multiple 130 application subflows may be multiplexed over a single DCCP connection 131 with no inherent performance penalty for flows that do not require 132 in-ordered delivery. DCCP does not provide built-in support for 133 those multiple application subflows. 135 In the following, use of the term subflow will refer to physical 136 separate DCCP subflows transmitted via different paths, but not to 137 application subflows. Application subflows are differing content- 138 wise by source and destination port per application as, for example, 139 enabled by Service Codes introduced to DCCP in [RFC5595], and those 140 subflows can be multiplexed over a single DCCP connection. For sake 141 of consistency we assume that only a single application is served by 142 a DCCP connection here as shown in Figure 1 while use of that feature 143 should not impact DCCP operation on each single path as noted in 144 ([RFC5595], sect. 2.4). 146 1.1. Multipath DCCP in the Networking Stack 148 MP-DCCP operates at the transport layer and aims to be transparent to 149 both higher and lower layers. It is a set of additional features on 150 top of standard DCCP; Figure 1 illustrates this layering. MP-DCCP is 151 designed to be used by applications in the same way as DCCP with no 152 changes to the application itself. 154 +-------------------------------+ 155 | Application | 156 +---------------+ +-------------------------------+ 157 | Application | | MP-DCCP | 158 +---------------+ + - - - - - - - + - - - - - - - + 159 | DCCP | |Subflow (DCCP) |Subflow (DCCP) | 160 +---------------+ +-------------------------------+ 161 | IP | | IP | IP | 162 +---------------+ +-------------------------------+ 164 Figure 1: Comparison of Standard DCCP and MP-DCCP Protocol Stacks 166 1.2. Terminology 168 Throughout this document we make use of terms that are either 169 specific for multipath transport or are defined in the context of MP- 170 DCCP, similar to [RFC8684], as follows: 172 Path: A sequence of links between a sender and a receiver, defined in 173 this context by a 4-tuple of source and destination address/ port 174 pairs. 176 Subflow: A flow of DCCP segments operating over an individual path, 177 which forms part of a larger MP-DCCP connection. A subflow is 178 started and terminated similar to a regular (single-path) DCCP 179 connection. 181 (MP-DCCP) Connection: A set of one or more subflows, over which an 182 application can communicate between two hosts. There is a one-to-one 183 mapping between a connection and an application socket. 185 Token: A locally unique identifier given to a multipath connection by 186 a host. May also be referred to as a "Connection ID". 188 Host: An end host operating an MP-DCCP implementation, and either 189 initiating or accepting an MP-DCCP connection. In addition to these 190 terms, within framework of MP-DCCP the interpretation of, and effect 191 on, regular single-path DCCP semantics is discussed in Section 3. 193 1.3. MP-DCCP Concept 195 Host A Host B 196 ------------------------ ------------------------ 197 Address A1 Address A2 Address B1 Address B2 198 ---------- ---------- ---------- ---------- 199 | | | | 200 | (DCCP flow setup) | | 201 |----------------------------------->| | 202 |<-----------------------------------| | 203 | | | | 204 | | (DCCP flow setup) | | 205 | |--------------------->| | 206 | |<---------------------| | 207 | merge individual DCCP flows to one multipath connection 208 | | | | 210 Figure 2: Example MP-DCCP Usage Scenario 212 1.4. Differences from Multipath TCP 214 Multipath DCCP is similar to Multipath TCP [RFC8684], in that it 215 extends the related basic DCCP transport protocol [RFC4340] with 216 multipath capabilities in the same way as Multipath TCP extends TCP 217 [RFC0793]. However, because of the differences between the 218 underlying TCP and DCCP protocols, the transport characteristics of 219 MPTCP and MP-DCCP are different. 221 Table 1 compares the protocol characteristics of TCP and DCCP, which 222 are by nature inherited by their respective multipath extensions. A 223 major difference lies in the delivery of payload, which is for TCP an 224 exact copy of the generated byte-stream. DCCP behaves in a different 225 way and does not guarantee to deliver any payload nor the order of 226 delivery. Since this is mainly affecting the receiving endpoint of a 227 TCP or DCCP communication, many similarities on the sender side can 228 be identified. Both transport protocols share the 3-way initiation 229 of a communication and both employ congestion control to adapt the 230 sending rate to the path characteristics. 232 +=======================+=================+======================+ 233 | Feature | TCP | DCCP | 234 +=======================+=================+======================+ 235 | Full-Duplex | yes | yes | 236 +-----------------------+-----------------+----------------------+ 237 | Connection-Oriented | yes | yes | 238 +-----------------------+-----------------+----------------------+ 239 | Header option space | 40 bytes | < 1008 bytes or PMTU | 240 +-----------------------+-----------------+----------------------+ 241 | Data transfer | reliable | unreliable | 242 +-----------------------+-----------------+----------------------+ 243 | Packet-loss handling | re-transmission | report only | 244 +-----------------------+-----------------+----------------------+ 245 | Ordered data delivery | yes | no | 246 +-----------------------+-----------------+----------------------+ 247 | Sequence numbers | one per byte | one per PDU | 248 +-----------------------+-----------------+----------------------+ 249 | Flow control | yes | no | 250 +-----------------------+-----------------+----------------------+ 251 | Congestion control | yes | yes | 252 +-----------------------+-----------------+----------------------+ 253 | ECN support | yes | yes | 254 +-----------------------+-----------------+----------------------+ 255 | Selective ACK | yes | depends on | 256 | | | congestion control | 257 +-----------------------+-----------------+----------------------+ 258 | Fix message | no | yes | 259 | boundaries | | | 260 +-----------------------+-----------------+----------------------+ 261 | Path MTU discovery | yes | yes | 262 +-----------------------+-----------------+----------------------+ 263 | Fragmentation | yes | no | 264 +-----------------------+-----------------+----------------------+ 265 | SYN flood protection | yes | no | 266 +-----------------------+-----------------+----------------------+ 267 | Half-open connections | yes | no | 268 +-----------------------+-----------------+----------------------+ 270 Table 1: TCP and DCCP protocol comparison 272 Consequently, the multipath features, shown in Table 2, are the same, 273 supporting volatile paths having varying capacity and latency, 274 session handover and path aggregation capabilities. All of them 275 profit by the existence of congestion control. 277 +==============================+============+====================+ 278 | Feature | MPTCP | MP-DCCP | 279 +==============================+============+====================+ 280 | Volatile paths | yes | yes | 281 +------------------------------+------------+--------------------+ 282 | Session handover | yes | yes | 283 +------------------------------+------------+--------------------+ 284 | Path aggregation | yes | yes | 285 +------------------------------+------------+--------------------+ 286 | Robust session establishment | no | yes | 287 +------------------------------+------------+--------------------+ 288 | Data re-assembly | yes | optional / modular | 289 +------------------------------+------------+--------------------+ 290 | Expandability | limited by | flexible | 291 | | TCP header | | 292 +------------------------------+------------+--------------------+ 294 Table 2: MPTCP and MP-DCCP protocol comparison 296 Therefore, the sender logic is not much different between MP-DCCP and 297 MPTCP, even if the multipath session initiation differs. MP-DCCP 298 inherits a robust session establishment feature, which guarantees 299 communication establishment if at least one functional path is 300 available. MPTCP relies on an initial path, which has to work; 301 otherwise no communication can be established. 303 The receiver side for MP-DCCP has to deal with the unreliable 304 transport character of DCCP and a possible re-assembly of the data 305 stream while not advocating it. As many unreliable applications have 306 built-in application support for reordering (such as adaptive audio 307 and video buffers), those applications might not need support for re- 308 assembly. However, for applications that benefit from partial or 309 full support of reordering, MP-DCCP can provide flexible support for 310 re-assembly, even if for DCCP the order of delivery is unreliable by 311 nature. Such optional re-assembly mechanisms may account for the 312 fact that packet loss may occur for any of the DCCP subflows. 313 Another issue may occur as packet reordering may happen when the 314 different DCCP subflows are routed across paths with different 315 latencies. In theory, applications using DCCP are aware that packet 316 reordering might happen, since DCCP has no mechanisms to prevent it. 318 The receiving process for MPTCP is on the other hand a rigid "just 319 wait" approach, since TCP guarantees reliable delivery. 321 1.5. Requirements Language 323 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 324 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 325 document are to be interpreted as described in [RFC2119]. 327 2. Operation Overview 329 RFC 4340 states that some applications might want to share congestion 330 control state among multiple DCCP flows between same source and 331 destination addresses. This functionality could be provided by the 332 Congestion Manager (CM) [RFC3124], a generic multiplexing facility. 333 However, the CM would not fully support MP-DCCP without change; it 334 does not gracefully handle multiple congestion control mechanisms, 335 for example. 337 The operation of MP-DCCP for data transfer takes one input data 338 stream from an application, and splits it into one or more subflows, 339 with sufficient control information to allow received data to be re- 340 assembled and delivered in order to the recipient application. The 341 following subsections define this behavior in detail. 343 The Multipath Capability for MP-DCCP can be negotiated with a new 344 DCCP feature, as described in Section 3. Once negotiated, all 345 subsequent MP-DCCP operations are signalled with a variable length 346 multipath-related option, as described in Section 3.1. 348 3. MP-DCCP Protocol 350 The DCCP protocol feature list ([RFC4340] section 6.4) will be 351 enhanced by a new Multipath related feature with Feature number 10, 352 as shown in Table 3. 354 +=========+===================+======+=============+===============+ 355 | Number | Meaning | Rule | Rec'n Value | Initial Req'd | 356 +=========+===================+======+=============+===============+ 357 | 0 | Reserved | | | | 358 +---------+-------------------+------+-------------+---------------+ 359 | 1 | Congestion | SP | 2 | Y | 360 | | Control ID (CCID) | | | | 361 +---------+-------------------+------+-------------+---------------+ 362 | 2 | Allow Short | SP | 0 | Y | 363 | | Seqnos | | | | 364 +---------+-------------------+------+-------------+---------------+ 365 | 3 | Sequence Window | NN | 100 | Y | 366 +---------+-------------------+------+-------------+---------------+ 367 | 4 | ECN Incapable | SP | 0 | N | 368 +---------+-------------------+------+-------------+---------------+ 369 | 5 | Ack Ratio | NN | 2 | N | 370 +---------+-------------------+------+-------------+---------------+ 371 | 6 | Send Ack Vector | SP | 0 | N | 372 +---------+-------------------+------+-------------+---------------+ 373 | 7 | Send NDP Count | SP | 0 | N | 374 +---------+-------------------+------+-------------+---------------+ 375 | 8 | Minimum Checksum | SP | 0 | N | 376 | | Coverage | | | | 377 +---------+-------------------+------+-------------+---------------+ 378 | 9 | Check Data | SP | 0 | N | 379 | | Checksum | | | | 380 +---------+-------------------+------+-------------+---------------+ 381 | 10 | Multipath Capable | SP | 0 | N | 382 +---------+-------------------+------+-------------+---------------+ 383 | 11-127 | Reserved | | | | 384 +---------+-------------------+------+-------------+---------------+ 385 | 128-255 | CCID-specific | | | | 386 | | features | | | | 387 +---------+-------------------+------+-------------+---------------+ 389 Table 3: Proposed Feature Set 391 The DCCP protocol options as defined in ([RFC4340] section 5.8) and 392 ([RFC5634] section 2.2.1) will be enhanced by a new Multipath related 393 variable-length option with option type 46, as shown in Table 4. 395 +=========+===============+=======================+============+ 396 | Type | Option Length | Meaning | DCCP-Data? | 397 +=========+===============+=======================+============+ 398 | 0 | 1 | Padding | Y | 399 +---------+---------------+-----------------------+------------+ 400 | 1 | 1 | Mandatory | N | 401 +---------+---------------+-----------------------+------------+ 402 | 2 | 1 | Slow Receiver | Y | 403 +---------+---------------+-----------------------+------------+ 404 | 3-31 | 1 | Reserved | | 405 +---------+---------------+-----------------------+------------+ 406 | 32 | variable | Change L | N | 407 +---------+---------------+-----------------------+------------+ 408 | 33 | variable | Confirm L | N | 409 +---------+---------------+-----------------------+------------+ 410 | 34 | variable | Change R | N | 411 +---------+---------------+-----------------------+------------+ 412 | 35 | variable | Confirm R | N | 413 +---------+---------------+-----------------------+------------+ 414 | 36 | variable | Init Cookie | N | 415 +---------+---------------+-----------------------+------------+ 416 | 37 | 3-8 | NDP Count | Y | 417 +---------+---------------+-----------------------+------------+ 418 | 38 | variable | Ack Vector [Nonce 0] | N | 419 +---------+---------------+-----------------------+------------+ 420 | 39 | variable | Ack Vector [Nonce 1] | N | 421 +---------+---------------+-----------------------+------------+ 422 | 40 | variable | Data Dropped | N | 423 +---------+---------------+-----------------------+------------+ 424 | 41 | 6 | Timestamp | Y | 425 +---------+---------------+-----------------------+------------+ 426 | 42 | 6/8/10 | Timestamp Echo | Y | 427 +---------+---------------+-----------------------+------------+ 428 | 43 | 4/6 | Elapsed Time | N | 429 +---------+---------------+-----------------------+------------+ 430 | 44 | 6 | Data Checksum | Y | 431 +---------+---------------+-----------------------+------------+ 432 | 45 | 8 | Quick-Start Response | ? | 433 +---------+---------------+-----------------------+------------+ 434 | 46 | variable | Multipath | Y | 435 +---------+---------------+-----------------------+------------+ 436 | 47-127 | variable | Reserved | | 437 +---------+---------------+-----------------------+------------+ 438 | 128-255 | variable | CCID-specific options | - | 439 +---------+---------------+-----------------------+------------+ 441 Table 4: Proposed Option Set 443 [Tbd/tbv] In addition to the multipath option, MP-DCCP requires 444 particular considerations for: 446 * The minimum PMTU of the individual paths must be announced to the 447 application. Changes of individual path PMTUs must be re- 448 announced to the application if they result in a value lower than 449 the currently announced PMTU. 451 * Overall sequencing for optional re-assembly procedure 453 * Congestion control 455 * Robust MP-DCCP session establishment (no dependency on an initial 456 path setup) 458 3.1. Multipath Capable Feature 460 DCCP endpoints are multipath-disabled by default and multipath 461 capability can be negotiated with the Multipath Capable Feature. 463 Multipath Capable has feature number 10 and is server-priority. It 464 takes one-byte values. The first four bits are used to specify 465 compatible versions of the MP-DCCP implementation. The following 466 four bits are reserved for further use. 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 | 11 | 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 | | 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 +------+--------+----------------+--------------------------------+ 504 Table 5: MP_OPT Option Types 506 3.2.1. MP_CONFIRM 508 +--------+--------+--------+--------+--------+--------+--------+ 509 |00101110| Length |00000000| List of options ... 510 +--------+--------+--------+--------+--------+--------+--------+ 511 Type=46 MP_OPT=0 513 MP_CONFIRM can be used to send confirmation of received and processed 514 options. Confirmed options are copied verbatim and appended as List 515 of options. The length varies dependent on the amount of options. 517 [Tbd] Encoding "list of options" 519 3.2.2. MP_JOIN 520 +--------+--------+--------+--------+--------+--------+--------+ 521 |00101110|00001011|00000001| Path Token | 522 +--------+--------+--------+--------+--------+--------+--------+ 523 | Nonce | 524 +--------+--------+--------+--------+ 525 Type=46 Length=11 MP_OPT=1 527 The MP_JOIN option is used to add a new path to an existing MP-DCCP 528 flow. The Path Token is the SHA-1 HASH of the derived key (d-key), 529 which was previously exchanged with the MP_KEY option. MP_HMAC MUST 530 be set when using MP_JOIN to provide authentication (See MP_HMAC for 531 details). Also MP_KEY MUST be set to provide key material for 532 authentication purposes. 534 3.2.3. MP_FAST_CLOSE 536 +--------+--------+--------+ 537 |00101110|00000011|00000010| 538 +--------+--------+--------+ 539 Type=46 Length=3 MP_OPT=2 541 MP_FAST_CLOSE terminates the MP-DCCP flow and all corresponding 542 subflows. 544 3.2.4. MP_KEY 546 +--------+--------+--------+--------+--------+--------+--------+ 547 |00101110| Length |00000011|Key Type| Key Data ... 548 +--------+--------+--------+--------+--------+--------+--------+ 549 Type=46 MP_OPT=3 551 The MP_KEY suboption is used to exchange key material between hosts. 552 The Length varies between 5 and 8 Bytes. The Key Type field is used 553 to specify the key type. Key types are shown in Table 6. 555 +========================+============+===================+ 556 | Key Type | Key Length | Meaning | 557 +========================+============+===================+ 558 | 0 =Plain Text | 8 | Plain Text Key | 559 +------------------------+------------+-------------------+ 560 | 1 =ECDHE-C25519-SHA256 | 32 | ECDHE with SHA256 | 561 | | | and Curve25519 | 562 +------------------------+------------+-------------------+ 563 | 2 =ECDHE-C25519-SHA512 | 32 | ECDHE with SHA512 | 564 | | | and Curve25519 | 565 +------------------------+------------+-------------------+ 566 | 3-255 | | Reserved | 567 +------------------------+------------+-------------------+ 569 Table 6: MP_KEY Key Types 571 Plain Text 572 Key Material is exchanged in plain text between hosts, and the key 573 parts (key-a, key-b) are used by each host to generate the derived 574 key (d-key) by concatenating the two parts with the local key in 575 front (e.g. hostA d-key=(key-a+key-b), hostB d-key=(key-b+key-a)). 577 ECDHE-SHA256-C25519 578 Key Material is exchanged via ECDHE key exchange with SHA256 and 579 Curve 25519 to generate the derived key (d-key). 581 ECDHE-SHA512-C25519 582 Key Material is exchanged via ECDHE key exchange with SHA512 and 583 Curve 25519 to generate the derived key (d-key). 585 3.2.5. MP_SEQ 587 +--------+--------+--------+--------+--------+--------+--------+ 588 |00101110|00000111|00000100| Multipath Sequence Number | 589 +--------+--------+--------+--------+--------+--------+--------+ 590 Type=46 Length=7 MP_OPT=4 592 The MP_SEQ option is used for end-to-end datagram-based sequence 593 numbers of an MP-DCCP connection. The initial data sequence number 594 (IDSN) SHOULD be set randomly. The MP_SEQ number space is different 595 from path individual sequence number space. 597 3.2.6. MP_HMAC 599 +--------+--------+--------+--------+--------+--------+ 600 |00101110|00001011|00000101| HMAC-SHA1 (20 bytes) ... 601 +--------+--------+--------+--------+--------+--------+ 602 Type=46 Length=23 MP_OPT=5 604 The MP_HMAC option is used to provide authentication for the MP_JOIN 605 option. The HMAC is built using the derived key (d-key) calculated 606 previously from the handshake key material exchanged with the MP_KEY 607 option. The Message for the HMAC is the header of the MP_JOIN for 608 which authentication shall be performed. By including a nonce in 609 these datagrams, possible replay-attacks are remedied. 611 3.2.7. MP_RTT 613 +--------+--------+--------+--------+--------+--------+--------+ 614 |00101110|00001100|00000110|RTT Type| RTT 615 +--------+--------+--------+--------+--------+--------+--------+ 616 | | Age | 617 +--------+--------+--------+--------+--------+ 618 Type=46 Length=12 MP_OPT=6 620 The MP_RTT option is used to transmit RTT values in milliseconds and 621 MUST belong to the path over which this information is transmitted. 622 Additionally, the age of the measurement is specified in 623 milliseconds. 625 Raw RTT (=0) 626 Raw RTT value of the last Datagram Round-Trip. The Age parameter 627 is set to the age of when the Ack for the datagram was received. 629 Min RTT (=1) 630 Min RTT value. The period for computing the Minimum can be 631 specified by the Age parameter. 633 Max RTT (=2) 634 Max RTT value. The period for computing the Maximum can be 635 specified by the Age parameter. 637 Smooth RTT (=3) 638 Averaged RTT value. The period for computing the smoothed RTT can 639 be specified by the Age parameter. 641 Age (=4) 642 The Age parameter is a 4-byte value which is set to the age or 643 timestamp when the Ack for the datagram was received in case of 644 RTT type = 0 and may contain the periods for computing of derived 645 RTT values depending on other RTT types, i.e., the Minimum (=1) 646 and Maximum (=2) as well as the averaged smoothed RTT value (=3). 647 [TBD/TBV] 649 3.2.8. MP_ADDADDR 651 The MP_ADDADDR option announces additional addresses (and, 652 optionally, ports) on which a host can be reached. This option can 653 be used at any time during an existing DCCP connection, when the 654 sender wishes to enable multiple paths and/or when additional paths 655 become available. Length is variable depending on IPv4 or IPv6 and 656 whether port number is used and is in range between 28 and 42 bytes. 658 1 2 3 659 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 660 +---------------+---------------+-------+-------+---------------+ 661 | Kind | Length |Subtype| IPVer | Address ID | 662 +---------------+---------------+-------+-------+---------------+ 663 | Address (IPv4 - 4 bytes / IPv6 - 16 bytes) | 664 +-------------------------------+-------------------------------+ 665 | Port (2 bytes, optional) | | 666 +-------------------------------+ | 667 | HMAC (20 bytes) | 668 | | 669 | | 670 | | 671 | | 672 | +-------------------------------+ 673 | | 674 +-------------------------------+ 676 Every address has an Address ID that can be used for uniquely 677 identifying the address within a connection for address removal. The 678 Address ID is also used to identify MP_JOIN options (see 679 Section 3.2.2) relating to the same address, even when address 680 translators are in use. The Address ID MUST uniquely identify the 681 address for the sender of the option (within the scope of the 682 connection); the mechanism for allocating such IDs is implementation 683 specific. 685 All Address IDs learned via either MP_JOIN or ADD_ADDR SHOULD be 686 stored by the receiver in a data structure that gathers all the 687 Address-ID-to-address mappings for a connection (identified by a 688 token pair). In this way, there is a stored mapping between the 689 Address ID, observed source address, and token pair for future 690 processing of control information for a connection. 692 Ideally, ADD_ADDR and REMOVE_ADDR options would be sent reliably, and 693 in order, to the other end. This would ensure that this address 694 management does not unnecessarily cause an outage in the connection 695 when remove/add addresses are processed in reverse order, and also to 696 ensure that all possible paths are used. Note, however, that losing 697 reliability and ordering will not break the multipath connections, it 698 will just reduce the opportunity to open new paths and to survive 699 different patterns of path failures. 701 Therefore, implementing reliability signals for these DCCP options is 702 not necessary. In order to minimize the impact of the loss of these 703 options, however, it is RECOMMENDED that a sender should send these 704 options on all available subflows. If these options need to be 705 received in order, an implementation SHOULD only send one ADD_ADDR/ 706 REMOVE_ADDR option per RTT, to minimize the risk of misordering. A 707 host that receives an ADD_ADDR but finds a connection set up to that 708 IP address and port number is unsuccessful SHOULD NOT perform further 709 connection attempts to this address/port combination for this 710 connection. A sender that wants to trigger a new incoming connection 711 attempt on a previously advertised address/port combination can 712 therefore refresh ADD_ADDR information by sending the option again. 714 [TBD/TBV] 716 3.2.9. MP_REMOVEADDR 718 If, during the lifetime of an MP-DCCP connection, a previously 719 announced address becomes invalid (e.g., if the interface 720 disappears), the affected host SHOULD announce this so that the peer 721 can remove subflows related to this address. 723 This is achieved through the Remove Address (REMOVE_ADDR) option 724 which will remove a previously added address (or list of addresses) 725 from a connection and terminate any subflows currently using that 726 address. 728 For security purposes, if a host receives a REMOVE_ADDR option, it 729 must ensure the affected path(s) are no longer in use before it 730 instigates closure. Typical DCCP validity tests on the subflow 731 (e.g., packet type specific sequence and acknowledgement number 732 check) MUST also be undertaken. An implementation can use 733 indications of these test failures as part of intrusion detection or 734 error logging. 736 The sending and receipt of this message SHOULD trigger the sending of 737 DCCP-Close and DCCP-Reset by client and server, respectively on the 738 affected subflow(s) (if possible), as a courtesy to cleaning up 739 middlebox state, before cleaning up any local state. 741 Address removal is undertaken by ID, so as to permit the use of NATs 742 and other middleboxes that rewrite source addresses. If there is no 743 address at the requested ID, the receiver will silently ignore the 744 request. 746 1 2 3 747 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 748 +---------------+---------------+-------+-------+---------------+ 749 | Kind | Length = 3+n |Subtype|(resvd)| Address ID |... 750 +---------------+---------------+-------+-------+---------------+ 751 (followed by n-1 Address IDs, if required) 753 Minimum length of this option is 4 bytes (for one address to remove). 755 [TBD/TBV] 757 3.2.10. MP_PRIO 759 In the event that a single specific path out of the set of available 760 paths shall be treated with higher priority compared to the others, a 761 host may wish to signal such change in priority of subflows to the 762 peer. Therefore, the MP_PRIO option, shown below, can be used to set 763 a priority flag for the subflow on which it is sent. 765 1 2 3 766 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 767 +---------------+---------------+-------+-------+--------------+ 768 | Kind | Length |Subtype| Prio | AddrID (opt) | 769 +---------------+---------------+-------+-------+--------------+ 771 Whether more than two values for priority (e.g., B for backup and P 772 for prioritized path) are defined in case of more than two parallel 773 paths is for further consideration. 775 [TBD/TBV] 777 3.3. MP-DCCP Handshaking Procedure 778 Host A Host B 779 ------------------------ ---------- 780 Address A1 Address A2 Address B1 781 ---------- ---------- ---------- 782 | | | 783 | DCCP-Request + | 784 |------- MP_KEY(Key-A) ------------------------------>| 785 |<---------------------- MP_KEY(Key-B) ---------------| 786 | DCCP-Response + agreed | 787 | | | 788 | DCCP-Ack | | 789 |--------- MP_KEY(Key-A) + MP_KEY(Key-B) ------------>| 790 | | | 791 | | DCCP-Request + | 792 | |--- MP_JOIN(TB,RA) ------------------->| 793 | |<------MP_JOIN(TB,RB) + MP_HMAC(A)-----| 794 | |DCCP-Response | 795 | | | 796 | |DCCP-Ack | 797 | |-------- MP_HMAC(B) ------------------>| 798 | |<--------------------------------------| 799 | |DCCP-ACK | 801 Figure 3: Example MP-DCCP Handshake 803 The basic initial handshake for the first flow is as follows: 805 * Host A sends a DCCP-Request with the MP-Capable feature Change 806 request and the MP_KEY option with Host-specific Key-A 808 * Host B sends a DCCP-Response with Confirm feature for MP-Capable 809 and the MP_Key option with Host-specific Key-B 811 * Host A sends a DCCP-Ack with both Keys echoed to Host B. 813 The handshake for subsequent flows based on a successful initial 814 handshake is as follows: 816 * Host A sends a DCCP-Request with the MP-Capable feature Change 817 request and the MP_JOIN option with Host B's Token TB, generated 818 from the derived key by applying a SHA-1 hash and truncating to 819 the first 32 bits. Additionally, an own random nonce RA is 820 transmitted with the MP_JOIN. 822 * Host B computes the HMAC of the DCCP-Request and sends a DCCP- 823 Response with Confirm feature option for MP-Capable and the 824 MP_JOIN option with the Token TB and a random nonce RB together 825 with the computed MP_HMAC. 827 * Host A sends a DCCP-Ack with the HMAC computed for the DCCP- 828 Response. 830 * Host B sends a DCCP-Ack confirm the HMAC and to conclude the 831 handshaking. 833 4. Security Considerations 835 Similar to DCCP, MP-DCCP does not provide cryptographic security 836 guarantees inherently. Thus, if applications need cryptographic 837 security (integrity, authentication, confidentiality, access control, 838 and anti-replay protection) the use of IPsec or some other kind of 839 end-to-end security is recommended; Secure Real-time Transport 840 Protocol (SRTP) [RFC3711] is one candidate protocol for 841 authentication. Together with Encryption of Header Extensions in 842 SRTP, as provided by [RFC6904], also integrity would be provided. 844 As described in [RFC4340], DCCP provides protection against hijacking 845 and limits the potential impact of some denial-of-service attacks, 846 but DCCP provides no inherent protection against attackers' snooping 847 on data packets. Regarding the security of MP-DCCP no additional 848 risks should be introduced compared to regular DCCP of today. 849 Thereof derived are the following key security requirements to be 850 fulfilled by MP-DCCP: 852 * Provide a mechanism to confirm that parties involved in a subflow 853 handshake are identical to those in the original connection setup. 855 * Provide verification that the new address to be included in a MP 856 connection is valid for a peer to receive traffic at before using 857 it. 859 * Provide replay protection, i.e., ensure that a request to add/ 860 remove a subflow is 'fresh'. 862 In order to achieve these goals, MP-DCCP includes a hash-based 863 handshake algorithm documented in Sections Section 3.2.4 and 864 Section 3.3. The security of the MP-DCCP connection depends on the 865 use of keys that are shared once at the start of the first subflow 866 and are never sent again over the network. To ease demultiplexing 867 while not giving away any cryptographic material, future subflows use 868 a truncated cryptographic hash of this key as the connection 869 identification "token". The keys are concatenated and used as keys 870 for creating Hash-based Message Authentication Codes (HMACs) used on 871 subflow setup, in order to verify that the parties in the handshake 872 are the same as in the original connection setup. It also provides 873 verification that the peer can receive traffic at this new address. 874 Replay attacks would still be possible when only keys are used; 875 therefore, the handshakes use single-use random numbers (nonces) at 876 both ends -- this ensures that the HMAC will never be the same on two 877 handshakes. Guidance on generating random numbers suitable for use 878 as keys is given in [RFC4086]. During normal operation, regular DCCP 879 protection mechanisms (such as header checksum to protect DCCP 880 headers against corruption) will provide the same level of protection 881 against attacks on individual DCCP subflows as exists for regular 882 DCCP today. 884 5. Interactions with Middleboxes 886 Issues from interaction with on-path middleboxes such as NATs, 887 firewalls, proxies, intrusion detection systems (IDSs), and others 888 have to be considered for all extensions to standard protocols since 889 otherwise unexpected reactions of middleboxes may hinder its 890 deployment. DCCP already provides means to mitigate the potential 891 impact of middleboxes, also in comparison to TCP (see [RFC4043], 892 sect. 16). In case, however, both hosts are located behind a NAT or 893 firewall entity, specific measures have to be applied such as the 894 [RFC5596]-specified simultaneous-open technique that update the 895 (traditionally asymmetric) connection-establishment procedures for 896 DCCP. Further standardized technologies addressing NAT type 897 middleboxes are covered by [RFC5597]. 899 [RFC6773] specifies UDP Encapsulation for NAT Traversal of DCCP 900 sessions, similar to other UDP encapsulations such as for SCTP 901 [RFC6951]. The alternative U-DCCP approach proposed in 902 [I-D.amend-tsvwg-dccp-udp-header-conversion] would reduce tunneling 903 overhead. The handshaking procedure for DCCP-UDP header conversion 904 or use of a DCCP-UDP negotiation procedure to signal support for 905 DCCP-UDP header conversion would require encapsulation during the 906 handshakes and use of two additional port numbers out of the UDP port 907 number space, but would require zero overhead afterwards. 909 6. Implementation 911 The approach described above has been implemented in open source 912 across different testbeds and a new scheduling algorithm has been 913 extensively tested. Also demonstrations of a laboratory setup have 914 been executed and have been published at [website]. 916 7. Acknowledgments 918 1. Notes 920 This document is inspired by Multipath TCP [RFC6824]/[RFC8684] and 921 some text passages for the -00 version of the draft are copied almost 922 unmodified. 924 8. IANA Considerations 926 This document defines one new value to DCCP feature list and one new 927 DCCP Option with ten corresponding Subtypes as follows. This 928 document defines a new DCCP feature parameter for negotiating the 929 support of multipath capability for DCCP sessions between hosts as 930 described in Section 3. The following entry in Table 7 should be 931 added to the "Feature Numbers Registry" according to [RFC4340], 932 Section 19.4. under the "DCCP Protocol" heading. 934 +=======+============================+===============+ 935 | Value | Feature Name | Specification | 936 +=======+============================+===============+ 937 | 0x10 | MP-DCCP capability feature | Section 3.1 | 938 +-------+----------------------------+---------------+ 940 Table 7: Addition to DCCP Feature list Entries 942 This document defines a new DCCP protocol option of type=46 as 943 described in Section 3.2 together with 10 additional sub-options. 944 The following entries in Table 8 should be added to the "DCCP 945 Protocol options" and assigned as "MP-DCCP sub-options", 946 respectively. 948 +==========+===============+=====================+===========+ 949 | Value | Symbol | Name | Reference | 950 +==========+===============+=====================+===========+ 951 | TBD or | MP_OPT | DCCP Multipath | Section | 952 | Type=46 | | option | 3.2 | 953 +----------+---------------+---------------------+-----------+ 954 | TBD or | MP_CONFIRM | Confirm reception/ | Section | 955 | MP_OPT=0 | | processing of an | 3.2.1 | 956 | | | MP_OPT option | | 957 +----------+---------------+---------------------+-----------+ 958 | TBD or | MP_JOIN | Join path to | Section | 959 | MP_OPT=1 | | existing MP-DCCP | 3.2.2 | 960 | | | flow | | 961 +----------+---------------+---------------------+-----------+ 962 | TBD or | MP_FAST_CLOSE | Close MP-DCCP flow | Section | 963 | MP_OPT=2 | | | 3.2.3 | 964 +----------+---------------+---------------------+-----------+ 965 | TBD or | MP_KEY | Exchange key | Section | 966 | MP_OPT=3 | | material for | 3.2.4 | 967 | | | MP_HMAC | | 968 +----------+---------------+---------------------+-----------+ 969 | TBD or | MP_SEQ | Multipath Sequence | Section | 970 | MP_OPT=4 | | Number | 3.2.5 | 971 +----------+---------------+---------------------+-----------+ 972 | TBD or | MP_HMAC | Hash-based Message | Section | 973 | MP_OPT=5 | | Auth. Code for MP- | 3.2.6 | 974 | | | DCCP | | 975 +----------+---------------+---------------------+-----------+ 976 | TBD or | MP_RTT | Transmit RTT values | Section | 977 | MP_OPT=6 | | and calculation | 3.2.7 | 978 | | | parameters | | 979 +----------+---------------+---------------------+-----------+ 980 | TBD or | MP_ADDADDR | Advertise | Section | 981 | MP_OPT=7 | | additional | 3.2.8 | 982 | | | Address(es)/Port(s) | | 983 +----------+---------------+---------------------+-----------+ 984 | TBD or | MP_REMOVEADDR | Remove Address(es)/ | Section | 985 | MP_OPT=8 | | Port(s) | 3.2.9 | 986 +----------+---------------+---------------------+-----------+ 987 | TBD or | MP_PRIO | Change Subflow | Section | 988 | MP_OPT=9 | | Priority | 3.2.10 | 989 +----------+---------------+---------------------+-----------+ 991 Table 8: Addition to DCCP Protocol options and 992 corresponding sub-options 994 [Tbd], must include options for: 996 * handshaking procedure to indicate MP support 998 * handshaking procedure to indicate JOINING of an existing MP 999 connection 1001 * signaling of new or changed addresses 1003 * setting handover or aggregation mode 1005 * setting reordering on/off 1007 should include options carrying: 1009 * overall sequence number for restoring purposes 1011 * sender time measurements for restoring purposes 1013 * scheduler preferences 1015 * reordering preferences 1017 9. Informative References 1019 [I-D.amend-tsvwg-dccp-udp-header-conversion] 1020 Amend, M., Brunstrom, A., Kassler, A., and V. Rakocevic, 1021 "Lossless and overhead free DCCP - UDP header conversion 1022 (U-DCCP)", Work in Progress, Internet-Draft, draft-amend- 1023 tsvwg-dccp-udp-header-conversion-01, 8 July 2019, 1024 . 1027 [I-D.amend-tsvwg-multipath-framework-mpdccp] 1028 Amend, M., Bogenfeld, E., Brunstrom, A., Kassler, A., and 1029 V. Rakocevic, "A multipath framework for UDP traffic over 1030 heterogeneous access networks", Work in Progress, 1031 Internet-Draft, draft-amend-tsvwg-multipath-framework- 1032 mpdccp-01, 8 July 2019, . 1035 [I-D.lhwxz-hybrid-access-network-architecture] 1036 Leymann, N., Heidemann, C., Wesserman, M., Xue, L., and M. 1037 Zhang, "Hybrid Access Network Architecture", Work in 1038 Progress, Internet-Draft, draft-lhwxz-hybrid-access- 1039 network-architecture-02, 13 January 2015, 1040 . 1043 [I-D.muley-network-based-bonding-hybrid-access] 1044 Muley, P., Henderickx, W., Liang, G., Liu, H., Cardullo, 1045 L., Newton, J., Seo, S., Draznin, S., and B. Patil, 1046 "Network based Bonding solution for Hybrid Access", Work 1047 in Progress, Internet-Draft, draft-muley-network-based- 1048 bonding-hybrid-access-03, 22 October 2018, 1049 . 1052 [paper] Amend, M., Bogenfeld, E., Cvjetkovic, M., Rakocevic, V., 1053 Pieska, M., Kassler, A., and A. Brunstrom, "A Framework 1054 for Multiaccess Support for Unreliable Internet Traffic 1055 using Multipath DCCP", DOI 10.1109/LCN44214.2019.8990746, 1056 October 2019, 1057 . 1059 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1060 RFC 793, DOI 10.17487/RFC0793, September 1981, 1061 . 1063 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1064 Requirement Levels", BCP 14, RFC 2119, 1065 DOI 10.17487/RFC2119, March 1997, 1066 . 1068 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 1069 RFC 3124, DOI 10.17487/RFC3124, June 2001, 1070 . 1072 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1073 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1074 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1075 . 1077 [RFC4043] Pinkas, D. and T. Gindin, "Internet X.509 Public Key 1078 Infrastructure Permanent Identifier", RFC 4043, 1079 DOI 10.17487/RFC4043, May 2005, 1080 . 1082 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1083 "Randomness Requirements for Security", BCP 106, RFC 4086, 1084 DOI 10.17487/RFC4086, June 2005, 1085 . 1087 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1088 Congestion Control Protocol (DCCP)", RFC 4340, 1089 DOI 10.17487/RFC4340, March 2006, 1090 . 1092 [RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol 1093 (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, 1094 September 2009, . 1096 [RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol 1097 (DCCP) Simultaneous-Open Technique to Facilitate NAT/ 1098 Middlebox Traversal", RFC 5596, DOI 10.17487/RFC5596, 1099 September 2009, . 1101 [RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) 1102 Behavioral Requirements for the Datagram Congestion 1103 Control Protocol", BCP 150, RFC 5597, 1104 DOI 10.17487/RFC5597, September 2009, 1105 . 1107 [RFC5634] Fairhurst, G. and A. Sathiaseelan, "Quick-Start for the 1108 Datagram Congestion Control Protocol (DCCP)", RFC 5634, 1109 DOI 10.17487/RFC5634, August 2009, 1110 . 1112 [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A 1113 Datagram Congestion Control Protocol UDP Encapsulation for 1114 NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 1115 2012, . 1117 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1118 "TCP Extensions for Multipath Operation with Multiple 1119 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1120 . 1122 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 1123 Real-time Transport Protocol (SRTP)", RFC 6904, 1124 DOI 10.17487/RFC6904, April 2013, 1125 . 1127 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 1128 Control Transmission Protocol (SCTP) Packets for End-Host 1129 to End-Host Communication", RFC 6951, 1130 DOI 10.17487/RFC6951, May 2013, 1131 . 1133 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 1134 Paasch, "TCP Extensions for Multipath Operation with 1135 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 1136 2020, . 1138 [slide] Amend, M., "MP-DCCP for enabling transfer of UDP/IP 1139 traffic over multiple data paths in multi-connectivity 1140 networks", IETF105 , n.d., 1141 . 1145 [TS23.501] 3GPP, "System architecture for the 5G System; Stage 2; 1146 Release 16", December 2020, 1147 . 1150 [website] "Multipath extension for DCCP", n.d., 1151 . 1153 Authors' Addresses 1155 Markus Amend (editor) 1156 Deutsche Telekom 1157 Deutsche-Telekom-Allee 9 1158 64295 Darmstadt 1159 Germany 1161 Email: Markus.Amend@telekom.de 1163 Dirk von Hugo 1164 Deutsche Telekom 1165 Deutsche-Telekom-Allee 9 1166 64295 Darmstadt 1167 Germany 1169 Email: Dirk.von-Hugo@telekom.de 1171 Anna Brunstrom 1172 Karlstad University 1173 Universitetsgatan 2 1174 SE-651 88 Karlstad 1175 Sweden 1177 Email: anna.brunstrom@kau.se 1178 Andreas Kassler 1179 Karlstad University 1180 Universitetsgatan 2 1181 SE-651 88 Karlstad 1182 Sweden 1184 Email: andreas.kassler@kau.se 1186 Veselin Rakocevic 1187 City University of London 1188 Northampton Square 1189 London 1190 United Kingdom 1192 Email: veselin.rakocevic.1@city.ac.uk 1194 Stephen Johnson 1195 BT 1196 Adastral Park 1197 Martlesham Heath 1198 IP5 3RE 1199 United Kingdom 1201 Email: stephen.h.johnson@bt.com