DCCP Extensions for Multipath Operation with Multiple Addresses

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 19 August 2022.¶

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Multipath DCCP (MP-DCCP) is a set of extensions to regular DCCP [RFC4340], i.e., the Datagram Congestion Control Protocol denoting a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. A multipath extension to DCCP enables the transport of user data across multiple paths simultaneously. This is beneficial to applications that transfer fairly large amounts of data, due to the possibility to aggregate capacity of the multiple paths. In addition, it enables to tradeoff timeliness and reliability, which is important for low latency applications that do not require guaranteed delivery services such as Audio/Video streaming. DCCP multipath operation is suggested in the context of ongoing 3GPP work on 5G multi-access solutions [I-D.amend-tsvwg-multipath-framework-mpdccp] and for hybrid access networks [I-D.lhwxz-hybrid-access-network-architecture][I-D.muley-network-based-bonding-hybrid-access]. It can be applied for load-balancing, seamless session handover, and aggregation purposes (referred to as ATSSS; Access steering, switching, and splitting in 3GPP terminology [TS23.501]).¶

This document presents the protocol changes required to add multipath capability to DCCP; specifically, those for signaling and setting up multiple paths ("subflows"), managing these subflows, reordering of data, and termination of sessions. DCCP, as stated in [RFC4340] does not provide reliable and ordered delivery. Consequently, multiple application subflows may be multiplexed over a single DCCP connection with no inherent performance penalty for flows that do not require in-ordered delivery. DCCP does not provide built-in support for those multiple application subflows.¶

In the following, use of the term subflow will refer to physical separate DCCP subflows transmitted via different paths, but not to application subflows. Application subflows are differing content-wise by source and destination port per application as, for example, enabled by Service Codes introduced to DCCP in [RFC5595], and those subflows can be multiplexed over a single DCCP connection. For sake of consistency we assume that only a single application is served by a DCCP connection here as shown in Figure 1 while use of that feature should not impact DCCP operation on each single path as noted in ([RFC5595], sect. 2.4).¶

                             +-------------------------------+
                             |           Application         |
+---------------+            +-------------------------------+
|  Application  |            |            MP-DCCP            |
+---------------+            + - - - - - - - + - - - - - - - +
|      DCCP     |            |Subflow (DCCP) |Subflow (DCCP) |
+---------------+            +-------------------------------+
|      IP       |            |       IP      |      IP       |
+---------------+            +-------------------------------+

           Host A                               Host B
------------------------             ------------------------
Address A1    Address A2             Address B1    Address B2
----------    ----------             ----------    ----------
  |             |                      |             |
  |         (DCCP flow setup)          |             |
  |----------------------------------->|             |
  |<-----------------------------------|             |
  |             |                      |             |
  |             |  (DCCP flow setup)   |             |
  |             |--------------------->|             |
  |             |<---------------------|             |
  | merge individual DCCP flows to one multipath connection
  |             |                      |             |

2. Operation Overview

DCCP according to RFC 4340 [RFC4340] allows multiple application subflows to be multiplexed over a single DCCP connection with potentially same performance. However, DCCP does not provide built-in support for multiple subflows and the Congestion Manager (CM) [RFC3124], as a generic multiplexing facility, can not fully support multiple congestion control mechanisms for multiple DCCP flows between same source and destination addresses.¶

The proposed extension of DCCP towards Multipath-DCCP (MP-DCCP) is described in detail in Section 3.¶

As a high level overview on the key functionality of MP-DCCP, the data stream from a DCCP application is split by MP-DCCP operation into one or more subflows which can be transmitted via different also physically isolated paths. The corresponding control information allows the receiver to optionally re-assemble and deliver the received data in the right order to the recipient application. The details of the transmission scheduling mechanism and optional reordering mechanism are up to the sender and receiver, respectively, and are outside the scope of the MP-DCCP protocol. The following sections define MP-DCCP behavior in detail.¶

The Multipath Capability for MP-DCCP can be negotiated with a new DCCP feature, as described and fully specified in Section 3. Once negotiated, all subsequent MP-DCCP operations are signalled with a variable length multipath-related option, as described in Section 3.1.¶

A Multipath DCCP connection provides a bidirectional byte-stream between two hosts exchanging data as in standard DCCP manner thus not requiring any change to the applications. However, Multipath DCCP enables the hosts to use different paths with different IP addresses to transport the packets of the MP-DCCP connection. MP-DCCP manages the request, set-up, authentication, prioritization, modification, and removal of the DCCP subflows on different paths as well as exchange of performance parameters. The number of concurrent DCCP subflows can vary during the lifetime of the Multipath DCCP connection. All MP-DCCP operations are signaled with MP-DCCP options described in detail in {#MP_OPT}.¶

3. MP-DCCP Protocol

The DCCP protocol feature list ([RFC4340] section 6.4) will be enhanced by a new Multipath related feature with Feature number 10, as shown in Table 3.¶

Rec'n Rule:

The reconciliation rule used for the feature. SP means server-priority, NN means non-negotiable.¶

Initial Value:

The initial value for the feature. Every feature has a known initial value.¶

Req'd:

This column is "Y" if and only if every DCCP implementation MUST understand the feature. If it is "N", then the feature behaves like an extension (see Section 15), and it is safe to respond to Change options for the feature with empty Confirm options. Of course, a CCID might require the feature; a DCCP that implements CCID 2 MUST support Ack Ratio and Send Ack Vector, for example.¶

The DCCP protocol options as defined in ([RFC4340] section 5.8) and ([RFC5634] section 2.2.1) will be enhanced by a new Multipath related variable-length option with option type 46, as shown in Table 4.¶

    0  1  2  3   4  5  6  7
   +------------------------+
   |  Version  |  Reserved  |
   +------------------------+
    '0000'->v0
    '0001'->v1
    ........

      Client                                             Server
      ------                                             ------
      DCCP-Req + Change R(CAPABLE, 1 0)
                     ----------------------------------->

                      DCCP-Resp + Confirm L(CAPABLE, 1, 2 1 0)
            <-----------------------------------

                 * agreement on version = 1 *

+--------+--------+--------+--------+--------
|00101110| Length | MP_OPT | Value(s) ...
+--------+--------+--------+--------+--------
 Type=46

  +--------+--------+--------+--------+--------+--------+--------+
  |00101110| Length |00000000| List of options ...
  +--------+--------+--------+--------+--------+--------+--------+
   Type=46           MP_OPT=0

  +--------+--------+--------+--------+
  |00101110|00001011|00000001| Addr ID|
  +--------+--------+--------+--------+
  | Path Token                        |
  +--------+--------+--------+--------+
  | Nonce                             |
  +--------+--------+--------+--------+
   Type=46  Length=12 MP_OPT=1

  +--------+--------+--------+
  |00101110|00000011|00000010|
  +--------+--------+--------+
   Type=46  Length=3 MP_OPT=2

  +--------+--------+--------+-----------+-------------+
  |00101110| Length |00000011|Key Type(1)| Key Data(1) | ->
  +--------+--------+--------+-----------+-------------+
   Type=46           MP_OPT=3

                             +-----------+-------------+-----
                          -> |Key Type(2)| Key Data(2) | ....
                             +-----------+-------------+-----

  +--------+--------+--------+--------+--------+--------+--------+
  |00101110|00000111|00000100| Multipath Sequence Number         |
  +--------+--------+--------+--------+--------+--------+--------+
   Type=46  Length=7 MP_OPT=4

  +--------+--------+--------+--------+--------+--------+
  |00101110|00001011|00000101| HMAC-SHA256 (20 bytes) ...
  +--------+--------+--------+--------+--------+--------+
   Type=46  Length=23 MP_OPT=5

  +--------+--------+--------+--------+--------+--------+--------+
  |00101110|00001100|00000110|RTT Type| RTT
  +--------+--------+--------+--------+--------+--------+--------+
  |        | Age                               |
  +--------+--------+--------+--------+--------+
   Type=46  Length=12 MP_OPT=6

                      1                   2                   3
  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
  +---------------+---------------+-------+-------+---------------+
  |     Type      |     Length    |Subtype| IPVer |  Address ID   |
  +---------------+---------------+-------+-------+---------------+
  |          Address (IPv4 - 4 bytes / IPv6 - 16 bytes)           |
  +-------------------------------+-------------------------------+
  |   Port (2 bytes, optional)    |                               |
  +-------------------------------+                               |
  |                       HMAC (20 bytes)                         |
  |                                                               |
  |                                                               |
  |                                                               |
  |                                                               |
  |                               +-------------------------------+
  |                               |
  +-------------------------------+

                     1                   2                   3
 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
+---------------+---------------+-------+-------+---------------+
|     Type      |  Length = 3+n |Subtype|(resvd)|   Address ID  |...
+---------------+---------------+-------+-------+---------------+
                          (followed by n-1 Address IDs, if required)

                        1                   2                   3
    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
   +---------------+---------------+-------+-------+--------------+
   |     Type      |     Length    |Subtype| Prio  | AddrID       |
   +---------------+---------------+-------+-------+--------------+

          Host A                                         Host B
------------------------                              ----------
Address A1    Address A2                              Address B1
----------    ----------                              ----------
     |             |                                       |
     |             DCCP-Request + MP_CAPABLE               |
     |------- MP_KEY(Key-A(1), Key-A(2),...) ------------->|
     |<---------------------- MP_KEY(Key-B) ---------------|
     |             DCCP-Response +  MP_CAPABLE             |
     |             |                                       |
     |   DCCP-Ack  |                                       |
     |--------- MP_KEY(Key-A) + MP_KEY(Key-B) ------------>|
     |<----------------------------------------------------|
     |   DCCP-Ack  |                                       |
     |             |                                       |
     |             |          DCCP-Request + MP_CAPABLE    |
     |             |--- MP_JOIN(TB,RA) ------------------->|
     |             |<------MP_JOIN(TB,RB) + MP_HMAC(A)-----|
     |             |DCCP-Response  + MP_CAPABLE            |
     |             |                                       |
     |             |DCCP-Ack                               |
     |             |-------- MP_HMAC(B) ------------------>|
     |             |<--------------------------------------|
     |             |DCCP-ACK                               |

4. Security Considerations

Similar to DCCP, MP-DCCP does not provide cryptographic security guarantees inherently. Thus, if applications need cryptographic security (integrity, authentication, confidentiality, access control, and anti-replay protection) the use of IPsec or some other kind of end-to-end security is recommended; Secure Real-time Transport Protocol (SRTP) [RFC3711] is one candidate protocol for authentication. Together with Encryption of Header Extensions in SRTP, as provided by [RFC6904], also integrity would be provided.¶

As described in [RFC4340], DCCP provides protection against hijacking and limits the potential impact of some denial-of-service attacks, but DCCP provides no inherent protection against attackers' snooping on data packets. Regarding the security of MP-DCCP no additional risks should be introduced compared to regular DCCP of today. Thereof derived are the following key security requirements to be fulfilled by MP-DCCP:¶

• Provide a mechanism to confirm that parties involved in a subflow handshake are identical to those in the original connection setup.¶
• Provide verification that the new address to be included in a MP connection is valid for a peer to receive traffic at before using it.¶
• Provide replay protection, i.e., ensure that a request to add/remove a subflow is 'fresh'.¶

In order to achieve these goals, MP-DCCP includes a hash-based handshake algorithm documented in Sections Section 3.2.4 and Section 3.3. The security of the MP-DCCP connection depends on the use of keys that are shared once at the start of the first subflow and are never sent again over the network. To ease demultiplexing while not giving away any cryptographic material, future subflows use a truncated cryptographic hash of this key as the connection identification "token". The keys are concatenated and used as keys for creating Hash-based Message Authentication Codes (HMACs) used on subflow setup, in order to verify that the parties in the handshake are the same as in the original connection setup. It also provides verification that the peer can receive traffic at this new address. Replay attacks would still be possible when only keys are used; therefore, the handshakes use single-use random numbers (nonces) at both ends -- this ensures that the HMAC will never be the same on two handshakes. Guidance on generating random numbers suitable for use as keys is given in [RFC4086]. During normal operation, regular DCCP protection mechanisms (such as header checksum to protect DCCP headers against corruption) will provide the same level of protection against attacks on individual DCCP subflows as exists for regular DCCP today.¶

5. Interactions with Middleboxes

Issues from interaction with on-path middleboxes such as NATs, firewalls, proxies, intrusion detection systems (IDSs), and others have to be considered for all extensions to standard protocols since otherwise unexpected reactions of middleboxes may hinder its deployment. DCCP already provides means to mitigate the potential impact of middleboxes, also in comparison to TCP (see [RFC4043], sect. 16). In case, however, both hosts are located behind a NAT or firewall entity, specific measures have to be applied such as the [RFC5596]-specified simultaneous-open technique that update the (traditionally asymmetric) connection-establishment procedures for DCCP. Further standardized technologies addressing NAT type middleboxes are covered by [RFC5597].¶

[RFC6773] specifies UDP Encapsulation for NAT Traversal of DCCP sessions, similar to other UDP encapsulations such as for SCTP [RFC6951]. The alternative U-DCCP approach proposed in [I-D.amend-tsvwg-dccp-udp-header-conversion] would reduce tunneling overhead. The handshaking procedure for DCCP-UDP header conversion or use of a DCCP-UDP negotiation procedure to signal support for DCCP-UDP header conversion would require encapsulation during the handshakes and use of two additional port numbers out of the UDP port number space, but would require zero overhead afterwards.¶

6. Implementation

The approach described above has been implemented in open source across different testbeds and a new scheduling algorithm has been extensively tested. Also demonstrations of a laboratory setup have been executed and have been published at [website].¶

7. Acknowledgments

Due to the great spearheading work of the Multipath TCP authors in [RFC6824]/[RFC8684], some text passages for the -00 version of the draft were copied almost unmodified.¶

The authors gratefully acknowledge significant input into this document from Dirk von Hugo.¶

8. IANA Considerations

This document defines one new value to DCCP feature list and one new DCCP Option with ten corresponding Subtypes as follows. This document defines a new DCCP feature parameter for negotiating the support of multipath capability for DCCP sessions between hosts as described in Section 3. The following entry in Table 8 should be added to the "Feature Numbers Registry" according to [RFC4340], Section 19.4. under the "DCCP Protocol" heading.¶

This document defines a new DCCP protocol option of type=46 as described in Section 3.2 together with 10 additional sub-options. The following entries in Table 9 should be added to the "DCCP Protocol options" and assigned as "MP-DCCP sub-options", respectively.¶

[Tbd], must include options for:¶

• handshaking procedure to indicate MP support¶
• handshaking procedure to indicate JOINING of an existing MP connection¶
• signaling of new or changed addresses¶
• setting handover or aggregation mode¶
• MP-specific congestion mechanisms¶

should include options carrying:¶

• overall sequence number for restoring/re-assembly/re-ordering purposes¶
• sender time measurements for restoring/re-assembly/re-ordering purposes¶

Authors' Addresses