Skip to main content

DCCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-tsvwg-multipath-dccp-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Markus Amend , Anna Brunstrom , Andreas Kassler , Veselin Rakocevic , Stephen Johnson
Last updated 2022-02-15
Replaces draft-amend-tsvwg-multipath-dccp
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Associated WG milestone
Mar 2024
Submit " DCCP Extensions for Multipath Operation with Multiple Addresses" as a Proposed Standard RFC
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-tsvwg-multipath-dccp-03
Transport Area Working Group                               M. Amend, Ed.
Internet-Draft                                                        DT
Intended status: Experimental                               A. Brunstrom
Expires: 19 August 2022                                       A. Kassler
                                                     Karlstad University
                                                            V. Rakocevic
                                               City University of London
                                                              S. Johnson
                                                                      BT
                                                        15 February 2022

    DCCP Extensions for Multipath Operation with Multiple Addresses
                   draft-ietf-tsvwg-multipath-dccp-03

Abstract

   DCCP communication is currently restricted to a single path per
   connection, yet multiple paths often exist between peers.  The
   simultaneous use of these multiple paths for a DCCP session could
   improve resource usage within the network and, thus, improve user
   experience through higher throughput and improved resilience to
   network failures.  Use cases for a Multipath DCCP (MP-DCCP) are
   mobile devices (handsets, vehicles) and residential home gateways
   simultaneously connected to distinct paths as, e.g., a cellular link
   and a WiFi link or to a mobile radio station and a fixed access
   network.  Compared to existing multipath protocols such as MPTCP, MP-
   DCCP provides specific support for non-TCP user traffic as UDP or
   plain IP.  More details on potential use cases are provided in
   [website], [slide], and [paper].  All these use cases profit from an
   Open Source Linux reference implementation provided under [website].

   This document presents a set of extensions to traditional DCCP to
   support multipath operation.  Multipath DCCP provides the ability to
   simultaneously use multiple paths between peers.  The protocol offers
   the same type of service to applications as DCCP and it provides the
   components necessary to establish and use multiple DCCP flows across
   potentially disjoint paths.

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/.

Amend, et al.            Expires 19 August 2022                 [Page 1]
Internet-Draft               Multipath DCCP                February 2022

   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Multipath DCCP in the Networking Stack  . . . . . . . . .   4
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  MP-DCCP Concept . . . . . . . . . . . . . . . . . . . . .   5
     1.4.  Differences from Multipath TCP  . . . . . . . . . . . . .   5
     1.5.  Requirements Language . . . . . . . . . . . . . . . . . .   7
   2.  Operation Overview  . . . . . . . . . . . . . . . . . . . . .   8
   3.  MP-DCCP Protocol  . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Multipath Capable Feature . . . . . . . . . . . . . . . .  12
     3.2.  Multipath Option  . . . . . . . . . . . . . . . . . . . .  13
       3.2.1.  MP_CONFIRM  . . . . . . . . . . . . . . . . . . . . .  14
       3.2.2.  MP_JOIN . . . . . . . . . . . . . . . . . . . . . . .  15
       3.2.3.  MP_FAST_CLOSE . . . . . . . . . . . . . . . . . . . .  16
       3.2.4.  MP_KEY  . . . . . . . . . . . . . . . . . . . . . . .  16
       3.2.5.  MP_SEQ  . . . . . . . . . . . . . . . . . . . . . . .  17
       3.2.6.  MP_HMAC . . . . . . . . . . . . . . . . . . . . . . .  17
       3.2.7.  MP_RTT  . . . . . . . . . . . . . . . . . . . . . . .  18
       3.2.8.  MP_ADDADDR  . . . . . . . . . . . . . . . . . . . . .  18
       3.2.9.  MP_REMOVEADDR . . . . . . . . . . . . . . . . . . . .  20
       3.2.10. MP_PRIO . . . . . . . . . . . . . . . . . . . . . . .  21
     3.3.  MP-DCCP Handshaking Procedure . . . . . . . . . . . . . .  22
     3.4.  Fallback  . . . . . . . . . . . . . . . . . . . . . . . .  24
     3.5.  Congestion Control Considerations . . . . . . . . . . . .  24
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  24
   5.  Interactions with Middleboxes . . . . . . . . . . . . . . . .  26

Amend, et al.            Expires 19 August 2022                 [Page 2]
Internet-Draft               Multipath DCCP                February 2022

   6.  Implementation  . . . . . . . . . . . . . . . . . . . . . . .  26
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  26
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  29
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32

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-net
   work-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).

Amend, et al.            Expires 19 August 2022                 [Page 3]
Internet-Draft               Multipath DCCP                February 2022

1.1.  Multipath DCCP in the Networking Stack

   MP-DCCP operates at the transport layer and aims to be transparent to
   both higher and lower layers.  It is a set of additional features on
   top of standard DCCP; Figure 1 illustrates this layering.  MP-DCCP is
   designed to be used by applications in the same way as DCCP with no
   changes to the application itself.

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

     Figure 1: Comparison of Standard DCCP and MP-DCCP Protocol Stacks

1.2.  Terminology

   Throughout this document we make use of terms that are either
   specific for multipath transport or are defined in the context of MP-
   DCCP, similar to [RFC8684], as follows:

   Path: A sequence of links between a sender and a receiver, defined in
   this context by a 4-tuple of source and destination address/ port
   pairs.

   Subflow: A flow of DCCP segments operating over an individual path,
   which forms part of a larger MP-DCCP connection.  A subflow is
   started and terminated similar to a regular (single-path) DCCP
   connection.

   (MP-DCCP) Connection: A set of one or more subflows, over which an
   application can communicate between two hosts.  There is a one-to-one
   mapping between a connection and an application socket.

   Token: A locally unique identifier given to a multipath connection by
   a host.  May also be referred to as a "Connection ID".

   Host: An end host operating an MP-DCCP implementation, and either
   initiating or accepting an MP-DCCP connection.  In addition to these
   terms, within framework of MP-DCCP the interpretation of, and effect
   on, regular single-path DCCP semantics is discussed in Section 3.

Amend, et al.            Expires 19 August 2022                 [Page 4]
Internet-Draft               Multipath DCCP                February 2022

1.3.  MP-DCCP Concept

              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
     |             |                      |             |

                  Figure 2: Example MP-DCCP Usage Scenario

1.4.  Differences from Multipath TCP

   Multipath DCCP is similar to Multipath TCP [RFC8684], in that it
   extends the related basic DCCP transport protocol [RFC4340] with
   multipath capabilities in the same way as Multipath TCP extends TCP
   [RFC0793].  However, because of the differences between the
   underlying TCP and DCCP protocols, the transport characteristics of
   MPTCP and MP-DCCP are different.

   Table 1 compares the protocol characteristics of TCP and DCCP, which
   are by nature inherited by their respective multipath extensions.  A
   major difference lies in the delivery of payload, which is for TCP an
   exact copy of the generated byte-stream.  DCCP behaves in a different
   way and does not guarantee to deliver any payload nor the order of
   delivery.  Since this is mainly affecting the receiving endpoint of a
   TCP or DCCP communication, many similarities on the sender side can
   be identified.  Both transport protocols share the 3-way initiation
   of a communication and both employ congestion control to adapt the
   sending rate to the path characteristics.

Amend, et al.            Expires 19 August 2022                 [Page 5]
Internet-Draft               Multipath DCCP                February 2022

    +=======================+=================+======================+
    |        Feature        |       TCP       |         DCCP         |
    +=======================+=================+======================+
    |      Full-Duplex      |       yes       |         yes          |
    +-----------------------+-----------------+----------------------+
    |  Connection-Oriented  |       yes       |         yes          |
    +-----------------------+-----------------+----------------------+
    |  Header option space  |     40 bytes    | < 1008 bytes or PMTU |
    +-----------------------+-----------------+----------------------+
    |     Data transfer     |     reliable    |      unreliable      |
    +-----------------------+-----------------+----------------------+
    |  Packet-loss handling | re-transmission |     report only      |
    +-----------------------+-----------------+----------------------+
    | Ordered data delivery |       yes       |          no          |
    +-----------------------+-----------------+----------------------+
    |    Sequence numbers   |   one per byte  |     one per PDU      |
    +-----------------------+-----------------+----------------------+
    |      Flow control     |       yes       |          no          |
    +-----------------------+-----------------+----------------------+
    |   Congestion control  |       yes       |         yes          |
    +-----------------------+-----------------+----------------------+
    |      ECN support      |       yes       |         yes          |
    +-----------------------+-----------------+----------------------+
    |     Selective ACK     |       yes       |      depends on      |
    |                       |                 |  congestion control  |
    +-----------------------+-----------------+----------------------+
    |      Fix message      |        no       |         yes          |
    |       boundaries      |                 |                      |
    +-----------------------+-----------------+----------------------+
    |   Path MTU discovery  |       yes       |         yes          |
    +-----------------------+-----------------+----------------------+
    |     Fragmentation     |       yes       |          no          |
    +-----------------------+-----------------+----------------------+
    |  SYN flood protection |       yes       |          no          |
    +-----------------------+-----------------+----------------------+
    | Half-open connections |       yes       |          no          |
    +-----------------------+-----------------+----------------------+

                Table 1: TCP and DCCP protocol comparison

   Consequently, the multipath features, shown in Table 2, are the same,
   supporting volatile paths having varying capacity and latency,
   session handover and path aggregation capabilities.  All of them
   profit by the existence of congestion control.

Amend, et al.            Expires 19 August 2022                 [Page 6]
Internet-Draft               Multipath DCCP                February 2022

          +==================+=======================+==========+
          |     Feature      |         MPTCP         | MP-DCCP  |
          +==================+=======================+==========+
          |  Volatile paths  |          yes          |   yes    |
          +------------------+-----------------------+----------+
          | Session handover |          yes          |   yes    |
          +------------------+-----------------------+----------+
          | Path aggregation |          yes          |   yes    |
          +------------------+-----------------------+----------+
          | Data reordering  |          yes          | optional |
          +------------------+-----------------------+----------+
          |  Expandability   | limited by TCP header | flexible |
          +------------------+-----------------------+----------+

               Table 2: MPTCP and MP-DCCP protocol comparison

   Therefore, the sender logic is not much different between MP-DCCP and
   MPTCP.

   The receiver side for MP-DCCP has to deal with the unreliable
   transport character of DCCP.  The multipath sequence numbers included
   in MP-DCCP (see Section 3.2.5) facilitates adding optional mechanisms
   for data stream packet reordering at the receiver.  Information from
   the MP_RTT multipath option (Section 3.2.7), DCCP path sequencing and
   the DCCP Timestamp Option provide further means for advanced
   reordering approaches, e.g., as described in
   [I-D.amend-iccrg-multipath-reordering].  Such mechanisms do, however,
   not affect interoperability and are not part of the MP-DCCP protocol.
   Many applications that use unreliable transport protocols can also
   inherently deal with out-of-sequence data (e.g., through adaptive
   audio and video buffers), and so additional reordering support may
   not be necessary.  The addition of optional reordering mechanisms are
   most likely to be needed when the different DCCP subflows are routed
   across paths with different latencies.  In theory, applications using
   DCCP are aware that packet reordering might happen, since DCCP has no
   mechanisms to prevent it.

   The receiving process for MPTCP is on the other hand a rigid "just
   wait" approach, since TCP guarantees reliable delivery.

1.5.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Amend, et al.            Expires 19 August 2022                 [Page 7]
Internet-Draft               Multipath DCCP                February 2022

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.

Amend, et al.            Expires 19 August 2022                 [Page 8]
Internet-Draft               Multipath DCCP                February 2022

   +=========+===================+======+=============+===============+
   |  Number | Meaning           | Rule | Rec'n Value | Initial Req'd |
   +=========+===================+======+=============+===============+
   |    0    | Reserved          |      |             |               |
   +---------+-------------------+------+-------------+---------------+
   |    1    | Congestion        |  SP  |      2      |       Y       |
   |         | Control ID (CCID) |      |             |               |
   +---------+-------------------+------+-------------+---------------+
   |    2    | Allow Short       |  SP  |      0      |       Y       |
   |         | Seqnos            |      |             |               |
   +---------+-------------------+------+-------------+---------------+
   |    3    | Sequence Window   |  NN  |     100     |       Y       |
   +---------+-------------------+------+-------------+---------------+
   |    4    | ECN Incapable     |  SP  |      0      |       N       |
   +---------+-------------------+------+-------------+---------------+
   |    5    | Ack Ratio         |  NN  |      2      |       N       |
   +---------+-------------------+------+-------------+---------------+
   |    6    | Send Ack Vector   |  SP  |      0      |       N       |
   +---------+-------------------+------+-------------+---------------+
   |    7    | Send NDP Count    |  SP  |      0      |       N       |
   +---------+-------------------+------+-------------+---------------+
   |    8    | Minimum Checksum  |  SP  |      0      |       N       |
   |         | Coverage          |      |             |               |
   +---------+-------------------+------+-------------+---------------+
   |    9    | Check Data        |  SP  |      0      |       N       |
   |         | Checksum          |      |             |               |
   +---------+-------------------+------+-------------+---------------+
   |    10   | Multipath Capable |  SP  |      0      |       N       |
   +---------+-------------------+------+-------------+---------------+
   |  11-127 | Reserved          |      |             |               |
   +---------+-------------------+------+-------------+---------------+
   | 128-255 | CCID-specific     |      |             |               |
   |         | features          |      |             |               |
   +---------+-------------------+------+-------------+---------------+

                      Table 3: Proposed Feature Set

   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

Amend, et al.            Expires 19 August 2022                 [Page 9]
Internet-Draft               Multipath DCCP                February 2022

      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.

Amend, et al.            Expires 19 August 2022                [Page 10]
Internet-Draft               Multipath DCCP                February 2022

     +=========+===============+=======================+============+
     |   Type  | Option Length |        Meaning        | DCCP-Data? |
     +=========+===============+=======================+============+
     |    0    |       1       |        Padding        |     Y      |
     +---------+---------------+-----------------------+------------+
     |    1    |       1       |       Mandatory       |     N      |
     +---------+---------------+-----------------------+------------+
     |    2    |       1       |     Slow Receiver     |     Y      |
     +---------+---------------+-----------------------+------------+
     |   3-31  |       1       |        Reserved       |            |
     +---------+---------------+-----------------------+------------+
     |    32   |    variable   |        Change L       |     N      |
     +---------+---------------+-----------------------+------------+
     |    33   |    variable   |       Confirm L       |     N      |
     +---------+---------------+-----------------------+------------+
     |    34   |    variable   |        Change R       |     N      |
     +---------+---------------+-----------------------+------------+
     |    35   |    variable   |       Confirm R       |     N      |
     +---------+---------------+-----------------------+------------+
     |    36   |    variable   |      Init Cookie      |     N      |
     +---------+---------------+-----------------------+------------+
     |    37   |      3-8      |       NDP Count       |     Y      |
     +---------+---------------+-----------------------+------------+
     |    38   |    variable   |  Ack Vector [Nonce 0] |     N      |
     +---------+---------------+-----------------------+------------+
     |    39   |    variable   |  Ack Vector [Nonce 1] |     N      |
     +---------+---------------+-----------------------+------------+
     |    40   |    variable   |      Data Dropped     |     N      |
     +---------+---------------+-----------------------+------------+
     |    41   |       6       |       Timestamp       |     Y      |
     +---------+---------------+-----------------------+------------+
     |    42   |     6/8/10    |     Timestamp Echo    |     Y      |
     +---------+---------------+-----------------------+------------+
     |    43   |      4/6      |      Elapsed Time     |     N      |
     +---------+---------------+-----------------------+------------+
     |    44   |       6       |     Data Checksum     |     Y      |
     +---------+---------------+-----------------------+------------+
     |    45   |       8       |  Quick-Start Response |     ?      |
     +---------+---------------+-----------------------+------------+
     |    46   |    variable   |       Multipath       |     Y      |
     +---------+---------------+-----------------------+------------+
     |  47-127 |    variable   |        Reserved       |            |
     +---------+---------------+-----------------------+------------+
     | 128-255 |    variable   | CCID-specific options |     -      |
     +---------+---------------+-----------------------+------------+

                       Table 4: Proposed Option Set

Amend, et al.            Expires 19 August 2022                [Page 11]
Internet-Draft               Multipath DCCP                February 2022

3.1.  Multipath Capable Feature

   DCCP endpoints are multipath-disabled by default and multipath
   capability can be negotiated with the Multipath Capable Feature.

   Multipath Capable has feature number 10 and has length of one-byte.
   The leftmost four bits are used to specify a compatible version of
   the MP-DCCP implementation (0 for this specification).  The following
   four bits are reserved for further use.

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

   Multipath Capable follows the server-priority reconciliation rule
   described in ([RFC4340] section 6.3.1), which allows multiple
   versions to be specified in order of priority.

   The negotiation MUST be done as part of the initial handshake
   procedure as described in Section 3.3, and no subsequent re-
   negotiation of the Multipath Capable feature is allowed on the same
   MP connection.

   Client MUST include a Change R option during the initial handshake
   request to supply a list of supported protocol versions, ordered by
   preference.

   Server MUST include a Confirm L option in the subsequent response to
   agree on a version to be used chosen from the Client list, followed
   by its own supported version(s) ordered by preference.

   For example:

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

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

                    * agreement on version = 1 *

Amend, et al.            Expires 19 August 2022                [Page 12]
Internet-Draft               Multipath DCCP                February 2022

   1.  Client indicates support for both versions 1 and 0, with
       preference for version 1

   2.  Server agrees on using version 1, and supply its own preference
       list.

   If no agreement can be found, the Server MUST reply with an empty
   Confirm L option with feature number 10 and no values.

   Any subflow addition to an existing MP connection MUST use the same
   version negotiated for the first flow.

3.2.  Multipath Option

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

Amend, et al.            Expires 19 August 2022                [Page 13]
Internet-Draft               Multipath DCCP                February 2022

    +======+========+================+================================+
    | Type | Option | MP_OPT         | Meaning                        |
    |      | Length |                |                                |
    +======+========+================+================================+
    | 46   | var    | 0 =MP_CONFIRM  | Confirm reception and          |
    |      |        |                | processing of an MP_OPT option |
    +------+--------+----------------+--------------------------------+
    | 46   | 12     | 1 =MP_JOIN     | Join path to an existing MP-   |
    |      |        |                | DCCP flow                      |
    +------+--------+----------------+--------------------------------+
    | 46   | 3      | 2              | Close MP-DCCP flow             |
    |      |        | =MP_FAST_CLOSE |                                |
    +------+--------+----------------+--------------------------------+
    | 46   | var    | 3 =MP_KEY      | Exchange key material for      |
    |      |        |                | MP_HMAC                        |
    +------+--------+----------------+--------------------------------+
    | 46   | 7      | 4 =MP_SEQ      | Multipath Sequence Number      |
    +------+--------+----------------+--------------------------------+
    | 46   | 23     | 5 =MP_HMAC     | HMA Code for authentication    |
    +------+--------+----------------+--------------------------------+
    | 46   | 12     | 6 =MP_RTT      | Transmit RTT values            |
    +------+--------+----------------+--------------------------------+
    | 46   | var    | 7 =MP_ADDADDR  | Advertise additional Address   |
    +------+--------+----------------+--------------------------------+
    | 46   | var    | 8              | Remove Address                 |
    |      |        | =MP_REMOVEADDR |                                |
    +------+--------+----------------+--------------------------------+
    | 46   | 4      | 9 =MP_PRIO     | Change Subflow Priority        |
    +------+--------+----------------+--------------------------------+

                        Table 5: MP_OPT Option Types

3.2.1.  MP_CONFIRM

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

   MP_CONFIRM is used to send confirmation of reception and processing
   of the multipath options that require it (see Table 6).  Such options
   will be retransmitted by the sender until this receives the
   corresponding MP_CONFIRM.  The length and sending path of the
   MP_CONFIRM are dependent on the confirmed options, which will be
   copied verbatim and appended as list of options.

Amend, et al.            Expires 19 August 2022                [Page 14]
Internet-Draft               Multipath DCCP                February 2022

   +======+===============+==================+=========================+
   | Type | Option Length | MP_OPT           | MP_CONFIRM Sending path |
   +======+===============+==================+=========================+
   | 46   | var           | 7 =MP_ADDADDR    | Any available           |
   +------+---------------+------------------+-------------------------+
   | 46   | var           | 8                | Any available           |
   |      |               | =MP_REMOVEADDR   |                         |
   +------+---------------+------------------+-------------------------+
   | 46   | 4             | 9 =MP_PRIO       | Any available           |
   +------+---------------+------------------+-------------------------+

             Table 6: Multipath options requiring confirmation

3.2.2.  MP_JOIN

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

   The MP_JOIN option is used to add a new path to an existing MP-DCCP
   flow.  The Path Token is the SHA256 hash of the derived key (d-key),
   which was previously exchanged with the MP_KEY option.  MP_HMAC MUST
   be set when using MP_JOIN to provide authentication (See MP_HMAC for
   details).  Also MP_KEY MUST be set to provide key material for
   authentication purposes.

   The Address IDs of the subflow used in the initial DCCP Request/
   Response exchange of the first subflow in the connection are
   implicit, and have the value zero.  A host MUST store the mappings
   between Address IDs and addresses both for itself and the remote
   host.  An implementation will also need to know which local and
   remote Address IDs are associated with which established subflows,
   for when addresses are removed from a local or remote host.  An
   Address ID has always to be unique over the lifetime of a subflow and
   can only be re-assigned if sender and receiver no longer have them in
   use.

   The Nonce is a 32-bit random value locally generated for every
   MP_JOIN option.  Together with the Token, the Nonce value builds the
   basis to calculate the HMAC used in the handshaking process as
   described in Section 3.3.

Amend, et al.            Expires 19 August 2022                [Page 15]
Internet-Draft               Multipath DCCP                February 2022

3.2.3.  MP_FAST_CLOSE

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

   MP_FAST_CLOSE terminates the MP-DCCP flow and all corresponding
   subflows.

3.2.4.  MP_KEY

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

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

   The MP_KEY suboption is used to exchange key material between hosts.
   The Length varies between 12 and 68 Bytes for a single-key message,
   and up to 110 Bytes when all specified Key Types 0-2 are provided.
   The Key Type field is used to specify the type of the following key
   data.  Key types are shown in Table 7.

    +========================+====================+===================+
    | Key Type               | Key Length (Bytes) | Meaning           |
    +========================+====================+===================+
    | 0 =Plain Text          | 8                  | Plain Text Key    |
    +------------------------+--------------------+-------------------+
    | 1 =ECDHE-C25519-SHA256 | 32                 | ECDHE with SHA256 |
    |                        |                    | and Curve25519    |
    +------------------------+--------------------+-------------------+
    | 2 =ECDHE-C25519-SHA512 | 64                 | ECDHE with SHA512 |
    |                        |                    | and Curve25519    |
    +------------------------+--------------------+-------------------+
    | 3-255                  |                    | Reserved          |
    +------------------------+--------------------+-------------------+

                         Table 7: MP_KEY Key Types

   Plain Text

Amend, et al.            Expires 19 August 2022                [Page 16]
Internet-Draft               Multipath DCCP                February 2022

      Key Material is exchanged in plain text between hosts, and the key
      parts (key-a, key-b) are used by each host to generate the derived
      key (d-key) by concatenating the two parts with the local key in
      front (e.g. hostA d-key(A)=(key-a+key-b), hostB d-key(B)=(key-
      b+key-a)).

   ECDHE-SHA256-C25519
      Key Material is exchanged via ECDHE key exchange with SHA256 and
      Curve 25519 to generate the derived key (d-key).

   ECDHE-SHA512-C25519
      Key Material is exchanged via ECDHE key exchange with SHA512 and
      Curve 25519 to generate the derived key (d-key).

   Providing multiple keys is only permitted in the DCCP-Request message
   of the handshake procedure for the first flow, and allows the hosts
   to agree on a single key type to be used as described in Section 3.3

3.2.5.  MP_SEQ

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

   The MP_SEQ option is used for end-to-end datagram-based sequence
   numbers of an MP-DCCP connection.  The initial data sequence number
   (IDSN) SHOULD be set randomly.  The MP_SEQ number space is different
   from the path individual sequence number space and MUST be sent with
   any DCCP-Data and DCCP-DataACK packet.

3.2.6.  MP_HMAC

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

   The MP_HMAC option is used to provide authentication for the MP_JOIN
   option.  The HMAC code is generated according to [RFC2104] in
   combination with the SHA256 hash algorithm described in [RFC6234],
   with the output truncated to the leftmost 160 bits (20 bytes).

   The "Key" used for the HMAC computation is the derived key (d-key)
   described in Section 3.2.4, while the HMAC "Message" is a
   concatenation of the token and nonce of the MP_JOIN for which
   authentication shall be performed.

Amend, et al.            Expires 19 August 2022                [Page 17]
Internet-Draft               Multipath DCCP                February 2022

3.2.7.  MP_RTT

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

   The MP_RTT option is used to transmit RTT values in milliseconds and
   MUST belong to the path over which this information is transmitted.
   Additionally, the age of the measurement is specified in
   milliseconds.

   The RTT and Age information is a 32-bit integer, which allows to
   cover a period of approximately 1193 hours.

   Raw RTT (=0)
      Raw RTT value of the last Datagram Round-Trip.  The Age parameter
      MUST be set to 0.

   Min RTT (=1)
      Min RTT value.  The period for computing the Minimum can be
      specified by the Age parameter.

   Max RTT (=2)
      Max RTT value.  The period for computing the Maximum can be
      specified by the Age parameter.

   Smooth RTT (=3)
      Averaged RTT value.  The period for computing the smoothed RTT can
      be specified by the Age parameter.

   Age
      The Age parameter is set to a time and
      contains the periods for computing of derived
      RTT values for the Minimum (=1), Maximum (=2) as well as for the
      averaged smoothed RTT value (=3).  An Age parameter of zero MUST
      NOT be interpreted by the receiver.

3.2.8.  MP_ADDADDR

   The MP_ADDADDR option announces additional addresses (and,
   optionally, ports) on which a host can be reached.  This option can
   be used at any time during an existing DCCP connection, when the
   sender wishes to enable multiple paths and/or when additional paths
   become available.  Length is variable depending on IPv4 or IPv6 and
   whether port number is used and is in range between 28 and 42 bytes.

Amend, et al.            Expires 19 August 2022                [Page 18]
Internet-Draft               Multipath DCCP                February 2022

                         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)                         |
     |                                                               |
     |                                                               |
     |                                                               |
     |                                                               |
     |                               +-------------------------------+
     |                               |
     +-------------------------------+

   Every address has an Address ID that can be used for uniquely
   identifying the address within a connection for address removal.  The
   Address ID is also used to identify MP_JOIN options (see
   Section 3.2.2) relating to the same address, even when address
   translators are in use.  The Address ID MUST uniquely identify the
   address for the sender of the option (within the scope of the
   connection); the mechanism for allocating such IDs is implementation
   specific.

   All Address IDs learned via either MP_JOIN or ADD_ADDR SHOULD be
   stored by the receiver in a data structure that gathers all the
   Address-ID-to-address mappings for a connection (identified by a
   token pair).  In this way, there is a stored mapping between the
   Address ID, observed source address, and token pair for future
   processing of control information for a connection.

   Ideally, ADD_ADDR and REMOVE_ADDR options would be sent reliably, and
   in order, to the other end.  This would ensure that this address
   management does not unnecessarily cause an outage in the connection
   when remove/add addresses are processed in reverse order, and also to
   ensure that all possible paths are used.  Note, however, that losing
   reliability and ordering will not break the multipath connections, it
   will just reduce the opportunity to open new paths and to survive
   different patterns of path failures.

   Therefore, implementing reliability signals for these DCCP options is
   not necessary.  In order to minimize the impact of the loss of these
   options, however, it is RECOMMENDED that a sender should send these
   options on all available subflows.  If these options need to be
   received in-order, an implementation SHOULD only send one ADD_ADDR/

Amend, et al.            Expires 19 August 2022                [Page 19]
Internet-Draft               Multipath DCCP                February 2022

   REMOVE_ADDR option per RTT, to minimize the risk of misordering.  A
   host that receives an ADD_ADDR but finds a connection set up to that
   IP address and port number is unsuccessful SHOULD NOT perform further
   connection attempts to this address/port combination for this
   connection.  A sender that wants to trigger a new incoming connection
   attempt on a previously advertised address/port combination can
   therefore refresh ADD_ADDR information by sending the option again.

   [TBD/TBV]

3.2.9.  MP_REMOVEADDR

   If, during the lifetime of an MP-DCCP connection, a previously
   announced address becomes invalid (e.g., if the interface
   disappears), the affected host SHOULD announce this so that the peer
   can remove subflows related to this address.

   This is achieved through the Remove Address (REMOVE_ADDR) option
   which will remove a previously added address (or list of addresses)
   from a connection and terminate any subflows currently using that
   address.

   For security purposes, if a host receives a REMOVE_ADDR option, it
   must ensure the affected path(s) are no longer in use before it
   instigates closure.  Typical DCCP validity tests on the subflow
   (e.g., packet type specific sequence and acknowledgement number
   check) MUST also be undertaken.  An implementation can use
   indications of these test failures as part of intrusion detection or
   error logging.

   The sending and receipt of this message SHOULD trigger the sending of
   DCCP-Close and DCCP-Reset by client and server, respectively on the
   affected subflow(s) (if possible), as a courtesy to cleaning up
   middlebox state, before cleaning up any local state.

   Address removal is undertaken by ID, so as to permit the use of NATs
   and other middleboxes that rewrite source addresses.  If there is no
   address at the requested ID, the receiver will silently ignore the
   request.

                        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)

   Minimum length of this option is 4 bytes (for one address to remove).

Amend, et al.            Expires 19 August 2022                [Page 20]
Internet-Draft               Multipath DCCP                February 2022

   [TBD/TBV]

3.2.10.  MP_PRIO

   In the event that a single specific path out of the set of available
   paths shall be treated with higher priority compared to the others, a
   host may wish to signal such change in priority to the peer.  One
   reason for such behavior is due to the different costs involved in
   using different paths (e.g., WiFi is free while cellular has limit on
   volume, 5G has higher energy consumption).  Also, the priority of a
   path may be subject to dynamic changes, for example when the mobile
   runs out of battery only a single path may be preferred.  Therefore,
   the path priority should be considered as hints for the packet
   scheduler when making decisions which path to use for user plane
   traffic.

   The MP_PRIO option, shown below, can be used to set a priority flag
   for the path which is specified by the AddrID field that uniquely
   identifies the path.  The option can be sent over any path.

                           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       |
      +---------------+---------------+-------+-------+--------------+

   The following values are available for Prio field:

   *  0: Do not use.  The path is not available.

   *  1: Standby: do not use this path for traffic scheduling, if
      another path (secondary or primary) is available.

   *  2: Secondary: do not use this path for traffic scheduling, if the
      other paths are good enough.  The path will be used occasionally,
      e.g. when primary paths are congested or become not available.

   *  3: Primary: can use the path in any way deemed reasonable by peer.
      Will always be used for packet scheduling decisions.

   *  4 - 15: relative priority of one path over the other to give
      relative path priority for primary paths.  The peer should
      consider sending more traffic over higher priority path.  Higher
      numbers indicate higher priority.

   Example use cases include: 1) Setting Wi-Fi path to Primary and
   Cellular paths to Secondary.  In this case Wi-Fi will be used and
   Cellular only if the Wi-Fi path is congested or not available.  Such

Amend, et al.            Expires 19 August 2022                [Page 21]
Internet-Draft               Multipath DCCP                February 2022

   setting results in using the Cellular path only temporally, if more
   capacity is needed than the WiFi path can provide, indicating a clear
   priority of the Wi-Fi path over the Cellular due to e.g. cost
   reasons.

   2) Setting Wi-Fi path to Primary and Cellular to Standby.  In this
   case Wi-Fi will be used and Cellular only, if the Wi-Fi path is not
   available.  3) Setting Wi-Fi path to Primary and Cellular path to
   Primary.  In this case, all packets can be scheduled over all paths
   at all time.

   The default behavior is, that a path can always be used for packet
   scheduling decisions (MP_PRIO=3), if the path has been established
   and added to an existing MP-DCCP connection.  At least one path
   should have a MP_PRIO value greater or equal to one for it to be
   allowed to send on the connection.  MP_PRIO is assumed to be
   exchanged reliably using the MP_CONFIRM mechanisms (see Table 6).

3.3.  MP-DCCP Handshaking Procedure

             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                               |

                    Figure 3: Example MP-DCCP Handshake

   The basic initial handshake for the first flow is as follows:

Amend, et al.            Expires 19 August 2022                [Page 22]
Internet-Draft               Multipath DCCP                February 2022

   *  Host A sends a DCCP-Request with the MP-Capable feature Change
      request and the MP_KEY option with an Host-specific Key-A for each
      of supported types as described in Section 3.2.4

   *  Host B sends a DCCP-Response with Confirm feature for MP-Capable
      and the MP_Key option with a single Host-specific Key-B.  The type
      of the key MUST be chosen from the list of supported types from
      the previous request

   *  Host A sends a DCCP-Ack with both Keys echoed to Host B.

   *  Host B sends a DCCP-Ack to confirm both keys and conclude the
      handshaking.

   Host A MUST wait the final DCCP-Ack from host B before starting any
   establishment of additional subflow connections.

   The handshake for subsequent flows based on a successful initial
   handshake is as follows:

   *  Host A sends a DCCP-Request with the MP-Capable feature Change
      request and the MP_JOIN option with Host B's Token TB, generated
      from the derived key by applying a SHA256 hash and truncating to
      the first 32 bits.  Additionally, an own random nonce RA is
      transmitted with the MP_JOIN.

   *  Host B computes the HMAC of the DCCP-Request and sends a DCCP-
      Response with Confirm feature option for MP-Capable and the
      MP_JOIN option with the Token TB and a random nonce RB together
      with the computed MP_HMAC.  The HMAC is calculated by taking the
      leftmost 20 bytes from the SHA256 hash of a HMAC code created by
      using token and nonce received with MP_JOIN(A) as message and the
      derived key described in Section 3.2.4 as key:

      MP_HMAC(A) = HMAC-SHA256(Key=d-key(B), Msg=TB+RA)

   *  Host A sends a DCCP-Ack with the HMAC computed for the DCCP-
      Response.  The HMAC is calculated by taking the leftmost 20 bytes
      from the SHA256 hash of a HMAC code created by using token and
      nonce received with MP_JOIN(B) as message and the derived key
      described in Section 3.2.4 as key:

      MP_HMAC(A) = HMAC-SHA256(Key=d-key(A), Msg=TB+RB)

   *  Host B sends a DCCP-Ack to confirm the HMAC and to conclude the
      handshaking.

Amend, et al.            Expires 19 August 2022                [Page 23]
Internet-Draft               Multipath DCCP                February 2022

3.4.  Fallback

   When a subflow fails to operate within the MP-DCCP requirements, it
   is necessary to fall back to the safe operation.  This may be either
   falling back to regular DCCP, or removing a problematic subflow.  The
   main reason for subflow failing is loss of MP-DCCP options.

   At the start of the MP-DCCP connection, the handshake ensures
   exchange of MP-DCCP options and thus ensures that the path is fully
   MP-DCCP capable.  If during the handshake procedure it appears that
   DCCP-Request or DCCP-Response or DCCP-Ack messages don't have the MP-
   DCCP options, the MP-DCCP connection will not be established and the
   handshake should fall back to regular DCCP.  The same fallback should
   take place if the endpoints fail to agree on a protocol version to
   use during the Multipath Capable feature negotiation.

   If a subflow attempts to join an existing MP-DCCP connection, but MP-
   DCCP options are not present in the handshake messages or the
   protocol version doesn't match the value negotiated for the first
   flow, that subflow will be closed.

3.5.  Congestion Control Considerations

   Senders MUST manage per-path congestion status, and SHOULD avoid to
   send more data on a given path than congestion control on that path
   allows.

   When a Multipath DCCP connection uses two or more paths, there is no
   guarantee that these paths are fully disjoint.  When two (or more
   paths) share the same bottleneck, using a standard congestion control
   scheme could result in an unfair distribution of the bandwidth with
   the multipath connection getting more bandwidth than competing single
   path connections.  Multipath TCP uses the coupled congestion control
   Linked Increases Algorithm (LIA) specified in [RFC6356] to solve this
   problem.  This scheme can be adapted also for Multipath DCCP.  The
   same applies to other coupled congestion control schemes, which have
   been proposed for Multipath TCP such as Opportunistic Linked
   Increases Algorithm [OLIA].

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

Amend, et al.            Expires 19 August 2022                [Page 24]
Internet-Draft               Multipath DCCP                February 2022

   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.

Amend, et al.            Expires 19 August 2022                [Page 25]
Internet-Draft               Multipath DCCP                February 2022

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.

Amend, et al.            Expires 19 August 2022                [Page 26]
Internet-Draft               Multipath DCCP                February 2022

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.

          +=======+============================+===============+
          | Value |        Feature Name        | Specification |
          +=======+============================+===============+
          |  0x10 | MP-DCCP capability feature |  Section 3.1  |
          +-------+----------------------------+---------------+

              Table 8: Addition to DCCP Feature list Entries

   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.

Amend, et al.            Expires 19 August 2022                [Page 27]
Internet-Draft               Multipath DCCP                February 2022

      +==========+===============+=====================+===========+
      |  Value   |     Symbol    |         Name        | Reference |
      +==========+===============+=====================+===========+
      |  TBD or  |     MP_OPT    |    DCCP Multipath   |  Section  |
      | Type=46  |               |        option       |    3.2    |
      +----------+---------------+---------------------+-----------+
      |  TBD or  |   MP_CONFIRM  |  Confirm reception/ |  Section  |
      | MP_OPT=0 |               |   processing of an  |   3.2.1   |
      |          |               |    MP_OPT option    |           |
      +----------+---------------+---------------------+-----------+
      |  TBD or  |    MP_JOIN    |     Join path to    |  Section  |
      | MP_OPT=1 |               |   existing MP-DCCP  |   3.2.2   |
      |          |               |         flow        |           |
      +----------+---------------+---------------------+-----------+
      |  TBD or  | MP_FAST_CLOSE |  Close MP-DCCP flow |  Section  |
      | MP_OPT=2 |               |                     |   3.2.3   |
      +----------+---------------+---------------------+-----------+
      |  TBD or  |     MP_KEY    |     Exchange key    |  Section  |
      | MP_OPT=3 |               |     material for    |   3.2.4   |
      |          |               |       MP_HMAC       |           |
      +----------+---------------+---------------------+-----------+
      |  TBD or  |     MP_SEQ    |  Multipath Sequence |  Section  |
      | MP_OPT=4 |               |        Number       |   3.2.5   |
      +----------+---------------+---------------------+-----------+
      |  TBD or  |    MP_HMAC    |  Hash-based Message |  Section  |
      | MP_OPT=5 |               | Auth.  Code for MP- |   3.2.6   |
      |          |               |         DCCP        |           |
      +----------+---------------+---------------------+-----------+
      |  TBD or  |     MP_RTT    | Transmit RTT values |  Section  |
      | MP_OPT=6 |               |   and calculation   |   3.2.7   |
      |          |               |      parameters     |           |
      +----------+---------------+---------------------+-----------+
      |  TBD or  |   MP_ADDADDR  |      Advertise      |  Section  |
      | MP_OPT=7 |               |      additional     |   3.2.8   |
      |          |               | Address(es)/Port(s) |           |
      +----------+---------------+---------------------+-----------+
      |  TBD or  | MP_REMOVEADDR | Remove Address(es)/ |  Section  |
      | MP_OPT=8 |               |       Port(s)       |   3.2.9   |
      +----------+---------------+---------------------+-----------+
      |  TBD or  |    MP_PRIO    |    Change Subflow   |  Section  |
      | MP_OPT=9 |               |       Priority      |   3.2.10  |
      +----------+---------------+---------------------+-----------+

              Table 9: Addition to DCCP Protocol options and
                        corresponding sub-options

   [Tbd], must include options for:

Amend, et al.            Expires 19 August 2022                [Page 28]
Internet-Draft               Multipath DCCP                February 2022

   *  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

9.  Informative References

   [I-D.amend-iccrg-multipath-reordering]
              Amend, M. and D. V. Hugo, "Multipath sequence
              maintenance", Work in Progress, Internet-Draft, draft-
              amend-iccrg-multipath-reordering-03, 25 October 2021,
              <https://www.ietf.org/archive/id/draft-amend-iccrg-
              multipath-reordering-03.txt>.

   [I-D.amend-tsvwg-dccp-udp-header-conversion]
              Amend, M., Brunstrom, A., Kassler, A., and V. Rakocevic,
              "Lossless and overhead free DCCP - UDP header conversion
              (U-DCCP)", Work in Progress, Internet-Draft, draft-amend-
              tsvwg-dccp-udp-header-conversion-01, 8 July 2019,
              <https://www.ietf.org/archive/id/draft-amend-tsvwg-dccp-
              udp-header-conversion-01.txt>.

   [I-D.amend-tsvwg-multipath-framework-mpdccp]
              Amend, M., Bogenfeld, E., Brunstrom, A., Kassler, A., and
              V. Rakocevic, "A multipath framework for UDP traffic over
              heterogeneous access networks", Work in Progress,
              Internet-Draft, draft-amend-tsvwg-multipath-framework-
              mpdccp-01, 8 July 2019, <https://www.ietf.org/archive/id/
              draft-amend-tsvwg-multipath-framework-mpdccp-01.txt>.

   [I-D.lhwxz-hybrid-access-network-architecture]
              Leymann, N., Heidemann, C., Wesserman, M., Xue, L., and M.
              Zhang, "Hybrid Access Network Architecture", Work in
              Progress, Internet-Draft, draft-lhwxz-hybrid-access-

Amend, et al.            Expires 19 August 2022                [Page 29]
Internet-Draft               Multipath DCCP                February 2022

              network-architecture-02, 13 January 2015,
              <https://www.ietf.org/archive/id/draft-lhwxz-hybrid-
              access-network-architecture-02.txt>.

   [I-D.muley-network-based-bonding-hybrid-access]
              Muley, P., Henderickx, W., Liang, G., Liu, H., Cardullo,
              L., Newton, J., Seo, S., Draznin, S., and B. Patil,
              "Network based Bonding solution for Hybrid Access", Work
              in Progress, Internet-Draft, draft-muley-network-based-
              bonding-hybrid-access-03, 22 October 2018,
              <https://www.ietf.org/archive/id/draft-muley-network-
              based-bonding-hybrid-access-03.txt>.

   [OLIA]     Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J.-
              Y. Le Boudec, "MPTCP is not pareto-optimal: performance
              issues and a possible solution", Proceedings of the 8th
              international conference on Emerging networking
              experiments and technologies, ACM , 2012.

   [paper]    Amend, M., Bogenfeld, E., Cvjetkovic, M., Rakocevic, V.,
              Pieska, M., Kassler, A., and A. Brunstrom, "A Framework
              for Multiaccess Support for Unreliable Internet Traffic
              using Multipath DCCP", DOI 10.1109/LCN44214.2019.8990746,
              October 2019,
              <https://doi.org/10.1109/LCN44214.2019.8990746>.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <https://www.rfc-editor.org/info/rfc793>.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/info/rfc2104>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3124]  Balakrishnan, H. and S. Seshan, "The Congestion Manager",
              RFC 3124, DOI 10.17487/RFC3124, June 2001,
              <https://www.rfc-editor.org/info/rfc3124>.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, DOI 10.17487/RFC3711, March 2004,
              <https://www.rfc-editor.org/info/rfc3711>.

Amend, et al.            Expires 19 August 2022                [Page 30]
Internet-Draft               Multipath DCCP                February 2022

   [RFC4043]  Pinkas, D. and T. Gindin, "Internet X.509 Public Key
              Infrastructure Permanent Identifier", RFC 4043,
              DOI 10.17487/RFC4043, May 2005,
              <https://www.rfc-editor.org/info/rfc4043>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086>.

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340,
              DOI 10.17487/RFC4340, March 2006,
              <https://www.rfc-editor.org/info/rfc4340>.

   [RFC5595]  Fairhurst, G., "The Datagram Congestion Control Protocol
              (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595,
              September 2009, <https://www.rfc-editor.org/info/rfc5595>.

   [RFC5596]  Fairhurst, G., "Datagram Congestion Control Protocol
              (DCCP) Simultaneous-Open Technique to Facilitate NAT/
              Middlebox Traversal", RFC 5596, DOI 10.17487/RFC5596,
              September 2009, <https://www.rfc-editor.org/info/rfc5596>.

   [RFC5597]  Denis-Courmont, R., "Network Address Translation (NAT)
              Behavioral Requirements for the Datagram Congestion
              Control Protocol", BCP 150, RFC 5597,
              DOI 10.17487/RFC5597, September 2009,
              <https://www.rfc-editor.org/info/rfc5597>.

   [RFC5634]  Fairhurst, G. and A. Sathiaseelan, "Quick-Start for the
              Datagram Congestion Control Protocol (DCCP)", RFC 5634,
              DOI 10.17487/RFC5634, August 2009,
              <https://www.rfc-editor.org/info/rfc5634>.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <https://www.rfc-editor.org/info/rfc6234>.

   [RFC6356]  Raiciu, C., Handley, M., and D. Wischik, "Coupled
              Congestion Control for Multipath Transport Protocols",
              RFC 6356, DOI 10.17487/RFC6356, October 2011,
              <https://www.rfc-editor.org/info/rfc6356>.

Amend, et al.            Expires 19 August 2022                [Page 31]
Internet-Draft               Multipath DCCP                February 2022

   [RFC6773]  Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A
              Datagram Congestion Control Protocol UDP Encapsulation for
              NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November
              2012, <https://www.rfc-editor.org/info/rfc6773>.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
              <https://www.rfc-editor.org/info/rfc6824>.

   [RFC6904]  Lennox, J., "Encryption of Header Extensions in the Secure
              Real-time Transport Protocol (SRTP)", RFC 6904,
              DOI 10.17487/RFC6904, April 2013,
              <https://www.rfc-editor.org/info/rfc6904>.

   [RFC6951]  Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
              Control Transmission Protocol (SCTP) Packets for End-Host
              to End-Host Communication", RFC 6951,
              DOI 10.17487/RFC6951, May 2013,
              <https://www.rfc-editor.org/info/rfc6951>.

   [RFC8684]  Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
              Paasch, "TCP Extensions for Multipath Operation with
              Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
              2020, <https://www.rfc-editor.org/info/rfc8684>.

   [slide]    Amend, M., "MP-DCCP for enabling transfer of UDP/IP
              traffic over multiple data paths in multi-connectivity
              networks", IETF105 , n.d.,
              <https://datatracker.ietf.org/meeting/105/materials/
              slides-105-tsvwg-sessa-62-dccp-extensions-for-multipath-
              operation-00>.

   [TS23.501] 3GPP, "System architecture for the 5G System; Stage 2;
              Release 16", December 2020,
              <https://www.3gpp.org/ftp//Specs/
              archive/23_series/23.501/23501-g70.zip>.

   [website]  "Multipath extension for DCCP", n.d.,
              <https://multipath-dccp.org/>.

Authors' Addresses

Amend, et al.            Expires 19 August 2022                [Page 32]
Internet-Draft               Multipath DCCP                February 2022

   Markus Amend (editor)
   Deutsche Telekom
   Deutsche-Telekom-Allee 9
   64295 Darmstadt
   Germany

   Email: Markus.Amend@telekom.de

   Anna Brunstrom
   Karlstad University
   Universitetsgatan 2
   SE-651 88 Karlstad
   Sweden

   Email: anna.brunstrom@kau.se

   Andreas Kassler
   Karlstad University
   Universitetsgatan 2
   SE-651 88 Karlstad
   Sweden

   Email: andreas.kassler@kau.se

   Veselin Rakocevic
   City University of London
   Northampton Square
   London
   United Kingdom

   Email: veselin.rakocevic.1@city.ac.uk

   Stephen Johnson
   BT
   Adastral Park
   Martlesham Heath
   IP5 3RE
   United Kingdom

   Email: stephen.h.johnson@bt.com

Amend, et al.            Expires 19 August 2022                [Page 33]