3.2.1.MP_CONFIRM

Some Multipath Options require confirmation from the remote peer (seeTable 4) for which MP_CONFIRM is specified.¶

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

Multipath Options that require confirmation will be retransmitted by the sender until an MP_CONFIRM is received or the confirmation of options is considered irrelevant because the data contained in the options has already been replaced by newer information.¶

This can happen, for example, with an MP_PRIO option if the path prioritizationis changed while the previous prioritization has not yet been confirmed. The further processingof 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 inTable 4MUST be sent in a DCCP datagram with MP_SEQ (seeSection 3.2.5). This allows a receiver to identify whetherMultipath 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 outdatedmultipath Option is detected at the receiver if a previous Multipath Option referring to the same dataset contained a higher sequence numberin the MP_SEQ. An MP_CONFIRMMAY be generated for Multipath Options that are identified as outdated.¶

Similarly, an MP_CONFIRM could arrive out of order. The associatedMP_SEQ receivedMUST 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 afterthe other on one path in order to first set the path priority to 0, then to 1, and finally to 0 again. Without an associatedMP_SEQ, a loss of the third MP_PRIO option and a loss of the MP_CONFIRM of the second update and the third update wouldcause the sender to incorrectly interpret that the priority value was set to 0 without recognizing that the receiver has appliedpriority 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 receivedMP_SEQ, which are both copied verbatim and appended as a list of confirmations. The list is structured by first listing the receivedMP_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 the following are received in short succession: a datagram with MP_PRIO and a first MP_SEQ_1 and another datagram with MP_ADDADDR and a second MP_SEQ_2. 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 confirmationsMUST reflect the incoming order at the host who sends the MP_CONFIRM, with the mostrecent suboption received listed first. This could allow the host receiving the MP_CONFIRM to verify that the options were applied in the correct orderand to take countermeasures if they were not, e.g., if an MP_REMOVEADDR overtakes an MP_ADDADDR that refers to the same dataset.¶

An example to illustrate the MP-DCCP confirm procedure for the MP_PRIO option is shown inFigure 7. Host A sends a DCCP-Request on path A2-B2 with an MP_PRIO option with value 1 and an 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).¶

          Host A                                     Host B------------------------                     ------------------------Address A1    Address A2                     Address B1    Address B2----------    ----------                     ----------    ----------     |             |                                   |       |     |             | DCCP-Request(seqno 1) + MP_PRIO(1)|       |     |             |------------------------------------------>|     |             |                                   |       |     |             | DCCP-Response +                   |       |     |             |<---- MP_CONFIRM(seqno 1, MP_PRIO) --------|     |             |                                   |       |

A second example that illustrates the same MP-DCCP confirm procedure but where an out-of-date option is also delivered is shown inFigure 8.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_PRIOset 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 Bignores this second MP_PRIO as the associated sequence number is earlier than the first. Host B sends a DCCP-Ack with sequence number 2 to confirm the receipt of the MP_PRIO(1).¶

          Host A                                     Host B------------------------                     ------------------------Address A1    Address A2                     Address B1    Address B2----------    ----------                     ----------    ----------     |             |                                   |       |     |             | DCCP-Data(seqno 1) +  MP_PRIO(4)  |       |     |             |------------                       |       |     |             |            \                      |       |     |             | DCCP-Data(seqno 2) +  MP_PRIO(1)  |       |     |             |--------------\--------------------------->|     |             |               \                   |       |     |             |                -------------------------->|     |             |                                   |       |     |             | DCCP-Ack +                        |       |     |             |<---- MP_CONFIRM(seqno 2, MP_PRIO) --------|     |             |                                   |       |

3.2.2.MP_JOIN

The MP_JOIN option is used to add a new subflow to an existing MP-DCCPconnection, and a successful establishment of the first subflow using MP_KEY isREQUIRED.¶

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

The CI is the one from the peer host,which was previously exchanged with the MP_KEY option.MP_HMACMUST be set when using MP_JOIN within a DCCP-Response packet; seeSection 3.2.6 for details. Similar to the setup of the first subflow, MP_JOIN also exchanges the Multipath Capable Feature MP_CAPABLE as described inSection 3.1. This procedure includes the DCCP Confirm principle and thus ensures a reliable exchange of the MP_JOIN in accordance withSection 6.6.4 of [RFC4340].¶

The MP_JOIN option includes an "Addr ID" (Address ID) generated by the sender of the option, which is used to identify the sourceaddress of this packet, even if the IP header was changed intransit by a middlebox. The value of this field is generatedby the sender andMUST map uniquely to a source IP address for thesending host. The Address ID allows address removal (Section 3.2.9)without the need to know the source address at the receiver,thus allowing address removal through NATs. The Address ID alsoallows correlation between new subflow setup attempts and addresssignaling (Section 3.2.8), to prevent setting up duplicate subflowson the same path, if an MP_JOIN and MP_ADDADDR are sent at the sametime.¶

The Address IDs of the subflow used in the initial DCCP Request/Response exchange ofthe first subflow in the connection are implicit and have the valuezero. A hostMUST store the mappings between Address IDs andaddresses for both itself and the remote host. An implementationwill also need to know which local and remote Address IDs areassociated with which established subflows for when addresses areremoved from a local or remote host. An Address IDMUST always be uniqueover the lifetime of a subflow and can only be reassigned if sender andreceiver no longer have them in use.¶

The Nonce is a 32-bit random value locally generated for every MP_JOIN option.Together with the derived key from both hosts' Key Data (as described inSection 3.2.4), the Nonce value builds the basis to calculate the Hash-based Message Authentication Code (HMAC) used in the handshake process (as described inSection 3.3) to avoid replay attacks.¶

If the CI cannot be verified by the receiving host during a handshake negotiation, the new subflowMUST be closed, as specified inSection 3.6.¶

3.2.3.MP_FAST_CLOSE

DCCP can send a Close or Reset signal to abruptly close aconnection. Using MP-DCCP, a regular Close or Reset only has the scope of thesubflow over which a signal was received. As such, it will only close the subflow and does notaffect other remaining subflows or the MP-DCCP connection (unless it is the lastsubflow).This permits break-before-make handover betweensubflows.¶

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

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

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 suboptionMUST 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 an unauthorized shutdown of an MP-DCCP connection, the selected Key Data of the peer host during the handshake procedure is carried by the MP_FAST_CLOSE option.¶

After sending the MP_FAST_CLOSE on all subflows, Host AMUST tear down all subflows, and the MP-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 BMUST then tear down all subflows and terminate the MP-DCCP connection.¶

3.2.4.MP_KEY

MP-DCCP protects against some on-path attacker as further outlined inSection 4. The basis of this protection is laid by an initial exchange of keys during the MP-DCCP connection setup, for which MP_KEY is introduced. The basis of this protection is laid by an initial exchange of keys during the MP-DCCP connection setup, for which MP_KEY is introduced.¶

                     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|      var      |0 0 0 0 0 0 1 1|     resvd     |+---------------+---------------+---------------+---------------+|                     Connection Identifier                     |+---------------+---------------+---------------+---------------+|  Key Type (1) |  Key Data (1) |  Key Type (2) |  Key Data (2) |+---------------+---------------+---------------+---------------+|  Key Type (3) | ...+---------------+---------------+    Type=46          Length         MP_OPT=3

The MP_KEY suboption is used to exchange a CI and key material betweenhosts (Host A and Host B) for a given connection.The CI is a unique number in the host for each multipath connection and is generated for inclusion in the first exchange of a connection with MP_KEY. With the CI, it is possible to connect other DCCP subflows to an MP-DCCP connection with MP_JOIN (Section 3.2.2). Its size of 32 bits also defines the maximum number of simultaneous MP-DCCP connections in a host to 2³².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 to82 bytes when all specified Key Types 0 and 255 are provided. The Key Type field specifies the type of the following Key Data. The set of Key Types are shown inTable 5.¶

Plain Text:

Key Data is exchanged in plain text between hosts (Host A and Host B), and the respective key parts (KeyA and KeyB) are used by each host to generate the derived key (d-key) by concatenating the two parts with the local key in front. That is,¶

Host A:

d-keyA=(KeyA+KeyB)¶

Host B:

d-keyB=(KeyB+KeyA)¶

Experimental:

This Key Type allows the use of other Key Data and can be used to validate other key exchange mechanisms for a possible future specification.¶

Multiple keys are only permitted in the DCCP-Request messageof the handshake procedure for the first subflow. This allows the hosts to agreeon a single Key Type to be used, as described inSection 3.3¶

It is possible that not all hosts will support all Key Types, and this specification does notrecommend or enforce the announcement of any particular Key Type within the MP_KEY option as this could have securityimplications. However, at least Key Type 0 (Plain Text)MUST be supported for interoperability testsin implementations of MP-DCCP. If the Key Type cannot be agreed in the handshake procedure, the MP-DCCP connectionMUST fall back to not using MP-DCCP, as indicated inSection 3.6.¶

3.2.5.MP_SEQ

DCCP[RFC4340] defines a packet sequencing scheme that continues to apply to the individual DCCP subflows within an MP-DCCP connection. However, for the operation of MP-DCPP, the order of packets within an MP-DCCP connectionMUST be known before assigning packets to subflows to apply the received Multipath Options in the correct order or to recognize whether delayed Multipath Options are obsolete. Therefore, MP_SEQ is introduced and can also be used to reorder data packets on the receiver side.¶

            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 suboption is used for end-to-end 48-bit datagram-based sequencenumbers of an MP-DCCP connection. The initial data sequencenumber (IDSN)SHOULD be set randomly[RFC4086]. As with the standard DCCPsequence number, the data sequence number should not start at zero but ata random value to make blind session hijacking more difficult; see alsoSection 7.2 of [RFC4340].¶

The MP_SEQ number space isindependent of the path individual sequence number space andMUST besent with all DCCP-Data and DCCP-DataACK packets.¶

When the sequence number space is exhausted, the sequence numberMUSTbe wrapped.[RFC7323] provides guidance on selecting an appropriatelysized sequence number space according to the Maximum Segment Lifetime (MSL) ofTCP. 64 bits is the recommended size for TCP to avoid the sequence numberspace going through within the segment lifetime. For DCCP, the MSL is the same as that of TCP as specified inSection 3.4 of [RFC4340].Compared to TCP, the sequence number for DCCP is incrementedper packet rather than per byte transmitted. For this reason, the 48 bitschosen in MP_SEQ are considered sufficiently large per the currentglobally routable maximum packet size (MPS) of 1500 bytes, which corresponds toroughly 375 pebibytes (PiBs) of data within the sequence number space.¶

3.2.6.MP_HMAC

MP-DCCP protects against some on-path attacker as further outlined inSection 4. Once an MP-DCCP connection has been established, the MP_HMAC option introduced here provides further protection based on the key material exchanged with MP_KEY when the connection is established.¶

            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 suboption is used to provide authentication for the MP_ADDADDR and MP_REMOVEADDR suboptions. In addition, it providesauthentication for subflows joining an existing MP_DCCP connection,as described in the second and third step of the handshake of asubsequent subflow inSection 3.3. For this specification of MP-DCCP,the HMAC code is generated according to[RFC2104] in combinationwith the SHA-256 hash algorithm described in[RFC6234], with theoutput in big-endian format truncated to the leftmost 160 bits (20 bytes). It is possiblethat other versions of MP-DCCP will define other hash algorithms in the future.¶

The "Key" used for the HMAC computation is the derived key (d-keyA for Host A or d-KeyB for Host B)described inSection 3.2.4, while the HMAC "Message" for MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR must be calculated in both hosts in order to protect the Multipath Option when sending and to validate the Multipath Option when receiving; it 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-keyA, Msg=RA+RB)¶

  • MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=RB+RA)¶

A usage example is shown inFigure 21.¶

• For MP_ADDADDR: The Address ID and Nonce with an associated IP address and a port, if defined; otherwise, 2 bytes of value 0. The IP address and portMUST 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-keyA, Msg=Address ID+Nonce+NBO(IP)+NBO(Port))¶

  • MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=Address ID+Nonce+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-keyA, Msg=Address ID+Nonce)¶

  • MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=Address ID+Nonce)¶

MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR can coexist or be used multiple timeswithin a single DCCP packet. All these Multipath Options require an individualMP_HMAC option. This ensures that the MP_HMAC is correctly associated.Otherwise, the receiver cannot validate multiple MP_JOIN, MP_ADDADDR, orMP_REMOVEADDR options. Therefore, an MP_HMACMUST directly follow its associated MultipathOption. In the likely case of sending an MP_JOIN together with an MP_ADDADDR, thisresults in concatenating MP_JOIN + MP_HMAC_1 + MP_ADDADDR + MP_HMAC_2, whereas thefirst MP_HMAC_1 is associated with the MP_JOIN and the second MP_HMAC_2 is associated with theMP_ADDADDR suboption.¶

On the receiver side, the HMAC validation of the suboptionsMUST be carried out according tothe sending sequence in which the associated MP_HMAC follows a suboption. If the suboptioncannot be validated by a receiving host because the HMAC validation fails (HMAC is wrong or missing), the subsequent handling dependson which suboption was being verified. If the suboption to be authenticated was eitherMP_ADDADDR or MP_REMOVEADDR, the receiving hostMUST silently ignore it (see Sections3.2.8 and3.2.9). If the suboption to be authenticated was MP_JOIN, the subflowMUST be closed (seeSection 3.6).¶

In the event that an MP_HMAC cannot be associated with a suboption, this MP_HMACMUST be ignored, unlessit is a single MP_HMAC that was sent in a DCCP-Ack corresponding to a DCCP response packet with MP_JOIN (see the penultimate arrow inFigure 21).¶

3.2.7.MP_RTT

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

            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 RTT and Age information is a 32-bit integer. This covers a period ofapproximately 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 -- the 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 inFigure 15. RTT1 refers to the first path and RTT2 to the second path. TheRTT values could be extracted from the sender's congestion control algorithm and are conveyed to the receiving host using the MP_RTT suboption. With the reception of RTT1and RTT2, the receiver is able to calculate the path_delta that corresponds tothe absolute difference of both values.In the case where the path individual RTTs are symmetric in the down-link and up-link 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.¶

MP-DCCP                   MP-DCCPSender                    Receiver+--------+  MP_RTT(RTT1)  +-------------+|   RTT1 |----------------|             ||        |                | path_delta= ||        |  MP_RTT(RTT2)  | |RTT1-RTT2| ||   RTT2 |----------------|             |+--------+                +-------------+

3.2.8.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 anytime during an existing MP-DCCP connection, when the sender wishes toenable 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 isused. This field is in the range between 12 and 26 bytes.¶

The Nonce is a 32-bit random value that is generated locally foreach MP_ADDADDR option and is used in the HMAC calculation processto prevent replay attacks.¶

The final 2 bytes optionally specify the DCCP port number touse, and their presence can be inferred from the length of the option.Although it is expected that the majority of use cases will use thesame port pairs as used for the initial subflow (e.g., port 80remains port 80 on all subflows, as does the ephemeral port at theclient), there could be cases (such as port-based load balancing) wherethe explicit specification of a different port is required. If noport is specified, the receiving hostMUST assume that any attempt toconnect to the specified address uses the port already used by thesubflow on which the MP_ADDADDR signal was sent.¶

Along with the MP_ADDADDR option, an MP_HMAC optionMUST be sent forauthentication. The truncated HMAC parameter present in this MP_HMACoption is the leftmost 20 bytes of an HMAC, negotiated and calculatedas described inSection 3.2.6. Similar to MP_JOIN,the key for the HMAC algorithm will be d-KeyA when the message is transmittedby Host A and d-KeyB when transmitted by Host B. These are the keys that were exchanged andselected in the original MP_KEY handshake. The message for the HMAC isthe Address ID, Nonce, IP address, and port number that precede the HMAC in theMP_ADDADDR option. If the port number is not present in the MP_ADDADDR option,the HMAC message will include 2 bytes of value zero.The rationale for the HMAC is to prevent unauthorized entities frominjecting MP_ADDADDR signals in an attempt to hijack a connection.Additionally, note that the presence of this HMAC prevents theaddress from being changed in flight unless the key is known by anintermediary. If a host receives an MP_ADDADDR option for which itcannot validate the HMAC, itMUST silently ignore the option.¶

The presence of an MP_SEQ (Section 3.2.5)MUST be ensured in a DCCP datagramin which MP_ADDADDR is sent, as described inSection 3.2.1.¶

                     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|      var      |0 0 0 0 0 1 1 1|  Address ID   |+---------------+---------------+-------+-------+---------------+|                             Nonce                             |+-------------------------------+-------------------------------+|          Address (IPv4 - 4 bytes / IPv6 - 16 bytes)           |+-------------------------------+-------------------------------+|   Port (2 bytes, optional)    | + MP_HMAC option+-------------------------------+     Type=46         Length         MP_OPT=7

Each address has an Address ID that could be used for uniquelyidentifying the address within a connection for address removal.Each host maintains a list of unique Address IDs, and it manages these as it wishes. TheAddress ID is also used to identify MP_JOIN options (seeSection 3.2.2)relating to the same address, even when address translators are in use.The Address IDMUST uniquely identify the address for the sender of theoption (within the scope of the connection); the mechanism forallocating such IDs is implementation specific.¶

All Address IDs learned via either MP_JOIN or MP_ADDADDR can be storedby the receiver in a data structure that gathers all theAddress-ID-to-address mappings for a connection (identified by a CIpair). In this way, there is a stored mapping between the Address ID,the observed source address, and the CI pair for future processing of controlinformation for a connection. Note that an implementationMAY discard incoming address advertisements. Reasons for this are, for example:¶

• to avoid the required mapping state, or¶

• because advertised addresses are of no use to it.¶

Possible scenarios in which this applies are the lack of resources to storea mapping or when IPv6 addresses are advertised even though the host onlysupports IPv4. Therefore, a hostMUST treat address announcements as soft state.However, a senderMAY choose to update the announcements periodically toovercome temporary limitations.¶

A hostMAY advertise private addresses, e.g., because there is a NAT on the path. It isdesirable to allow this as there could be cases where both hostshave additional interfaces on the same private network. The advertisementof broadcast or multicast IP addressesMUST be ignored by the recipient ofthis option, as it is not permitted according to the unicast principle of thebasic DCCP.¶

The MP_JOIN handshake used tocreate a new subflow (Section 3.2.2) provides mechanisms to minimizesecurity risks. The MP_JOIN message contains a 32-bit CI thatuniquely identifies a connection to the receiving host. If theCI is unknown, the hostMUST send a DCCP-Reset.¶

Further security considerations around the issue ofMP_ADDADDR messages that accidentally misdirect, or maliciously direct,new MP_JOIN attempts are discussed inSection 4.If a sending host of an MP_ADDADDR knows that no incoming subflows canbe established at a particular address, an MP_ADDADDRMUST NOTannounce that address unless the sending host has new knowledge aboutthe possibility to do so. This information can be obtained from localfirewall or routing settings, knowledge about availability of an externalNAT or a firewall, or connectivity checks performed by thehost/application.¶

The reception of an MP_ADDADDR message is acknowledged using MP_CONFIRM(Section 3.2.1). This ensures a reliable exchange of addressinformation.¶

A host that receives an MP_ADDADDR but findsthat the IP address and port number is unsuccessful at connection setupSHOULD NOT performfurther connection attempts to this address/port combination for thisconnection to save resources. However, if a sender wishes to trigger a new incomingconnection attempt on a previously advertised address/port combination, they can refresh the MP_ADDADDR information by sending the option again.¶

A hostMAY send an MP_ADDADDR message with an already-assigned AddressID using the IP address previously assigned to this Address ID. The newMP_ADDADDR could have the same port number or a different port number. ThereceiverMUST silently ignore the MP_ADDADDR if the IP address is not thesame as that previously assigned to this Address ID. A host wishing toreplace an existing Address IDMUST first remove the existing one(Section 3.2.9).¶

3.2.9.MP_REMOVEADDR

If, during the lifetime of an MP-DCCP connection, a previously announcedaddress becomes invalid (e.g., if an interface disappears), theaffected hostSHOULD announce this. The peer can remove a previously added address with an Address ID from a connectionusing the Remove Address (MP_REMOVEADDR) suboption. Thiswill terminate any subflows currently using that address.¶

MP_REMOVEADDR is only used to close already-established subflows thathave an invalid address. Functional flows with a valid addressMUST beclosed with a DCCP Close exchange (as with regular DCCP) instead ofusing MP_REMOVEADDR. For more information seeSection 3.5.¶

The Nonce is a 32-bit random value that is generated locally foreach MP_REMOVEADDR option and is used in the HMAC calculation processto prevent replay attacks.¶

Along with the MP_REMOVEADDR suboption, an MP_HMAC optionMUST be sent forauthentication. The truncated HMAC parameter present in this MP_HMACoption is the leftmost 20 bytes of an HMAC, negotiated and calculatedas described inSection 3.2.6. Similar to MP_JOIN,the key for the HMAC algorithm will be d-KeyA when the message is transmitted by Host A andd-KeyB when transmitted by Host B. These are the keys that were exchanged andselected in the original MP_KEY handshake. The message for the HMAC isthe Address ID.¶

The rationale for using an HMAC is to prevent unauthorized entities frominjecting MP_REMOVEADDR signals in an attempt to hijack a connection.Additionally, note that the presence of this HMAC prevents theaddress from being modified in flight unless the key is known by anintermediary. If a host receives an MP_REMOVEADDR option for which itcannot validate the HMAC, itMUST silently ignore the option.¶

A receiverMUST include an MP_SEQ (Section 3.2.5) in a DCCP datagram that sendsan MP_REMOVEADDR. Further details are given inSection 3.2.1.¶

The reception of an MP_REMOVEADDR message is acknowledged using MP_CONFIRM(Section 3.2.1). This ensures a reliable exchange of addressinformation. To avoid inconsistent states, the sender releases the Address ID only after MP_REMOVEADDR has been confirmed.¶

The sending and receiving of this messageSHOULD trigger the closing proceduredescribed in[RFC4340] between the client and the server on the affectedsubflow(s), if possible. This helps remove middlebox state beforeremoving any local state.¶

Address removal is done by the Address ID to allow the use of NATs and othermiddleboxes that rewrite source addresses. If there is no addressat the requested Address 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+---------------+---------------+---------------+---------------+|0 0 1 0 1 1 1 0|0 0 0 0 0 1 0 0|0 0 0 0 1 0 0 0|   Address ID  |+---------------+---------------+---------------+---------------+|                             Nonce                             |+-------------------------------+-------------------------------+     Type=46        Length=8         MP_OPT=8-> followed by the MP_HMAC option

3.2.10.MP_PRIO

The path priority signaled with the MP_PRIO option provides hints for the packet scheduler when making decisions about which path to use for payload traffic.When a single specific path from the set of availablepaths is treated with higher priority compared to the otherswhen 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 forusing different paths (e.g., Wi-Fi is free while cellular has a limit onvolume, and 5G has higher energy consumption). The priority of a pathcould also change, for example, when a mobile host runs outof battery, and the usage of only a single path may be the preferred choiceof the user.¶

The MP_PRIO suboption, shown below, can be used to set a priority valuefor the subflow over which the suboption is received.¶

                     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|0 0 0 0 0 1 0 0|0 0 0 0 1 0 0 1|(resvd)| prio  |+---------------+---------------+---------------+---------------+    Type=46         Length=4        MP_OPT=9

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 the available capacity temporarily, 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 the Wi-Fi path to Primary and Cellular path 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 Wi-Fi path can provide, indicating a clear priority of the Wi-Fi path over the Cellular due to, e.g., cost reasons.¶

2. Setting the Wi-Fi path to Primary and Cellular path 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 the 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 an MP_PRIO value greater than or equal to one for it to be allowed to send on the connection. It isRECOMMENDED to update at least one path to a non-zero MP_PRIOvalue when an MP-DCCP connection enters a state where all paths remain with anMP_PRIO value of zero. This helps an MP-DCCP connection to schedule when the multipath scheduler strictly respects MP_PRIO value 0.To ensure reliable transmission, the MP_PRIO suboptionMUST be acknowledged via an MP_CONFIRM (seeTable 4).¶

The relative ratio of the primary path values 3-15 depends on the path usage strategy, which is described in more detail inSection 3.11.In the case of path mobility (Section 3.11.1), only one path can be used at a time andMUST have the highest available priority value. That also includes the prio numbers 1 and 2. In the other case of concurrent path usage (Section 3.11.2), the definition is up to the multipath scheduler logic.¶

An MP_SEQ (Section 3.2.5)MUST be present in a DCCP datagramin which the MP_PRIO suboption is sent. Further details are given inSection 3.2.1.¶

3.2.11.MP_CLOSE

The mechanism available in DCCP[RFC4340] for closing a connection cannot give an indication for closing an MP-DCCP connection, which typically contains several DCCP subflows; therefore, one cannot conclude from the closing of a subflow to the closing of an MP-DCCP connection. This is solved by introducing MP_CLOSE.¶

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

An MP-DCCP connection can be gracefully closed by sending an MP_CLOSE to the peer host. On all subflows, the regular termination procedure described in[RFC4340]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-CloseMUST 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 multipath connection, the selected Key Data of the peer hostMUST be included in the MP_CLOSE option during the handshake procedure andMUST be validated by the peer host. Please note that the Key Data sent in DCCP-CloseReq will not be the same as the Key Data sent in DCCP-Close as these originate from different ends of the connection.¶

On reception of the first DCCP-CloseReq carrying an 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 the 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 an 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 1MUST 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 CLOSED state, new subflow requests using MP_JOINMUST be ignored.¶

Contrary to an MP_FAST_CLOSE (Section 3.2.3), no single-sided abrupt termination is applied.¶

3.2.12.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 optimizing the MP-DCCP protocol. Thisoption 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:¶

                     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|      var      |0 0 0 0 1 0 1 1|     Data      |+---------------+---------------+---------------+---------------+|   ...+---------------------------------------------------------------+     Type=46         Length         MP_OPT=11

The Data field can carry any data according to the foreseen use by the experimenters with a maximum Length of 252 bytes.¶

3.4.1.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 (Section 3.2.8) asshown in the example inFigure 22. 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¶

• a Nonce value to prevent replay attacks¶

• the IP address of the new path (A2_IP)¶

• a pair of bytes specifying the port number associated with this IP address. The value of 00 here indicates that the port number is the sameas that used for the initial subflow address A1_IP.¶

According toSection 3.2.8, the following options are required in a packet carrying MP_ADDADDR:¶

• the leftmost 20 bytes of the HMAC(A) generated during the initial handshake procedure described in Sections3.3 and3.2.6¶

• the MP_SEQ option with the sequence number (seqno 12) for this message, according toSection 3.2.5¶

Host B acknowledges receipt of the MP_ADDADDR message with a DCCP-Ack containing the MP_CONFIRM option. The parameters supplied in thisresponse 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 handshake procedure (Section 3.3)¶

          Host A                                         Host B------------------------                              -----------Address A1    Address A2                               Address B1----------    ----------                              -----------     |             |                                       |     |   DCCP-Data +  MP_ADDADDR(id 2, Nonce, A2_IP, 00) + |     |------- MP_HMAC(A) + MP_SEQ(seqno 12) -------------->|     |             |                                       |     |   DCCP-Ack + MP_HMAC(B) +                           |     |<----- MP_CONFIRM(seqno 12, MP_ADDADDR) -------------|

3.4.2.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 (Section 3.2.9) asshown in the example inFigure 23. 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 that was specified in a previous MP_ADDADDR message¶

• a Nonce value to prevent replay attacks¶

According toSection 3.2.9, the following options are required in a packet carrying MP_REMOVEADDR:¶

• the leftmost 20 bytes of the HMAC(A) generated during the initial handshake procedure described in Sections3.3 and3.2.6¶

• the MP_SEQ option with the sequence number (seqno 33) for this message, according toSection 3.2.5¶

Host B acknowledges receipt of the MP_REMOVEADDR message with a DCCP-Ack containing the MP_CONFIRM option. The parameters supplied in thisresponse 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 handshake procedure (Section 3.3)¶

          Host A                                         Host B------------------------                              -----------Address A1    Address A2                               Address B1----------    ----------                              -----------     |             |                                       |     |   DCCP-Data +  MP_REMOVEADDR(id 2, Nonce) +         |     |------- MP_HMAC(A) + MP_SEQ(seqno 33) -------------->|     |             |                                       |     |   DCCP-Ack + MP_HMAC(B) +                           |     |<----- MP_CONFIRM(seqno 33, MP_REMOVEADDR) ----------|

3.11.1.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 an MP-DCCP connection might become inactive due to either the occurrence of certain error conditions (e.g., DCCP timeout, packet loss threshold, RTT threshold, and 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 deprioritized, the MP-DCCP endpointSHOULD 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 processSHOULD respect the path priority configured by the MP_PRIO suboption; otherwise, if the path priority is not available, pick the most divergent source-destination pair from the originally used source-destination pair.¶

Note: Rules for picking the most appropriate source-destination pairare an implementation decision and are not specified within this document.Path mobility is supported in the current Linux reference implementation[MP-DCCP.Site].¶

3.11.2.Concurrent Path Usage

Different from a path mobility strategy, the selection between MP-DCCPsubflows is a per-packet decision that is a part of the multipathscheduling process. This method would allow multiple subflows to besimultaneously used to aggregate the path resources to obtain higherconnection throughput.¶

In this scenario, the selection of congestion control, per-packet scheduling,and a potential reordering method determines a concurrent path utilizationstrategy and result in a particular transport characteristic.A concurrent path usage method uses a scheduling design that could seek tomaximize reliability, maximize throughput, minimize latency, etc.¶

Concurrent path usage over the Internet can have implications. When an MP-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 algorithm 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 an experimental specification[RFC6356] to solve this problem. This scheme could also be specified for MP-DCCP. The same applies to other coupled congestion control algorithms that have been proposed for Multipath TCP such as the Opportunistic Linked Increases Algorithm[OLIA].¶

The specification of scheduling for concurrent multipath and related congestion control algorithms and reordering methods for use in the generalInternet are outside the scope of this document. If, and when, the IETFspecifies a method for concurrent usage of multiple paths for thegeneral Internet, the framework specified in this document could be used to provide an IETF-recommended method for MP-DCCP.¶