DCCP Extensions for Multipath Operation with Multiple Addresses

3.2.1. MP_CONFIRM

              1          2          3           4          5
   01234567 89012345 67890123 45678901 23456789 01234567 89012345
  +--------+--------+--------+--------+--------+--------+--------+
  |00101110| Length |00000000| List of options ...
  +--------+--------+--------+--------+--------+--------+--------+
   Type=46           MP_OPT=0

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

3.2.2. MP_JOIN

              1          2          3
   01234567 89012345 67890123 45678901
  +--------+--------+--------+--------+
  |00101110|00001100|00000001| Addr ID|
  +--------+--------+--------+--------+
  | Path Token                        |
  +--------+--------+--------+--------+
  | Nonce                             |
  +--------+--------+--------+--------+
   Type=46  Length=12 MP_OPT=1

The MP_JOIN option is used 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 "Address ID". This is an identifier 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 (Section 3.2.9) 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 (Section 3.2.8), 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 Section 3.3.¶

3.2.3. MP_FAST_CLOSE

Regular DCCP has the means of sending a Close or Reset signal to abruptly close a connection. With MP-DCCP, a regular Close or Reset only has the scope of the subflow; it will only close the applicable subflow and will not affect the remaining subflows concurrently in use on other paths. MP-DCCP's 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 option.¶

              1          2          3
   01234567 89012345 67890123 45678901 23456789
  +--------+--------+--------+--------+--------+
  |00101110| Length |00000010| Key Data ...
  +--------+--------+--------+--------+--------+
   Type=46           MP_OPT=2

For being effective, the MP_FAST_CLOSE 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 multi-path 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 multi-path connection immediately terminates. Upon reception of the MP_FAST_CLOSE and validation of the Key Data at the peer host, a DCCP Reset packet is replied on all subflows to the initiating host again with Reset Code 13. The peer host can now close the whole MP-DCCP connection (it transitions directly to CLOSED state).¶

3.2.4. MP_KEY

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +---------------+---------------+---------------+---------------+
  |0 0 1 0 1 1 1 0|     Length    |0 0 0 0 0 0 1 1| Key Type (1)  |
  +---------------+---------------+---------------+---------------+
  |  Key Data (1) |  Key Type (2) |  Key Data (2) | ....
  +---------------+---------------+---------------+---------------+
      Type=46                         MP_OPT=3

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

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 Section 3.3¶

3.2.5. MP_SEQ

              1          2          3           4          5
   01234567 89012345 67890123 45678901 23456789 01234567 89012345
  +--------+--------+--------+--------+--------+--------+--------+
  |00101110|00001001|00000100| Multipath Sequence Number
  +--------+--------+--------+--------+--------+--------+--------+
  |                 |
  +--------+--------+
   Type=46  Length=9 MP_OPT=4

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

3.2.6. MP_HMAC

              1          2          3           4
   01234567 89012345 67890123 45678901 23456789 01234567
  +--------+--------+--------+--------+--------+--------+
  |00101110|00010111|00000101| HMAC-SHA256 (20 bytes) ...
  +--------+--------+--------+--------+--------+--------+
   Type=46  Length=23 MP_OPT=5

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

The "Key" used for the HMAC computation is the derived key (d-key) described in Section 3.2.4, while the HMAC "Message" is a concatenation of¶

• 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.¶

3.2.7. MP_RTT

              1          2          3           4          5
   01234567 89012345 67890123 45678901 23456789 01234567 89012345
  +--------+--------+--------+--------+--------+--------+--------+
  |00101110|00001100|00000110|RTT Type| RTT
  +--------+--------+--------+--------+--------+--------+--------+
  |        | Age                               |
  +--------+--------+--------+--------+--------+
   Type=46  Length=12 MP_OPT=6

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

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

Raw RTT (=0)

Raw RTT value of the last Datagram Round-Trip 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.¶

3.2.8. MP_ADDADDR

The MP_ADDADDR option announces additional addresses (and, optionally, ports) on which a host can be reached. This option can be used at any time during an existing DCCP connection, when the sender wishes to enable multiple paths and/or when additional paths become available. Multiple instances of this option within a packet advertise simultaneously new addresses.¶

Length is variable depending on IPv4 or IPv6 and whether port number is used and 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, MP-DCCP SHOULD attempt to connect to the specified address 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 Section 3.2.6. 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.¶

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +---------------+---------------+-------+-------+---------------+
  |     Type      |     Length    |0 0 0 0 0 1 1 1|  Address ID   |
  +---------------+---------------+-------+-------+---------------+
  |          Address (IPv4 - 4 bytes / IPv6 - 16 bytes)           |
  +-------------------------------+-------------------------------+
  |   Port (2 bytes, optional)    | + MP_HMAC option
  +-------------------------------+
       Type=46       Length=var       MP_OPT=7

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

All Address IDs learned via either MP_JOIN or 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 (Section 3.2.2) 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 Section 4.¶

The reception of an MP_ADDADDR message is acknowledged using MP_CONFIRM (Section 3.2.1). 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 (Section 3.2.9).¶

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

3.2.9. MP_REMOVEADDR

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

This is achieved through the Remove Address (MP_REMOVEADDR) option 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 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 Section 3.2.6. 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 reception of an MP_REMOVEADDR message is acknowledged using MP_CONFIRM (Section 3.2.1). Using this mechanism reliable exchange of address information is ensured.¶

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

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

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-------+---------------+
|   Type = 46   |  Length = 4   |   MP_OPT = 8  |   Address ID  |
+---------------+---------------+-------+-------+---------------+
+ 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 Section 3.4.¶

3.2.10. MP_PRIO

In the event that a single specific path out of the set of available paths shall be treated with higher priority compared to the others 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 option, shown below, can be used to set a priority flag for the path which is specified by the AddrID field that uniquely identifies the path. The option can be sent over any path.¶

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+-------+-------+--------------+
   |   Type = 46   |  Length = 4   |   MP_OPT = 9  |    AddrID    |
   +---------------+---------------+-------+-------+--------------+
   |(resvd)|  Prio |
   +---------------+

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 Table 4).¶

3.2.11. MP_CLOSE

              1          2          3
   01234567 89012345 67890123 45678901 23456789
  +--------+--------+--------+--------+--------+
  |00101110| Length |00001010| Key Data ...
  +--------+--------+--------+--------+--------+
   Type=46           MP_OPT=10

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 [RFC4340] 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 Section 3.2.3, no single-sided abrupt termination is applied.¶