DCCP Extensions for Multipath Operation with Multiple Addresses

MP-DCCP Protocol The DCCP protocol feature list () is updated by adding a new Multipath feature with Feature number 10, as shown in . Multipath feature

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

Rec'n Rule:: The reconciliation rule used for the feature. SP indicates the server-priority.
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.

This specification adds a DCCP protocol option as defined in (, Section 5.8) providing 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

Note to the RFC Editor: Please update the Number and Type with the value assigned by IANA.

Multipath Capable Feature A DCCP endpoint negotiates the Multipath Capable Feature to determine whether multipath extensions can be enabled for a DCCP connection. The Multipath Capable feature (MP_CAPABLE) has feature number 10 and follows the structure for features given in Section 6. Beside the negotiation of the feature itself, also one or several values can be exchanged. The value field specified here for the Multipath Capable feature has a length of one-byte and can be repeated several times within the DCCP option for feature negotiation if required for example to announce support of different versions of the protocol. For that, the leftmost four bits in specify the compatible version of the MP-DCCP implementation and MUST be set to 0 following this specification. The four bits following the Version field are unassigned in version 0 and MUST be set to zero by the sender and MUST be ignored by the receiver.

Format of the Multipath Capable feature value field The setting of the MP_CAPABLE feature MUST follow the server-priority reconciliation rule described in (, Section 6.3.1). This allows multiple versions to be specified in order of priority. The negotiation MUST be a part of the initial handshake procedure described in . No subsequent re-negotiation of the MP_CAPABLE feature is allowed for 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 added to an existing MP-DCCP connection MUST use the 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 and follows the negotiation example shown in Section 6.5. For better understanding, this example uses the unspecified MP-DCCP versions 1 and 2 in addition to the MP-DCCP version 0 specified in this document:

Example of MP-DCCP support negotiation using MP_CAPABLE DCCP-Resp + Confirm L(MP_CAPABLE, 1, 2 1 0) <----------------------------------- * agreement on version = 1 * ]]>

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

Unlike the example in , this document only allows the negotiation of MP-DCCP version 0, which means that client and server must support it. 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 fallback to regular DCCP or MUST close the connection. Further details are specified in

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

Multipath option format The fields used by the multipath option are described in . MP_OPT refers to an Multipath option. 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	var	11 =MP_EXP	Experimental for private use
46	TBD	>11	Reserved for future MP options.

Future MP options could be defined in a later version or extension to this specification. These operations are largely inspired by the signals defined in .

MP_CONFIRM

Format of the MP_CONFIRM option Some multipath options require confirmation from the remote peer (see ). Such options will be retransmitted by the sender until an 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. Multipath options could arrive out-of-order, therefore multipath options defined in MUST be sent in a DCCP datagram with MP_SEQ . This allows a receiver to identify whether multipath options are associated with obsolete datasets (information carried in the option header) that would otherwise conflict with newer datasets. In the case of MP_ADDADDR or 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 multipath option is detected at the receiver if a previous multipath option referring to the same dataset contained a higher sequence number in the MP_SEQ. An MP_CONFIRM MAY be generated for multipath options that are identified as outdated. Similarly an MP_CONFIRM could arrive out of order. The associated MP_SEQ received MUST be echoed to ensure that the most recent multipath option is confirmed. This protects from inconsistencies that could occur, e.g. if three MP_PRIO options are sent one after the other on one path in order to first set the path priority to 0, then to 1 and finally to 0 again. Without an associated MP_SEQ, a loss of the third MP_PRIO option and a loss of the MP_CONFIRM of the second update and the third update would cause the sender to incorrectly interpret that the priority value was set to 0 without recognizing that the receiver has applied priority value 1. The length of the MP_CONFIRM option and the path over which the option is sent depend on the confirmed multipath options and the received MP_SEQ, which are both copied verbatim and appended as a list of confirmations. The list is structured by first listing the received MP_SEQ followed by the related multipath option or options to confirm. The same rules apply when multipath options with different MP_SEQs are confirmed at once. This could 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_2 + MP_ADDADDR + MP_SEQ_1 + MP_PRIO. The order of the confirmed multipath options in the list of confirmations MUST reflect the incoming order at the host who sends the MP_CONFIRM, with the most recent suboption received listed first. This could allow the host receiving the MP_CONFIRM to verify that the options were applied in the correct order and to take countermeasures if they were not, e.g., if an MP_REMOVEADDR overtakes an MP_ADDADDR that refers to the same dataset. 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 (any path can be used) 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, the first DCCP-Data is sent from Host A to Host B with option MP_PRIO set to 4. Host A subsequently sends the second DCCP-Data with option MP_PRIO set to 1. In this case, 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 to add a new subflow to an existing MP-DCCP connection and REQUIRES a successful establishment of the first subflow using MP_KEY. The Connection Identifier (CI) is the one from the peer host, which was previously exchanged with the MP_KEY option. MP_HMAC MUST be set when using MP_JOIN within a DCCP-Response packet (See for details). 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 was changed in transit by a middlebox. The 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 MUST 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 CI, the Nonce value builds the basis to calculate the HMAC used in the handshaking process as described in . If the CI cannot be verified by the receiving host during a handshake negotiation, the new subflow MUST be closed, as specified in .

MP_FAST_CLOSE DCCP can send a Close or Reset signal to abruptly close a connection. Using MP-DCCP, a regular Close or Reset only has the scope of the subflow over which a signal was received. As such, it will only close the subflow and does not affect other remaining subflows or the MP-DCCP connection (unless it is the last subflow). This permits break-before-make handover between subflows. In order to provide an MP-DCCP-level "reset" and thus allow the abrupt closure of the MP-DCCP connection, the MP_FAST_CLOSE suboption can be used.

Format of the MP_FAST_CLOSE suboption When host A wants to abruptly close an MP-DCCP connection with host B, it will send out the MP_FAST_CLOSE. The MP_FAST_CLOSE suboption MUST be sent from host A on all subflows using a DCCP-Reset packet with Reset Code 13. The requirement to send the MP_FAST_CLOSE on all subflows increases the probability that host B will receive the MP_FAST_CLOSE to take the same action. To protect from unauthorized shutdown of a MP-DCCP connection, the selected Key Data of the peer host during the handshaking procedure is carried by the MP_FAST_CLOSE option. After sending the MP_FAST_CLOSE on all subflows, host A will tear down all subflows and the multipath DCCP connection immediately terminates. Upon reception of the first MP_FAST_CLOSE with successfully validated Key Data, host B will send a DCCP Reset packet response on all subflows to host A with Reset Code 13 to clean potential middlebox states. Host B will then tear down all subflows and terminate the MP-DCCP connection.

MP_KEY

Format of the MP_KEY suboption The MP_KEY suboption is used to exchange a Connection Identifier (CI) and key material between hosts for a given connection. The CI is a unique number that is configured per host during the initial exchange of a connection with MP_KEY and is necessary to connect other DCCP subflows to an MP-DCCP connection with MP_JOIN (). Its size of 32-bits also defines the maximum number of simultaneous MP-DCCP connections in a host to 2^32. According to the Key related elements of the MP_KEY suboption, the Length varies between 17 and 73 Bytes for a single-key message, and up to 115 Bytes when all specified Key Types 0-2 are provided. The Key Type field specifies the type of the following key data. The set of 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. The full potential of ECDHE use is realized when it is combined with peer authentication technologies to protect against men-in-the-middle attacks. This can be achieved, for example, with separate use and verification of certificates issued by a certificate authority.

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.

Multiple keys are only permitted in the DCCP-Request message of the handshake procedure for the first subflow. This allows the hosts to agree on a single key type to be used, as described in It is possible that not all hosts will have all key types. If the key type cannot be agreed in the handshake procedure, the MP-DCCP connection MUST fall back to not using MP-DCCP, as indicated in .

MP_SEQ

Format of the MP_SEQ suboption The MP_SEQ suboption is used for end-to-end 48-bit 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 independent from the path individual sequence number space and MUST be sent with all DCCP-Data and DCCP-DataACK packets. When the sequence number space is exhausted, the sequence number MUST be wrapped. provides guidance on selecting an appropriately sized sequence number space according to the maximum segment lifetime of TCP. 64 bits is the recommended size for TCP to avoid the sequence number space going through within the segment lifetime. For DCCP, the Maximum Segment Lifetime is the same as that of TCP as specified in . Compared to TCP, the sequence number for DCCP is incremented per packet rather than per byte transmitted. For this reason, the 48 bits chosen in MP_SEQ are considered sufficiently large.

MP_HMAC

Format of the MP_HMAC suboption The MP_HMAC suboption is used to provide authentication for the MP_ADDADDR, and MP_REMOVEADDR suboptions. In addition, it provides authentication for subflows joining an existing MP_DCCP connection, as described in the second and third step of the handshake of a subsequent subflow in . For this specification of MP-DCCP, 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" for MP_JOIN, MP_ADDADDR and MP_REMOVEADDR is a concatenation of:

for MP_JOIN: The nonces of the MP_JOIN messages for which authentication shall be performed. Depending on whether Host A or Host B performs the HMAC-SHA256 calculation, it is carried out as follows: MP_HMAC(A) = HMAC-SHA256(Key=d-key(A), Msg=RA+RB) MP_HMAC(B) = HMAC-SHA256(Key=d-key(B), Msg=RB+RA) An usage example is shown in .
for MP_ADDADDR: The Address ID with associated IP address and if defined port, otherwise two octets of value 0. IP address and port MUST be used in network byte order (NBO). Depending on whether Host A or Host B performs the HMAC-SHA256 calculation, it is carried out as follows: MP_HMAC(A) = HMAC-SHA256(Key=d-key(A), Msg=Address ID+NBO(IP)+NBO(Port)) MP_HMAC(B) = HMAC-SHA256(Key=d-key(B), Msg=Address ID+NBO(IP)+NBO(Port))
for MP_REMOVEADDR: Solely the Address ID. Depending on whether Host A or Host B performs the HMAC-SHA256 calculation, it is carried out as follows: MP_HMAC(A) = HMAC-SHA256(Key=d-key(A), Msg=Address ID) MP_HMAC(B) = HMAC-SHA256(Key=d-key(B), Msg=Address ID)

MP_JOIN, MP_ADDADDR and MP_REMOVEADDR can co-exist or be used multiple times within a single DCCP packet. All these multipath options require an individual MP_HMAC option. This ensures that the MP_HMAC is correctly associated. Otherwise, the receiver cannot validate multiple MP_JOIN, MP_ADDADDR or MP_REMOVEADDR. Therefore, a MP_HMAC 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 is associated with the MP_ADDADDR suboption. On the receiver side, the HMAC validation of the suboptions MUST be carried out according to the sending sequence in which the associated MP_HMAC follows a suboption. If the suboption cannot be validated by a receiving host because the HMAC validation fails, the subsequent handling depends on which suboption was being verified. If the suboption to be authenticated was either MP_ADDADDR or MP_REMOVEADDR, the receiving host MUST silently ignore it (see and ). If the suboption to be authenticated was MP_JOIN, the subflow MUST be closed (see ). In the event that an MP_HMAC cannot be associated with a suboption, unless it is an MP_HMAC sent in DCCP-Ack in response to a DCCP-Response packet containing an MP_JOIN option, this MP_HMAC MUST be ignored.

MP_RTT

Format of the MP_RTT suboption The MP_RTT suboption is used to transmit RTT values and age (represented in milliseconds) that belong to the path over which this information is transmitted. This information is 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. This covers a period of approximately 1193 hours. The Field RTT type indicates the type of RTT estimation, according to the following description:

Raw RTT (=0): Raw RTT value of the last Datagram Round-Trip

Min RTT (=1): Min RTT value over a given period

Max RTT (=2): Max RTT value over a given period

Smooth RTT (=3): Averaged RTT value over a given period

Each CCID specifies the algorithms and period applied for their corresponding RTT estimations.The availability of the above described types, to be used in the MP_RTT option, depends on the CCID implementation in place.

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.

An example of a flow showing the exchange of path individual RTT information is provided in . RTT1 refers to the first path and RTT2 to the second path. The RTT values could be extracted from the sender's Congestion Control procedure and are conveyed to the receiving host using the 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 the case that the path individual RTTs are symmetric in the down- and uplink directions and there is no jitter, 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) by which a host can be reached. This can be sent at any time during an existing MP-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 can simultaneously advertise new addresses. The 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 final 2 octets, optionally specify the DCCP port number to use, and their presence 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 could 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 host MUST assume that any attempt to connect to the specified address uses the port already used by the subflow on which the MP_ADDADDR signal was sent. Along with the MP_ADDADDR option an 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 number that precede the HMAC in the MP_ADDADDR option. If the port number is not present in the MP_ADDADDR option, the HMAC message will 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 an MP_SEQ MUST be ensured in a DCCP datagram in which MP_ADDADDR is sent, as described in .

Format of the MP_ADDADDR suboption Each address has an Address ID that could be used for uniquely identifying the address within a connection for address removal. Each host maintains a list of unique Address IDs and it manages these as it wishes. 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 can be stored by the receiver in a data structure that gathers all the Address-ID-to-address mappings for a connection (identified by a CI pair). In this way, there is a stored mapping between the Address ID, the observed source address, and the CI pair for future processing of control information for a connection. Note that an implementation MAY discard incoming address advertisements - for example, to avoid 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 the sender MAY choose to refresh advertisements periodically. A host MAY advertise private addresses, e.g., because there is a NAT on the path. It is desirable to allow this, since there could be cases where both hosts have additional interfaces on the same private network. The MP_JOIN handshake to create a new subflow () provides mechanisms to minimize security risks. The MP_JOIN message contains a 32-bit CI that uniquely identifies a connection to the receiving host. If the CI is unknown, the host MUST send a DCCP-Reset. Further security considerations around the issue of MP_ADDADDR messages that accidentally misdirect, or maliciously direct, new MP_JOIN attempts are discussed in . If a sending host of an MP_ADDADDR knows that no incoming subflows can be established at a particular address, an MP_ADDADDR SHOULD NOT announce that address unless the sending host has new knowledge about the possibility to do so. This 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 (). This ensures reliable exchange of address information. A host MAY 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 at connection set up that the 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 wishes to trigger a new incoming connection attempt on a previously advertised address/port combination can therefore refresh the 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. The peer can remove a previously added address with an Address ID from a connection using the Remove Address (MP_REMOVEADDR) suboption. This will 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 using a 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 modified 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. A receiver MUST include a MP_SEQ in a DCCP datagram that sends an MP_REMOVEADDR. Further details are given in . The reception of an MP_REMOVEADDR message is acknowledged using MP_CONFIRM (). This ensures reliable exchange of address information. To avoid inconsistent states, the sender releases the address ID only after MP_REMOVEADDR has been confirmed. The sending and receiving of this message SHOULD trigger the closing procedure described in between the client and the server, respectively on the affected subflow(s) (if possible). This helps remove middlebox state, before removing any local state. Address removal is done by Address ID to allow the use of NATs and other middleboxes that rewrite source addresses. If there is no address at the requested Address ID, the receiver will silently ignore the request.

Format of the MP_REMOVEADDR suboption followed by MP_HMAC option ]]> A subflow that is still functioning MUST be closed with a DCCP-Close exchange as in regular DCCP, rather than using this option. For more information, see .

MP_PRIO The path priority SHOULD be considered as hints for the packet scheduler when making decisions which path to use for payload traffic. When a single specific path from the set of available paths is treated with higher priority compared to the others when making scheduling decisions for payload traffic, a host can signal such change in priority to the peer. This could be used when there are different costs for using different paths (e.g., WiFi is free while cellular has limit on volume, 5G has higher energy consumption). The priority of a path could also change, for example, when a mobile host runs out of battery, the usage of only a single path may be the preferred choice of the user. The MP_PRIO suboption, shown below, can be used to set a priority flag for the subflow over which the suboption is received.

Format of the MP_PRIO suboption The following values are available for the 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: The path can 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 traffic first 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 will be used 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 will be used only if the Wi-Fi path is not available. 3) Setting Wi-Fi path to Primary and Cellular path to Primary. In this case, both paths can be used when making packet scheduling decisions. If not specified, the default behavior is to always use a path for packet scheduling decisions (MP_PRIO=3), when the path has been established and added to an existing MP-DCCP connection. At least one path ought to have a MP_PRIO value greater or equal to one for it to be allowed to send on the connection. It is RECOMMENDED to update at least one path to a non-zero MP_PRIO value when an MP-DCCP connection enters a state where all paths remain with an MP_PRIO value of zero. This helps an MP-DCCP connection to schedule when the multipath scheduler strictly respects MP_PRIO value 0. MP_PRIO is assumed to be exchanged reliably using the MP_CONFIRM mechanisms (see ). The relative ratio of the primary path values 3-15 depends on the path usage strategy, which is described in more detail in . In the case of path mobility (), only one path can be used at a time and MUST be the appropriate one that has the highest available priority value including also the prio numbers 1 and 2. In the other case of concurrent path usage (), the definition is up to the multipath scheduler logic. A MP_SEQ () MUST be present in a DCCP datagram in which MP_PRIO is sent. Further details are given in .

MP_CLOSE

Format of the MP_CLOSE suboption An MP-DCCP connection can be gracefully closed by sending and MP_CLOSE to the 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). When a DCCP-CloseReq is used, the following DCCP-Close MUST also carry the MP_CLOSE to avoid keeping a state in the sender of the DCCP-CloseReq. At the initiator of the DCCP-CloseReq, all sockets including the MP-DCCP connection socket, transition to CLOSEREQ state. To protect from unauthorized shutdown of a multi-path connection, the selected Key Data of the peer host during the handshaking procedure MUST be included in by the MP_CLOSE option and must be validated by the peer host. Note, the Key Data is different between MP_CLOSE option carried by DCCP-CloseReq or DCCP-Close. On reception of the 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. The MP-DCCP connection socket on the host sending the DCCP-Close reflects the state of the initial subflow 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 Multipath option MP_EXP for private use This section reserves a Multipath option to define and specify any experimental additional feature for improving and optimization of the MP-DCCP protocol. This option could be applicable to specific environments or scenarios according to potential new requirements and is meant for private use only. MP_OPT feature number 11 is specified with an exemplary description as below:

Format of the MP_EXP suboption The Data field can carry any data according to the foreseen use by the experimenters with a maximum length of 252 Bytes.

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

Example MP-DCCP handshake | |<------------------- MP_KEY(CI-B + Key-B) -----------| | DCCP-Response + Confirm L (MP_CAPABLE, ...) | | | | | DCCP-Ack | | |---------------------------------------------------->| |<----------------------------------------------------| | DCCP-Ack | | | | | | |DCCP-Request + Change R(MP_CAPABLE,...)| | |--- MP_JOIN(CI-B,RA) ----------------->| | |<------MP_JOIN(CI-A,RB) + MP_HMAC(B)---| | |DCCP-Response+Confirm L(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 a Host-specific CI-A and a Key-A for each of the supported key types as described in . CI-A is a unique identifier during the lifetime of a MP-DCCP connection.
Host B sends a DCCP-Response with Confirm feature for MP-Capable and the MP_Key option with a unique Host-specific CI-B and 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 to confirm the proper key exchange.
Host B sends a DCCP-Ack to complete the handshake and set both connection ends to the OPEN state.

It should be noted that DCCP is protected against corruption of DCCP header data (section 9 of ), so no additional mechanisms beyond the general confirmation are required to ensure that the header data has been properly received. 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 CI-B, obtained during the initial handshake. 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 CI-A 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 the nonce received with MP_JOIN(A) and the local nonce RB 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 the local nonce RA and the 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 (MP_ADDADDR) 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 MP_SEQ option with the sequence number (seqno 12) for this message according to .

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 (MP_REMOVEADDR) 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 MP_SEQ option with the sequence number (seqno 33) for this message according to .

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

Closing an MP-DCCP connection When a host wants to close an existing subflow but not the whole MP-DCCP connection, it MUST initiate the regular DCCP connection termination procedure as described in Section 5.6 of , 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 MUST use an appropriate DCCP reset code as specified in IANA for DCCP operations. 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. A host terminates an MP-DCCP connection using the DCCP connection termination specified in section 5.5 of 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 fallback. 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 Multipath options, 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 do not carry the MP_CAPABLE feature, the MP-DCCP connection will not be established and the handshake SHOULD fallback to regular DCCP (if this is not possible it MUST be closed). A connection SHOULD fallback to regular DCCP if the endpoints fail to agree on a protocol version to use during the Multipath Capable feature negotiation. This 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 fallback to regular DCCP. The fallback procedure to regular DCCP MUST be also applied if the MP_KEY Key Type cannot be negotiated. 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. Reception of a non-verifiable MP_HMAC () or an invalid CI used in MP_JOIN () during flow establishment MUST cause the subflow to be closed. The subflow closing procedure MUST be also applied if a final ACK carrying MP_KEY with wrong Key-A/Key-B is received or MP_KEY option is malformed. 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 data is dropped due to corruption for an MP-DCCP connection, the affected subflow MAY be closed.

State Diagram The MP-DCCP per subflow state transitions to a large extent follow the state transitions defined for DCCP in , with some modifications due to the MP-DCCP four-way handshake and fast close procedures. The state diagram below illustrates the most common state transitions. The diagram is illustrative. For example, there are arcs (not shown) from several additional states to TIMEWAIT, contingent on the receipt of a valid DCCP-Reset. The states transitioned when moving from the CLOSED to OPEN state during the four-way handshake remain the same as for DCCP, but it is no longer possible to transmit application data while in the REQUEST state. The fast close procedure can be triggered by either the client or the server and results in the transmission of a Reset packet. The fast close procedure moves the state of the client and server directly to TIMEWAIT and CLOSED, respectively.

Congestion Control Considerations Senders MUST manage per-path congestion status, and avoid to sending more data on a given path than congestion control for each path allows.

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. The DCCP application interface SHOULD allow the application to discover the current MPS. This reflects the current supported largest size for the data stream that can be used across the set of all active MP-DCCP subflows.

Maximum number of Subflows In theory, an infinite number of subflows can be created within an MP-DCCP connection, as there is no element in the protocol that represents a restriction. In practical scenarios, however, there will be resource limitations on the host or use cases that do not benefit from additional subflows. It is RECOMMENDED to limit the number of subflows in implementations and to reject incoming subflow requests with a DCCP-Reset using the Reset Code "too busy" as specified in if this limit is exceeded.

Path usage strategies MP-DCCP can be configured to realize one of several strategies for path usage, via selecting one DCCP subflow of the multiple DCCP subflows within a MP-DCCP connection for data transmission. This can be a dynamic process further facilitated by the means of DCCP and MP-DCCP defined options such as path preference using MP-PRIO, adding or removing DCCP subflows using MP_REMOVEADDR, MP_ADDADDR or DCCP-Close/DCCP-Reset and also path metrics such as packet-loss-rate, CWND or RTT provided by the Congestion Control Algorithm. Selecting an appropriate method can allow MP-DCCP to realize different path utilization strategies that make MP-DCCP suitable for end-to-end implementation over the Internet or in controlled environments such as Hybrid Access or 5G ATSSS.

Path mobility The path mobility strategy provides the use of a single path with a seamless handover function to continue the connection when the currently used path is deemed unsuitable for service delivery. Some of the DCCP subflows of a MP-DCCP connection might become inactive due to either the occurrence of certain error conditions (e.g., DCCP timeout, packet loss threshold, RTT threshold, closed/removed) or adjustments from the MP-DCCP user. When there is outbound data to send and the primary path becomes inactive (e.g., due to failures) or de-prioritized, the MP-DCCP endpoint SHOULD try to send the data through an alternate path with a different source or destination address (depending on the point of failure), if one exists. This process SHOULD respect the path priority configured by MP_PRIO or if not available pick the most divergent source-destination pair from the original used source-destination pair.

Note: Rules for picking the most appropriate source-destination pair are an implementation decision and are not specified within this document. Path mobility is supported in the current Linux reference implementation .

Concurrent path usage Different to a path mobility strategy, the selection between MP-DCCP subflows is a per-packet decision that is a part of the multipath scheduling process. This method would allow multiple subflows to be simultaneously used to aggregate the path resources to obtain higher connection throughput. In this scenario, the selection of congestion control, per-packet scheduling and potential re-ordering method determines a concurrent path utilization strategy and result in a particular transport characteristic. A concurrent path usage method uses a scheduling design that could seek to maximize reliability, throughput, minimizing latency, etc. Concurrent path usage over the Internet can have implications. When a Multipath DCCP connection uses two or more paths, there is no guarantee that these paths are fully disjoint. When two (or more) subflows share the same bottleneck, using a standard congestion control scheme could result in an unfair distribution of the capacity with the multipath connection using more capacity than competing single path connections.
Multipath TCP uses the coupled congestion control Linked Increases Algorithm (LIA) specified in the experimental specification to solve this problem. This scheme could also be specified for Multipath DCCP. The same applies to other coupled congestion control schemes that have been proposed for Multipath TCP such as Opportunistic Linked Increases Algorithm . The specification of scheduling for concurrent multipath and related the congestion control algorithms and re-ordering methods for use in the general Internet are outside the scope of this document. If, and when, the IETF specifies a method for concurrent usage of multiple paths for the general Internet, the framework specified in this document could be used to provide an IETF recommended method for MP-DCCP.

Version	Value	Specification
0	0000 suggested	[ThisDocument]
Unassigned	0001 - 1111

Multipath Option	Name	Description
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 suboption for private use
MP_OPT>11	Unassigned	Reserved for future Multipath Options

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

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

Type	Name	Meaning
0	Plain Text	Plain text key
1	ECDHE-C25519-SHA256	ECDHE with SHA256 and Curve25519
2	ECDHE-C25519-SHA512	ECDHE with SHA512 and Curve25519
3-255	Unassigned	Reserved for future use