rfc9897v1.txt   rfc9897.txt 
Internet Engineering Task Force (IETF) M. Amend, Ed. Internet Engineering Task Force (IETF) M. Amend, Ed.
Request for Comments: 9897 DT Request for Comments: 9897 DT
Category: Standards Track A. Brunstrom Category: Standards Track A. Brunstrom
ISSN: 2070-1721 A. Kassler ISSN: 2070-1721 A. Kassler
Karlstad University Karlstad University
V. Rakocevic V. Rakocevic
City, University of London City St George's, University of London
S. Johnson S. Johnson
BT BT
October 2025 October 2025
Datagram Congestion Control Protocol (DCCP) Extensions for Multipath Datagram Congestion Control Protocol (DCCP) Extensions for Multipath
Operation with Multiple Addresses Operation with Multiple Addresses
Abstract Abstract
Datagram Congestion Control Protocol (DCCP) communications, as Datagram Congestion Control Protocol (DCCP) communications, as
skipping to change at line 93 skipping to change at line 93
3.2.3. MP_FAST_CLOSE 3.2.3. MP_FAST_CLOSE
3.2.4. MP_KEY 3.2.4. MP_KEY
3.2.5. MP_SEQ 3.2.5. MP_SEQ
3.2.6. MP_HMAC 3.2.6. MP_HMAC
3.2.7. MP_RTT 3.2.7. MP_RTT
3.2.8. MP_ADDADDR 3.2.8. MP_ADDADDR
3.2.9. MP_REMOVEADDR 3.2.9. MP_REMOVEADDR
3.2.10. MP_PRIO 3.2.10. MP_PRIO
3.2.11. MP_CLOSE 3.2.11. MP_CLOSE
3.2.12. Experimental Multipath Option MP_EXP for Private Use 3.2.12. Experimental Multipath Option MP_EXP for Private Use
3.3. MP-DCCP Handshaking Procedure 3.3. MP-DCCP Handshake Procedure
3.4. Address Knowledge Exchange 3.4. Address Knowledge Exchange
3.4.1. Advertising a New Path (MP_ADDADDR) 3.4.1. Advertising a New Path (MP_ADDADDR)
3.4.2. Removing a Path (MP_REMOVEADDR) 3.4.2. Removing a Path (MP_REMOVEADDR)
3.5. Closing an MP-DCCP Connection 3.5. Closing an MP-DCCP Connection
3.6. Fallback 3.6. Fallback
3.7. State Diagram 3.7. State Diagram
3.8. Congestion Control Considerations 3.8. Congestion Control Considerations
3.9. Maximum Packet Size Considerations 3.9. Maximum Packet Size Considerations
3.10. Maximum Number of Subflow Considerations 3.10. Maximum Number of Subflow Considerations
3.11. Path Usage Strategies 3.11. Path Usage Strategies
skipping to change at line 131 skipping to change at line 131
1. Introduction 1. Introduction
The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a
transport protocol that provides bidirectional unicast connections of transport protocol that provides bidirectional unicast connections of
congestion-controlled unreliable datagrams. DCCP communications are congestion-controlled unreliable datagrams. DCCP communications are
restricted to one single path. Other fundamentals of the DCCP restricted to one single path. Other fundamentals of the DCCP
protocol are summarized in Section 1 of [RFC4340] such as the protocol are summarized in Section 1 of [RFC4340] such as the
reliable handshake process in Section 4.7 of [RFC4340] and the reliable handshake process in Section 4.7 of [RFC4340] and the
reliable negotiation of features in Section 4.5 of [RFC4340]. These reliable negotiation of features in Section 4.5 of [RFC4340]. These
are an important basis for this document. This also applies to the are an important basis for this document. These fundamentals also
DCCP sequencing scheme, which is packet-based (Section 4.2 of apply to the DCCP sequencing scheme, which is packet-based
[RFC4340]), and the principles for loss and retransmission of (Section 4.2 of [RFC4340]), and the principles for loss and
features as described in more detail in Section 6.6.3 of [RFC4340]. retransmission of features as described in more detail in
This document specifies a set of protocol changes that add multipath Section 6.6.3 of [RFC4340]. This document specifies a set of
support to DCCP, specifically support for signaling and setting up protocol changes that add multipath support to DCCP, specifically
multiple paths (a.k.a., "subflows"), managing these subflows, the support for signaling and setting up multiple paths (a.k.a.,
reordering of data, and the termination of sessions. "subflows"), managing these subflows, the reordering of data, and the
termination of sessions.
Multipath DCCP (MP-DCCP) enables a DCCP connection to simultaneously Multipath DCCP (MP-DCCP) enables a DCCP connection to simultaneously
establish a flow across multiple paths. This can be beneficial to establish a flow across multiple paths. This can be beneficial to
applications that transfer large amounts of data, by utilizing the applications that transfer large amounts of data, by utilizing the
capacity/connectivity offered by multiple paths. In addition, the capacity/connectivity offered by multiple paths. In addition, the
multipath extensions enable the trade-off of timeliness and multipath extensions enable the trade-off of timeliness and
reliability, which is important for low-latency applications that do reliability, which is important for low-latency applications that do
not require guaranteed delivery services such as Audio/Video not require guaranteed delivery services such as Audio/Video
streaming. streaming.
In addition to the integration into DCCP services, implementers or In addition to the integration into DCCP services, implementers or
future specification could choose MP-DCCP for other use cases like future specifications could choose MP-DCCP for other use cases such
3GPP 5G multi-access solutions (e.g., Access Traffic Steering, as 3GPP 5G multi-access solutions (e.g., Access Traffic Steering,
Switching, and Splitting (ATSSS) specified in [TS23.501]) or hybrid Switching, and Splitting (ATSSS) specified in [TS23.501]) or hybrid
access networks that either combine a 3GPP and a non-3GPP access or a access networks. ATSSS combines 3GPP and non-3GPP access between the
fixed and cellular access between user-equipment/residential gateway user equipment and an operator network, while hybrid access combines
and operator network. MP-DCCP can be used in these scenarios for fixed and cellular access between a residential gateway and an
load balancing, seamless session handover, and bandwidth aggregation operator network. MP-DCCP can be used in these scenarios for load
when non-DCCP traffic such as IP, UDP, or TCP is encapsulated into balancing, seamless session handover, and bandwidth aggregation when
MP-DCCP. More details on potential use cases for MP-DCCP are non-DCCP traffic such as IP, UDP, or TCP is encapsulated into MP-
provided in [MP-DCCP.Site], [IETF105.Slides], and [MP-DCCP.Paper]. DCCP. More details on potential use cases for MP-DCCP are provided
All of these use cases profit from an Open Source Linux reference in [MP-DCCP.Site], [IETF105.Slides], and [MP-DCCP.Paper]. All of
these use cases profit from an Open Source Linux reference
implementation provided under [MP-DCCP.Site]. implementation provided under [MP-DCCP.Site].
The encapsulation of non-DCCP traffic (e.g., UDP or IP) in MP-DCCP to The encapsulation of non-DCCP traffic (e.g., UDP or IP) in MP-DCCP to
enable the above-mentioned use cases is not considered in this enable the above-mentioned use cases is not considered in this
specification. Also out of scope is the encapsulation of DCCP specification. Also out of scope is the encapsulation of DCCP
traffic in UDP to pass middleboxes (e.g., NATs, firewalls, proxies, traffic in UDP to pass middleboxes (e.g., NATs, firewalls, proxies,
intrusion detection systems (IDSs), etc.) that do not support DCCP. intrusion detection systems (IDSs), etc.) that do not support DCCP.
However, a possible method is defined in [RFC6773] and considered in However, a possible method is defined in [RFC6773] and considered in
[U-DCCP] to achieve the same with less overhead. [U-DCCP] to achieve the same with less overhead.
skipping to change at line 260 skipping to change at line 262
capitals, as shown here. capitals, as shown here.
2. Operation Overview 2. Operation Overview
DCCP transmits congestion-controlled unreliable datagrams over a DCCP transmits congestion-controlled unreliable datagrams over a
single path. Various congestion control mechanisms have been single path. Various congestion control mechanisms have been
specified to optimize DCCP performance for specific traffic types in specified to optimize DCCP performance for specific traffic types in
terms of profiles denoted by a Congestion Control IDentifier (CCID). terms of profiles denoted by a Congestion Control IDentifier (CCID).
However, DCCP does not provide built-in support for managing multiple However, DCCP does not provide built-in support for managing multiple
subflows within one DCCP connection. The extension of DCCP for subflows within one DCCP connection. The extension of DCCP for
Multipath-DCCP (MP-DCCP) is described in detail in Section 3. Multipath DCCP (MP-DCCP) is described in detail in Section 3.
At a high level of MP-DCCP operation, the data stream from a DCCP At a high level of MP-DCCP operation, the data stream from a DCCP
application is split by the MP-DCCP operation into one or more application is split by the MP-DCCP operation into one or more
subflows that can be transmitted via different paths, for example, subflows that can be transmitted via different paths, for example,
using paths via different links. The corresponding control using paths via different links. The corresponding control
information allows the receiver to optionally reassemble and deliver information allows the receiver to optionally reassemble and deliver
the received data in the originally transmitted order to the the received data in the originally transmitted order to the
recipient application. This may be necessary because DCCP does not recipient application. This may be necessary because DCCP does not
guarantee in-order delivery. The details of the transmission guarantee in-order delivery. The details of the transmission
scheduling mechanism and optional reordering mechanism are up to the scheduling mechanism and optional reordering mechanism are up to the
sender and receiver, respectively, and are outside the scope of this sender and receiver, respectively, and are outside the scope of this
document. document.
A Multipath DCCP connection provides a bidirectional connection of An MP-DCCP connection provides a bidirectional connection of
datagrams between two hosts exchanging data using DCCP. It does not datagrams between two hosts exchanging data using DCCP. It does not
require any change to the applications. Multipath DCCP enables the require any change to the applications. MP-DCCP enables the hosts to
hosts to use multiple paths with different 4-tuples to transport the use multiple paths with different 4-tuples to transport the packets
packets of an MP-DCCP connection. MP-DCCP manages the request, set- of an MP-DCCP connection. MP-DCCP manages the request, set-up,
up, authentication, prioritization, modification, and removal of the authentication, prioritization, modification, and removal of the DCCP
DCCP subflows on different paths as well as the exchange of subflows on different paths as well as the exchange of performance
performance parameters. parameters.
The number of DCCP subflows can vary during the lifetime of a The number of DCCP subflows can vary during the lifetime of an MP-
Multipath DCCP connection. The details of the path management DCCP connection. The details of the path management decisions for
decisions for when to add or remove subflows are outside the scope of when to add or remove subflows are outside the scope of this
this document. document.
The Multipath Capability for MP-DCCP is negotiated with a new DCCP The multipath capability for MP-DCCP is negotiated with a new DCCP
feature, as specified in Section 3.1. Once negotiated, all feature, as specified in Section 3.1. Once negotiated, all
subsequent MP-DCCP operations for that connection are signaled with a subsequent MP-DCCP operations for that connection are signaled with a
variable length multipath-related option, as described in Section 3. variable length multipath-related option, as described in Section 3.
All MP-DCCP operations are signaled by Multipath options described in All MP-DCCP operations are signaled by Multipath Options described in
Section 3.2. Options that require confirmation from the remote peer Section 3.2. Options that require confirmation from the remote peer
are retransmitted by the sender until confirmed or until confirmation are retransmitted by the sender until confirmed or until confirmation
is no longer considered relevant. is no longer considered relevant.
The sections that follow define MP-DCCP behavior in detail. The sections that follow define MP-DCCP behavior in detail.
2.1. MP-DCCP Concept 2.1. MP-DCCP Concept
Figure 2 provides a general overview of the MP-DCCP working mode, Figure 2 provides a general overview of the MP-DCCP working mode,
whose main characteristics are summarized in this section. whose main characteristics are summarized in this section.
skipping to change at line 324 skipping to change at line 326
| |--------------------->| | | |--------------------->| |
| |<---------------------| | | |<---------------------| |
| merge individual DCCP subflows to one MP-DCCP connection | merge individual DCCP subflows to one MP-DCCP connection
| | | | | | | |
Figure 2: Example MP-DCCP Usage Scenario Figure 2: Example MP-DCCP Usage Scenario
* An MP-DCCP connection begins with a 4-way handshake between two * An MP-DCCP connection begins with a 4-way handshake between two
hosts. In Figure 2, an MP-DCCP connection is established between hosts. In Figure 2, an MP-DCCP connection is established between
addresses A1 and B1 on Hosts A and B. In the handshake, a addresses A1 and B1 on Hosts A and B. In the handshake, a
Multipath Capable feature is used to negotiate multipath support Multipath Capable Feature is used to negotiate multipath support
for the connection. Host-specific keys are also exchanged between for the connection. Host-specific keys are also exchanged between
Host A and Host B during the handshake. The details of the MP- Host A and Host B during the handshake. The details of the MP-
DCCP handshaking procedure is described in Section 3.3. MP-DCCP DCCP handshake procedure is described in Section 3.3. MP-DCCP
does not require both peers to have more than one address. does not require both peers to have more than one address.
* When additional paths and corresponding addresses/ports are * When additional paths and corresponding addresses/ports are
available, additional DCCP subflows can be created on these paths available, additional DCCP subflows can be created on these paths
and attached to the existing MP-DCCP connection. An MP_JOIN and attached to the existing MP-DCCP connection. An MP_JOIN
option is used to connect a new DCCP subflow to an existing MP- option is used to connect a new DCCP subflow to an existing MP-
DCCP connection. It contains a Connection Identifier during the DCCP connection. It contains a Connection Identifier (CI) during
setup of the initial subflow and is exchanged in the 4-way the setup of the initial subflow and is exchanged in the 4-way
handshake for the subflow together with the Multipath Capable handshake for the subflow together with the Multipath Capable
feature. The example in Figure 2 illustrates the creation of an Feature. The example in Figure 2 illustrates the creation of an
additional DCCP subflow between Address A2 on Host A and Address additional DCCP subflow between Address A2 on Host A and Address
B1 on Host B. The two subflows continue to provide a single B1 on Host B. The two subflows continue to provide a single
connection to the applications at both endpoints. connection to the applications at both endpoints.
* MP-DCCP identifies multiple paths by the presence of multiple * MP-DCCP identifies multiple paths by the presence of multiple
addresses/ports at hosts. Combinations of these multiple addresses/ports at hosts. Combinations of these multiple
addresses/ports indicate the additional paths. In the example, addresses/ports indicate the additional paths. In the example,
other potential paths that could be set up are A1<->B2 and other potential paths that could be set up are A1<->B2 and
A2<->B2. Although the additional subflow in the example is shown A2<->B2. Although the additional subflow in the example is shown
as being initiated from A2, an additional subflow could as being initiated from A2, an additional subflow could
alternatively have been initiated from B1 or B2. alternatively have been initiated from B1 or B2.
* The discovery and setup of additional subflows is achieved through * The discovery and setup of additional subflows is achieved through
a path management method including the logic and details of the a path management method including the logic and details of the
procedures for adding/removing subflows. This document describes procedures for adding/removing subflows. This document describes
the procedures that enable a host to initiate new subflows or to the procedures that enable a host to initiate new subflows or to
signal available IP addresses between peers. However, the signal available IP addresses between peers. However, the
definition of a path management method, in which sequence and definition of a path management method, in which sequence and when
subflows are created, is outside the scope of this document. This subflows are created, is outside the scope of this document. This
method is subject to a corresponding policy and the specifics of method is subject to a corresponding policy and the specifics of
the implementation. If an MP-DCCP peer host wishes to limit the the implementation. If an MP-DCCP peer host wishes to limit the
maximum number of paths that can be maintained (e.g., similar to maximum number of paths that can be maintained (e.g., similar to
that discussed in Section 3.4 of [RFC8041]), the creation of new that discussed in Section 3.4 of [RFC8041]), the creation of new
subflows from that peer host is omitted when the threshold of subflows from that peer host is omitted when the threshold of
maximum paths is exceeded and incoming subflow requests MUST be maximum paths is exceeded and incoming subflow requests MUST be
rejected. rejected.
* Through the use of multipath options, MP-DCCP adds connection- * Through the use of Multipath Options, MP-DCCP adds connection-
level sequence numbers and the exchange of Round-Trip Time (RTT) level sequence numbers and the exchange of Round-Trip Time (RTT)
information to enable optional reordering features. As a hint for information to enable optional reordering features. As a hint for
scheduling decisions, a multipath option that allows a peer to scheduling decisions, a Multipath Option that allows a peer to
indicate its priorities for which path to use is also defined. indicate its priorities for which path to use is also defined.
* Subflows are terminated in the same way as regular DCCP * Subflows are terminated in the same way as regular DCCP
connections, as described in Section 8.3 of [RFC4340]. MP-DCCP connections, as described in Section 8.3 of [RFC4340]. MP-DCCP
connections are closed by including an MP_CLOSE option in subflow connections are closed by including an MP_CLOSE option in subflow
DCCP-CloseReq or DCCP-Close messages. An MP-DCCP connection may DCCP-CloseReq or DCCP-Close messages. An MP-DCCP connection may
also be reset through the use of an MP_FAST_CLOSE option. Key also be reset through the use of an MP_FAST_CLOSE option. Key
Data from the initial handshake is included in MP_CLOSE and Data from the initial handshake is included in MP_CLOSE and
MP_FAST_CLOSE to protect from an unauthorized shutdown of MP-DCCP MP_FAST_CLOSE to protect from an unauthorized shutdown of MP-DCCP
connections. connections.
3. MP-DCCP Protocol 3. MP-DCCP Protocol
The DCCP protocol feature list (Section 6.4 of [RFC4340]) is extended The DCCP protocol feature list (Section 6.4 of [RFC4340]) is extended
in this document by adding a new Multipath feature with Feature in this document by adding a new Multipath Feature with Feature
number 10, as shown in Table 1. Number 10, as shown in Table 1.
+========+===================+============+===============+=======+ +========+===================+============+===============+=======+
| Number | Meaning | Rec'n Rule | Initial Value | Req'd | | Number | Meaning | Rec'n Rule | Initial Value | Req'd |
+========+===================+============+===============+=======+ +========+===================+============+===============+=======+
| 10 | Multipath Capable | SP | 0 | N | | 10 | Multipath Capable | SP | 0 | N |
+--------+-------------------+------------+---------------+-------+ +--------+-------------------+------------+---------------+-------+
Table 1: Multipath Feature Table 1: Multipath Feature
Rec'n Rule: The reconciliation rule used for the feature. SP Rec'n Rule: The reconciliation rule used for the feature. SP
skipping to change at line 423 skipping to change at line 425
| 46 | variable | Multipath | Y | | 46 | variable | Multipath | Y |
+------+---------------+-----------+------------+ +------+---------------+-----------+------------+
Table 2: Multipath Option Set Table 2: Multipath Option Set
3.1. Multipath Capable Feature 3.1. Multipath Capable Feature
A DCCP endpoint negotiates the Multipath Capable Feature to determine A DCCP endpoint negotiates the Multipath Capable Feature to determine
whether multipath extensions can be enabled for a DCCP connection. whether multipath extensions can be enabled for a DCCP connection.
The Multipath Capable feature (MP_CAPABLE) has feature number 10 and The Multipath Capable Feature (MP_CAPABLE) has Feature Number 10 and
follows the structure for features given in Section 6 of [RFC4340]. follows the structure for features given in Section 6 of [RFC4340].
Beside the negotiation of the feature itself, one or several values Beside the negotiation of the feature itself, one or several values
can also be exchanged. The value field specified here for the can also be exchanged. The value field specified here for the
Multipath Capable feature has a length of one byte and can be Multipath Capable Feature has a length of one byte and can be
repeated several times within the DCCP option for feature repeated several times within the DCCP option for feature
negotiation. This can be, for example, required to announce support negotiation. This can be, for example, required to announce support
of different versions of the protocol. For that, the leftmost four of different versions of the protocol. For that, the leftmost four
bits in Figure 3 specify the compatible version of the MP-DCCP bits in Figure 3 specify the compatible version of the MP-DCCP
implementation and MUST be set to 0 following this specification. implementation and MUST be set to 0 following this specification.
The four bits following the Version field are unassigned in version 0 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 and MUST be set to zero by the sender and MUST be ignored by the
receiver. receiver.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-----------+------------+ +-----------+------------+
| Version | Unassigned | | Version | Unassigned |
+-----------+------------+ +-----------+------------+
Figure 3: Format of the Multipath Capable Feature Value Field Figure 3: Format of the Multipath Capable Feature Value Field
The setting of the MP_CAPABLE feature MUST follow the server-priority The setting of the Multipath Capable Feature MUST follow the server-
reconciliation rule described in Section 6.3.1 of [RFC4340]. This priority reconciliation rule described in Section 6.3.1 of [RFC4340].
allows multiple versions to be specified in order of priority. This allows multiple versions to be specified in order of priority.
The negotiation MUST be a part of the initial handshake procedure The negotiation MUST be a part of the initial handshake procedure
described in Section 3.3. No subsequent renegotiation of the described in Section 3.3. No subsequent renegotiation of the
MP_CAPABLE feature is allowed for the same MP-DCCP connection. Multipath Capable Feature is allowed for the same MP-DCCP connection.
Clients MUST include a Change R option (Section 6 of [RFC4340]) Clients MUST include a Change R option (Section 6 of [RFC4340])
during the initial handshake request to supply a list of supported during the initial handshake request to supply a list of supported
MP-DCCP protocol versions, ordered by preference. MP-DCCP protocol versions, ordered by preference.
Servers MUST include a Confirm L option (Section 6 of [RFC4340]) in Servers MUST include a Confirm L option (Section 6 of [RFC4340]) in
the subsequent response to agree on an MP-DCCP version to be used the subsequent response to agree on an MP-DCCP version to be used
from the Client list, followed by its own supported version(s), from the Client list, followed by its own supported version(s),
ordered by preference. Any subflow added to an existing MP-DCCP ordered by preference. Any subflow added to an existing MP-DCCP
connection MUST use the version negotiated for the first subflow. connection MUST use the version negotiated for the first subflow.
If no agreement is found, the Server MUST reply with an empty Confirm If no agreement is found, the Server MUST reply with an empty Confirm
L option with feature number 10 and no values. L option with Feature Number 10 and no values.
An example of successful version negotiation is shown hereafter and An example of successful version negotiation is shown hereafter and
follows the negotiation example shown in Section 6.5 of [RFC4340]. follows the negotiation example shown in Section 6.5 of [RFC4340].
For better understanding, this example uses the unspecified MP-DCCP For better understanding, this example uses the unspecified MP-DCCP
versions 1 and 2 in addition to the MP-DCCP version 0 specified in versions 1 and 2 in addition to the MP-DCCP version 0 specified in
this document: this document:
Client Server Client Server
------ ------ ------ ------
DCCP-Req + Change R(MP_CAPABLE, 1 0) DCCP-Req + Change R(MP_CAPABLE, 1 0)
-----------------------------------> ----------------------------------->
DCCP-Resp + Confirm L(MP_CAPABLE, 1, 2 1 0) DCCP-Resp + Confirm L(MP_CAPABLE, 1, 2 1 0)
<----------------------------------- <-----------------------------------
* agreement on version = 1 * * agreement on version = 1 *
Figure 4: Example of MP-DCCP Support Negotiation Using MP_CAPABLE Figure 4: Example of MP-DCCP Support Negotiation Using MP_CAPABLE
This example illustrates the following:
1. The Client indicates support for both MP-DCCP versions 1 and 0, 1. The Client indicates support for both MP-DCCP versions 1 and 0,
with a preference for version 1. with a preference for version 1.
2. The Server agrees on using MP-DCCP version 1 indicated by the 2. The Server agrees on using MP-DCCP version 1 indicated by the
first value and supplies its own preference list with the first value and supplies its own preference list with the
subsequent values. subsequent values.
3. MP-DCCP is then enabled between the Client and Server with 3. MP-DCCP is then enabled between the Client and Server with
version 1. version 1.
Unlike the example in Figure 4, this document only allows the Unlike the example in Figure 4, this document only allows the
negotiation of MP-DCCP version 0. Therefore, per successful negotiation of MP-DCCP version 0. Therefore, per successful
negotiation of MP-DCCP as defined in this document, the client and negotiation of MP-DCCP as defined in this document, the Client and
the server MUST both support MP-DCCP version 0. the Server MUST both support MP-DCCP version 0.
If the version negotiation fails or the MP_CAPABLE feature is not If the version negotiation fails or the Multipath Capable Feature is
present in the DCCP-Request or DCCP-Response packets of the initial not present in the DCCP-Request or DCCP-Response packets of the
handshake procedure, the MP-DCCP connection either MUST fall back to initial handshake procedure, the MP-DCCP connection either MUST fall
regular DCCP or MUST close the connection. Further details are back to regular DCCP or MUST close the connection. Further details
specified in Section 3.6. are specified in Section 3.6.
3.2. Multipath Option 3.2. Multipath Option
MP-DCCP uses one single option to signal various multipath-related MP-DCCP uses one single option to signal various multipath-related
operations. The format of this multipath option is shown in operations. The format of this Multipath Option is shown in
Figure 5. Figure 5.
1 2 3 1 2 3
01234567 89012345 67890123 45678901 23456789 01234567 89012345 67890123 45678901 23456789
+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+
|00101110| Length | MP_OPT | Value(s) ... |00101110| Length | MP_OPT | Value(s) ...
+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+
Type=46 Type=46
Figure 5: Multipath Option Format Figure 5: Multipath Option Format
The fields used by the multipath option are described in Table 3. The fields used by the Multipath Option are described in Table 3.
MP_OPT refers to a Multipath option. MP_OPT refers to a Multipath Option.
+======+========+================+=================================+ +======+========+================+=================================+
| Type | Option | MP_OPT | Meaning | | Type | Option | MP_OPT | Meaning |
| | Length | | | | | Length | | |
+======+========+================+=================================+ +======+========+================+=================================+
| 46 | var | 0 =MP_CONFIRM | Confirm reception and | | 46 | var | 0 =MP_CONFIRM | Confirm reception and |
| | | | processing of an MP_OPT option | | | | | processing of an MP_OPT option |
+------+--------+----------------+---------------------------------+ +------+--------+----------------+---------------------------------+
| 46 | 12 | 1 =MP_JOIN | Join subflow to an existing MP- | | 46 | 12 | 1 =MP_JOIN | Join subflow to an existing MP- |
| | | | DCCP connection | | | | | DCCP connection |
skipping to change at line 546 skipping to change at line 550
| | | | MP_HMAC | | | | | MP_HMAC |
+------+--------+----------------+---------------------------------+ +------+--------+----------------+---------------------------------+
| 46 | 9 | 4 =MP_SEQ | Multipath sequence number | | 46 | 9 | 4 =MP_SEQ | Multipath sequence number |
+------+--------+----------------+---------------------------------+ +------+--------+----------------+---------------------------------+
| 46 | 23 | 5 =MP_HMAC | Hash-based message | | 46 | 23 | 5 =MP_HMAC | Hash-based message |
| | | | authentication code for MP-DCCP | | | | | authentication code for MP-DCCP |
+------+--------+----------------+---------------------------------+ +------+--------+----------------+---------------------------------+
| 46 | 12 | 6 =MP_RTT | Transmit RTT values and | | 46 | 12 | 6 =MP_RTT | Transmit RTT values and |
| | | | calculation parameters | | | | | calculation parameters |
+------+--------+----------------+---------------------------------+ +------+--------+----------------+---------------------------------+
| 46 | var | 7 =MP_ADDADDR | Advertise additional | | 46 | var | 7 =MP_ADDADDR | Advertise one or more |
| | | | address(es)/port(s) | | | | | additional addresses/ports |
+------+--------+----------------+---------------------------------+ +------+--------+----------------+---------------------------------+
| 46 | 8 | 8 | Remove address(es)/port(s) | | 46 | 8 | 8 | Remove one or more addresses/ |
| | | =MP_REMOVEADDR | | | | | =MP_REMOVEADDR | ports |
+------+--------+----------------+---------------------------------+ +------+--------+----------------+---------------------------------+
| 46 | 4 | 9 =MP_PRIO | Change subflow priority | | 46 | 4 | 9 =MP_PRIO | Change subflow priority |
+------+--------+----------------+---------------------------------+ +------+--------+----------------+---------------------------------+
| 46 | var | 10 =MP_CLOSE | Close an MP-DCCP connection | | 46 | var | 10 =MP_CLOSE | Close an MP-DCCP connection |
+------+--------+----------------+---------------------------------+ +------+--------+----------------+---------------------------------+
| 46 | var | 11 =MP_EXP | Experimental option for private | | 46 | var | 11 =MP_EXP | Experimental option for private |
| | | | use | | | | | use |
+------+--------+----------------+---------------------------------+ +------+--------+----------------+---------------------------------+
| 46 | TBD | >11 | Reserved for future Multipath | | 46 | TBD | >11 | (available for future Multipath |
| | | | options. | | | | | Options) |
+------+--------+----------------+---------------------------------+ +------+--------+----------------+---------------------------------+
Table 3: MP_OPT Option Types Table 3: MP_OPT Option Types
Future MP options could be defined in a later version of or extension Future Multipath Options could be defined in a later version of or
to this specification. extension to this specification.
These operations are largely inspired by the signals defined in These operations are largely inspired by the signals defined in
[RFC8684]. The procedures for handling faulty or unknown MP options [RFC8684]. The procedures for handling faulty or unknown Multipath
are described in Section 3.6. Options are described in Section 3.6.
3.2.1. MP_CONFIRM 3.2.1. MP_CONFIRM
Some Multipath Options require confirmation from the remote peer (see
Table 4) for which MP_CONFIRM is specified.
1 2 3 4 5 1 2 3 4 5
01234567 89012345 67890123 45678901 23456789 01234567 89012345 01234567 89012345 67890123 45678901 23456789 01234567 89012345
+--------+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+--------+--------+
|00101110| var |00000000| List of confirmations ... |00101110| var |00000000| List of confirmations ...
+--------+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+--------+--------+
Type=46 Length MP_OPT=0 Type=46 Length MP_OPT=0
Figure 6: Format of the MP_CONFIRM Option Figure 6: Format of the MP_CONFIRM Option
Some multipath options require confirmation from the remote peer (see Multipath Options that require confirmation will be retransmitted by
Table 4). Such options will be retransmitted by the sender until an the sender until an MP_CONFIRM is received or the confirmation of
MP_CONFIRM is received or the confirmation of options is considered options is considered irrelevant because the data contained in the
irrelevant because the data contained in the options has already been options has already been replaced by newer information.
replaced by newer information. This can happen, for example, with an
MP_PRIO option if the path prioritization is changed while the
previous prioritization has not yet been confirmed. 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 This can happen, for example, with an MP_PRIO option if the path
options defined in Table 4 MUST be sent in a DCCP datagram with prioritization is changed while the previous prioritization has not
yet been confirmed. 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 Table 4 MUST be sent in a DCCP datagram with
MP_SEQ (see Section 3.2.5). This allows a receiver to identify MP_SEQ (see Section 3.2.5). This allows a receiver to identify
whether multipath options are associated with obsolete datasets whether Multipath Options are associated with obsolete datasets
(information carried in the option header) that would otherwise (information carried in the option header) that would otherwise
conflict with newer datasets. In the case of MP_ADDADDR or conflict with newer datasets. In the case of MP_ADDADDR or
MP_REMOVEADDR, the same dataset is identified based on AddressID, MP_REMOVEADDR, the same dataset is identified based on AddressID,
whereas the same dataset for MP_PRIO is identified by the subflow in 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 use. An outdated multipath Option is detected at the receiver if a
previous multipath option referring to the same dataset contained a previous Multipath Option referring to the same dataset contained a
higher sequence number in the MP_SEQ. An MP_CONFIRM MAY be generated higher sequence number in the MP_SEQ. An MP_CONFIRM MAY be generated
for multipath options that are identified as outdated. for Multipath Options that are identified as outdated.
Similarly, an MP_CONFIRM could arrive out of order. The associated Similarly, an MP_CONFIRM could arrive out of order. The associated
MP_SEQ received MUST be echoed to ensure that the most recent MP_SEQ received MUST be echoed to ensure that the most recent
multipath option is confirmed. This protects from inconsistencies Multipath Option is confirmed. This protects from inconsistencies
that could occur, e.g., if three MP_PRIO options are sent one after 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, 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 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 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 second update and the third update would cause the sender to
incorrectly interpret that the priority value was set to 0 without incorrectly interpret that the priority value was set to 0 without
recognizing that the receiver has applied priority value 1. recognizing that the receiver has applied priority value 1.
The length of the MP_CONFIRM option and the path over which the The length of the MP_CONFIRM option and the path over which the
option is sent depend on the confirmed multipath options and the option is sent depend on the confirmed Multipath Options and the
received MP_SEQ, which are both copied verbatim and appended as a received MP_SEQ, which are both copied verbatim and appended as a
list of confirmations. The list is structured by first listing the list of confirmations. The list is structured by first listing the
received MP_SEQ followed by the related multipath option or options received MP_SEQ followed by the related Multipath Option or options
to confirm. The same rules apply when multipath options with to confirm. The same rules apply when Multipath Options with
different MP_SEQs are confirmed at once. This could happen if a different MP_SEQs are confirmed at once. This could happen if the
datagram with MP_PRIO and a first MP_SEQ_1 and another datagram with following are receieved in short succession: a datagram with MP_PRIO
MP_ADDADDR and a second MP_SEQ_2 are received in short succession. and a first MP_SEQ_1 and another datagram with MP_ADDADDR and a
In this case, the structure described above is concatenated resulting second MP_SEQ_2. In this case, the structure described above is
in MP_SEQ_2 + MP_ADDADDR + MP_SEQ_1 + MP_PRIO. The order of the concatenated resulting in MP_SEQ_2 + MP_ADDADDR + MP_SEQ_1 + MP_PRIO.
confirmed multipath options in the list of confirmations MUST reflect The order of the confirmed Multipath Options in the list of
the incoming order at the host who sends the MP_CONFIRM, with the confirmations MUST reflect the incoming order at the host who sends
most recent suboption received listed first. This could allow the the MP_CONFIRM, with the most recent suboption received listed first.
host receiving the MP_CONFIRM to verify that the options were applied This could allow the host receiving the MP_CONFIRM to verify that the
in the correct order and to take countermeasures if they were not, options were applied in the correct order and to take countermeasures
e.g., if an MP_REMOVEADDR overtakes an MP_ADDADDR that refers to the if they were not, e.g., if an MP_REMOVEADDR overtakes an MP_ADDADDR
same dataset. that refers to the same dataset.
+======+===============+==================+=========================+ +======+===============+==================+=========================+
| Type | Option Length | MP_OPT | MP_CONFIRM Sending Path | | Type | Option Length | MP_OPT | MP_CONFIRM Sending Path |
+======+===============+==================+=========================+ +======+===============+==================+=========================+
| 46 | var | 7 =MP_ADDADDR | Any available | | 46 | var | 7 =MP_ADDADDR | Any available |
+------+---------------+------------------+-------------------------+ +------+---------------+------------------+-------------------------+
| 46 | 4 | 8 | Any available | | 46 | 4 | 8 | Any available |
| | | =MP_REMOVEADDR | | | | | =MP_REMOVEADDR | |
+------+---------------+------------------+-------------------------+ +------+---------------+------------------+-------------------------+
| 46 | 4 | 9 =MP_PRIO | Any available | | 46 | 4 | 9 =MP_PRIO | Any available |
skipping to change at line 669 skipping to change at line 676
Address A1 Address A2 Address B1 Address B2 Address A1 Address A2 Address B1 Address B2
---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
| | | | | | | |
| | DCCP-Request(seqno 1) + MP_PRIO(1)| | | | DCCP-Request(seqno 1) + MP_PRIO(1)| |
| |------------------------------------------>| | |------------------------------------------>|
| | | | | | | |
| | DCCP-Response + | | | | DCCP-Response + | |
| |<---- MP_CONFIRM(seqno 1, MP_PRIO) --------| | |<---- MP_CONFIRM(seqno 1, MP_PRIO) --------|
| | | | | | | |
Figure 7: Example MP-DCCP CONFIRM Procedure Figure 7: Example MP_CONFIRM Procedure
A second example that illustrates the same MP-DCCP confirm procedure A second example that illustrates the same MP-DCCP confirm procedure
but where an out-of-date option is also delivered is shown in but where an out-of-date option is also delivered is shown in
Figure 8. Here, the first DCCP-Data is sent from Host A to Host B Figure 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 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 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 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 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 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 first. Host B sends a DCCP-Ack with sequence number 2 to confirm the
skipping to change at line 699 skipping to change at line 706
| | \ | | | | \ | |
| | DCCP-Data(seqno 2) + MP_PRIO(1) | | | | DCCP-Data(seqno 2) + MP_PRIO(1) | |
| |--------------\--------------------------->| | |--------------\--------------------------->|
| | \ | | | | \ | |
| | -------------------------->| | | -------------------------->|
| | | | | | | |
| | DCCP-Ack + | | | | DCCP-Ack + | |
| |<---- MP_CONFIRM(seqno 2, MP_PRIO) --------| | |<---- MP_CONFIRM(seqno 2, MP_PRIO) --------|
| | | | | | | |
Figure 8: Example MP-DCCP CONFIRM Procedure with an Outdated Figure 8: Example MP_CONFIRM Procedure with an Outdated Suboption
Suboption
3.2.2. MP_JOIN 3.2.2. MP_JOIN
The MP_JOIN option is used to add a new subflow to an existing MP-
DCCP connection, and a successful establishment of the first subflow
using MP_KEY is REQUIRED.
1 2 3 1 2 3
01234567 89012345 67890123 45678901 01234567 89012345 67890123 45678901
+--------+--------+--------+--------+ +--------+--------+--------+--------+
|00101110|00001100|00000001| Addr ID| |00101110|00001100|00000001| Addr ID|
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Connection Identifier | | Connection Identifier |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Nonce | | Nonce |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Type=46 Length=12 MP_OPT=1 Type=46 Length=12 MP_OPT=1
Figure 9: Format of the MP_JOIN Suboption Figure 9: Format of the MP_JOIN Suboption
The MP_JOIN option is used to add a new subflow to an existing MP- The CI is the one from the peer host, which was previously exchanged
DCCP connection and REQUIRES a successful establishment of the first with the MP_KEY option. MP_HMAC MUST be set when using MP_JOIN
subflow using MP_KEY. The Connection Identifier (CI) is the one from within a DCCP-Response packet; see Section 3.2.6 for details.
the peer host, which was previously exchanged with the MP_KEY option. Similar to the setup of the first subflow, MP_JOIN also exchanges the
MP_HMAC MUST be set when using MP_JOIN within a DCCP-Response packet; Multipath Capable Feature MP_CAPABLE as described in Section 3.1.
see Section 3.2.6 for details. Similar to the setup of the first This procedure includes the DCCP Confirm principle and thus ensures a
subflow, MP_JOIN also exchanges the Multipath Capable feature reliable exchange of the MP_JOIN in accordance with Section 6.6.4 of
MP_CAPABLE as described in Section 3.1. This procedure includes the [RFC4340].
DCCP Confirm principle and thus ensures a reliable exchange of the
MP_JOIN in accordance with Section 6.6.4 of [RFC4340].
The MP_JOIN option includes an "Addr ID" (Address ID) generated by The MP_JOIN option includes an "Addr ID" (Address ID) generated by
the sender of the option, which is used to identify the source the sender of the option, which is used to identify the source
address of this packet, even if the IP header was changed in transit 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 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. and MUST map uniquely to a source IP address for the sending host.
The Address ID allows address removal (Section 3.2.9) without the The Address ID allows address removal (Section 3.2.9) without the
need to know the source address at the receiver, thus allowing need to know the source address at the receiver, thus allowing
address removal through NATs. The Address ID also allows correlation address removal through NATs. The Address ID also allows correlation
between new subflow setup attempts and address signaling between new subflow setup attempts and address signaling
skipping to change at line 751 skipping to change at line 759
Response exchange of the first subflow in the connection are implicit Response exchange of the first subflow in the connection are implicit
and have the value zero. A host MUST store the mappings between and have the value zero. A host MUST store the mappings between
Address IDs and addresses for both itself and the remote host. An Address IDs and addresses for both itself and the remote host. An
implementation will also need to know which local and remote Address implementation will also need to know which local and remote Address
IDs are associated with which established subflows for when addresses IDs are associated with which established subflows for when addresses
are removed from a local or remote host. An Address ID MUST always are removed from a local or remote host. An Address ID MUST always
be unique over the lifetime of a subflow and can only be reassigned be unique over the lifetime of a subflow and can only be reassigned
if sender and receiver no longer have them in use. if sender and receiver no longer have them in use.
The Nonce is a 32-bit random value locally generated for every The Nonce is a 32-bit random value locally generated for every
MP_JOIN option. Together with the derived key from the both hosts MP_JOIN option. Together with the derived key from both hosts' Key
Key Data described in Section 3.2.4, the Nonce value builds the basis Data (as described in Section 3.2.4), the Nonce value builds the
to calculate the Hash-based Message Authentication Code (HMAC) used basis to calculate the Hash-based Message Authentication Code (HMAC)
in the handshaking process as described in Section 3.3 to avoid used in the handshake process (as described in Section 3.3) to avoid
replay attacks. replay attacks.
If the CI cannot be verified by the receiving host during a handshake If the CI cannot be verified by the receiving host during a handshake
negotiation, the new subflow MUST be closed, as specified in negotiation, the new subflow MUST be closed, as specified in
Section 3.6. Section 3.6.
3.2.3. MP_FAST_CLOSE 3.2.3. MP_FAST_CLOSE
DCCP can send a Close or Reset signal to abruptly close a connection. 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 Using MP-DCCP, a regular Close or Reset only has the scope of the
skipping to change at line 790 skipping to change at line 798
Figure 10: Format of the MP_FAST_CLOSE Suboption Figure 10: Format of the MP_FAST_CLOSE Suboption
When Host A wants to abruptly close an MP-DCCP connection with Host 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 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 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 with Reset Code 13. The requirement to send the MP_FAST_CLOSE on all
subflows increases the probability that Host B will receive the subflows increases the probability that Host B will receive the
MP_FAST_CLOSE to take the same action. To protect from an MP_FAST_CLOSE to take the same action. To protect from an
unauthorized shutdown of an MP-DCCP connection, the selected Key Data unauthorized shutdown of an MP-DCCP connection, the selected Key Data
of the peer host during the handshaking procedure is carried by the of the peer host during the handshake procedure is carried by the
MP_FAST_CLOSE option. MP_FAST_CLOSE option.
After sending the MP_FAST_CLOSE on all subflows, Host A MUST tear After sending the MP_FAST_CLOSE on all subflows, Host A MUST tear
down all subflows, and the Multipath DCCP connection immediately down all subflows, and the MP-DCCP connection immediately terminates.
terminates.
Upon reception of the first MP_FAST_CLOSE with successfully validated Upon reception of the first MP_FAST_CLOSE with successfully validated
Key Data, Host B will send a DCCP-Reset packet response on all 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 subflows to Host A with Reset Code 13 to clean potential middlebox
states. Host B MUST then tear down all subflows and terminate the states. Host B MUST then tear down all subflows and terminate the
MP-DCCP connection. MP-DCCP connection.
3.2.4. MP_KEY 3.2.4. MP_KEY
MP-DCCP protects against some man-in-the-middle attacks as further
outlined in Section 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 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 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 | |0 0 1 0 1 1 1 0| var |0 0 0 0 0 0 1 1| resvd |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Connection Identifier | | Connection Identifier |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Key Type (1) | Key Data (1) | Key Type (2) | Key Data (2) | | Key Type (1) | Key Data (1) | Key Type (2) | Key Data (2) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Key Type (3) | ... | Key Type (3) | ...
+---------------+---------------+ +---------------+---------------+
Type=46 Length MP_OPT=3 Type=46 Length MP_OPT=3
Figure 11: Format of the MP_KEY Suboption Figure 11: Format of the MP_KEY Suboption
The MP_KEY suboption is used to exchange a Connection Identifier (CI) The MP_KEY suboption is used to exchange a CI and key material
and key material between hosts (Host A and Host B) for a given between hosts (Host A and Host B) for a given connection. The CI is
connection. The CI is a unique number in the host for each multipath a unique number in the host for each multipath connection and is
connection and is generated for inclusion in the first exchange of a generated for inclusion in the first exchange of a connection with
connection with MP_KEY. With the CI, it is possible to connect other MP_KEY. With the CI, it is possible to connect other DCCP subflows
DCCP subflows to an MP-DCCP connection with MP_JOIN (Section 3.2.2). to an MP-DCCP connection with MP_JOIN (Section 3.2.2). Its size of
Its size of 32 bits also defines the maximum number of simultaneous 32 bits also defines the maximum number of simultaneous MP-DCCP
MP-DCCP connections in a host to 2^32. According to the Key-related connections in a host to 2^32. According to the Key-related elements
elements of the MP_KEY suboption, the Length varies between 17 and 73 of the MP_KEY suboption, the Length varies between 17 and 73 bytes
bytes for a single-key message and up to 82 bytes when all specified for a single-key message and up to 82 bytes when all specified Key
Key Types 0 and 255 are provided. The Key Type field specifies the Types 0 and 255 are provided. The Key Type field specifies the type
type of the following Key Data. The set of key types are shown in of the following Key Data. The set of Key Types are shown in
Table 5. Table 5.
+===============+====================+==================+ +===============+====================+===================+
| Key Type | Key Length (bytes) | Meaning | | Key Type | Key Length (bytes) | Meaning |
+===============+====================+==================+ +===============+====================+===================+
| 0 =Plain Text | 8 | Plain Text Key | | 0 =Plain Text | 8 | Plain text Key |
+---------------+--------------------+------------------+ +---------------+--------------------+-------------------+
| 1-254 | | Reserved for | | 1-254 | | (available for |
| | | future Key Types | | | | future Key Types) |
+---------------+--------------------+------------------+ +---------------+--------------------+-------------------+
| 255 | 64 | For private use | | 255 | 64 | For private use |
| =Experimental | | only | | =Experimental | | only |
+---------------+--------------------+------------------+ +---------------+--------------------+-------------------+
Table 5: MP_KEY Key Types Table 5: MP_KEY Key Types
Plain Text: Plain Text:
Key Data is exchanged in plain text between hosts (Host A and Host 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 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 host to generate the derived key (d-key) by concatenating the two
parts with the local key in front. That is, parts with the local key in front. That is,
Host A: d-keyA=(KeyA+KeyB) Host A: d-keyA=(KeyA+KeyB)
Host B: d-keyB=(KeyB+KeyA) Host B: d-keyB=(KeyB+KeyA)
Experimental: Experimental:
This Key Type allows the use of other Key Data and can be used to This Key Type allows the use of other Key Data and can be used to
validate other key exchange mechanisms for a possible future validate other key exchange mechanisms for a possible future
specification. specification.
Multiple keys are only permitted in the DCCP-Request message of the Multiple keys are only permitted in the DCCP-Request message of the
handshake procedure for the first subflow. This allows the hosts to handshake procedure for the first subflow. This allows the hosts to
agree on a single key type to be used, as described in Section 3.3 agree on a single Key Type to be used, as described in Section 3.3
It is possible that not all hosts will support all key types, and It is possible that not all hosts will support all Key Types, and
this specification does not recommend or enforce the announcement of this specification does not recommend or enforce the announcement of
any particular Key Type within the MP_KEY option as this could have any particular Key Type within the MP_KEY option as this could have
security implications. However, at least Key Type 0 (Plain Text) security implications. However, at least Key Type 0 (Plain Text)
MUST be supported for interoperability tests in implementations of MUST be supported for interoperability tests in implementations of
MP-DCCP. If the key type cannot be agreed in the handshake MP-DCCP. If the Key Type cannot be agreed in the handshake
procedure, the MP-DCCP connection MUST fall back to not using MP- procedure, the MP-DCCP connection MUST fall back to not using MP-
DCCP, as indicated in Section 3.6. DCCP, as indicated in Section 3.6.
3.2.5. MP_SEQ 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 connection MUST be known before assigning packets to subflows
in order to apply 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 1 2 3 4 5
01234567 89012345 67890123 45678901 23456789 01234567 89012345 01234567 89012345 67890123 45678901 23456789 01234567 89012345
+--------+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+--------+--------+
|00101110|00001001|00000100| Multipath Sequence Number |00101110|00001001|00000100| Multipath Sequence Number
+--------+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+--------+--------+
| |
+--------+--------+ +--------+--------+
Type=46 Length=9 MP_OPT=4 Type=46 Length=9 MP_OPT=4
Figure 12: Format of the MP_SEQ Suboption Figure 12: Format of the MP_SEQ Suboption
skipping to change at line 915 skipping to change at line 938
segment lifetime. For DCCP, the MSL is the same as that of TCP as segment lifetime. For DCCP, the MSL is the same as that of TCP as
specified in Section 3.4 of [RFC4340]. Compared to TCP, the sequence specified in Section 3.4 of [RFC4340]. Compared to TCP, the sequence
number for DCCP is incremented per packet rather than per byte number for DCCP is incremented per packet rather than per byte
transmitted. For this reason, the 48 bits chosen in MP_SEQ are transmitted. For this reason, the 48 bits chosen in MP_SEQ are
considered sufficiently large per the current globally routable considered sufficiently large per the current globally routable
maximum packet size (MPS) of 1500 bytes, which corresponds to roughly maximum packet size (MPS) of 1500 bytes, which corresponds to roughly
375 pebibytes (PiBs) of data within the sequence number space. 375 pebibytes (PiBs) of data within the sequence number space.
3.2.6. MP_HMAC 3.2.6. MP_HMAC
MP-DCCP protects against some man-in-the-middle attacks as further
outlined in Section 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 1 2 3 4
01234567 89012345 67890123 45678901 23456789 01234567 01234567 89012345 67890123 45678901 23456789 01234567
+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+--------+
|00101110|00010111|00000101| HMAC-SHA256 (20 bytes) ... |00101110|00010111|00000101| HMAC-SHA256 (20 bytes) ...
+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+--------+
Type=46 Length=23 MP_OPT=5 Type=46 Length=23 MP_OPT=5
Figure 13: Format of the MP_HMAC Suboption Figure 13: Format of the MP_HMAC Suboption
The MP_HMAC suboption is used to provide authentication for the The MP_HMAC suboption is used to provide authentication for the
MP_ADDADDR and MP_REMOVEADDR suboptions. In addition, it provides MP_ADDADDR and MP_REMOVEADDR suboptions. In addition, it provides
authentication for subflows joining an existing MP_DCCP connection, authentication for subflows joining an existing MP_DCCP connection,
as described in the second and third step of the handshake of a as described in the second and third step of the handshake of a
subsequent subflow in Section 3.3. For this specification of MP- subsequent subflow in Section 3.3. For this specification of MP-
DCCP, the HMAC code is generated according to [RFC2104] in DCCP, the HMAC code is generated according to [RFC2104] in
combination with the SHA256 hash algorithm described in [RFC6234], combination with the SHA-256 hash algorithm described in [RFC6234],
with the output in big-endian format truncated to the leftmost 160 with the output in big-endian format truncated to the leftmost 160
bits (20 bytes). It is possible that other versions of MP-DCCP will bits (20 bytes). It is possible that other versions of MP-DCCP will
define other hash algorithms in the future. define other hash algorithms in the future.
The "Key" used for the HMAC computation is the derived key (d-keyA The "Key" used for the HMAC computation is the derived key (d-keyA
for Host A or d-KeyB for Host B) described in Section 3.2.4, while for Host A or d-KeyB for Host B) described in Section 3.2.4, while
the HMAC "Message" for MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR must be the HMAC "Message" for MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR must be
calculated in both hosts in order to protect the multipath option calculated in both hosts in order to protect the Multipath Option
when sending and to validate the multipath option when receiving; it when sending and to validate the Multipath Option when receiving; it
is a concatenation of: is a concatenation of:
* For MP_JOIN: The nonces of the MP_JOIN messages for which * For MP_JOIN: The Nonces of the MP_JOIN messages for which
authentication shall be performed. Depending on whether Host A or authentication shall be performed. Depending on whether Host A or
Host B performs the HMAC-SHA256 calculation, it is carried out as Host B performs the HMAC-SHA256 calculation, it is carried out as
follows: follows:
- MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=RA+RB) - MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=RA+RB)
- MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=RB+RA) - MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=RB+RA)
A usage example is shown in Figure 21. A usage example is shown in Figure 21.
skipping to change at line 974 skipping to change at line 1003
* For MP_REMOVEADDR: Solely the Address ID. Depending on whether * For MP_REMOVEADDR: Solely the Address ID. Depending on whether
Host A or Host B performs the HMAC-SHA256 calculation, it is Host A or Host B performs the HMAC-SHA256 calculation, it is
carried out as follows: carried out as follows:
- MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=Address ID+Nonce) - 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_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=Address ID+Nonce)
MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR can coexist or be used MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR can coexist or be used
multiple times within a single DCCP packet. All these multipath multiple times within a single DCCP packet. All these Multipath
options require an individual MP_HMAC option. This ensures that the Options require an individual MP_HMAC option. This ensures that the
MP_HMAC is correctly associated. Otherwise, the receiver cannot MP_HMAC is correctly associated. Otherwise, the receiver cannot
validate multiple MP_JOIN, MP_ADDADDR, or MP_REMOVEADDR options. validate multiple MP_JOIN, MP_ADDADDR, or MP_REMOVEADDR options.
Therefore, an MP_HMAC MUST directly follow its associated multipath Therefore, an MP_HMAC MUST directly follow its associated Multipath
option. In the likely case of sending an MP_JOIN together with an Option. In the likely case of sending an MP_JOIN together with an
MP_ADDADDR, this results in concatenating MP_JOIN + MP_HMAC_1 + MP_ADDADDR, this results in concatenating MP_JOIN + MP_HMAC_1 +
MP_ADDADDR + MP_HMAC_2, whereas the first MP_HMAC_1 is associated 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 with the MP_JOIN and the second MP_HMAC_2 is associated with the
MP_ADDADDR suboption. MP_ADDADDR suboption.
On the receiver side, the HMAC validation of the suboptions MUST be On the receiver side, the HMAC validation of the suboptions MUST be
carried out according to the sending sequence in which the associated carried out according to the sending sequence in which the associated
MP_HMAC follows a suboption. If the suboption cannot be validated by MP_HMAC follows a suboption. If the suboption cannot be validated by
a receiving host because the HMAC validation fails (HMAC is wrong or a receiving host because the HMAC validation fails (HMAC is wrong or
missing), the subsequent handling depends on which suboption was missing), the subsequent handling depends on which suboption was
skipping to change at line 1003 skipping to change at line 1032
authenticated was MP_JOIN, the subflow MUST be closed (see authenticated was MP_JOIN, the subflow MUST be closed (see
Section 3.6). Section 3.6).
In the event that an MP_HMAC cannot be associated with a suboption, In the event that an MP_HMAC cannot be associated with a suboption,
this MP_HMAC MUST be ignored, unless it is a single MP_HMAC that was this MP_HMAC MUST be ignored, unless it is a single MP_HMAC that was
sent in a DCCP-Ack corresponding to a DCCP response packet with sent in a DCCP-Ack corresponding to a DCCP response packet with
MP_JOIN (see the penultimate arrow in Figure 21). MP_JOIN (see the penultimate arrow in Figure 21).
3.2.7. MP_RTT 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 1 2 3 4 5
01234567 89012345 67890123 45678901 23456789 01234567 89012345 01234567 89012345 67890123 45678901 23456789 01234567 89012345
+--------+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+--------+--------+
|00101110|00001100|00000110|RTT Type| RTT |00101110|00001100|00000110|RTT Type| RTT
+--------+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+--------+--------+
| Age | | Age |
+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+
Type=46 Length=12 MP_OPT=6 Type=46 Length=12 MP_OPT=6
Figure 14: Format of the MP_RTT Suboption Figure 14: 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 The RTT and Age information is a 32-bit integer. This covers a
period of approximately 1193 hours. period of approximately 1193 hours.
The Field RTT type indicates the type of RTT estimation, according to The Field RTT type indicates the type of RTT estimation, according to
the following description: the following description:
Raw RTT (=0) Raw RTT (=0)
Raw RTT value of the last Datagram round trip. Raw RTT value of the last Datagram round trip.
Min RTT (=1) Min RTT (=1)
skipping to change at line 1102 skipping to change at line 1131
remains port 80 on all subflows, as does the ephemeral port at the remains port 80 on all subflows, as does the ephemeral port at the
client), there could be cases (such as port-based load balancing) client), there could be cases (such as port-based load balancing)
where the explicit specification of a different port is required. If where the explicit specification of a different port is required. If
no port is specified, the receiving host MUST assume that any attempt 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 to connect to the specified address uses the port already used by the
subflow on which the MP_ADDADDR signal was sent. subflow on which the MP_ADDADDR signal was sent.
Along with the MP_ADDADDR option, an MP_HMAC option MUST be sent for Along with the MP_ADDADDR option, an MP_HMAC option MUST be sent for
authentication. The truncated HMAC parameter present in this MP_HMAC authentication. The truncated HMAC parameter present in this MP_HMAC
option is the leftmost 20 bytes of an HMAC, negotiated and calculated 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 as described in Section 3.2.6. Similar to MP_JOIN, the key for the
key for the HMAC algorithm, in the case of the message transmitted by HMAC algorithm will be d-KeyA when the message is transmitted by Host
Host A, will be d-KeyA, and in the case of Host B, d-KeyB. These are A and d-KeyB when transmitted by Host B. These are the keys that
the keys that were exchanged and selected in the original MP_KEY were exchanged and selected in the original MP_KEY handshake. The
handshake. The message for the HMAC is the Address ID, Nonce, IP message for the HMAC is the Address ID, Nonce, IP address, and port
address, and port number that precede the HMAC in the MP_ADDADDR number that precede the HMAC in the MP_ADDADDR option. If the port
option. If the port number is not present in the MP_ADDADDR option, number is not present in the MP_ADDADDR option, the HMAC message will
the HMAC message will include 2 bytes of value zero. The rationale include 2 bytes of value zero. The rationale for the HMAC is to
for the HMAC is to prevent unauthorized entities from injecting prevent unauthorized entities from injecting MP_ADDADDR signals in an
MP_ADDADDR signals in an attempt to hijack a connection. attempt to hijack a connection. Additionally, note that the presence
Additionally, note that the presence of this HMAC prevents the of this HMAC prevents the address from being changed in flight unless
address from being changed in flight unless the key is known by an the key is known by an intermediary. If a host receives an
intermediary. If a host receives an MP_ADDADDR option for which it MP_ADDADDR option for which it cannot validate the HMAC, it MUST
cannot validate the HMAC, it MUST silently ignore the option. silently ignore the option.
The presence of an MP_SEQ (Section 3.2.5) MUST be ensured in a DCCP The presence of an MP_SEQ (Section 3.2.5) MUST be ensured in a DCCP
datagram in which MP_ADDADDR is sent, as described in Section 3.2.1. datagram in which MP_ADDADDR is sent, as described in Section 3.2.1.
1 2 3 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 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 | |0 0 1 0 1 1 1 0| var |0 0 0 0 0 1 1 1| Address ID |
+---------------+---------------+-------+-------+---------------+ +---------------+---------------+-------+-------+---------------+
| Nonce | | Nonce |
skipping to change at line 1228 skipping to change at line 1257
be closed with a DCCP Close exchange (as with regular DCCP) instead be closed with a DCCP Close exchange (as with regular DCCP) instead
of using MP_REMOVEADDR. For more information see Section 3.5. of using MP_REMOVEADDR. For more information see Section 3.5.
The Nonce is a 32-bit random value that is generated locally for each The Nonce is a 32-bit random value that is generated locally for each
MP_REMOVEADDR option and is used in the HMAC calculation process to MP_REMOVEADDR option and is used in the HMAC calculation process to
prevent replay attacks. prevent replay attacks.
Along with the MP_REMOVEADDR suboption, an MP_HMAC option MUST be Along with the MP_REMOVEADDR suboption, an MP_HMAC option MUST be
sent for authentication. The truncated HMAC parameter present in sent for authentication. The truncated HMAC parameter present in
this MP_HMAC option is the leftmost 20 bytes of an HMAC, negotiated 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 and calculated as described in Section 3.2.6. Similar to MP_JOIN,
MP_JOIN, the key for the HMAC algorithm, in the case of the message the key for the HMAC algorithm will be d-KeyA when the message is
transmitted by Host A, will be d-KeyA, and in the case of Host B, transmitted by Host A and d-KeyB when transmitted by Host B. These
d-KeyB. These are the keys that were exchanged and selected in the are the keys that were exchanged and selected in the original MP_KEY
original MP_KEY handshake. The message for the HMAC is the Address handshake. The message for the HMAC is the Address ID.
ID.
The rationale for using an HMAC is to prevent unauthorized entities The rationale for using an HMAC is to prevent unauthorized entities
from injecting MP_REMOVEADDR signals in an attempt to hijack a from injecting MP_REMOVEADDR signals in an attempt to hijack a
connection. Additionally, note that the presence of this HMAC connection. Additionally, note that the presence of this HMAC
prevents the address from being modified in flight unless the key is prevents the address from being modified in flight unless the key is
known by an intermediary. If a host receives an MP_REMOVEADDR option known by an intermediary. If a host receives an MP_REMOVEADDR option
for which it cannot validate the HMAC, it MUST silently ignore the for which it cannot validate the HMAC, it MUST silently ignore the
option. option.
A receiver MUST include an MP_SEQ (Section 3.2.5) in a DCCP datagram A receiver MUST include an MP_SEQ (Section 3.2.5) in a DCCP datagram
skipping to change at line 1326 skipping to change at line 1354
* 3 - 15: Primary: The path can be used for packet scheduling * 3 - 15: Primary: The path can be used for packet scheduling
decisions. The priority number indicates the relative priority of decisions. The priority number indicates the relative priority of
one path over the other for primary paths. Higher numbers one path over the other for primary paths. Higher numbers
indicate higher priority. The peer should consider sending indicate higher priority. The peer should consider sending
traffic first over higher priority paths. This is the recommended traffic first over higher priority paths. This is the recommended
setting for paths that do not have a cost or data caps associated setting for paths that do not have a cost or data caps associated
with them as these paths will be frequently used. with them as these paths will be frequently used.
Example use cases include: Example use cases include:
1. Setting the Wi-Fi path to Primary and Cellular paths to 1. Setting the Wi-Fi path to Primary and Cellular path to Secondary.
Secondary. In this case, Wi-Fi will be used and Cellular will be In this case, Wi-Fi will be used and Cellular will be used only
used only if the Wi-Fi path is congested or not available. Such if the Wi-Fi path is congested or not available. Such setting
setting results in using the Cellular path only temporally, if results in using the Cellular path only temporally, if more
more capacity is needed than the Wi-Fi path can provide, capacity is needed than the Wi-Fi path can provide, indicating a
indicating a clear priority of the Wi-Fi path over the Cellular clear priority of the Wi-Fi path over the Cellular due to, e.g.,
due to, e.g., cost reasons. cost reasons.
2. Setting the Wi-Fi path to Primary and Cellular path to Standby. 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 In this case, Wi-Fi will be used and Cellular will be used only
if the Wi-Fi path is not available. if the Wi-Fi path is not available.
3. Setting the Wi-Fi path to Primary and Cellular path to Primary. 3. Setting the Wi-Fi path to Primary and Cellular path to Primary.
In this case, both paths can be used when making packet In this case, both paths can be used when making packet
scheduling decisions. scheduling decisions.
If not specified, the default behavior is to always use a path for If not specified, the default behavior is to always use a path for
skipping to change at line 1357 skipping to change at line 1385
update at least one path to a non-zero MP_PRIO value when an MP-DCCP 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 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 value of zero. This helps an MP-DCCP connection to schedule when the
multipath scheduler strictly respects MP_PRIO value 0. To ensure multipath scheduler strictly respects MP_PRIO value 0. To ensure
reliable transmission, the MP_PRIO suboption MUST be acknowledged via reliable transmission, the MP_PRIO suboption MUST be acknowledged via
an MP_CONFIRM (see Table 4). an MP_CONFIRM (see Table 4).
The relative ratio of the primary path values 3-15 depends on the The relative ratio of the primary path values 3-15 depends on the
path usage strategy, which is described in more detail in path usage strategy, which is described in more detail in
Section 3.11. In the case of path mobility (Section 3.11.1), only Section 3.11. In the case of path mobility (Section 3.11.1), only
one path can be used at a time and MUST be the appropriate one that one path can be used at a time and MUST have the highest available
has the highest available priority value including also the prio priority value. That also includes the prio numbers 1 and 2. In the
numbers 1 and 2. In the other case of concurrent path usage other case of concurrent path usage (Section 3.11.2), the definition
(Section 3.11.2), the definition is up to the multipath scheduler is up to the multipath scheduler logic.
logic.
An MP_SEQ (Section 3.2.5) MUST be present in a DCCP datagram in which An MP_SEQ (Section 3.2.5) MUST be present in a DCCP datagram in which
the MP_PRIO suboption is sent. Further details are given in the MP_PRIO suboption is sent. Further details are given in
Section 3.2.1. Section 3.2.1.
3.2.11. MP_CLOSE 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 1 2 3
01234567 89012345 67890123 45678901 23456789 01234567 89012345 67890123 45678901 23456789
+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+
|00101110| var |00001010| Key Data ... |00101110| var |00001010| Key Data ...
+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+--------+
Type=46 Length MP_OPT=10 Type=46 Length MP_OPT=10
Figure 19: Format of the MP_CLOSE Suboption Figure 19: Format of the MP_CLOSE Suboption
An MP-DCCP connection can be gracefully closed by sending an MP_CLOSE An MP-DCCP connection can be gracefully closed by sending an MP_CLOSE
to the peer host. On all subflows, the regular termination procedure to the peer host. On all subflows, the regular termination procedure
described in [RFC4340] MUST be initiated using MP_CLOSE in the described in [RFC4340] MUST be initiated using MP_CLOSE in the
initial packet (either a DCCP-CloseReq or a DCCP-Close). When a initial packet (either a DCCP-CloseReq or a DCCP-Close). When a
DCCP-CloseReq is used, the following DCCP-Close MUST also carry the 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. 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- At the initiator of the DCCP-CloseReq, all sockets, including the MP-
DCCP connection socket, transition to CLOSEREQ state. To protect DCCP connection socket, transition to CLOSEREQ state. To protect
from unauthorized shutdown of a multipath connection, the selected from unauthorized shutdown of a multipath connection, the selected
Key Data of the peer host during the handshaking procedure MUST be Key Data of the peer host MUST be included in the MP_CLOSE option
included in by the MP_CLOSE option and must be validated by the peer during the handshake procedure and MUST be validated by the peer
host. Note, the Key Data is different between MP_CLOSE option host. Please note that the Key Data sent in DCCP-CloseReq will not
carried by DCCP-CloseReq or DCCP-Close. 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 On reception of the first DCCP-CloseReq carrying an MP_CLOSE with
valid Key Data, or due to a local decision, all subflows transition valid Key Data, or due to a local decision, all subflows transition
to the CLOSING state before transmitting a DCCP-Close carrying to the CLOSING state before transmitting a DCCP-Close carrying
MP_CLOSE. The MP-DCCP connection socket on the host sending the MP_CLOSE. The MP-DCCP connection socket on the host sending the
DCCP-Close reflects the state of the initial subflow during the DCCP-Close reflects the state of the initial subflow during the
handshake with MP_KEY option. If the initial subflow no longer handshake with MP_KEY option. If the initial subflow no longer
exists, the state moves immediately to CLOSED. exists, the state moves immediately to CLOSED.
Upon reception of the first DCCP-Close carrying an MP_CLOSE with 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 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- 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 Reset with Reset Code 1 MUST be sent on any subflow in response to a
received DCCP-Close containing a valid MP_CLOSE option. received DCCP-Close containing a valid MP_CLOSE option.
When the MP-DCCP connection socket is in CLOSEREQ or CLOSE state, new When the MP-DCCP connection socket is in CLOSEREQ or CLOSED state,
subflow requests using MP_JOIN MUST be ignored. new subflow requests using MP_JOIN MUST be ignored.
Contrary to an MP_FAST_CLOSE (Section 3.2.3), no single-sided abrupt Contrary to an MP_FAST_CLOSE (Section 3.2.3), no single-sided abrupt
termination is applied. termination is applied.
3.2.12. Experimental Multipath Option MP_EXP for Private Use 3.2.12. Experimental Multipath Option MP_EXP for Private Use
This section reserves a Multipath option to define and specify any This section reserves a Multipath Option to define and specify any
experimental additional feature for improving and optimizing the MP- experimental additional feature for improving and optimizing the MP-
DCCP protocol. This option could be applicable to specific DCCP protocol. This option could be applicable to specific
environments or scenarios according to potential new requirements and environments or scenarios according to potential new requirements and
is meant for private use only. MP_OPT feature number 11 is specified is meant for private use only. MP_OPT Feature Number 11 is specified
with an exemplary description as below: with an exemplary description as below:
1 2 3 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 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 TBD | |0 0 1 0 1 1 1 0| var |0 0 0 0 1 0 1 1| Data |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| ... | ...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Type=46 Length MP_OPT=11 Type=46 Length MP_OPT=11
Figure 20: Format of the MP_EXP Suboption Figure 20: Format of the MP_EXP Suboption
The Data field can carry any data according to the foreseen use by The Data field can carry any data according to the foreseen use by
the experimenters with a maximum length of 252 bytes. the experimenters with a maximum length of 252 bytes.
3.3. MP-DCCP Handshaking Procedure 3.3. MP-DCCP Handshake Procedure
An example MP-DCCP handshake procedure is shown in Figure 21. An example MP-DCCP handshake procedure is shown in Figure 21.
Host A Host B Host A Host B
------------------------ ---------- ------------------------ ----------
Address A1 Address A2 Address B1 Address A1 Address A2 Address B1
---------- ---------- ---------- ---------- ---------- ----------
| | | | | |
| DCCP-Request + Change R (MP_CAPABLE,...) | | DCCP-Request + Change R (MP_CAPABLE,...) |
|----- MP_KEY(CI-A + KeyA(1), KeyA(2),...) ---------->| |----- MP_KEY(CI-A + KeyA(1), KeyA(2),...) ---------->|
skipping to change at line 1468 skipping to change at line 1502
| | | | | |
| |DCCP-Ack | | |DCCP-Ack |
| |-------- MP_HMAC(A) ------------------>| | |-------- MP_HMAC(A) ------------------>|
| |<--------------------------------------| | |<--------------------------------------|
| |DCCP-Ack | | |DCCP-Ack |
Figure 21: Example MP-DCCP Handshake Figure 21: Example MP-DCCP Handshake
The basic initial handshake for the first subflow is as follows: The basic initial handshake for the first subflow is as follows:
* Host A sends a DCCP-Request with the MP-Capable feature change 1. Host A sends a DCCP-Request with the Multipath Capable Feature
request and the MP_KEY option with a Host-specific CI-A and a KeyA change request and the MP_KEY option with a Host-specific CI-A
for each of the supported key types as described in Section 3.2.4. and a KeyA for each of the supported Key Types as described in
CI-A is a unique identifier during the lifetime of an MP-DCCP Section 3.2.4. CI-A is a unique identifier during the lifetime
connection. of an MP-DCCP connection.
* Host B sends a DCCP-Response with a Confirm feature for MP-Capable 2. Host B sends a DCCP-Response with a Confirm feature for MP-
and the MP_Key option with a unique Host-specific CI-B and a Capable and the MP_Key option with a unique Host-specific CI-B
single Host-specific KeyB. The type of the key is chosen from the and a single Host-specific KeyB. The type of the key is chosen
list of supported types from the previous request. from the list of supported types from the previous request.
* Host A sends a DCCP-Ack to confirm the proper key exchange. 3. 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 4. Host B sends a DCCP-Ack to complete the handshake and set both
connection ends to the OPEN state. connection ends to the OPEN state.
It should be noted that DCCP is protected against corruption of DCCP It should be noted that DCCP is protected against corruption of DCCP
header data (Section 9 of [RFC4340]), so no additional mechanisms header data (Section 9 of [RFC4340]), so no additional mechanisms
beyond the general confirmation are required to ensure that the beyond the general confirmation are required to ensure that the
header data has been properly received. header data has been properly received.
Host A waits for the final DCCP-Ack from Host B before starting any Host A waits for the final DCCP-Ack from Host B before starting any
establishment of additional subflow connections. establishment of additional subflow connections.
The handshake for subsequent subflows, based on a successful initial The handshake for subsequent subflows, based on a successful initial
handshake, is as follows: handshake, is as follows:
* Host A sends a DCCP-Request with the MP-Capable feature change 1. Host A sends a DCCP-Request with the Multipath Capable Feature
request and the MP_JOIN option with Host B's CI-B, obtained during change request and the MP_JOIN option with Host B's CI-B,
the initial handshake. Additionally, an own random nonce RA is obtained during the initial handshake. Additionally, a random
transmitted with the MP_JOIN. Nonce RA is transmitted with the MP_JOIN.
* Host B computes the HMAC of the DCCP-Request and sends a DCCP- 2. Host B computes the HMAC of the DCCP-Request and sends a DCCP-
Response with a Confirm feature option for MP-Capable and the Response with a Confirm feature option for MP-Capable and the
MP_JOIN option with the CI-A and a random nonce RB together with MP_JOIN option with the CI-A and a random Nonce RB together with
the computed MP_HMAC. As specified in Section 3.2.6, the HMAC is the computed MP_HMAC. As specified in Section 3.2.6, the HMAC is
calculated by taking the leftmost 20 bytes from the SHA256 hash of calculated by taking the leftmost 20 bytes from the SHA-256 hash
an HMAC code created by using the nonce received with MP_JOIN(A) of an HMAC code that is created by using the Nonce received with
and the local nonce RB as message and the derived key described in MP_JOIN(A) and the local Nonce RB as the Message and the derived
Section 3.2.4 as key: key as the Key, as described in Section 3.2.4:
MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=RB+RA) MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=RB+RA)
* Host A sends a DCCP-Ack with the HMAC computed for the DCCP- 3. Host A sends a DCCP-Ack with the HMAC computed for the DCCP-
Response. As specified in Section 3.2.6, the HMAC is calculated Response. As specified in Section 3.2.6, the HMAC is calculated
by taking the leftmost 20 bytes from the SHA256 hash of an HMAC by taking the leftmost 20 bytes from the SHA-256 hash of an HMAC
code created by using the local nonce RA and the nonce received code created by using the local Nonce RA and the Nonce received
with MP_JOIN(B) as message and the derived key described in with MP_JOIN(B) as message and the derived key described in
Section 3.2.4 as key: Section 3.2.4 as key:
MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=RA+RB) MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=RA+RB)
* Host B sends a DCCP-Ack to confirm the HMAC and to conclude the 4. Host B sends a DCCP-Ack to confirm the HMAC and to conclude the
handshaking. handshake.
3.4. Address Knowledge Exchange 3.4. Address Knowledge Exchange
3.4.1. Advertising a New Path (MP_ADDADDR) 3.4.1. Advertising a New Path (MP_ADDADDR)
When a host (Host A) wants to advertise the availability of a new 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) as shown in path, it should use the MP_ADDADDR option (Section 3.2.8) as shown in
the example in Figure 22. The MP_ADDADDR option passed in the DCCP- the example in Figure 22. The MP_ADDADDR option passed in the DCCP-
Data contains the following parameters: Data contains the following parameters:
skipping to change at line 1547 skipping to change at line 1581
* the IP address of the new path (A2_IP) * the IP address of the new path (A2_IP)
* a pair of bytes specifying the port number associated with this 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 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 same as that used for the initial subflow address A1_IP.
According to Section 3.2.8, the following options are required in a According to Section 3.2.8, the following options are required in a
packet carrying MP_ADDADDR: packet carrying MP_ADDADDR:
* the leftmost 20 bytes of the HMAC(A) generated during the initial * the leftmost 20 bytes of the HMAC(A) generated during the initial
handshaking procedure described in Sections 3.3 and 3.2.6 handshake procedure described in Sections 3.3 and 3.2.6
* the MP_SEQ option with the sequence number (seqno 12) for this * the MP_SEQ option with the sequence number (seqno 12) for this
message, according to Section 3.2.5 message, according to Section 3.2.5
Host B acknowledges receipt of the MP_ADDADDR message with a DCCP-Ack Host B acknowledges receipt of the MP_ADDADDR message with a DCCP-Ack
containing the MP_CONFIRM option. The parameters supplied in this containing the MP_CONFIRM option. The parameters supplied in this
response are as follows: response are as follows:
* an MP_CONFIRM containing the MP_SEQ number (seqno 12) of the * an MP_CONFIRM containing the MP_SEQ number (seqno 12) of the
packet carrying the option that we are confirming together with packet carrying the option that we are confirming together with
the MP_ADDADDR option the MP_ADDADDR option
* the leftmost 20 bytes of the HMAC(B) generated during the initial * the leftmost 20 bytes of the HMAC(B) generated during the initial
handshaking procedure (Section 3.3) handshake procedure (Section 3.3)
Host A Host B Host A Host B
------------------------ ----------- ------------------------ -----------
Address A1 Address A2 Address B1 Address A1 Address A2 Address B1
---------- ---------- ----------- ---------- ---------- -----------
| | | | | |
| DCCP-Data + MP_ADDADDR(id 2, Nonce, A2_IP, 00) + | | DCCP-Data + MP_ADDADDR(id 2, Nonce, A2_IP, 00) + |
|------- MP_HMAC(A) + MP_SEQ(seqno 12) -------------->| |------- MP_HMAC(A) + MP_SEQ(seqno 12) -------------->|
| | | | | |
| DCCP-Ack + MP_HMAC(B) + | | DCCP-Ack + MP_HMAC(B) + |
|<----- MP_CONFIRM(seqno 12, MP_ADDADDR) -------------| |<----- MP_CONFIRM(seqno 12, MP_ADDADDR) -------------|
Figure 22: Example MP-DCCP ADDADDR Procedure Figure 22: Example MP_ADDADDR Procedure
3.4.2. Removing a Path (MP_REMOVEADDR) 3.4.2. Removing a Path (MP_REMOVEADDR)
When a host (Host A) wants to indicate that a path is no longer 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) as available, it should use the MP_REMOVEADDR option (Section 3.2.9) as
shown in the example in Figure 23. The MP_REMOVEADDR option passed shown in the example in Figure 23. The MP_REMOVEADDR option passed
in the DCCP-Data contains the following parameters: in the DCCP-Data contains the following parameters:
* an identifier (id 2) for the IP address to remove (A2_IP) and that * an identifier (id 2) for the IP address to remove (A2_IP) and that
was specified in a previous MP_ADDADDR message was specified in a previous MP_ADDADDR message
* a Nonce value to prevent replay attacks * a Nonce value to prevent replay attacks
According to Section 3.2.9, the following options are required in a According to Section 3.2.9, the following options are required in a
packet carrying MP_REMOVEADDR: packet carrying MP_REMOVEADDR:
* the leftmost 20 bytes of the HMAC(A) generated during the initial * the leftmost 20 bytes of the HMAC(A) generated during the initial
handshaking procedure described in Sections 3.3 and 3.2.6 handshake procedure described in Sections 3.3 and 3.2.6
* the MP_SEQ option with the sequence number (seqno 33) for this * the MP_SEQ option with the sequence number (seqno 33) for this
message, according to Section 3.2.5 message, according to Section 3.2.5
Host B acknowledges receipt of the MP_REMOVEADDR message with a DCCP- Host B acknowledges receipt of the MP_REMOVEADDR message with a DCCP-
Ack containing the MP_CONFIRM option. The parameters supplied in Ack containing the MP_CONFIRM option. The parameters supplied in
this response are as follows: this response are as follows:
* an MP_CONFIRM containing the MP_SEQ number (seqno 33) of the * an MP_CONFIRM containing the MP_SEQ number (seqno 33) of the
packet carrying the option that we are confirming, together with packet carrying the option that we are confirming, together with
the MP_REMOVEADDR option the MP_REMOVEADDR option
* the leftmost 20 bytes of the HMAC(B) generated during the initial * the leftmost 20 bytes of the HMAC(B) generated during the initial
handshaking procedure (Section 3.3) handshake procedure (Section 3.3)
Host A Host B Host A Host B
------------------------ ----------- ------------------------ -----------
Address A1 Address A2 Address B1 Address A1 Address A2 Address B1
---------- ---------- ----------- ---------- ---------- -----------
| | | | | |
| DCCP-Data + MP_REMOVEADDR(id 2, Nonce) + | | DCCP-Data + MP_REMOVEADDR(id 2, Nonce) + |
|------- MP_HMAC(A) + MP_SEQ(seqno 33) -------------->| |------- MP_HMAC(A) + MP_SEQ(seqno 33) -------------->|
| | | | | |
| DCCP-Ack + MP_HMAC(B) + | | DCCP-Ack + MP_HMAC(B) + |
|<----- MP_CONFIRM(seqno 33, MP_REMOVEADDR) ----------| |<----- MP_CONFIRM(seqno 33, MP_REMOVEADDR) ----------|
Figure 23: Example MP-DCCP REMOVEADDR Procedure Figure 23: Example MP_REMOVEADDR Procedure
3.5. Closing an MP-DCCP Connection 3.5. Closing an MP-DCCP Connection
When a host wants to close an existing subflow but not the whole MP- When a host wants to close an existing subflow but not the whole MP-
DCCP connection, it MUST initiate the regular DCCP connection DCCP connection, it MUST initiate the regular DCCP connection
termination procedure as described in Section 5.6 of [RFC4340], i.e., termination procedure as described in Section 5.6 of [RFC4340], i.e.,
it sends a DCCP-Close/DCCP-Reset on the subflow. This may be it sends a DCCP-Close/DCCP-Reset on the subflow. This may be
preceded by a DCCP-CloseReq. In the event of an irregular preceded by a DCCP-CloseReq. In the event of an irregular
termination of a subflow, e.g., during subflow establishment, it MUST termination of a subflow, e.g., during subflow establishment, it MUST
use an appropriate DCCP-Reset code as specified by IANA use an appropriate DCCP-Reset Code as specified by IANA
[DCCP-PARAMETERS] for DCCP operations. This could be, for example, [DCCP-PARAMETERS] for DCCP operations. This could be, for example,
sending reset code 5 (Option Error) when an MP-DCCP option provides 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 invalid data or Reset Code 9 (Too Busy) when the maximum number of
maintainable paths is reached. Note that receiving a reset code 9 maintainable paths is reached. Note that receiving a Reset Code 9
for secondary subflows MUST NOT impact already existing active for secondary subflows MUST NOT impact already existing active
subflows. If necessary, these subflows are terminated in a subflows. If necessary, these subflows are terminated in a
subsequent step using the procedures described in this section. subsequent step using the procedures described in this section.
A host terminates an MP-DCCP connection using the DCCP connection A host terminates an MP-DCCP connection using the DCCP connection
termination specified in Section 5.5 of [RFC4340] on each subflow termination specified in Section 5.5 of [RFC4340] on each subflow
with the first packet on each subflow carrying MP_CLOSE (see with the first packet on each subflow carrying MP_CLOSE (see
Section 3.2.11). Section 3.2.11).
Host A Host B Host A Host B
------ ------ ------ ------
<- Optional DCCP-CloseReq + <- Optional DCCP-CloseReq +
MP_CLOSE [A's key] MP_CLOSE [A's key]
[on all subflows] [on all subflows]
DCCP-Close + MP_CLOSE -> DCCP-Close + MP_CLOSE ->
[B's key] [on all subflows] [B's key] [on all subflows]
<- DCCP-Reset <- DCCP-Reset
[on all subflows] [on all subflows]
Additionally, an MP-DCCP connection may be closed abruptly using the Additionally, an MP-DCCP connection may be closed abruptly using the
"Fast Close" procedure described in Section 3.2.3, where a DCCP-Reset "fast close" procedure described in Section 3.2.3, where a DCCP-Reset
is sent on all subflows, each carrying the MP_FAST_CLOSE option. is sent on all subflows, each carrying the MP_FAST_CLOSE option.
Host A Host B Host A Host B
------ ------ ------ ------
DCCP-Reset + MP_FAST_CLOSE -> DCCP-Reset + MP_FAST_CLOSE ->
[B's key] [on all subflows] [B's key] [on all subflows]
<- DCCP-Reset <- DCCP-Reset
[on all subflows] [on all subflows]
3.6. Fallback 3.6. Fallback
When a subflow fails to operate following the intended behavior of When a subflow fails to operate following the intended behavior of
the MP-DCCP, it is necessary to proceed with a fallback. This may be the MP-DCCP, it is necessary to proceed with a fallback. This may be
either falling back to regular DCCP [RFC4340] or removing a either falling back to regular DCCP [RFC4340] or removing a
problematic subflow. The main reasons for a subflow failing include: problematic subflow. The main reasons for a subflow failing include:
no MP support at the peer host, failure to negotiate the protocol no MP support at the peer host, failure to negotiate the protocol
version, loss of Multipath options, faulty/non-supported MP-DCCP version, loss of Multipath Options, faulty/non-supported MP-DCCP
options, or modification of payload data. options, or modification of payload data.
At the start of an MP-DCCP connection, the handshake ensures the At the start of an MP-DCCP connection, the handshake ensures the
exchange of the MP-DCCP feature and options and thus ensures that the exchange of the MP-DCCP feature and options and thus ensures that the
path is fully MP-DCCP capable. If during the handshake procedure it path is fully MP-DCCP capable. If during the handshake procedure it
appears that DCCP-Request or DCCP-Response messages do not carry the appears that DCCP-Request or DCCP-Response messages do not carry the
MP_CAPABLE feature, the MP-DCCP connection will not be established Multipath Capable Feature, the MP-DCCP connection will not be
and the handshake SHOULD fall back to regular DCCP. If this is not established and the handshake SHOULD fall back to regular DCCP. If
possible, the connection MUST be closed. this is not possible, the connection MUST be closed.
If the endpoints fail to agree on the protocol version to use during If the endpoints fail to agree on the protocol version to use during
the Multipath Capable feature negotiation, the connection MUST either the Multipath Capable Feature negotiation, the connection MUST either
be closed or fall back to regular DCCP. This is described in be closed or fall back to regular DCCP. This is described in
Section 3.1. The protocol version negotiation distinguishes between Section 3.1. The protocol version negotiation distinguishes between
negotiation for the initial connection establishment and the addition negotiation for the initial connection establishment and the addition
of subsequent subflows. If protocol version negotiation is not of subsequent subflows. If protocol version negotiation is not
successful during the initial connection establishment, the MP-DCCP successful during the initial connection establishment, the MP-DCCP
connection will fall back to regular DCCP. connection will fall back to regular DCCP.
The fallback procedure for regular DCCP MUST also be applied if the The fallback procedure for regular DCCP MUST also be applied if the
MP_KEY (Section 3.2.4) Key Type cannot be negotiated. MP_KEY (Section 3.2.4) Key Type cannot be negotiated.
If a subflow attempts to join an existing MP-DCCP connection but MP- If a subflow attempts to join an existing MP-DCCP connection but MP-
DCCP options or the MP_CAPABLE feature are not present or are faulty DCCP options or the Multipath Capable Feature are not present or are
in the handshake procedure, that subflow MUST be closed. This is the faulty in the handshake procedure, that subflow MUST be closed. This
case especially if a different MP_CAPABLE version than the originally is the case especially if a different MP_CAPABLE version than the
negotiated version is used. Reception of a non-verifiable MP_HMAC originally negotiated version is used. Reception of a non-verifiable
(Section 3.2.6) or an invalid CI used in MP_JOIN (Section 3.2.2) MP_HMAC (Section 3.2.6) or an invalid CI used in MP_JOIN
during flow establishment MUST cause the subflow to be closed. (Section 3.2.2) during flow establishment MUST cause the subflow to
be closed.
The subflow closing procedure MUST also be applied if a final ACK The subflow closing procedure MUST also be applied if a final ACK
carrying MP_KEY with the wrong KeyA/KeyB is received or the MP_KEY carrying MP_KEY with the wrong KeyA/KeyB is received or the MP_KEY
option is malformed. option is malformed.
Another relevant case is when payload data is modified by Another relevant case is when payload data is modified by
middleboxes. DCCP uses a checksum to protect the data, as described middleboxes. DCCP uses a checksum to protect the data, as described
in Section 9 of [RFC4340]. A checksum will fail if the data has been in Section 9 of [RFC4340]. A checksum will fail if the data has been
changed in any way. All data from the start of the segment that changed in any way. All data from the start of the segment that
failed the checksum onwards cannot be considered trustworthy. If the failed the checksum onwards cannot be considered trustworthy. As
checksum fails as defined by the DCCP, the receiving endpoint MUST defined by DCCP, if the checksum fails, the receiving endpoint MUST
drop the application data and report that data as dropped due to drop the application data and report that data as dropped due to
corruption using a Data Dropped option (Drop Code 3, Corrupt). If corruption using a Data Dropped option (Drop Code 3, Corrupt). If
data is dropped due to corruption for an MP-DCCP connection, the data is dropped due to corruption for an MP-DCCP connection, the
affected subflow MAY be closed. The same procedure applies if the MP affected subflow MAY be closed. The same procedure applies if the
option is unknown. Multipath Option is unknown.
3.7. State Diagram 3.7. State Diagram
The MP-DCCP per subflow state transitions follow the state The MP-DCCP per subflow state transitions follow the state
transitions defined for DCCP in [RFC4340] to a large extent, with transitions defined for DCCP in [RFC4340] to a large extent, with
some modifications due to the MP-DCCP 4-way handshake and fast close some modifications due to the MP-DCCP 4-way handshake and fast close
procedures. The state diagram below shows the most common state procedures. The state diagram below shows the most common state
transitions. The diagram is illustrative. For example, there are transitions. The diagram is illustrative. For example, there are
arcs (not shown) from several additional states to TIMEWAIT, arcs (not shown) from several additional states to TIMEWAIT,
contingent on the receipt of a valid DCCP-Reset. contingent on the receipt of a valid DCCP-Reset.
The states transitioned when moving from the CLOSED to OPEN state When the state moves from CLOSED to OPEN during the 4-way handshake,
during the 4-way handshake remain the same as for DCCP, but it is no the transitioned states remain the same as for DCCP, but it is no
longer possible to transmit application data while in the REQUEST longer possible to transmit application data while in the REQUEST
state. The fast close procedure can be triggered by either the state. The fast close procedure can be triggered by either the
client or the server and results in the transmission of a Reset client or the server and results in the transmission of a Reset
packet. The fast close procedure moves the state of the client and packet. The fast close procedure moves the state of the Client and
server directly to TIMEWAIT and CLOSED, respectively. Server directly to TIMEWAIT and CLOSED, respectively.
+----------------------------+ +------------------------------+ +----------------------------+ +------------------------------+
| v v | | v v |
| +----------+ | | +----------+ |
| +-------------+ CLOSED +-------------+ | | +-------------+ CLOSED +-------------+ |
| | passive +----------+ active | | | | passive +----------+ active | |
| | open open | | | | open open | |
| | snd Request | | | | snd Request | |
| v v | | v v |
| +-----------+ +----------+ | | +-----------+ +----------+ |
skipping to change at line 1805 skipping to change at line 1840
MP-DCCP does not support any explicit procedure to negotiate the MP-DCCP does not support any explicit procedure to negotiate the
maximum number of subflows between endpoints. However, in practical maximum number of subflows between endpoints. However, in practical
scenarios, there will be resource limitations on the host or use scenarios, there will be resource limitations on the host or use
cases that do not benefit from additional subflows. cases that do not benefit from additional subflows.
It is RECOMMENDED to limit the number of subflows in implementations It is RECOMMENDED to limit the number of subflows in implementations
and to reject incoming subflow requests with a DCCP-Reset using the and to reject incoming subflow requests with a DCCP-Reset using the
Reset Code "too busy" according to [RFC4340] if the resource limit is Reset Code "too busy" according to [RFC4340] if the resource limit is
exceeded or it is known that the multipath connection will not exceeded or it is known that the multipath connection will not
benefit from further subflows. Likewise, the host that wants to benefit from further subflows. Likewise, it is RECOMMENDED that the
create the subflows is RECOMMENDED to consider the aspect of host that wants to create the subflows considers the available
available resources and the possible gains. resources and possible gains.
To avoid further inefficiencies with subflows due to short-lived To avoid further inefficiencies with subflows due to short-lived
connections, it MAY be useful to delay the start of additional connections, it MAY be useful to delay the start of additional
subflows. The decision on the initial number of subflows can be subflows. The decision on the initial number of subflows can be
based on the occupancy of the socket buffer and/or the timing. based on the occupancy of the socket buffer and/or the timing.
While in the socket-buffer-based approach the number of initial While in the socket-buffer-based approach the number of initial
subflows can be derived by opening new subflows until their initial subflows can be derived by opening new subflows until their initial
windows cover the amount of buffered application data, the timing- windows cover the amount of buffered application data, the timing-
based approach delays the start of additional subflows based on a based approach delays the start of additional subflows based on a
skipping to change at line 1853 skipping to change at line 1888
currently used path is deemed unsuitable for service delivery. Some currently used path is deemed unsuitable for service delivery. Some
of the DCCP subflows of an MP-DCCP connection might become inactive of the DCCP subflows of an MP-DCCP connection might become inactive
due to either the occurrence of certain error conditions (e.g., DCCP due to either the occurrence of certain error conditions (e.g., DCCP
timeout, packet loss threshold, RTT threshold, and closed/removed) or timeout, packet loss threshold, RTT threshold, and closed/removed) or
adjustments from the MP-DCCP user. When there is outbound data to 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 send and the primary path becomes inactive (e.g., due to failures) or
deprioritized, the MP-DCCP endpoint SHOULD try to send the data deprioritized, the MP-DCCP endpoint SHOULD try to send the data
through an alternate path with a different source or destination through an alternate path with a different source or destination
address (depending on the point of failure), if one exists. This address (depending on the point of failure), if one exists. This
process SHOULD respect the path priority configured by the MP_PRIO process SHOULD respect the path priority configured by the MP_PRIO
suboption or, if not available, pick the most divergent source- suboption; otherwise, if the path priority is not available, pick the
destination pair from the original used source-destination pair. most divergent source-destination pair from the originally used
source-destination pair.
| Note: Rules for picking the most appropriate source-destination | Note: Rules for picking the most appropriate source-destination
| pair are an implementation decision and are not specified | pair are an implementation decision and are not specified
| within this document. Path mobility is supported in the | within this document. Path mobility is supported in the
| current Linux reference implementation [MP-DCCP.Site]. | current Linux reference implementation [MP-DCCP.Site].
3.11.2. Concurrent Path Usage 3.11.2. Concurrent Path Usage
Different from a path mobility strategy, the selection between MP- Different from a path mobility strategy, the selection between MP-
DCCP subflows is a per-packet decision that is a part of the DCCP subflows is a per-packet decision that is a part of the
skipping to change at line 1877 skipping to change at line 1913
obtain higher connection throughput. obtain higher connection throughput.
In this scenario, the selection of congestion control, per-packet In this scenario, the selection of congestion control, per-packet
scheduling, and a potential reordering method determines a concurrent scheduling, and a potential reordering method determines a concurrent
path utilization strategy and result in a particular transport path utilization strategy and result in a particular transport
characteristic. A concurrent path usage method uses a scheduling characteristic. A concurrent path usage method uses a scheduling
design that could seek to maximize reliability, maximize throughput, design that could seek to maximize reliability, maximize throughput,
minimize latency, etc. minimize latency, etc.
Concurrent path usage over the Internet can have implications. When Concurrent path usage over the Internet can have implications. When
a Multipath DCCP connection uses two or more paths, there is no an MP-DCCP connection uses two or more paths, there is no guarantee
guarantee that these paths are fully disjoint. When two (or more) that these paths are fully disjoint. When two (or more) subflows
subflows share the same bottleneck, using a standard congestion share the same bottleneck, using a standard Congestion Control
control scheme could result in an unfair distribution of the capacity procedure could result in an unfair distribution of the capacity with
with the multipath connection using more capacity than competing the multipath connection using more capacity than competing single-
single-path connections. path connections.
Multipath TCP uses the coupled congestion control Linked Increases Multipath TCP uses the coupled congestion control Linked Increases
Algorithm (LIA) specified in an experimental specification [RFC6356] Algorithm (LIA) specified in an experimental specification [RFC6356]
to solve this problem. This scheme could also be specified for to solve this problem. This scheme could also be specified for MP-
Multipath DCCP. The same applies to other coupled congestion control DCCP. The same applies to other coupled Congestion Control
schemes that have been proposed for Multipath TCP such as the procedures that have been proposed for Multipath TCP such as the
Opportunistic Linked Increases Algorithm [OLIA]. Opportunistic Linked Increases Algorithm [OLIA].
The specification of scheduling for concurrent multipath and related The specification of scheduling for concurrent multipath and related
congestion control algorithms and reordering methods for use in the congestion control algorithms and reordering methods for use in the
general Internet are outside the scope of this document. If, and general Internet are outside the scope of this document. If, and
when, the IETF specifies a method for concurrent usage of multiple when, the IETF specifies a method for concurrent usage of multiple
paths for the general Internet, the framework specified in this paths for the general Internet, the framework specified in this
document could be used to provide an IETF-recommended method for MP- document could be used to provide an IETF-recommended method for MP-
DCCP. DCCP.
skipping to change at line 1936 skipping to change at line 1972
remove a subflow is 'fresh'. remove a subflow is 'fresh'.
* Allow a party to limit the number of subflows that it allows. * Allow a party to limit the number of subflows that it allows.
To achieve these goals, MP-DCCP includes a hash-based handshake To achieve these goals, MP-DCCP includes a hash-based handshake
algorithm documented in Sections 3.2.4, 3.2.6, and 3.3. The security algorithm documented in Sections 3.2.4, 3.2.6, and 3.3. The security
of the MP-DCCP connection depends on the use of keys that are shared of the MP-DCCP connection depends on the use of keys that are shared
once at the start of the first subflow and are never sent again over once at the start of the first subflow and are never sent again over
the network. Depending on the security requirements, different Key the network. Depending on the security requirements, different Key
Types can be negotiated in the handshake procedure or must follow the Types can be negotiated in the handshake procedure or must follow the
fallback scenario described in Section 4. If there are security fallback scenario described in Section 3.6. If there are security
requirements that go beyond the capabilities of Key Type 0, then it requirements that go beyond the capabilities of Key Type 0, then it
is RECOMMENDED that Key Type 0 not be enabled to avoid downgrade is RECOMMENDED that Key Type 0 not be enabled to avoid downgrade
attacks that result in the key being exchanged as plain text. To attacks that result in the key being exchanged as plain text. To
ease demultiplexing while not revealing cryptographic material, ease demultiplexing while not revealing cryptographic material,
subsequent subflows use the initially exchanged CI information. The subsequent subflows use the initially exchanged CI information. The
keys exchanged once at the beginning are concatenated and used as keys exchanged once at the beginning are concatenated and used as
keys for creating HMACs used on subflow setup, in order to verify keys for creating HMACs used on subflow setup, in order to verify
that the parties in the handshake of subsequent subflows are the same that the parties in the handshake of subsequent subflows are the same
as in the original connection setup. This also provides verification as in the original connection setup. This also provides verification
that the peer can receive traffic at this new address. Replay that the peer can receive traffic at this new address. Replay
attacks would still be possible when only keys are used; therefore, attacks would still be possible when only keys are used; therefore,
the handshakes use single-use random numbers (nonces) for both the handshakes use single-use random numbers (Nonces) for both
parties -- this ensures that the HMAC will never be the same on two parties -- this ensures that the HMAC will never be the same on two
handshakes. Guidance on generating random numbers suitable for use handshakes. Guidance on generating random numbers suitable for use
as keys is given in [RFC4086]. During normal operation, regular DCCP as keys is given in [RFC4086]. During normal operation, regular DCCP
protection mechanisms (such as the header checksum to protect DCCP protection mechanisms (such as the header checksum to protect DCCP
headers against corruption) is designed to provide the same level of headers against corruption) is designed to provide the same level of
protection against attacks on individual DCCP subflows as exists for protection against attacks on individual DCCP subflows as exists for
regular DCCP. regular DCCP.
As discussed in Section 3.2.8, a host may advertise its private As discussed in Section 3.2.8, a host may advertise its private
addresses, but these might point to different hosts in the receiver's addresses, but these might point to different hosts in the receiver's
skipping to change at line 1982 skipping to change at line 2018
to reduce the MPS to less than a minimum MPS and then stop using to reduce the MPS to less than a minimum MPS and then stop using
these paths. these paths.
5. Interactions with Middleboxes 5. Interactions with Middleboxes
Issues from interaction with on-path middleboxes such as NATs, Issues from interaction with on-path middleboxes such as NATs,
firewalls, proxies, IDSs, and others have to be considered for all firewalls, proxies, IDSs, and others have to be considered for all
extensions to standard protocols; otherwise, unexpected reactions of extensions to standard protocols; otherwise, unexpected reactions of
middleboxes may hinder its deployment. DCCP already provides means middleboxes may hinder its deployment. DCCP already provides means
to mitigate the potential impact of middleboxes, in comparison to TCP to mitigate the potential impact of middleboxes, in comparison to TCP
(see Section 16 of [RFC4043]). When both hosts are located behind a (see Section 16 of [RFC4340]). When both hosts are located behind a
NAT or firewall entity, specific measures have to be applied such as NAT or firewall entity, specific measures have to be applied such as
the simultaneous-open technique specified in [RFC5596] that updates the simultaneous-open technique specified in [RFC5596] that updates
the (traditionally asymmetric) connection-establishment procedures the asymmetric connection-establishment procedures for DCCP. Further
for DCCP. Further standardized technologies addressing middleboxes standardized technologies addressing middleboxes operating as NATs
operating as NATs are provided in [RFC5597]. are provided in [RFC5597].
[RFC6773] specifies UDP encapsulation for NAT traversal of DCCP [RFC6773] specifies UDP encapsulation for NAT traversal of DCCP
sessions, similar to other UDP encapsulations such as the Stream sessions, similar to other UDP encapsulations such as the Stream
Control Transmission Protocol (SCTP) [RFC6951]. Future Control Transmission Protocol (SCTP) [RFC6951]. Future
specifications by the IETF could specify other methods for DCCP specifications by the IETF could specify other methods for DCCP
encapsulation. encapsulation.
The security impact of MP-DCCP-aware middleboxes is discussed in The security impact of MP-DCCP-aware middleboxes is discussed in
Section 4. Section 4.
skipping to change at line 2095 skipping to change at line 2131
| | | number | 3.2.5 | | | | number | 3.2.5 |
+-----------+---------------+---------------------+-----------+ +-----------+---------------+---------------------+-----------+
| MP_OPT=5 | MP_HMAC | Hash-based message | Section | | MP_OPT=5 | MP_HMAC | Hash-based message | Section |
| | | authentication code | 3.2.6 | | | | authentication code | 3.2.6 |
| | | for MP-DCCP | | | | | for MP-DCCP | |
+-----------+---------------+---------------------+-----------+ +-----------+---------------+---------------------+-----------+
| MP_OPT=6 | MP_RTT | Transmit RTT values | Section | | MP_OPT=6 | MP_RTT | Transmit RTT values | Section |
| | | and calculation | 3.2.7 | | | | and calculation | 3.2.7 |
| | | parameters | | | | | parameters | |
+-----------+---------------+---------------------+-----------+ +-----------+---------------+---------------------+-----------+
| MP_OPT=7 | MP_ADDADDR | Advertise | Section | | MP_OPT=7 | MP_ADDADDR | Advertise one or | Section |
| | | additional | 3.2.8 | | | | more additional | 3.2.8 |
| | | address(es)/port(s) | | | | | addresses/ports | |
+-----------+---------------+---------------------+-----------+ +-----------+---------------+---------------------+-----------+
| MP_OPT=8 | MP_REMOVEADDR | Remove address(es)/ | Section | | MP_OPT=8 | MP_REMOVEADDR | Remove one or more | Section |
| | | port(s) | 3.2.9 | | | | addresses/ports | 3.2.9 |
+-----------+---------------+---------------------+-----------+ +-----------+---------------+---------------------+-----------+
| MP_OPT=9 | MP_PRIO | Change subflow | Section | | MP_OPT=9 | MP_PRIO | Change subflow | Section |
| | | priority | 3.2.10 | | | | priority | 3.2.10 |
+-----------+---------------+---------------------+-----------+ +-----------+---------------+---------------------+-----------+
| MP_OPT=10 | MP_CLOSE | Close an MP-DCCP | Section | | MP_OPT=10 | MP_CLOSE | Close an MP-DCCP | Section |
| | | connection | 3.2.11 | | | | connection | 3.2.11 |
+-----------+---------------+---------------------+-----------+ +-----------+---------------+---------------------+-----------+
| MP_OPT=11 | MP_EXP | Experimental option | Section | | MP_OPT=11 | MP_EXP | Experimental option | Section |
| | | for private use | 3.2.12 | | | | for private use | 3.2.12 |
+-----------+---------------+---------------------+-----------+ +-----------+---------------+---------------------+-----------+
| MP_OPT>11 | Unassigned | Reserved for future | | | MP_OPT=12 | Unassigned | | |
| | | Multipath options | | | to 255 | | | |
+-----------+---------------+---------------------+-----------+ +-----------+---------------+---------------------+-----------+
Table 8: Multipath Options Registry Table 8: Multipath Options Registry
Future Multipath options with MP_OPT>11 will be assigned from this Future Multipath Options with MP_OPT>11 will be assigned from this
registry using the RFC Required policy (Section 4.7 of [RFC8126]). registry using the RFC Required policy (Section 4.7 of [RFC8126]).
7.4. New DCCP-Reset Code 7.4. New DCCP-Reset Code
IANA has assigned a new DCCP-Reset Code, value 13, in the "Reset IANA has assigned a new DCCP-Reset Code, value 13, in the "Reset
Codes" registry, with the description "Abrupt MP termination". Use Codes" registry, with the description "Abrupt MP termination". Use
of this reset code is defined in Section 3.2.3. of this Reset Code is defined in Section 3.2.3.
7.5. New Multipath Key Type Registry 7.5. New Multipath Key Type Registry
IANA has created a new "Multipath Key Type" registry for this version IANA has created a new "Multipath Key Type" registry for this version
of the MP-DCCP protocol that contains two different suboptions to the of the MP-DCCP protocol that contains two different suboptions to the
MP_KEY option to identify the MP_KEY Key types in terms of 8-bit MP_KEY option to identify the MP_KEY Key types in terms of 8-bit
values as specified in Section 3.2.4. See the initial entries in values as specified in Section 3.2.4. See the initial entries in
Table 9 below. Values in the range 1-254 (decimal) inclusive remain Table 9 below. Values in the range 1-254 (decimal) inclusive remain
unassigned in this specified version 0 of the protocol and will be unassigned in this specified version 0 of the protocol and will be
assigned via the RFC Required policy [RFC8126] in potential future assigned via the RFC Required policy [RFC8126] in potential future
versions of the MP-DCCP protocol. versions of the MP-DCCP protocol.
+=======+==============+=========================+===============+ +=======+==============+======================+===============+
| Type | Name | Meaning | Reference | | Type | Name | Meaning | Reference |
+=======+==============+=========================+===============+ +=======+==============+======================+===============+
| 0 | Plain Text | Plain text key | Section 3.2.4 | | 0 | Plain Text | Plain text Key | Section 3.2.4 |
+-------+--------------+-------------------------+---------------+ +-------+--------------+----------------------+---------------+
| 1-254 | Unassigned | Reserved for future use | Section 3.2.4 | | 1-254 | Unassigned | | |
+-------+--------------+-------------------------+---------------+ +-------+--------------+----------------------+---------------+
| 255 | Experimental | For private use only | Section 3.2.4 | | 255 | Experimental | For private use only | Section 3.2.4 |
+-------+--------------+-------------------------+---------------+ +-------+--------------+----------------------+---------------+
Table 9: Multipath Key Type Registry with the MP_KEY Key Types Table 9: Multipath Key Type Registry with the MP_KEY Key
for Key Data Exchange on Different Paths Types for Key Data Exchange on Different Paths
8. References 8. References
8.1. Normative References 8.1. Normative References
[DCCP-PARAMETERS] [DCCP-PARAMETERS]
IANA, "Datagram Congestion Control Protocol (DCCP) IANA, "Datagram Congestion Control Protocol (DCCP)
Parameters", Parameters",
<https://www.iana.org/assignments/dccp-parameters>. <https://www.iana.org/assignments/dccp-parameters>.
skipping to change at line 2222 skipping to change at line 2258
Amend, M. and D. Von Hugo, "Multipath sequence Amend, M. and D. Von Hugo, "Multipath sequence
maintenance", Work in Progress, Internet-Draft, draft- maintenance", Work in Progress, Internet-Draft, draft-
amend-iccrg-multipath-reordering-03, 25 October 2021, amend-iccrg-multipath-reordering-03, 25 October 2021,
<https://datatracker.ietf.org/doc/html/draft-amend-iccrg- <https://datatracker.ietf.org/doc/html/draft-amend-iccrg-
multipath-reordering-03>. multipath-reordering-03>.
[OLIA] Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J. [OLIA] Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J.
Le Boudec, "MPTCP is not pareto-optimal: performance Le Boudec, "MPTCP is not pareto-optimal: performance
issues and a possible solution", CoNEXT '12: Proceedings issues and a possible solution", CoNEXT '12: Proceedings
of the 8th international conference on Emerging networking of the 8th international conference on Emerging networking
experiments and technologies, pp. 1-12, December 2012. experiments and technologies, pp. 1-12,
DOI 10.1145/2413176.2413178, December 2012,
<https://dl.acm.org/doi/10.1145/2413176.2413178>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC4043] Pinkas, D. and T. Gindin, "Internet X.509 Public Key
Infrastructure Permanent Identifier", RFC 4043,
DOI 10.17487/RFC4043, May 2005,
<https://www.rfc-editor.org/info/rfc4043>.
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over
the Datagram Congestion Control Protocol (DCCP)", the Datagram Congestion Control Protocol (DCCP)",
RFC 5238, DOI 10.17487/RFC5238, May 2008, RFC 5238, DOI 10.17487/RFC5238, May 2008,
<https://www.rfc-editor.org/info/rfc5238>. <https://www.rfc-editor.org/info/rfc5238>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
skipping to change at line 2317 skipping to change at line 2350
"Lossless and overhead free DCCP - UDP header conversion "Lossless and overhead free DCCP - UDP header conversion
(U-DCCP)", Work in Progress, Internet-Draft, draft-amend- (U-DCCP)", Work in Progress, Internet-Draft, draft-amend-
tsvwg-dccp-udp-header-conversion-01, 8 July 2019, tsvwg-dccp-udp-header-conversion-01, 8 July 2019,
<https://datatracker.ietf.org/doc/html/draft-amend-tsvwg- <https://datatracker.ietf.org/doc/html/draft-amend-tsvwg-
dccp-udp-header-conversion-01>. dccp-udp-header-conversion-01>.
Appendix A. Differences from Multipath TCP Appendix A. Differences from Multipath TCP
This appendix is informative. This appendix is informative.
Multipath DCCP is similar to Multipath TCP [RFC8684] in that it MP-DCCP is similar to Multipath TCP [RFC8684] in that it extends the
extends the related basic DCCP transport protocol [RFC4340] with related basic DCCP transport protocol [RFC4340] with multipath
multipath capabilities in the same way as Multipath TCP extends TCP capabilities in the same way as Multipath TCP extends TCP [RFC9293].
[RFC9293]. However, because of the differences between the However, because of the differences between the underlying TCP and
underlying TCP and DCCP protocols, the transport characteristics of DCCP protocols, the transport characteristics of MPTCP and MP-DCCP
MPTCP and MP-DCCP are different. are different.
Table 10 compares the protocol characteristics of TCP and DCCP, which Table 10 compares the protocol characteristics of TCP and DCCP, which
are by nature inherited by their respective multipath extensions. A are by nature inherited by their respective multipath extensions. A
major difference lies in the delivery of the payload, which for TCP major difference lies in the delivery of the payload, which for TCP
is an exact copy of the generated byte stream. DCCP behaves is an exact copy of the generated byte stream. DCCP behaves
differently and does not guarantee the delivery of any payload nor differently and does not guarantee the delivery of any payload nor
the order of delivery. Since this is mainly affecting the receiving the order of delivery. Since this is mainly affecting the receiving
endpoint of a TCP or DCCP communication, many similarities on the endpoint of a TCP or DCCP communication, many similarities on the
sender side can be identified. Both transport protocols share the sender side can be identified. Both transport protocols share the
3-way initiation of a communication and both employ congestion 3-way initiation of a communication and both employ congestion
skipping to change at line 2375 skipping to change at line 2408
+-----------------------+----------------+----------------------+ +-----------------------+----------------+----------------------+
| Fragmentation | yes | no | | Fragmentation | yes | no |
+-----------------------+----------------+----------------------+ +-----------------------+----------------+----------------------+
| SYN flood protection | yes | no | | SYN flood protection | yes | no |
+-----------------------+----------------+----------------------+ +-----------------------+----------------+----------------------+
| Half-open connections | yes | no | | Half-open connections | yes | no |
+-----------------------+----------------+----------------------+ +-----------------------+----------------+----------------------+
Table 10: TCP and DCCP Protocol Comparison Table 10: TCP and DCCP Protocol Comparison
Consequently, the multipath features shown in Table 11 are the same, Consequently, the multipath characteristics shown in Table 11 are the
supporting volatile paths that have varying capacities and latency, same, supporting volatile paths that have varying capacities and
session handovers, and path aggregation capabilities. All of these latency, session handovers, and path aggregation capabilities. All
features profit by the existence of congestion control. of these features profit by the existence of congestion control.
+==================+=======================+==========+ +==================+=======================+==========+
| Feature | MPTCP | MP-DCCP | | Feature | MPTCP | MP-DCCP |
+==================+=======================+==========+ +==================+=======================+==========+
| Volatile paths | yes | yes | | Volatile paths | yes | yes |
+------------------+-----------------------+----------+ +------------------+-----------------------+----------+
| Session handover | yes | yes | | Session handover | yes | yes |
+------------------+-----------------------+----------+ +------------------+-----------------------+----------+
| Path aggregation | yes | yes | | Path aggregation | yes | yes |
+------------------+-----------------------+----------+ +------------------+-----------------------+----------+
skipping to change at line 2403 skipping to change at line 2436
Table 11: MPTCP and MP-DCCP Protocol Comparison Table 11: MPTCP and MP-DCCP Protocol Comparison
Therefore, the sender logic is not much different between MP-DCCP and Therefore, the sender logic is not much different between MP-DCCP and
MPTCP. MPTCP.
The receiver side for MP-DCCP has to deal with the unreliable The receiver side for MP-DCCP has to deal with the unreliable
delivery provided by DCCP. The multipath sequence numbers included delivery provided by DCCP. The multipath sequence numbers included
in MP-DCCP (see Section 3.2.5) facilitates adding optional mechanisms in MP-DCCP (see Section 3.2.5) facilitates adding optional mechanisms
for data stream packet reordering at the receiver. Information from for data stream packet reordering at the receiver. Information from
the MP_RTT multipath option (Section 3.2.7), DCCP path sequencing, the MP_RTT Multipath Option (Section 3.2.7), DCCP path sequencing,
and the DCCP Timestamp Option provide further means for advanced and the DCCP Timestamp Option provide further means for advanced
reordering approaches, e.g., as proposed in [MULTIPATH-REORDERING]. reordering approaches, e.g., as proposed in [MULTIPATH-REORDERING].
However, such mechanisms do not affect interoperability and are not However, such mechanisms do not affect interoperability and are not
part of the MP-DCCP protocol. Many applications that use unreliable part of the MP-DCCP protocol. Many applications that use unreliable
transport protocols can also inherently process out-of-sequence data transport protocols can also inherently process out-of-sequence data
(e.g., through adaptive audio and video buffers), so additional (e.g., through adaptive audio and video buffers), so additional
reordering support might not be necessary. The addition of optional reordering support might not be necessary. The addition of optional
reordering mechanisms are likely to be needed when the different DCCP reordering mechanisms are likely to be needed when the different DCCP
subflows are routed across paths with different latencies. In subflows are routed across paths with different latencies. In
theory, applications using DCCP are aware that packet reordering theory, applications using DCCP are aware that packet reordering
skipping to change at line 2455 skipping to change at line 2488
Email: anna.brunstrom@kau.se Email: anna.brunstrom@kau.se
Andreas Kassler Andreas Kassler
Karlstad University Karlstad University
Universitetsgatan 2 Universitetsgatan 2
SE-651 88 Karlstad SE-651 88 Karlstad
Sweden Sweden
Email: andreas.kassler@kau.se Email: andreas.kassler@kau.se
Veselin Rakocevic Veselin Rakocevic
City, University of London City St George's, University of London
Northampton Square Northampton Square
London London
United Kingdom United Kingdom
Email: veselin.rakocevic.1@city.ac.uk Email: veselin.rakocevic.1@city.ac.uk
Stephen Johnson Stephen Johnson
BT BT
Adastral Park Adastral Park
Martlesham Heath Martlesham Heath
IP5 3RE IP5 3RE
 End of changes. 125 change blocks. 
327 lines changed or deleted 360 lines changed or added

This html diff was produced by rfcdiff 1.48.