Deutsche Telekom

Deutsche-Telekom-Allee 9 Darmstadt 64295 Germany Markus.Amend@telekom.de

Karlstad University

Universitetsgatan 2 Karlstad 651 88 Sweden anna.brunstrom@kau.se

Karlstad University

Universitetsgatan 2 Karlstad 651 88 Sweden andreas.kassler@kau.se

City University of London

Northampton Square London United Kingdom veselin.rakocevic.1@city.ac.uk

BT

Adastral Park Martlesham Heath IP5 3RE United Kingdom stephen.h.johnson@bt.com

transport Transport Area Working Group Internet-Draft DCCP communications as defined in are restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of available 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 (e.g., handsets, vehicles) and residential home gateways simultaneously connected to distinct networks as, e.g., a cellular and a Wireless Local Area (WLAN) networks or a cellular and a fixed access networks. Compared to existing multipath protocols, such as MPTCP, MP-DCCP provides specific support for non-TCP user traffic (e.g., UDP or plain IP). More details on potential use cases are provided in , , and . All these use cases profit from an Open Source Linux reference implementation provided under . This document specifies a set of extensions to DCCP to support multipath operations. 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 different paths simultaneously.

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

Copyright Notice Copyright (c) 2023 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 () 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

• .  Introduction
  • .  Multipath DCCP in the Networking Stack
  • .  Terminology
  • .  MP-DCCP Concept
  • .  Requirements Language
• .  Operation Overview
• .  MP-DCCP Protocol
  • .  Multipath Capable Feature
  • .  Multipath Option
    • .  MP_CONFIRM
    • .  MP_JOIN
    • .  MP_FAST_CLOSE
    • .  MP_KEY
    • .  MP_SEQ
    • .  MP_HMAC
    • .  MP_RTT
    • .  MP_ADDADDR
    • .  MP_REMOVEADDR
    • . MP_PRIO
    • . MP_CLOSE
    • . Experimental MP-DCCP Sub-Option MP_EXP for private use
  • .  MP-DCCP Handshaking Procedure
  • .  Address knowledge exchange
    • .  Removing a path (Section 3.2.9)
  • .  Close a MP-DCCP connection
  • .  Fallback
  • .  Congestion Control Considerations
  • .  Maximum Packet Size Considerations
• .  Security Considerations
• .  Interactions with Middleboxes
• .  Implementation
• .  Acknowledgments
• .  IANA Considerations
• .  Informative References
• .  Differences from Multipath TCP
• Authors' Addresses

Introduction Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP communications are restricted to one single path. Multipath DCCP (MP-DCCP) is a set of extensions to DCCP to enable DCCP flows to be established across multiple paths simultaneously. Such extensions are beneficial to applications that transfer
large amounts of data, due to the possibility to aggregate capacity of the multiple paths. In addition, the multipath extensions enable to tradeoff timeliness and reliability, which is important for low-latency applications that do not require guaranteed delivery services, such as Audio/Video streaming. MP-DCCP has been first suggested in the context of the 3GPP work on 5G multi-access solutions and for hybrid access networks . MP-DCCP can be applied for load-balancing, seamless session handover, and bandwidth aggregation purposes (referred to as Access Traffic Steering, Switching, and Splitting (ATSSS) in the 3GPP terminology ). This document presents the protocol changes required to add multipath support to DCCP; specifically, those for signaling and setting up multiple paths (a.k.a, "subflows"), managing these subflows, reordering of data, and termination of sessions. DCCP, as stated in 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 application subflows that do not require in-ordered delivery. DCCP does not provide built-in support for those multiple application subflows. In the following, the term subflow refers to DCCP subflows transmitted via different paths (4-tuple of source and destination address/port pairs), not to be mixed up with the "application sub-flows" mentioned in Section 17.2 of . Application subflows are differing content-wise by source and destination port per application as, for example, enabled by Service Codes introduced to DCCP in , and those application subflows can be multiplexed over a single DCCP connection. For the sake of consistency we assume that only a single application is served by a DCCP connection here as shown in while use of that feature should not impact DCCP operation on each single path as noted in (Section 2.4 of ). Application subflows can co-exist with MP-DCCP operation as defined in this document. As pointed out in the proposed encapsulation in terms of lightweight DCCP flow headers is more appropriate for unreliable IP traffic in terms of UDP and other non-TCP packets in comparison to MPTCP. Such considerations are not detailed in the present specification.

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 DCCP; 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.

Comparison of Standard DCCP and MP-DCCP Protocol Stacks

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 , 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. The term subflow can also be used to refer to an MP-DCCP connection with a single path. (MP-DCCP) Connection: A set of one or more subflows, over which an application can communicate between two hosts. The MP-DCCP connection is exposed as single DCCP socket to the application. 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 .

MP-DCCP Concept provides a general overview of the MP-DCCP working mode, whose main characteristics are summarized in this section.

Example MP-DCCP Usage Scenario | | |<-----------------------------------| | | | | | | | (DCCP subflow setup)| | | |--------------------->| | | |<---------------------| | | merge individual DCCP subflows to one MP-DCCP connection | | | | ]]>

• An MP-DCCP connection begins with a 4-way handshaking procedure, between two hosts as described in . In , an MP-DCCP connection is established between addresses A1 and B1 on Hosts A and B, respectively. It should be noted that MP-DCCP does not require the presence of more than one address in both peers.
• In case extra paths and corresponding addresses/ports are available, additional DCCP subflows are created on these paths and are attached to the existing MP-DCCP session, which continues to appear as a single connection to the applications at both ends. The creation of an additional DCCP subflow is illustrated between Address A2 on Host A and Address B1 on Host B.
• MP-DCCP identifies multiple paths by the presence of multiple addresses/ports at hosts. Combinations of these multiple addresses/ports equate to the additional paths. In the example, other potential paths that could be set up are A1<->B2 and A2<->B2. Although this additional subflow is shown as being initiated from A2, it could equally have been initiated from B1 or B2.
• The discovery and setup of additional subflows will be achieved through a path management method including the logic and details of the procedures for adding/removing subflows; this document describes supportive measures by which a host can initiate new subflows and signal available addresses between peers. The definition of a path management method is, however, out of scope of this document and subject to a corresponding policy and the specifics of the implementation. In the same context, if any of the MP-DCCP peer hosts has a limit on the maximum number of paths that can be maintained (e.g., similar to what is discussed in Section 3.4 of , the creation of new subflows from that peer host should be avoided and incoming subflow requests should be terminated.
• MP-DCCP adds connection-level sequence numbers and exchange of Round-Trip Time (RTT) information to enable optional reordering features.
• Subflows are terminated as regular DCCP connections, as described in (, Section 8.3). The MP-DCCP connection is terminated by a connection-level DCCP-CloseReq or DCCP-Close message.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Operation Overview DCCP (Section 17.2 of ) 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) , as a generic multiplexing facility, can not fully support multiple congestion control mechanisms for multiple DCCP flows between same source and destination addresses. Various congestion control mechanisms have been specified to optimize DCCP performance for specific traffic types in terms of profiles denoted by a Congestion Control IDentifier (CCID). The extension of DCCP towards Multipath-DCCP (MP-DCCP) is described in detail in . As a high level overview of the MP-DCCP operation, 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 this document. The following sections define MP-DCCP behavior in detail. A Multipath DCCP connection provides a bidirectional connection of datagrams between two hosts exchanging data as in DCCP, 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 an 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 the exchange of performance parameters. The Multipath Capability for MP-DCCP can be negotiated with a new DCCP feature, as specified in . Once negotiated, all subsequent MP-DCCP operations for that connection are signalled with a variable length multipath-related option, as described in . All MP-DCCP operations are signaled with MP-DCCP suboptions described in {#MP_OPT}. The number of concurrent DCCP subflows can vary during the lifetime of a Multipath DCCP connection. The details of the path management decisions for when to add or remove subflows are outside the scope of this document.

MP-DCCP Protocol The DCCP protocol feature list (, Section 6.4) are enriched with a new Multipath related feature with Feature number 10, as shown in . Multipath Feature

Number	Meaning	Rule	Rec'n Value	Initial Req'd
10	Multipath Capable	SP	0	N

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, and it is safe to respond to Change options for the feature with empty Confirm options.

The DCCP protocol options as defined in (, Section 5.8) and (, Section 2.2.1) are enriched with a new Multipath related variable-length option with option type 46, as shown in . Multipath Option Set

Type	Option Length	Meaning	DCCP-Data?
46	variable	Multipath	Y

Multipath Capable Feature DCCP endpoints uses the Multipath Capable Feature to decide whether multipath extensions can be enabled for a DCCP connection. Multipath Capable feature 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 (0000 for this specification). The following four bits are unassigned in version 0. The unassigned bits MUST be set to zero by the sender and MUST be ignored by the receiver. The setting of Multipath Capable MUST follow the server-priority reconciliation rule described in (, 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 , and no subsequent re-negotiation of the Multipath Capable feature is allowed on the same MP-DCCP connection. Clients MUST include a Change R option during the initial handshake request to supply a list of supported MP-DCCP protocol versions, ordered by preference. Servers MUST include a Confirm L option in the subsequent response to agree on an MP-DCCP version to be used from the Client list, followed by its own supported version(s) ordered by preference. Any subflow addition to an existing MP-DCCP connection MUST use the same version negotiated for the first subflow. If no agreement is found, the Server MUST reply with an empty Confirm L option with feature number 10 and no values. An example of successful version negotiation is shown hereafter: DCCP-Resp + Confirm L(CAPABLE, 1, 2 1 0) <----------------------------------- * agreement on version = 1 * ]]>

1. The Client indicates support for both MP-DCCP versions 1 and 0, with a preference for version 1.
2. Server agrees on using MP-DCCP version 1, and supplies its own preference list.
3. MP-DCCP is then enabled between the Client and Server with version 1.

If the version negotiation fails or the MP_CAPABLE feature is not present in the DCCP-Request or DCCP-Response packets of the initial handshake procedure, the MP-DCCP connection SHOULD fall back to regular DCCP or MUST be closed. Further details are specified in

Multipath Option MP-DCCP uses one single option to signal various multipath-related operations. The format of this option is shown in .

Multipath Option Format

The description of the fields of the multipath option is shown in . MP_OPT refers to an MP-DCCP suboption. MP_OPT Option Types

Type	Option Length	MP_OPT	Meaning
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 connection
46	var	2 =MP_FAST_CLOSE	Close an MP-DCCP connection unconditionally
46	var	3 =MP_KEY	Exchange key material for MP_HMAC
46	9	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	4	8 =MP_REMOVEADDR	Remove Address
46	4	9 =MP_PRIO	Change Subflow Priority
46	var	10 =MP_CLOSE	Close an MP-DCCP subflow
46	TBD	>10	Reserved for future MP suboptions defined in Version > 0 or extension

These operations are largely inspired by the signals defined in .

MP_CONFIRM Some multipath options require confirmation from the remote peer (see ). Such options will be retransmitted by the sender until a MP_CONFIRM is received or confirmation of options is identified outdated. The further processing of the multipath options in the receiving host is not the subject of MP_CONFIRM. As the transmission of multipath suboptions is subject to out-of-order arrival, suboptions defined in SHALL be sent in a DCCP datagram with MP_SEQ . This allows to identify outdated suboptions which updates the same dataset. In case of MP_ADDADDR, MP_REMOVEADDR the same dataset is identified based on AddressID, whereas the same dataset for MP_PRIO is identified by the subflow in use. An outdated suboption is detected at the receiver if a previous suboption referring to the same dataset contained a higher sequence number carried by MP_SEQ. Generating a MP_CONFIRM for suboptions identified outdated is optional. Similarly MP_CONFIRM is subject to out-of-order arrival. To ensure that the most recent suboption is confirmed the associated MP_SEQ received MUST be echoed. Otherwise inconsistency happens if between updates of a dataset with the same value, another value is sent. If the MP_CONFIRM of the second update and the third update itself gets lost, the value of the second update is applied on receiver side without being detected by the sender. The length and sending path of the MP_CONFIRM are dependent on the confirmed suboptions and the received MP_SEQ, which will be both copied verbatim and appended as list of confirmations. The list structures by first listing the received MP_SEQ followed by the confirmed suboption or suboptions. The same rules apply when suboptions with different MP_SEQs are confirmed at once. This might happen if a datagram with MP_PRIO and a first MP_SEQ_1 and another datagram with MP_ADDADDR and a second MP_SEQ_2 are received in short succession. In this case, the structure described above is concatenated resulting in MP_SEQ_1 + MP_PRIO + MP_SEQ_2 + MP_ADDADDR. Multipath options requiring confirmation

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

An example to illustrate the MP-DCCP confirm procedure for the MP_PRIO option is shown in . The host A sends a DCCP-Request on path A2-B2 with an MP_PRIO option with value 1 and associated sequence number of 1. Host B replies on the same path in this instance (but could be any path) with a DCCP-Response containing the MP_CONFIRM option and a list containing the original sequence number (1) together with the associated option (MP_PRIO)

Example MP-DCCP CONFIRM procedure | | | | | | | DCCP-Response + | | | |<---- MP_CONFIRM(seqno 1, MP_PRIO) --------| | | | | ]]>

A second example to illustrate the same MP-DCCP confirm procedure but where an out of date option is also delivered is shown in (. Here, a first DCCP-Data is sent from Host A to Host B with option MP_PRIO set to 4. Host A subsequently issues a second DCCP-Data with option MP_PRIO set to 1. The delivery of the first MP_PRIO is delayed in the network between Host A and Host B and arrives after the second MP_PRIO. Host B ignores this second MP_PRIO as the associated sequence number is earlier than the first. Host B sends a DCCP-Ack confirming receipt of the MP_PRIO(1) with sequence number 2.

Example MP-DCCP CONFIRM procedure with outdated suboption | | | \ | | | | -------------------------->| | | | | | | DCCP-Ack + | | | |<---- MP_CONFIRM(seqno 2, MP_PRIO) --------| | | | | ]]>

MP_JOIN

Format of the MP_JOIN Suboption

The MP_JOIN option is used by a host to add a new subflow to an existing MP-DCCP connection. 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 MP_JOIN option includes an "Addr ID" (Address ID) generated by the sender of the option, used to identify the source address of this packet, even if the IP header has been changed in transit by a middlebox. The numeric value of this field is generated by the sender and must map uniquely to a source IP address for the sending host. The Address ID allows address removal () without needing to know what the source address at the receiver is, thus allowing address removal through NATs. The Address ID also allows correlation between new subflow setup attempts and address signaling (), to prevent setting up duplicate subflows on the same path, if an MP_JOIN and MP_ADDADDR are sent at the same time. 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 always has 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 . If the path token can not be verified by the receiving host during a handshake negotiation, the new subflow MUST be closed, as specified in .

MP_FAST_CLOSE Regular DCCP has the means of sending a Close or Reset signals to abruptly close a connection. With MP-DCCP, a regular Close or Reset only has the scope of the subflow over which the signal was received. As such, it will only close the applicable subflow and will not affect the remaining subflows concurrently in use on other paths. A MP-DCCP connection will stay alive at the data level in order to permit break-before-make handover between subflows. It is therefore necessary to provide an MP-DCCP-level "Reset" to allow the abrupt closure of the whole MP-DCCP connection; this is done via the MP_FAST_CLOSE suboption.

Format of the MP_FAST_CLOSE Suboption

For being effective, the MP_FAST_CLOSE suboption MUST be sent from an initiating host on all subflows as part of a DCCP-Reset packet with Reset Code 13. To protect unauthorized shutdown of a multipath DCCP connection, the selected Key Data of the peer host during the handshaking procedure is carried by the MP_FAST_CLOSE option. With completion of this step, the initiating host can tear down the subflows and the multipath DCCP connection immediately terminates. Upon reception of the MP_FAST_CLOSE and successful validation of the Key Data at the peer host, a DCCP Reset packet is replied on all subflows to the initiating host with Reset Code 13. The peer host can now close the whole MP-DCCP connection (i.e., it transitions the connection state directly to CLOSED).

MP_KEY

Format of the MP_KEY Suboption

The MP_KEY suboption is used to exchange key material between hosts for a given connection. 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 . MP_KEY Key Types

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		Unassigned

Plain Text

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

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

ECDHE-SHA512-C25519

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

Providing multiple keys is only permitted in the DCCP-Request message of the handshake procedure for the first subflow, and allows the hosts to agree on a single key type to be used as described in If the key type can not be agreed when the MP_KEY option is sent as part of the handshake procedure, the MP-DCCP connection should fallback to regular DCCP as indicated in

MP_SEQ

Format of the MP_SEQ Suboption

The MP_SEQ suboption 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.

MP_HMAC

Format of the MP_HMAC Suboption

The MP_HMAC suboption is used to provide authentication for the MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR suboptions. The HMAC code is generated according to in combination with the SHA256 hash algorithm described in , 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 , while the HMAC "Message" is a concatenation of

• MP_JOIN: The token and nonce of the MP_JOIN for which authentication shall be performed.
• MP_ADDADDR: The Address ID with associated IP address and if defined port, otherwise two octets of value 0.
• MP_REMOVEADDR: Solely the Address ID.

MP_JOIN, MP_ADDADDR and MP_REMOVEADDR can co-exist or be used multiple times within a single DCCP packet. As all this multipath options come along with an individual MP_HASH option, this requires the MP_HASH to be correctly associated. Otherwise, the receiver cannot validate multiple MP_JOIN, MP_ADDADDR or MP_REMOVEADDR. Therefore, a MP_HASH MUST directly follow its associated multipath option. In the likely case of sending a MP_JOIN together with a MP_ADDADDR, this results in concatenating MP_JOIN + MP_HMAC_1 + MP_ADDADDR + MP_HMAC_2, whereas the first MP_HMAC_1 is associated with the MP_JOIN and the second MP_HMAC_2 with the MP_ADDADDR suboption. If the HMAC can not be validated by a receiving host, the subsequent handling depends on which suboption was being authenticated. If the suboption to be authenticated was either MP_ADDADDR or MP_REMOVEADDR, the receiving host SHOULD silently ignore it (see and ). If the suboption to be authenticated was MP_JOIN, it MUST lead to a subflow closing (see )

MP_RTT

Format of the MP_RTT Suboption

The MP_RTT suboption 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. This information is in particular useful for the receiving host to calculate the RTT difference between the subflows and to estimate whether missing data has been lost. 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 preferably provided by the CCID in use.

Min RTT (=1)

Min RTT value over a given period preferably provided by the CCID in use.

Max RTT (=2)

Max RTT value over a given period preferably provided by the CCID in use.

Smooth RTT (=3)

Averaged RTT value over a given period preferably provided by the CCID in use.

Age

The Age parameter defines the time difference between now - creation of the MP_RTT option - and the conducted RTT measurement in milliseconds. If no previous measurement exists, e.g., when initialized, the value is 0.

In an exemplary flow shows the exchange of path individual RTT information with RTT1 pointing to a first path and RTT2 to a second path. Those RTT values might be extracted from the sender's Congestion Control procedure and carried to the receiving host using MP_RTT suboption. With the reception of RTT1 and RTT2, the receiver is able to calculate the path_delta which corresponds to the absolute difference of both values. In case the path individual RTTs are symmetric in down- and uplink direction, packets with missing sequence number MP_SEQ, e.g., in a reordering process, can be assumed lost after path_delta/2.

Exemplary flow of MP_RTT exchange and usage

MP_ADDADDR The MP_ADDADDR suboption announces additional addresses (and, optionally, port numbers) 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. Multiple instances of this suboption within a packet advertise simultaneously new addresses. Length is variable depending on the address family (IPv4 or IPv6) and whether a port number is used. This field is in range between 8 and 22 bytes. The presence of the final 2 octets, specifying the DCCP port number to use, are optional and can be inferred from the length of the option. Although it is expected that the majority of use cases will use the same port pairs as used for the initial subflow (e.g., port 80 remains port 80 on all subflows, as does the ephemeral port at the client), there may be cases (such as port-based load balancing) where the explicit specification of a different port is required. If no port is specified, the receiving peer SHOULD assume that any attempt to connect to the specified address has to be on the same port as is already in use by the subflow on which the MP_ADDADDR signal was sent. Along with the MP_ADDADDR option a MP_HMAC option MUST be sent for authentication. The truncated HMAC parameter present in this MP_HMAC option is the leftmost 20 bytes of an HMAC, negotiated and calculated as described in . In the same way as for MP_JOIN, the key for the HMAC algorithm, in the case of the message transmitted by Host A, will be Key-A followed by Key-B, and in the case of Host B, Key-B followed by Key-A. These are the keys that were exchanged and selected in the original MP_KEY handshake. The message for the HMAC is the Address ID, IP address, and port that precede the HMAC in the MP_ADDADDR option. If the port is not present in the MP_ADDADDR option, the HMAC message will nevertheless include 2 octets of value zero. The rationale for the HMAC is to prevent unauthorized entities from injecting MP_ADDADDR signals in an attempt to hijack a connection. Note that, additionally, the presence of this HMAC prevents the address from being changed in flight unless the key is known by an intermediary. If a host receives an MP_ADDADDR option for which it cannot validate the HMAC, it SHOULD silently ignore the option. The presence of a MP_SEQ MUST be ensured in a DCCP datagram in which MP_ADDADDR is sent. Further details are given in .

Format of the MP_ADDADDR Suboption

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 ) 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 MP_ADDADDR 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. Note that an implementation MAY discard incoming address advertisements at will, for example, for avoiding the required mapping state, or because advertised addresses are of no use to it (for example, IPv6 addresses when it has IPv4 only). Therefore, a host MUST treat address advertisements as soft state, and it MAY choose to refresh advertisements periodically. Due to the proliferation of NATs, it is reasonably likely that one host may attempt to advertise private addresses. It is not desirable to prohibit this, since there may be cases where both hosts have additional interfaces on the same private network, and a host MAY want to advertise such addresses. The MP_JOIN handshake to create a new subflow () provides mechanisms to minimize security risks. The MP_JOIN message contains a 32-bit token that uniquely identifies the connection to the receiving host. If the token is unknown, the host will return with a DCCP-Reset. In the unlikely event that the token is known, subflow setup will continue, but the HMAC exchange must occur for authentication. This will fail, and will provide sufficient protection against two unconnected hosts accidentally setting up a new subflow upon the signal of a private address. Further security considerations around the issue of MP_ADDADDR messages that accidentally misdirect, or maliciously direct, new MP_JOIN attempts are discussed in . In case a sending host of a MP_ADDADDR knows about the inability to establish incoming subflows on a particular address, a MP_ADDADDR SHOULD NOT advertise this address unless sending host has new knowledge about the ability. Such ability information can be obtained from local firewall or routing settings, knowledge about availability of external NAT or firewall, or from connectivity checks performed by the host/application. The reception of an MP_ADDADDR message is acknowledged using MP_CONFIRM (). Using this mechanism reliable exchange of address information is ensured. A host can send an MP_ADDADDR message with an already assigned Address ID, but the Address MUST be the same as previously assigned to this Address ID, and the Port MUST be different from one already in use for this Address ID. If these conditions are not met, the receiver SHOULD silently ignore the MP_ADDADDR. A host wishing to replace an existing Address ID MUST first remove the existing one (). A host that receives an MP_ADDADDR 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. However, a sender that wants to trigger a new incoming connection attempt on a previously advertised address/port combination can therefore refresh MP_ADDADDR information by sending the option again.

MP_REMOVEADDR If, during the lifetime of an MP-DCCP connection, a previously announced address becomes invalid (e.g., if an 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 (MP_REMOVEADDR) suboption which will remove a previously added address with an Address ID from a connection and terminate any subflows currently using that address. Along with the MP_REMOVEADDR suboption a MP_HMAC option MUST be sent for authentication. The truncated HMAC parameter present in this MP_HMAC option is the leftmost 20 bytes of an HMAC, negotiated and calculated as described in . In the same way as for MP_JOIN, the key for the HMAC algorithm, in the case of the message transmitted by Host A, will be Key-A followed by Key-B, and in the case of Host B, Key-B followed by Key-A. These are the keys that were exchanged and selected in the original MP_KEY handshake. The message for the HMAC is the Address ID. The rationale for the HMAC is to prevent unauthorized entities from injecting MP_REMOVEADDR signals in an attempt to hijack a connection. Note that, additionally, the presence of this HMAC prevents the address from being removed in flight unless the key is known by an intermediary. If a host receives an MP_REMOVEADDR option for which it cannot validate the HMAC, it SHOULD silently ignore the option. The presence of a MP_SEQ MUST be ensured in a DCCP datagram in which MP_REMOVEADDR is sent. Further details are given in . The reception of an MP_REMOVEADDR message is acknowledged using MP_CONFIRM (). Using this mechanism reliable exchange of address information is ensured. To avoid inconsistent states, it is recommended to release the sender address ID only after MP_REMOVEADDR has been confirmed. 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.

Format of theMP_REMOVEADDR Suboption followed by MP_HMAC option ]]>

A subflow that is still functioning MUST be closed with a DCCP-Close or exchange as in regular DCCP, rather than using this option. For more information, see Section .

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 when making scheduling decisions for user plane traffic, 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, the usage of only a single path may be the preferred choice of the user. 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 suboption, shown below, can be used to set a priority flag for the path over which the suboption is received.

Format of the MP_PRIO Suboption

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. The path will only be used if other secondary or primary paths are not established.
• 2: Secondary: do not use this path for traffic scheduling, if the other paths are good enough. The path will be used occasionally for increasing temporarily the available capacity, e.g. when primary paths are congested or are not available. This is the recommended setting for paths that have costs or data caps as these paths will be used less frequently then primary paths.
• 3 - 15: Primary: can use the path in any way deemed reasonable by peer. The path will always be used for packet scheduling decisions. The priority number indicates the relative priority of one path over the other for primary paths. Higher numbers indicate higher priority. The peer should consider sending more traffic over higher priority paths. This is the recommended setting for paths that do not have a cost or data caps associated with them as these paths will be frequently used.

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 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. If not specified, 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 ). The presence of a MP_SEQ MUST be ensured in a DCCP datagram in which MP_PRIO is sent. Further details are given in .

MP_CLOSE

Format of the MP_CLOSE Suboption

For a graceful shutdown of a MP-DCCP connection, MP_CLOSE is used to communicate this to a peer host. On all subflows, the regular termination procedure as described in MUST be initiated using MP_CLOSE in the initial packet (either a DCCP-CloseReq or a DCCP-Close). In the case where a DCCP-CloseReq is used, the following DCCP-Close MUST carry the MP_CLOSE as well. At the initiator of the DCCP-CloseReq all sockets, including the MP-DCCP connection socket, transition to CLOSEREQ state. To protect unauthorized shutdown of a multi-path connection, the selected Key Data of the peer host during the handshaking procedure MUST be carried by the MP_CLOSE option and validated by the peer host. Note, Key Data is different between MP_CLOSE option carried by DCCP-CloseReq or DCCP-Close. On reception of a first DCCP-CloseReq carrying a MP_CLOSE with valid Key Data, or due to a local decision, all subflows transition to the CLOSING state before transmitting a DCCP-Close carrying MP_CLOSE. In this case, the MP-DCCP connection socket on the host sending the DCCP-Close reflects the state of the initial subflow used during handshake with MP_KEY option. If the initial subflow no longer exists, the state moves immediately to CLOSED. Upon reception of the first DCCP-Close carrying a MP_CLOSE with valid Key Data at the peer host, all subflows, as well as the MP-DCCP connection socket, move to the CLOSED state. After this, a DCCP-Reset with Reset Code 1 MUST be sent on any subflow in response to a received DCCP-Close containing a valid MP_CLOSE option. When the MP-DCCP connection socket is in CLOSEREQ or CLOSE state, new subflow requests using MP_JOIN MUST be ignored. Contrary to a MP_FAST_CLOSE , no single-sided abrupt termination is applied.

Experimental MP-DCCP Sub-Option MP_EXP for private use This section reserves a MP-DCCP sub-option to define and specify any experimental additional feature for improving and optimization of MP-DCCP protocol. This option may be applicable to specific environments or scenarios according to potential new requirements and meant for private use only at this stage. MP_OPT feature number 11 is foreseen with an exemplary description as below:

Format of the MP_EXP Suboption

Details as length and type of data remain to be defined according to the foreseen use by the experimenters.

MP-DCCP Handshaking Procedure An example to illustrate the MP-DCCP handshake procedure is shown in .

Example MP-DCCP Handshake | |<---------------------- 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(B)-----| | |DCCP-Response + MP_CAPABLE | | | | | |DCCP-Ack | | |-------- MP_HMAC(A) ------------------>| | |<--------------------------------------| | |DCCP-ACK | ]]>

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

• 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 .
• 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 is 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 waits for the final DCCP-Ack from host B before starting any establishment of additional subflow connections. The handshake for subsequent subflows 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 as key: MP_HMAC(B) = HMAC-SHA256(Key=d-key(B), Msg=RB+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 as key: MP_HMAC(A) = HMAC-SHA256(Key=d-key(A), Msg=RA+RB)
• Host B sends a DCCP-Ack to confirm the HMAC and to conclude the handshaking.

Address knowledge exchange ### Advertising a new path () When a host (Host A) wants to advertise the availability of a new path, it should use the MP_ADDADDR option () as shown in the example in . The MP_ADDADDR option passed in the DCCP-Data contains the following parameters: * an identifier (id 2) for the new IP address which is used as a reference in subsequent control exchanges. * the IP address of the new path (A2_IP) * A pair of octets specifying the port number associated with this IP address. The value of 00 here, indicates that the port number is the same as that used for the initial subflow address A1_IP The following options must be included in a packet carrying MP_ADDADDR: * the leftmost 20 bytes of the HMAC(A) generated during the initial handshaking procedure described in and * the sequence number (seqno 12) for this message Host B acknowledges receipt of the MP_ADDADDR message with a DCCP-Ack containing the MP_CONFIRM option. The parameters supplied in this response are as follows: * an MP_CONFIRM containing the MP_SEQ number (seqno 12) of the packet carrying the option that we are confirming together with the MP_ADDADDR option * the leftmost 20 bytes of the HMAC(B) generated during the initial handshaking procedure

Example MP-DCCP ADDADDR procedure | | | | | DCCP-Ack + MP_HMAC(B) + | |<----- MP_CONFIRM(seqno 12, MP_ADDADDR) -------------| ]]>

Removing a path () When a host (Host A) wants to indicate that a path is no longer available, it should use the MP_REMOVEADDR option () as shown in the example in . The MP_REMOVEADDR option passed in the DCCP-Data contains the following parameters: * an identifier (id 2) for the IP address to remove (A2_IP) and which was specified in a previous MP_ADDADDR message. The following options must be included in a packet carrying MP_REMOVEADDR * the leftmost 20 bytes of the HMAC(A) generated during the initial handshaking procedure described in and * the sequence number (seqno 33) for this message Host B acknowledges receipt of the MP_REMOVEADDR message with a DCCP-Ack containing the MP_CONFIRM option. The parameters supplied in this response are as follows: * an MP_CONFIRM containing the MP_SEQ number (seqno 33) of the packet carrying the option that we are confirming, together with the MP_REMOVEADDR option * the leftmost 20 bytes of the HMAC(B) generated during the initial handshaking procedure

Example MP-DCCP REMOVEADDR procedure | | | | | DCCP-Ack + MP_HMAC(B) + | |<----- MP_CONFIRM(seqno 33, MP_REMOVEADDR) ----------| ]]>

Close a MP-DCCP connection When a host wants to close an existing subflow but not the whole MP-DCCP connection, it initiates the regular DCCP connection termination procedure as described in , i.e., it sends a DCCP-Close/DCCP-Reset on the subflow. This may be preceded by a DCCP-CloseReq. In the event of an irregular termination of a subflow, e.g., during subflow establishment, it is RECOMMENDED to use an appropriate DCCP reset code as specified in Table 2 of . This could be, for example, sending reset code 5 (Option Error) when an MP-DCCP option provides invalid data or reset code 9 (Too Busy) when the maximum number of maintainable paths is reached. Note that receiving a reset code 9 for secondary subflows SHOULD NOT impact already existing active subflows. If necessary, these subflows are terminated in a subsequent step using the procedures described in this section. When a host wants to terminate an MP-DCCP connection, it is RECOMMENDED that the host initiates the DCCP connection termination as per on each subflow with the first packet on each subflow carrying MP_CLOSE (see ). [B's key] [on all subflows] <- DCCP-Reset [on all subflows] ]]> Additionally, an MP-DCCP connection may be closed abruptly using the "Fast Close" procedure described in , where a DCCP-Reset is sent on all subflows, each carrying the MP_FAST_CLOSE option. [B's key] [on all subflows] <- DCCP-Reset [on all subflows] ]]>

Fallback When a subflow fails to operate following MP-DCCP intended behavior, it is necessary to proceed with a fall back. This may be either falling back to regular DCCP or removing a problematic subflow. The main reasons for subflow failing include: no MP support at peer host, failure to negotiate protocol version, loss of MP-DCCP suboptions, faulty/non-supported MP-DCCP options or modification of payload data. At the start of an MP-DCCP connection, the handshake ensures exchange of MP-DCCP feature and 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 messages don't carry the MP_CAPABLE feature, the MP-DCCP connection will not be established and the handshake SHOULD fall back to regular DCCP or MUST be closed. The same fallback SHOULD take place if the endpoints fail to agree on a protocol version to use during the Multipath Capable feature negotiation, which is described in . The protocol version negotiation distinguishes between negotiation for the initial connection establishment, and addition of subsequent subflows. If protocol version negotiation is not successful during the initial connection establishment, MP-DCCP connection will fall back to regular DCCP. Similar procedure MUST be applied if the MP_KEY Key Type cannot be negotiated, a final ACK carrying MP_KEY with wrong Key-A/Key-B is received or MP_KEY option is malformed. If a subflow attempts to join an existing MP-DCCP connection, but MP-DCCP options or MP_CAPABLE feature are not present or are faulty in the handshake procedure, that subflow MUST be closed. This is especially the case if a different MP_CAPABLE version than the originally negotiated version is used. Also non-verifiable MP_HMAC or MP_JOIN Path Token as part of the subsequent flow establishment MUST lead to a subflow closing. Another relevant case is when payload data is modified by middleboxes. DCCP uses checksum to protect the data, as described in section 9 of . A checksum will fail if the data has been changed in any way. All data from the start of the segment that failed the checksum onwards cannot be considered trustworthy. DCCP defines that if the checksum fails, the receiving endpoint MUST drop the application data and report that data as dropped due to corruption using a Data Dropped option (Drop Code 3, Corrupt). If this happens in an MP-DCCP connection, the affected subflow can either be closed or other action can be taken.

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 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 . The details of the congestion control algorithms are outside the scope of this document.

Maximum Packet Size Considerations A DCCP implementation maintains the maximum packet size (MPS) during operation of a DCCP session. This procedure is specified for single-path DCCP in , Section 14. Without any restrictions, this is adopted for MP-DCCP operations, in particular the PMTU measurement and the Sender Behaviour. As per this definition a DCCP application interface SHOULD let the application discover the current MPS, this is subject to ambiguity with potential different path MPS in a multipath system. For compatibility reasons, an MP-DCCP implementation SHOULD always announce the minimum MPS across all paths.

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) is one candidate protocol for authentication. Together with Encryption of Header Extensions in SRTP, as provided by , also integrity would be provided. As described in , 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. 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 and . 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 . 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. As discussed in , a host may advertise its private addresses, but these might point to different hosts in the receiver's network. The MP_JOIN handshake () will ensure that this does not succeed in setting up a subflow to the incorrect host. However, it could still create unwanted DCCP handshake traffic. This feature of MP-DCCP could be a target for denial-of-service exploits, with malicious participants in MP-DCCP connections encouraging the recipient to target other hosts in the network. Therefore, implementations should consider heuristics at both the sender and receiver to reduce the impact of this.

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 , Section 16). In case, however, both hosts are located behind a NAT or firewall entity, specific measures have to be applied such as the -specified simultaneous-open technique that update the (traditionally asymmetric) connection-establishment procedures for DCCP. Further standardized technologies addressing NAT type middleboxes are covered by . specifies UDP Encapsulation for NAT Traversal of DCCP sessions, similar to other UDP encapsulations such as for SCTP . The alternative U-DCCP approach proposed in 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.

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 .

Acknowledgments Due to the great spearheading work of the Multipath TCP authors in /, some text passages were copied almost unmodified from these documents. The authors gratefully acknowledge significant input into this document from Dirk von Hugo, Nathalie Romo Moreno, Omar Nassef, Mohamed Boucadair, and Behcet Sarikaya.

IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the MP extension of the DCCP protocol in accordance with . This document defines one new value to be added to the DCCP Feature Numbers registry and three new registries to be added to the DCCP registry group. This document requests IANA to assign a new DCCP feature parameter for negotiating the support of multipath capability for DCCP sessions between hosts as described in . The following entry in should be added to the Feature Numbers registry in the DCCP registry group according to , Section 19.4. under the "DCCP Protocol" heading. Addition to DCCP Feature Numbers registry

Value	Feature Name	Specification
10 (suggested)	MP-DCCP capability feature	[ThisDocument]

As outlined in sect. the new 1-Byte entry above includes a 4-bit part to specify the version of the used MP-DCCP implementation. This document requests IANA to create a new 'MP-DCCP Versions' registry within the DCCP registry group to track the MP-DCCP version. The initial content of this registry is as follows: MP-DCCP Versions Registry

Version	Description	Specification
0000	Version 0	[ThisDocument]
0001 - 1111	Unassigned

Future MP-DCCP versions 1 to 15 are assigned from this registry using the Specification Required policy (Section 4.6 of ). This document requests IANA to assign a new DCCP protocol option of type=46 as described in Section 3.2. IANA is requested to create a new 'MP-DCCP Suboptions' registry within the DCCP registry group. The following entries in should be added to the new 'MP-DCCP Suboptions' registry. The registry in has an upper boundary of 255 in the numeric value field. MP-DCCP Suboptions registry

Value	Symbol	Name	Reference
Type=46	MP_OPT	DCCP Multipath option
MP_OPT=0	MP_CONFIRM	Confirm reception/processing of an MP_OPT option
MP_OPT=1	MP_JOIN	Join subflow to existing MP-DCCP connection
MP_OPT=2	MP_FAST_CLOSE	Close MP-DCCP connection
MP_OPT=3	MP_KEY	Exchange key material for MP_HMAC
MP_OPT=4	MP_SEQ	Multipath Sequence Number
MP_OPT=5	MP_HMAC	Hash-based Message Auth. Code for MP-DCCP
MP_OPT=6	MP_RTT	Transmit RTT values and calculation parameters
MP_OPT=7	MP_ADDADDR	Advertise additional Address(es)/Port(s)
MP_OPT=8	MP_REMOVEADDR	Remove Address(es)/ Port(s)
MP_OPT=9	MP_PRIO	Change Subflow Priority
MP_OPT=10	MP_CLOSE	Close MP-DCCP subflow
MP_OPT=11	MP_EXP	Experimental Sub-Option for private use
MP_OPT>11	Unassigned	Reserved for future MP-DCCP suboptions

Future MP-DCCP sub-options with MP_OPT>11 can be assigned from this registry using the Specification Required policy (Section 4.6 of ). In addition IANA is requested to assign a new DCCP Reset Code value 13 (or TBD) in the DCCP Reset Codes Registry, with the short description "Abrupt MP termination". Use of this reset code is defined in section . In addition IANA is requested to assign for this version of the MP-DCCP protocol a new 'MP_KEY' registry containing three different sub options to the MP-KEY option to identify the MP_KEY Key types in terms of 8-bit values as specified in according to the entries in below. Values in range 3-255 (decimal) inclusive remain unassigned in this version 0 of the protocol and are assigned via Specification Required in potential future versions of the MP-DCCP protocol. MP-DCCP MP_KEY registry with type sub-options for key data exchange on different paths

Value	Key Type	Name or Meaning	Reference
0	Plain Text	Plain Text Key
1	ECDHE-C25519-SHA256	ECDHE with SHA256 and Curve25519
2	ECDHE-C25519-SHA512	ECDHE with SHA512 and Curve25519

Informative References Deutsche Telekom Deutsche Telekom This document discusses the issue of packet reordering which occurs as a specific problem in multi-path connections without reliable transport protocols such as TCP. The topic is relevant for devices connected via multiple accesses technologies towards the network as is foreseen, e.g., within Access Traffic Selection, Switching, and Splitting (ATSSS) service of 3rd Generation Partnership Project (3GPP) enabling fixed mobile converged (FMC) scenario. Work in Progress Deutsche Telekom Karlstad University Karlstad University City University of London The Datagram Congestion Control Protocol (DCCP) is a transport-layer protocol that provides upper layers with the ability to use non- reliable congestion-controlled flows. DCCP is not widely deployed in the Internet, and the reason for that can be defined as a typical example of a chicken-egg problem. Even if an application developer decided to use DCCP, the middle-boxes like firewalls and NATs would prevent DCCP end-to-end since they lack support for DCCP. Moreover, as long as the protocol penetration of DCCP does not increase, the middle-boxes will not handle DCCP properly. To overcome this challenge, NAT/NATP traversal and UDP encapsulation for DCCP is already defined. However, the former requires special middle-box support and the latter introduces overhead. The recent proposal of a multipath extension for DCCP further underlines the challenge of efficient middle-box passing as its main goal is to be applied over the Internet, traversing numerous uncontrolled middle-boxes. This document introduces a new solution which disguises DCCP during transmission as UDP without requiring middle-box modification or introducing any overhead. Work in Progress Deutsche Telekom Deutsche Telekom Karlstad University Karlstad University City University of London More and more of today's devices are multi-homing capable, in particular 3GPP user equipment like smartphones. In the current standardization of the next upcoming mobile network generation 5G Rel.16, this is especially targeted in the study group Access Traffic Steering Switching Splitting [TR23.793]. ATSSS describes the flexible selection or combination of 3GPP untrusted access like Wi-Fi and cellular access, overcoming the single-access limitation of today's devices and services. Another multi-connectivity scenario is the Hybrid Access [I-D.lhwxz-hybrid-access-network-architecture][I-D. muley-network-based-bonding-hybrid-access], providing multiple access for CPEs, which extends the traditional way of single access connectivity at home to dual-connectivity over 3GPP and fixed access. A missing piece in the ATSSS and Hybrid Access is the access and path measurement, which is required for efficient and beneficial traffic steering decisions. This becomes particularly important in heterogeneous access networks with a multitude of volatile access paths. While MP-TCP has been proposed to be used within ATSSS, there are drawbacks when being used to encapsulate unreliable traffic as it blindly retransmits each lost frame leading to excessive delay and potential head-of-line blocking. A decision for MP-TCP though leaves the increasing share of UDP in today's traffic mix (<https://arxiv.org/abs/1801.05168>) unconsidered. In this document, a multi-access framework is proposed leveraging the MP-DCCP network protocol, which enables flexible traffic steering, switching and splitting also for unreliable traffic. A benefit is the support for pluggable congestion control which enables our framework to be used either independent or complementary to MP-TCP. Work in Progress Deutsche Telekom AG Deutsche Telekom AG Painless Security Huawei Huawei Residential and Enterprise customers require continuously increasing bandwidth, however it may be difficult for operators to update or rebuild existing fixed access networks, especially when they are deployed in certain areas. This document discusses a general way to address this problem by bundling together multiple heterogeneous access networks according to certain management policies. Work in Progress Nokia Nokia China Mobile D-Link Corp Vodafone Vodafone Korea Telecom Verizon Wireless AT&T In order to address increasing bandwidth demands, operators are considering bundling of multiple heterogeneous access networks (Hybrid access) for residential and enterprise customers. This document describes a solution for Hybrid access and covers the use case scenarios. Work in Progress This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the Congestion Manager (CM), an end-system module that enables an ensemble of multiple concurrent streams from a sender destined to the same receiver and sharing the same congestion properties to perform proper congestion avoidance and control, and allows applications to easily adapt to network congestion. [STANDARDS-TRACK] This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK] This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity. The permanent identifier is an optional feature that may be used by a CA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed. The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA. [STANDARDS-TRACK] Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability. [STANDARDS-TRACK] This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340. It motivates the setting of a Service Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g., network address translators and firewalls). This document updates the specification provided in RFC 4340. [STANDARDS-TRACK] This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g., a Network Address Port Translator or a DCCP server behind a firewall), where peering endpoints need to initiate communication in a near- simultaneous manner to establish necessary middlebox state. [STANDARDS-TRACK] This document defines a set of requirements for NATs handling the Datagram Congestion Control Protocol (DCCP). These requirements allow DCCP applications, such as streaming applications, to operate consistently, and they are very similar to the TCP requirements for NATs, which have already been published by the IETF. Ensuring that NATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the use of the Quick-Start mechanism by the Datagram Congestion Control Protocol (DCCP). DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP is intended for applications such as streaming media, Internet telephony, and online games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID 2, CCID 3, and CCID 4. Quick-Start enables a DCCP sender to cooperate with Quick-Start routers along the end-to-end path to determine an allowed sending rate at the start of a connection and, at times, in the middle of a DCCP connection (e.g., after an idle or application- limited period). The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. This memo defines an Experimental Protocol for the Internet community. Federal Information Processing Standard, FIPS Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP. New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, achieving a property called "resource pooling" where a bundle of links effectively behaves like one shared link with bigger capacity. This would increase the overall efficiency of the network and also its robustness to failure. This document presents a congestion control algorithm that couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. This document defines an Experimental Protocol for the Internet community. This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. This document also updates the Session Description Protocol (SDP) information for DCCP defined in RFC 5762. [STANDARDS-TRACK] TCP/IP 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 TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community. The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP. This document updates RFC 3711, the Secure Real-time Transport Protocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted. This document describes a simple method of encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges. Please note that this document only describes the functionality required within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document. This document covers only end-hosts and not tunneling (egress or ingress) endpoints. This document discusses both use cases and operational experience with Multipath TCP (MPTCP) in real networks. It lists several prominent use cases where Multipath TCP has been considered and is being used. It also gives insight to some heuristics and decisions that have helped to realize these use cases and suggests possible improvements. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. TCP/IP 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 TCP/IP session would improve resource usage within the network and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., a reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC 6824, through clarifications and modifications primarily driven by deployment experience. n.d. 3GPP n.d.

Differences from Multipath TCP Multipath DCCP is similar to Multipath TCP , in that it extends the related basic DCCP transport protocol with multipath capabilities in the same way as Multipath TCP extends TCP . However, because of the differences between the underlying TCP and DCCP protocols, the transport characteristics of MPTCP and MP-DCCP are different. 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. TCP and DCCP protocol comparison

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 boundaries	no	yes
Path MTU discovery	yes	yes
Fragmentation	yes	no
SYN flood protection	yes	no
Half-open connections	yes	no

Consequently, the multipath features, shown in , 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. MPTCP and MP-DCCP protocol comparison

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

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 ) facilitates adding optional mechanisms for data stream packet reordering at the receiver. Information from the MP_RTT multipath option (), DCCP path sequencing and the DCCP Timestamp Option provide further means for advanced reordering approaches, e.g., as described in . 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.

Authors' Addresses Deutsche Telekom

Deutsche-Telekom-Allee 9 Darmstadt 64295 Germany Markus.Amend@telekom.de

Karlstad University

Universitetsgatan 2 Karlstad 651 88 Sweden anna.brunstrom@kau.se

Karlstad University

Universitetsgatan 2 Karlstad 651 88 Sweden andreas.kassler@kau.se

City University of London

Northampton Square London United Kingdom veselin.rakocevic.1@city.ac.uk

BT

Adastral Park Martlesham Heath IP5 3RE United Kingdom stephen.h.johnson@bt.com