idnits 2.17.1 draft-amend-tsvwg-multipath-dccp-03.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 (November 04, 2019) is 1606 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Tbd' is mentioned on line 597, but not defined == Missing Reference: 'Nonce 0' is mentioned on line 323, but not defined == Missing Reference: 'Nonce 1' is mentioned on line 324, but not defined == Missing Reference: 'TBD' is mentioned on line 519, but not defined == Unused Reference: 'I-D.muley-network-based-bonding-hybrid-access' is defined on line 641, 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 (~~), 6 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 E. Bogenfeld 4 Intended status: Experimental Deutsche Telekom 5 Expires: May 7, 2020 A. Brunstrom 6 A. Kassler 7 Karlstad University 8 V. Rakocevic 9 City University of London 10 November 04, 2019 12 DCCP Extensions for Multipath Operation with Multiple Addresses 13 draft-amend-tsvwg-multipath-dccp-03 15 Abstract 17 DCCP communication is currently restricted to a single path per 18 connection, yet multiple paths often exist between peers. The 19 simultaneous use of these multiple paths for a DCCP session could 20 improve resource usage within the network and, thus, improve user 21 experience through higher throughput and improved resilience to 22 network failure. 24 Multipath DCCP provides the ability to simultaneously use multiple 25 paths between peers. This document presents a set of extensions to 26 traditional DCCP to support multipath operation. The protocol offers 27 the same type of service to applications as DCCP and it provides the 28 components necessary to establish and use multiple DCCP flows across 29 potentially disjoint paths. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 7, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Multipath DCCP in the Networking Stack . . . . . . . . . 3 67 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.3. MP-DCCP Concept . . . . . . . . . . . . . . . . . . . . . 3 69 1.4. Differences from Multipath TCP . . . . . . . . . . . . . 4 70 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 7 71 2. Operation Overview . . . . . . . . . . . . . . . . . . . . . 7 72 3. MP-DCCP Protocol . . . . . . . . . . . . . . . . . . . . . . 7 73 3.1. Multipath Capable Feature . . . . . . . . . . . . . . . . 8 74 3.2. Multipath Option . . . . . . . . . . . . . . . . . . . . 9 75 3.2.1. MP_CONFIRM . . . . . . . . . . . . . . . . . . . . . 9 76 3.2.2. MP_JOIN . . . . . . . . . . . . . . . . . . . . . . . 9 77 3.2.3. MP_FAST_CLOSE . . . . . . . . . . . . . . . . . . . . 10 78 3.2.4. MP_KEY . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.2.5. MP_SEQ . . . . . . . . . . . . . . . . . . . . . . . 11 80 3.2.6. MP_HMAC . . . . . . . . . . . . . . . . . . . . . . . 11 81 3.2.7. MP_RTT . . . . . . . . . . . . . . . . . . . . . . . 11 82 3.2.8. MP_ADDADDR . . . . . . . . . . . . . . . . . . . . . 12 83 3.2.9. MP_REMOVEADDR . . . . . . . . . . . . . . . . . . . . 12 84 3.2.10. MP_PRIO . . . . . . . . . . . . . . . . . . . . . . . 12 85 3.3. MP-DCCP Handshaking Procedure . . . . . . . . . . . . . . 12 86 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 5. Interactions with Middleboxes . . . . . . . . . . . . . . . . 13 88 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 8. Informative References . . . . . . . . . . . . . . . . . . . 14 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 93 1. Introduction 95 Multipath DCCP (MP-DCCP) is a set of extensions to regular DCCP 96 [RFC4340], which enables a transport connection to operate across 97 multiple paths simultaneously. DCCP multipath operations is 98 suggested in the context of ongoing 3GPP work on 5G multi-access 99 solutions [I-D.amend-tsvwg-multipath-framework-mpdccp] and for hybrid 100 access networks [I-D.lhwxz-hybrid-access-network-architecture][I-D.mu 101 ley-network-based-bonding-hybrid-access]. It can be applied for 102 load-balancing, seamless session handover and aggregation purposes 103 (referred to as steering, switching and splitting in 3GPP terminology 104 [TR23.793]). 106 This document presents the protocol changes required to add multipath 107 capability to DCCP; specifically, those for signaling and setting up 108 multiple paths ("subflows"), managing these subflows, reassembly of 109 data, and termination of sessions. 111 1.1. Multipath DCCP in the Networking Stack 113 MP-DCCP operates at the transport layer and aims to be transparent to 114 both higher and lower layers. It is a set of additional features on 115 top of standard DCCP; Figure 1 illustrates this layering. MP-DCCP is 116 designed to be used by applications in the same way as DCCP with no 117 changes. 119 +-------------------------------+ 120 | Application | 121 +---------------+ +-------------------------------+ 122 | Application | | MP-DCCP | 123 +---------------+ + - - - - - - - + - - - - - - - + 124 | DCCP | |Subflow (DCCP) |Subflow (DCCP) | 125 +---------------+ +-------------------------------+ 126 | IP | | IP | IP | 127 +---------------+ +-------------------------------+ 129 Figure 1: Comparison of Standard DCCP and MP-DCCP Protocol Stacks 131 1.2. Terminology 133 [Tbd], could be similar to [RFC6824] 135 1.3. MP-DCCP Concept 136 Host A Host B 137 ------------------------ ------------------------ 138 Address A1 Address A2 Address B1 Address B2 139 ---------- ---------- ---------- ---------- 140 | | | | 141 | (DCCP flow setup) | | 142 |----------------------------------->| | 143 |<-----------------------------------| | 144 | | | | 145 | | (DCCP flow setup) | | 146 | |--------------------->| | 147 | |<---------------------| | 148 | merge individual DCCP flows to one multipath connection 149 | | | | 151 Figure 2: Example MP-DCCP Usage Scenario 153 1.4. Differences from Multipath TCP 155 Multipath DCCP is similar to Multipath TCP [RFC6824], in that it 156 extends the related basic DCCP transport protocol [RFC4340] with 157 multipath capabilities in the same way as Multipath TCP extends TCP 158 [RFC0793]. However, mainly dominated by the basic protocols TCP and 159 DCPP, the transport characteristics are different. 161 Table 1 compares the protocol characteristics of TCP and DCCP, which 162 are by nature inherited by their respective multipath extensions. A 163 major difference lies in the delivery of payload, which is for TCP an 164 exact copy of the generated byte-stream. DCCP behaves contrary and 165 does not guarantee to transmit any payload nor the order of delivery. 166 Since this is mainly affecting the receiving endpoint of a TCP or 167 DCCP communication, many similarities on sender side can be stated. 168 Both transport protocols share the 3-way initiation of a 169 communication and both exploit a congestion control to adapt to path 170 characteristics. 172 +----------------------+-----------------+--------------------------+ 173 | Feature | TCP | DCCP | 174 +----------------------+-----------------+--------------------------+ 175 | Full-Duplex | yes | yes | 176 +----------------------+-----------------+--------------------------+ 177 | Connection- Oriented | yes | yes | 178 +----------------------+-----------------+--------------------------+ 179 | Header option space | 40 bytes | < 1008 bytes or PMTU | 180 +----------------------+-----------------+--------------------------+ 181 | Data transfer | reliable | unreliable | 182 +----------------------+-----------------+--------------------------+ 183 | Packet-loss handling | re- | report only | 184 | | transmission | | 185 +----------------------+-----------------+--------------------------+ 186 | Ordered data | yes | no | 187 | delivery | | | 188 +----------------------+-----------------+--------------------------+ 189 | Sequence numbers | one per byte | one per PDU | 190 +----------------------+-----------------+--------------------------+ 191 | Flow control | yes | no | 192 +----------------------+-----------------+--------------------------+ 193 | Congestion control | yes | yes | 194 +----------------------+-----------------+--------------------------+ 195 | ECN support | yes | yes | 196 +----------------------+-----------------+--------------------------+ 197 | Selective ACK | yes | depends on congestion | 198 | | | control | 199 +----------------------+-----------------+--------------------------+ 200 | Fix message | no | yes | 201 | boundaries | | | 202 +----------------------+-----------------+--------------------------+ 203 | Path MTU discovery | yes | yes | 204 +----------------------+-----------------+--------------------------+ 205 | Fragmentation | yes | no | 206 +----------------------+-----------------+--------------------------+ 207 | SYN flood protection | yes | no | 208 +----------------------+-----------------+--------------------------+ 209 | Half-open | yes | no | 210 | connections | | | 211 +----------------------+-----------------+--------------------------+ 213 Table 1: TCP and DCCP protocol comparison 215 Consequently, the multipath features, shown in Table 2, are the same, 216 supporting volatile paths, session handover and path aggregation 217 capabilities. All of them profit by the existence of congestion 218 control. 220 +--------------------------+---------------------+------------------+ 221 | Feature | MP-TCP | MP-DCCP | 222 +--------------------------+---------------------+------------------+ 223 | Volatile paths | yes | yes | 224 +--------------------------+---------------------+------------------+ 225 | Robust session | no | yes | 226 | establishment | | | 227 +--------------------------+---------------------+------------------+ 228 | Data reassembly | yes | optional / | 229 | | | modular | 230 +--------------------------+---------------------+------------------+ 231 | Expandability | limited by TCP | flexible | 232 | | header | | 233 +--------------------------+---------------------+------------------+ 234 | Session handover | yes | yes | 235 +--------------------------+---------------------+------------------+ 236 | Path aggregation | yes | yes | 237 +--------------------------+---------------------+------------------+ 239 Table 2: MPTCP and MP-DCCP protocol comparison 241 Therefore the sender logic is not much different between MP-DCCP and 242 MPTCP, even if the multipath session initiation differs. MP-DCCP 243 inherits a robust session establishment feature, which guarantees 244 communication establishment if at least one functional path is 245 available. MP-TCP relies on an initial path, which has to work; 246 otherwise no communication can be established. 248 The receiver side for MP-DCCP has to deal with the unreliable 249 transport character of DCCP and a possible re-assembly of the data 250 stream. In practice, it is assumed that some sort of re-assembly has 251 to be applied, even if DCCP and the order of delivery is unreliable 252 by nature. Such re-assembly mechanisms have to account for the fact 253 that packet loss may occur for any of the DCCP subflows. Another 254 issue is the packet reordering introduced when a DCCP communication 255 is split across paths with disjoint latencies. In theory, 256 applications using DCCP certainly have to deal with packet 257 reordering, since DCCP has no mechanisms to prevent it. However, in 258 practice, without any multipath extension, packet reordering can be 259 assumed to be very limited. Therefore most services on top of DCCP 260 are not expecting massive packet reordering and degrades their 261 performance if it happens anyway. 263 The receiving process for MP-TCP is on the other hand a simple "just 264 wait" approach, since TCP guarantees reliable delivery. 266 1.5. Requirements Language 268 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 269 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 270 document are to be interpreted as described in [RFC2119]. 272 2. Operation Overview 274 [Tbd], could be similar to [RFC6824] 276 The Multipath Capability for MP-DCCP can be negotiated with a new 277 DCCP feature, as described in Section 3. Once negotiated, all 278 subsequent MP-DCCP operations are signalled with a variable length 279 multipath-related option, as described in Section 3.1. 281 3. MP-DCCP Protocol 283 The DCCP protocol feature list ([RFC4340] section 6.4) will be 284 enhanced by a new Multipath related feature with Feature number 10, 285 as shown in Figure 3. 287 Rec'n Initial 288 Number Meaning Rule Value Req'd 289 ------ ------- ----- ----- ----- 290 0 Reserved 291 1 Congestion Control ID (CCID) SP 2 Y 292 2 Allow Short Seqnos SP 0 Y 293 3 Sequence Window NN 100 Y 294 4 ECN Incapable SP 0 N 295 5 Ack Ratio NN 2 N 296 6 Send Ack Vector SP 0 N 297 7 Send NDP Count SP 0 N 298 8 Minimum Checksum Coverage SP 0 N 299 9 Check Data Checksum SP 0 N 300 10 Multipath Capable SP 0 N 301 11-127 Reserved 302 128-255 CCID-specific features 304 Figure 3: Proposed Feature Set 306 The DCCP protocol options ([RFC4340] section 5.8) will be enhanced by 307 a new Multipath related variable-length option with option type 45, 308 as shown in Figure 4. 310 Option DCCP- 311 Type Length Meaning Data? 312 ---- ------ ------- ----- 313 0 1 Padding Y 314 1 1 Mandatory N 315 2 1 Slow Receiver Y 316 3-31 1 Reserved 317 32 variable Change L N 318 33 variable Confirm L N 319 34 variable Change R N 320 35 variable Confirm R N 321 36 variable Init Cookie N 322 37 3-8 NDP Count Y 323 38 variable Ack Vector [Nonce 0] N 324 39 variable Ack Vector [Nonce 1] N 325 40 variable Data Dropped N 326 41 6 Timestamp Y 327 42 6/8/10 Timestamp Echo Y 328 43 4/6 Elapsed Time N 329 44 6 Data Checksum Y 330 45 variable Multipath Y 331 46-127 variable Reserved 332 128-255 variable CCID-specific options - 334 Figure 4: Proposed Option Set 336 [Tbd] On top it requires particular considerations for: 338 o The minimum PMTU of the individual paths must be selected to 339 announce to the application. Changes of individual path PMTUs 340 must be re-announced to the application if they are lower than the 341 current announced PMTU. 343 o Overall sequencing for optional reassembly procedure 345 o Congestion control 347 o Robust MP-DCCP session establishment (no dependency on an initial 348 path setup) 350 3.1. Multipath Capable Feature 352 DCCP endpoints are multipath-disabled by default and multipath 353 capability can be negotiated with the Multipath Capable Feature. 355 Multipath Capable has feature number 10 and is server-priority. It 356 takes one-byte values. The first four bits are used to specify 357 compatible versions of the MP-DCCP implementation. The following 358 four bits are reserved for further use. 360 3.2. Multipath Option 362 +--------+--------+--------+--------+-------- 363 |00101101| Length | MP_OPT | Value(s) ... 364 +--------+--------+--------+--------+-------- 365 Type=45 367 Option 368 Type Length MP_OPT Meaning 369 ---- ------ ------- ----- 370 45 7 0 =MP_CONFIRM Confirm reception and processing of 371 an MP_OPT option 372 45 7 1 =MP_JOIN Join path to an existing MP-DCCP flow 373 45 3 2 =MP_FAST_CLOSE Close MP-DCCP flow 374 45 var 3 =MP_KEY Exchange key material for MP_HMAC 375 45 7 4 =MP_SEQ Multipath Sequence Number 376 45 23 5 =MP_HMAC HMA Code for authentication 377 45 12 6 =MP_RTT Transmit RTT values 378 45 TBD 7 =MP_ADDADDR TBD 379 45 TBD 8 =MP_REMOVEADDR TBD 380 45 TBD 9 =MP_PRIO TBD 382 Figure 5: MP_OPT Option Types 384 3.2.1. MP_CONFIRM 386 +--------+--------+--------+--------+--------+--------+--------+ 387 |00101101| Length |00000000| List of options ... 388 +--------+--------+--------+--------+--------+--------+--------+ 389 Type=45 MP_OPT=0 391 MP_CONFIRM can be used to send confirmation of received and processed 392 options. Confirmed options are copied verbatim and appended as List 393 of options. 395 3.2.2. MP_JOIN 397 +--------+--------+--------+--------+--------+--------+--------+ 398 |00101101|00001011|00000001| Path Token | 399 +--------+--------+--------+--------+--------+--------+--------+ 400 | Nonce | 401 +--------+--------+--------+--------+ 402 Type=45 Length=11 MP_OPT=1 404 The MP_JOIN option is used to add a new path to an existing MP-DCCP 405 flow. The Path Token is the SHA-1 HASH of the derived key (d-key), 406 which was previously exchanged with the MP_KEY option. MP_HMAC MUST 407 be set when using MP_JOIN to provide authentication (See MP_HMAC for 408 details). Also MP_KEY must be set to provide key material for 409 authentication purposes. 411 3.2.3. MP_FAST_CLOSE 413 +--------+--------+--------+ 414 |00101101|00000011|00000010| 415 +--------+--------+--------+ 416 Type=45 Length=3 MP_OPT=2 418 MP_FAST_CLOSE terminates the MP-DCCP flow and all corresponding 419 subflows. 421 3.2.4. MP_KEY 423 +--------+--------+--------+--------+--------+--------+--------+ 424 |00101101| Length |00000011|Key Type| Key Data 425 +--------+--------+--------+--------+--------+--------+--------+ 426 Type=45 MP_OPT=3 428 The MP_KEY suboption is used to exchange key material between hosts. 429 The Key Type field is used to specify the key type. Key types are 430 shown in table Figure 6. 432 Option 433 Key Type Key Length Meaning 434 ---- ------ ----- 435 0 =Plain Text 8 Plain Text Key 436 1 =ECDHE-C25519-SHA256 32 ECDHE with SHA256 and Curve25519 437 2 =ECDHE-C25519-SHA512 32 ECDHE with SHA512 and Curve25519 438 3-255 Reserved 440 Figure 6: MP_KEY Key Types 442 Plain Text 443 Key Material is exchanged in plain text between hosts and the key 444 parts (key-a, key-b) are concatenated to form the derived key 445 (d-key). 447 ECDHE-SHA256-C25519 448 Key Material is exchanged via ECDHE key exchange with SHA256 and 449 Curve 25519 to generate the derived key (d-key). 451 ECDHE-SHA512-C25519 452 Key Material is exchanged via ECDHE key exchange with SHA512 and 453 Curve 25519 to generate the derived key (d-key). 455 3.2.5. MP_SEQ 457 +--------+--------+--------+--------+--------+--------+--------+ 458 |00101101|00000111|00000100| Multipath Sequence Number | 459 +--------+--------+--------+--------+--------+--------+--------+ 460 Type=45 Length=7 MP_OPT=4 462 The MP_SEQ option is used for end-to-end datagram-based sequence 463 numbers of an MP-DCCP connection. The initial data sequence number 464 (IDSN) SHOULD be set randomly. 466 3.2.6. MP_HMAC 468 +--------+--------+--------+--------+--------+--------+ 469 |00101101|00000111|00000101| HMAC-SHA1 (20 bytes) ... 470 +--------+--------+--------+--------+--------+--------+ 471 Type=45 Length=23 MP_OPT=5 473 The MP_HMAC option is used to provide authentication for the MP_JOIN 474 option. The HMAC is built using the derived key (d-key) calculated 475 previously from the handshake key material exchanged with the MP_KEY 476 option. The Message for the HMAC is the header of the MP_JOIN for 477 which authentication shall be performed. By including a nonce in 478 these datagrams, possible replay-attacks are remedied. t 480 3.2.7. MP_RTT 482 +--------+--------+--------+--------+--------+--------+--------+ 483 |00101101|00000111|00000110|RTT Type| RTT 484 +--------+--------+--------+--------+--------+--------+--------+ 485 | | Age | 486 +--------+--------+--------+--------+--------+ 487 Type=45 Length=12 MP_OPT=6 489 The MP_RTT option is used to transmit RTT values in milliseconds. 490 Additionally, the age of the measurement is specified in 491 milliseconds. 493 Raw RTT (=0) 494 Raw RTT value of the last Datagram Round-Trip. The Age parameter 495 is set to the age of when the Ack for the datagram was received. 497 Min RTT (=1) 498 Min RTT value. The period for computing the Minimum can be 499 specified by the Age parameter. 501 Max RTT (=2) 502 Max RTT value. The period for computing the Maximum can be 503 specified by the Age parameter. 505 Smooth RTT (=3) 506 Averaged RTT value. The period for computing the Minimum can be 507 specified by the Age parameter. 509 3.2.8. MP_ADDADDR 511 [TBD] 513 3.2.9. MP_REMOVEADDR 515 [TBD] 517 3.2.10. MP_PRIO 519 [TBD] 521 3.3. MP-DCCP Handshaking Procedure 523 Host A Host B 524 ------------------------ ---------- 525 Address A1 Address A2 Address B1 526 ---------- ---------- ---------- 527 | | | 528 | DCCP-Request + MP_CAPABLE | 529 |------- MP_KEY(Key-A) ------------------------------>| 530 |<---------------------- MP_KEY(Key-B) ---------------| 531 | DCCP-Response + MP_CAPABLE agreed | 532 | | | 533 | DCCP-Ack | | 534 |--------- MP_KEY(Key-A) + MP_KEY(Key-B) ------------>| 535 | | | 536 | |DCCP-Request + MP_CAPABLE | 537 | |--- MP_JOIN(TB,RA) ------------------->| 538 | |<------MP_JOIN(TB,RB) + MP_HMAC(A)-----| 539 | |DCCP-Response | 540 | | | 541 | |DCCP-Ack | 542 | |-------- MP_HMAC(B) ------------------>| 543 | |<--------------------------------------| 544 | |DCCP-ACK | 546 Figure 7: Example MP-DCCP Handshake 548 The basic initial handshake for the first flow is as follows: 550 o Host A sends a DCCP-Request with the MP-Capable feature Change 551 request and the MP_KEY option with Host-specific Key-A 553 o Host B sends a DCCP-Response with Confirm feature for MP-Capable 554 and the MP_Key option with Host-specific Key-B 556 o Host A sends a DCCP-Ack with both Keys echoed to Host B 558 The handshake for subsequent flows based on a successful initial 559 handshake is as follows: 561 o Host A sends a DCCP-Request with the MP-Capable feature Change 562 request and the MP_JOIN option with Token TB, derived from the 563 derived key by applying a SHA-1 hash and truncating to the first 564 32 bits. Additionally, a random nonce RA is transmitted with the 565 MP_JOIN. 567 o Host B computes the HMAC of the DCCP-Request and sends a DCCP- 568 Response with Confirm feature option for MP-Capable and the 569 MP_JOIN option with the Token TB and a random nonce RB together 570 with the computed MP_HMAC. 572 o Host A sends a DCCP-Ack with the HMAC computed for the DCCP- 573 Response. 575 o Host B sends a DCCP-Ack confirm the HMAC and to conclude the 576 handshaking. 578 4. Security Considerations 580 [Tbd] 582 5. Interactions with Middleboxes 584 [Tbd], should mention standardized technologies like [RFC5597] or 585 [RFC6773] and U-DCCP [I-D.amend-tsvwg-dccp-udp-header-conversion] 587 6. Acknowledgments 589 1. Notes 591 This document is inspired by Multipath TCP [RFC6824] and some text 592 passages for the -00 version of the draft are copied almost 593 unmodified. 595 7. IANA Considerations 597 [Tbd], must include options for: 599 o handshaking procedure to indicate MP support 601 o handshaking procedure to indicate JOINING of an existing MP 602 connection 604 o signaling of new or changed addresses 606 o setting handover or aggregation mode 608 o setting reordering on/off 610 should include options carrying: 612 o overall sequence number for restoring purposes 614 o sender time measurements for restoring purposes 616 o scheduler preferences 618 o reordering preferences 620 8. Informative References 622 [I-D.amend-tsvwg-dccp-udp-header-conversion] 623 Amend, M., Brunstrom, A., Kassler, A., and V. Rakocevic, 624 "Lossless and overhead free DCCP - UDP header conversion 625 (U-DCCP)", draft-amend-tsvwg-dccp-udp-header-conversion-01 626 (work in progress), July 2019. 628 [I-D.amend-tsvwg-multipath-framework-mpdccp] 629 Amend, M., Bogenfeld, E., Brunstrom, A., Kassler, A., and 630 V. Rakocevic, "A multipath framework for UDP traffic over 631 heterogeneous access networks", draft-amend-tsvwg- 632 multipath-framework-mpdccp-01 (work in progress), July 633 2019. 635 [I-D.lhwxz-hybrid-access-network-architecture] 636 Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M. 637 Zhang, "Hybrid Access Network Architecture", draft-lhwxz- 638 hybrid-access-network-architecture-02 (work in progress), 639 January 2015. 641 [I-D.muley-network-based-bonding-hybrid-access] 642 Muley, P., Henderickx, W., Geng, L., Liu, H., Cardullo, 643 L., Newton, J., Seo, S., Draznin, S., and B. Patil, 644 "Network based Bonding solution for Hybrid Access", draft- 645 muley-network-based-bonding-hybrid-access-03 (work in 646 progress), October 2018. 648 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 649 RFC 793, DOI 10.17487/RFC0793, September 1981, 650 . 652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 653 Requirement Levels", BCP 14, RFC 2119, 654 DOI 10.17487/RFC2119, March 1997, 655 . 657 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 658 Congestion Control Protocol (DCCP)", RFC 4340, 659 DOI 10.17487/RFC4340, March 2006, 660 . 662 [RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) 663 Behavioral Requirements for the Datagram Congestion 664 Control Protocol", BCP 150, RFC 5597, 665 DOI 10.17487/RFC5597, September 2009, 666 . 668 [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A 669 Datagram Congestion Control Protocol UDP Encapsulation for 670 NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 671 2012, . 673 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 674 "TCP Extensions for Multipath Operation with Multiple 675 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 676 . 678 [TR23.793] 679 3GPP, "Study on access traffic steering, switch and 680 splitting support in the 5G System (5GS) architecture", 681 December 2018. 683 Authors' Addresses 684 Markus Amend 685 Deutsche Telekom 686 T-Online-Allee 1 687 64295 Darmstadt 688 Germany 690 Email: Markus.Amend@telekom.de 692 Eckard Bogenfeld 693 Deutsche Telekom 694 T-Online-Allee 1 695 64295 Darmstadt 696 Germany 698 Email: Eckard.Bogenfeld@telekom.de 700 Anna Brunstrom 701 Karlstad University 702 Universitetsgatan 2 703 651 88 Karlstad 704 Sweden 706 Email: anna.brunstrom@kau.se 708 Andreas Kassler 709 Karlstad University 710 Universitetsgatan 2 711 651 88 Karlstad 712 Sweden 714 Email: andreas.kassler@kau.se 716 Veselin Rakocevic 717 City University of London 718 Northampton Square 719 London 720 United Kingdom 722 Email: veselin.rakocevic.1@city.ac.uk