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