DCCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-tsvwg-multipath-dccp-24

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-tsvwg-multipath-dccp and RFC 9897, changed IESG state to RFC Published)

[Ballot comment]
Thanks for dealing with my DISCUSS position.  My original comments, which may or may not still be applicable:

Many SHOULD [NOT]s in this document would benefit from either conversion to MUST [NOT]s, or some explanation of under what circumstances an implementer/operator might legitimately decide to deviate from the advice presented.

I think Section 8 should be broken into subsections, one subsection per major IANA request.  It's otherwise a bit unclear where one action ends and another begins.

[Ballot discuss]
Section 8 appears to create two Specification Required registries.  RFC 8126 says of such registries:

  As with Expert Review (Section 4.5), clear guidance to the designated
  expert should be provided when defining the registry, and thorough
  understanding of Section 5 is important.

I don't see any such advice included here.  Is none appropriate?

[Ballot comment]
Many SHOULD [NOT]s in this document would benefit from either conversion to MUST [NOT]s, or some explanation of under what circumstances an implementer/operator might legitimately decide to deviate from the advice presented.

I think Section 8 should be broken into subsections, one subsection per major IANA request.  It's otherwise a bit unclear where one action ends and another begins.

[Ballot discuss]

I have a real concern about the security model of this protocol
document that I believe need to be resolved before publication.


#1 I have some questions on the MP_KEY types and their use

I do not understand the Plain Text key type. It seems this accomplishes
only obfuscation, and not real authentication or real encryption, not
even against passive attackers? I understand it is "plain text" but
why bother with the obfuscation? I do not think that an IETF standard
should rely on obfuscation as a security model.

ECDHE-SHA256-C25519 and ECDHE-SHA512-C25519 seem to be an extremely
underspecified variant of D(TLS). It raises many security concerns,
but even fundamental ones. How does a receiving peer know the difference
between the data stream and the data from an ECDHE exchange? How is
rekeying done if there is no clear distinction between control frame
and data frame ? How is the key exchange itself protected from a MITM
attack? Normally the exchanges are somehow verified along with authentication
and key derivation. Pointing at X.509 certificates is not a specification.
Which KU and EKUs are used, required or not allowed? How does one send
an indication on which root CAs or PKIX identities to use? Can one use
more then one certificate, eg different ones from different peers? How
would one know which (presumbly on dynamic IP) peer is which certificate?

I advise bringing this document to the UTA WG for help on how to properly
add (D)TLS to this protocol. Inventing your own key exchange protocol
will be more difficult, errorprone and won't have common library support
like (D)TLS has. Bonus points will be that your key exchange will
modernize by itself, such as getting post-quantum algorithm support, etc.

#2 MP_HMAC

What is described is "authentication" but with the above considertions of
"plain text" and ECDHE MITM attacks, this is really just a checksum and
not "authentication".

#3 MP_ADDADDR and MP_REMOVEADDR

Based on the above items, it means that any MITM attacker can send an MP_ADDADDR
imessage and become a "legitimate" receiver. It can even MP_REMOVEADDR the
other paths so it becomes to sole path for the traffic?

        The rationale for using a HMAC is to prevent unauthorized entities
        from injecting MP_REMOVEADDR signals in an attempt to hijack a
        connection. Note that, additionally, the presence of this HMAC
        prevents the address from being modified in flight unless the
        key is known by an intermediary.

But all of this builds on having a secure and authenticated exchange, and
the above does not really seem to deliver that other than handwaving RFC5280.

#3 Security Considertions

The Security Considerations do point out the MP-DCCP has no protection against
any active attacks. But then it tries to defend this with a statement like:

        The security of the MP-DCCP connection depends on the use of
        keys that are shared once at the start of the first subflow and
        are never sent again over the network

Claiming that "private keys are only sent once over the network" is a security
property is not acceptable.


I think the document should make a decision. Either it sticks to MP-DCCP itself has
no inherent security properties against active attacks, or it adds a real one.

For example, TLS 1.3 can be used for the initial setup, and an Exporter
https://datatracker.ietf.org/doc/html/rfc8446#section-7.5 can be used to generate
key material for subsequent streams without the need to establish TLS sessions
for each path. Again, please talk to the UTA and/or TLS Working Groups.



#3 tables vs IANA registries

        Multipath feature
        Multipath option set
        MP_OPT option types

Why are these tables not proper IANA registries ? There is now no single place
where one can see all the table entries for these options.

[Ballot discuss]
Section 3.2.4, Plain text:  This method MUST be discouraged, or the channel protected in some other way.

Section 3.2.4, both ECDHE subsections:  These are under specified.

Section 3.2.4, ECDHE-SHA256-C25519:  This appears to be a combination of a key agreement (ECDHE is an ephemeral key agreement) and 'peer authentication technologies'.  Remove the 'peer authentication technology part of this and make is separate as it applies to the ECDHE-SHA512-C25519 sub section as well.

Section 3.2.4, ECDHE-SHA512-C25519:  I find this to be a bit strange.  SHA512 is not 'matchy matchy' from a cryptographic strength point of view with X25519.  Why not use X448 instead (or even P-521 - a NIST curve)?

Section 4, para 3 and 4:  The sharing of keys over an unprotected channel SHOULD be discouraged.  Especially since it appears that there is an option to share those keys protected by an ECDHE negotiated key encryption key.

Section 4, para 4:  Note:  ECDHE is by definition ephemeral.  If certificate authentication is desired, then it has to be linked to a static private/public key pair.  ECDHE does not directly contribute to authentication.  But it can/does help with protecting keys being sent over an unprotected channel.

[Ballot comment]
Section 1.2:  Please define '+' up front.  It appears from Section 3.2, 3.2.4, 3.2.6x2, and 4, that it means 'concatenation'.  Alternatively, please specify 'concatenation' everywhere '+' is used, if that is what is meant.  [Normally, I would expect '|' to signify concatenation.]

Section 3.1, Figure 4 and supporting text:  It seems a tiny bit odd to use an example that is not actually supported by this draft.

Section 3.2.6, para 1 (below the figure):  'output truncated to the leftmost 160 bits (20 bytes)'is under specified. Please reiterate here that it refers to 'big-endian' formats.  Or merely state that the output is truncated to 160 bits (20 bytes).

Section 3.2.6, para 2: 'in order to protect on the one hand and validate on the other'.  hands?  What entity is doing the calculation and what entity is validating?  As for 'protect', I'm guessing you mean protecting the integrity.

Section 3.3, first set of bullets:  There is no nonce for the first subflow?  Why?

Section 3.3, 3.4.1:  Either provide a pointer to RFC6234, or a pointer back to Section 3.2.6 to ensure that the hash truncation is performed properly.

[Ballot comment]
Section 6, paragraph 0
>    The approach described above has been implemented in open source
>    across different testbeds and a new scheduling algorithm has been
>    extensively tested.  Also demonstrations of a laboratory setup have
>    been executed and have been published at [multipath-dccp.org].

Much like Gunter, I do not have much experience with DCCP. This review will therefore look at this protocol from a manageability perspective. For details on how to evaluate a protocol from manageability perspective, please refer to RFC 5706. In particular, I am referring to Section 1.2 and 3.
Those sections suggest that implementations start by identifying the entities that need to be managed, both from a configuration and monitoring perspective. In this particular case, that would include both endpoints and middleboxes. Has that evaluation been done?

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "traditionally"; alternatives might be "classic", "classical",
  "common", "conventional", "customary", "fixed", "habitual", "historic",
  "long-established", "popular", "prescribed", "regular", "rooted",
  "time-honored", "universal", "widely used", "widespread"
* Term "blind"; alternatives might be "visually impaired", "unmindful of",
  "unconcerned about", "negligent of", "unaware", "uncomprehending",
  "unaware", "uncritical", "unthinking", "hasty", "blocked", "opaque"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 1
> ling and setting up multiple paths (a.k.a, "subflows"), managing these subflo
>                                    ^^^^^
The abbreviation/initialism is missing a period after the last letter.

Section 2.1, paragraph 5
>  specifics of the implementation. If a MP-DCCP peer host wishes to limit the
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.1, paragraph 7
> he MP-DCCP connection MUST either fallback to regular DCCP or MUST close the
>                                  ^^^^^^^^
The word "fallback" is a noun. The verb is spelled with a space.

Section 3.1, paragraph 10
> escribed in Table 3. MP_OPT refers to an Multipath option. +======+========+=
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 3.2, paragraph 5
> that are identified as outdated. Similarly an MP_CONFIRM could arrive out of
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Similarly".

Section 3.2.2, paragraph 4
> protect from unauthorized shutdown of a MP-DCCP connection, the selected Key
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.3, paragraph 10
> ]. The MP_SEQ number space is independent from the path individual sequence n
>                              ^^^^^^^^^^^^^^^^
The usual collocation for "independent" is "of", not "from". Did you mean
"independent of"?

Section 3.2.3, paragraph 18
> = HMAC-SHA256(Key=d-keyB, Msg=RB+RA) An usage example is shown in Figure 21.
>                                      ^^
Use "A" instead of "An" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 3.2.5, paragraph 2
> ADDADDR or MP_REMOVEADDR. Therefore, a MP_HMAC MUST directly follow its asso
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.5, paragraph 2
> ption. In the likely case of sending a MP_JOIN together with a MP_ADDADDR, t
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.5, paragraph 2
> se of sending a MP_JOIN together with a MP_ADDADDR, this results in concatena
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.8, paragraph 9
> long with the MP_REMOVEADDR suboption a MP_HMAC option MUST be sent for authe
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.8, paragraph 10
>  the option. A receiver MUST include a MP_SEQ (Section 3.2.5) in a DCCP data
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.8, paragraph 17
> ts for using different paths (e.g., WiFi is free while cellular has limit on
>                                    ^^^^
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

Section 3.2.9, paragraph 4
> if more capacity is needed than the WiFi path can provide, indicating a clea
>                                    ^^^^
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

Section 3.2.9, paragraph 5
> ion. At least one path ought to have a MP_PRIO value greater or equal to one
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.9, paragraph 9
> up to the multipath scheduler logic. A MP_SEQ (Section 3.2.5) MUST be presen
>                                      ^
Use "An" instead of "A" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.10, paragraph 1
> n of the first DCCP-CloseReq carrying a MP_CLOSE with valid Key Data, or due
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.10, paragraph 3
> tion of the first DCCP-Close carrying a MP_CLOSE with valid Key Data at the p
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.10, paragraph 6
> MP_JOIN MUST be ignored. Contrary to a MP_FAST_CLOSE (Section 3.2.3), no sin
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.10, paragraph 14
> ique identifier during the lifetime of a MP-DCCP connection. * Host B sends a
>                                        ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.4.1, paragraph 5
> tablished and the handshake SHOULD fallback to regular DCCP. If this is not p
>                                    ^^^^^^^^
The word "fallback" is a noun. The verb is spelled with a space.

Section 3.4.1, paragraph 9
> blishment, MP-DCCP connection will fallback to regular DCCP. The fallback pro
>                                    ^^^^^^^^
The word "fallback" is a noun. The verb is spelled with a space.

Section 3.5, paragraph 4
> e 24: Most common state transitions of a MP-DCCP subflow 3.8. Congestion Cont
>                                        ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.6, paragraph 5
>  of the multiple DCCP subflows within a MP-DCCP connection for data transmiss
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.7, paragraph 1
> livery. Some of the DCCP subflows of a MP-DCCP connection might become inact
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.8, paragraph 1
> hat the new address to be included in a MP connection is valid for a peer to
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.11, paragraph 1
> m Packet Size (MPS) is maintained for a MP-DCCP connection. If MP-DCCP expos
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.11.1, paragraph 2
> orithm has been extensively tested. Also demonstrations of a laboratory setup
>                                    ^^^^
A comma may be missing after the conjunctive/linking adverb "Also".

Section 5, paragraph 1
> cy (Section 4.6 of [RFC8126]). In addition IANA is requested to assign a new
>                                  ^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "addition".

Section 5, paragraph 1
> ined in section Section 3.2.3. In addition IANA is requested to assign for th
>                                  ^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "addition".

Section 8, paragraph 17
> ed byte-stream. DCCP behaves in a different way and does not guarantee to del
>                              ^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "differently" to avoid
wordiness.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-tsvwg-multipath-dccp-20
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Gorry Fairhurst for the shepherd's write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## COMMENTS (non-blocking)

### Section 1

What is a middle box in `to pass middleboxes`? Please add a reference as "middlebox" covers a wide range of devices/roles. Section 5 is better on this topic.

### Section 1.2

Please use RFC 5952 when writing IPv6 addresses.

### Section 3.2

Suggest appending "TLV" to all sub-sections title.

I was about to DISCUSS on the lack of behavior specification for a node receiving an unknown MP_OPT value, is it ignored or does it break the whole set-up ?

### Section 3.2.6

Even if this document only specifies SHA-256 for HMAC, it is not fully clear (albeit guessing a new code for MP_OPT in the registry) how to add another HMAC later.

### Section 3.2.8

Even if probably obvious, what is the expected receiver behavior in the absence of the MP_HMAC ?

Should there be a requirement that the addresses are unicast ? (assuming that link-local, ULA, RFC 1918, global are accepted by default).

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-)

[Ballot comment]
# Internet AD comments for draft-ietf-tsvwg-multipath-dccp-20
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S1

* "between user user-equipment/residential" ->
  "between user-equipment/residential"

* The slides reference says "IETF 115" but the slides themselves say
  "IETF 105".

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-tsvwg-multipath-dccp-20

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-tsvwg-multipath-dccp-20.txt

# I am not familiar with DCCP technology, hence my review comments are from a novice perspective.

# for your convenience, please find some non-blocking COMMENTS

# comments
# ========

18   DCCP communications as defined in RFC 4340 are restricted to a single

GV> Maybe expand DCCP at first usage to Datagram Congestion Control Protocol. I had to go look it up what it was

18   DCCP communications as defined in RFC 4340 are restricted to a single
19   path per connection, yet multiple paths often exist between peers.
20   The simultaneous use of available multiple paths for a DCCP session
21   could improve resource usage within the network and, thus, improve
22   user experience through higher throughput and improved resilience to
23   network failures.  Use cases for Multipath DCCP (MP-DCCP) are mobile
24   devices (e.g., handsets, vehicles) and residential home gateways
25   simultaneously connected to distinct networks as, e.g., a cellular
26   and a Wireless Local Area (WLAN) network or a cellular and a fixed
27   access network.  Compared to existing multipath protocols such as
28   MPTCP, MP-DCCP offers special support for latency-sensitive services
29   with different requirements for reliability and in-order delivery.
30
31   This document specifies a set of extensions to DCCP to support
32   multipath operations.  The protocol offers the same type of service
33   to applications as DCCP and provides the components necessary to
34   establish and use multiple DCCP flows across different paths
35   simultaneously.

GV> May i sugegst the following from readability perspective

"
Datagram Congestion Control Protocol (DCCP) communications, as defined in RFC 4340, are inherently restricted to a single path per connection, despite the availability of multiple network paths between peers. The ability to utilize multiple paths simultaneously for a DCCP session can enhance network resource utilization, improve throughput, and increase resilience to network failures, ultimately enhancing the user experience.

Use cases for Multipath DCCP (MP-DCCP) include mobile devices (e.g., handsets, vehicles) and residential home gateways that maintain simultaneous connections to distinct network types, such as cellular and Wireless Local Area Networks (WLANs) or cellular and fixed access networks. Compared to existing multipath transport protocols, such as Multipath TCP (MPTCP), MP-DCCP is particularly suited for latency-sensitive applications with varying requirements for reliability and in-order delivery.

This document specifies a set of protocol extensions to DCCP that enable multipath operations. These extensions maintain the same service model as DCCP while introducing mechanisms to establish and utilize multiple concurrent DCCP flows across different network paths.
"

192   This document uses terms that are either specific for multipath
193   transport or are defined in the context of MP-DCCP, similar to
194   [RFC8684], as follows:

GV> I suspect that the used terminology is not similar, but identical? maybe clarify that and explicitly call out a difference when needed

368     +========+===================+============+===============+=======+
369     | Number | Meaning          | Rec'n Rule | Initial Value | Req'd |
370     +========+===================+============+===============+=======+
371     |  10  | Multipath Capable |    SP    |      0      |  N  |
372     +--------+-------------------+------------+---------------+-------+

374                         Table 1: Multipath feature

376   Rec'n Rule:  The reconciliation rule used for the feature.  SP
377       indicates the server-priority.

GV> What is a "Rec'n Rule"? I guess i am missing something obvious

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

GV> It would help to call out explicitly which value to update

Gunter Van de Velde
RTG Area Director

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-tsvwg-multipath-dccp-17. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are six actions which we must complete.

First, in the Feature Numbers registry in the Datagram Congestion Control Protocol (DCCP) Parameters registry group located at:

https://www.iana.org/assignments/dccp-parameters/

a single new registration will be made as follows:

Number: [ TBD-at-Registration ]
Description/Meaning: Multipath Capable
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested a value of 10 for this registration. Please note that specific values cannot be reserved. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

Second, a new registry is to be created called the MP-DCCP Versions registry. The new registry will be located in the Datagram Congestion Control Protocol (DCCP) Parameters registry group located at:

https://www.iana.org/assignments/dccp-parameters/

The new registry is managed via Specification Required as defined by RFC8126. There is a single initial registration in the new registry as follows:

Version: 0
Value: 0000
Reference: [ RFC-to-be ]

Values 0001 through 1111 are unassigned.

Third, in the Option Types registry also in the Datagram Congestion Control Protocol (DCCP) Parameters registry group located at:

https://www.iana.org/assignments/dccp-parameters/

a single new registration will be made as follows:

Type: 46
Description/Meaning: Multipath Options
Reference: [ RFC-to-be ]

Fourth, a new registry is to be created called the Multipath Options registry. The new registry will be located in the Datagram Congestion Control Protocol (DCCP) Parameters registry group located at:

https://www.iana.org/assignments/dccp-parameters/

The registry is managed via Specification Required as defined by RFC8126. The values in the new registry range from 0-255. There are initial registrations in the new registry as follows:

Multipath Option Name Description Reference
-----------------+-----+-----------+-----------
MP_OPT=0 MP_CONFIRM Confirm reception/processing of an MP_OPT option [ RFC-to-be; Section 3.2.1 ]
MP_OPT=1 MP_JOIN Join subflow to existing MP-DCCP connection [ RFC-to-be; Section 3.2.2 ]
MP_OPT=2 MP_FAST_CLOSE Close MP-DCCP connection [ RFC-to-be; Section 3.2.3 ]
MP_OPT=3 MP_KEY Exchange key material for MP_HMAC [ RFC-to-be; Section 3.2.4 ]
MP_OPT=4 MP_SEQ Multipath sequence number [ RFC-to-be; Section 3.2.5 ]
MP_OPT=5 MP_HMAC Hash-based message auth. code for MP-DCCP [ RFC-to-be; Section 3.2.6 ]
MP_OPT=6 MP_RTT Transmit RTT values and calculation parameters [ RFC-to-be; Section 3.2.7 ]
MP_OPT=7 MP_ADDADDR Advertise additional address(es)/port(s) [ RFC-to-be; Section 3.2.8 ]
MP_OPT=8 MP_REMOVEADDR Remove address(es)/ port(s) [ RFC-to-be; Section 3.2.9 ]
MP_OPT=9 MP_PRIO Change subflow priority [ RFC-to-be; Section 3.2.10 ]
MP_OPT=10 MP_CLOSE Close MP-DCCP subflow [ RFC-to-be; Section 3.2.11 ]
MP_OPT=11 MP_EXP Experimental suboption for private use [ RFC-to-be; Section 3.2.12 ]

Fifth, in the Reset Codes registry also in the Datagram Congestion Control Protocol (DCCP) Parameters registry group located at:

https://www.iana.org/assignments/dccp-parameters/

a single, new registration will be made as follows:

Reset Code: [ TBD-at-Registration ]
Name: Abrupt MP termination
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested a value of 13 for this Reset Code. Please note that specific values cannot be reserved. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

Sixth, a new registry is to be created called the Multipath Key Type registry. The new registry will be located in the Datagram Congestion Control Protocol (DCCP) Parameters registry group located at:

https://www.iana.org/assignments/dccp-parameters/

The registry is managed via Specification Required as defined by RFC8126. The values in the new registry range from 0-255. There are three, initial registrations in the new registry as follows:

Type: 0
Name: Plain Text
Meaning: Plain text key
Reference: [ RFC-to-be; Section 3.2.4 ]

Type: 1
Name: ECDHE-C25519-SHA256
Meaning: ECDHE with SHA256 and Curve25519
Reference: [ RFC-to-be; Section 3.2.4 ]

Type: 2
Name: ECDHE-C25519-SHA512
Meaning: ECDHE with SHA512 and Curve25519
Reference: [ RFC-to-be; Section 3.2.4 ]

Values 3-255 in the new registry are unassigned.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-10-17):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tsvwg-multipath-dccp@ietf.org, gorry@erg.abdn.ac.uk, tsvwg-chairs@ietf.org, tsvwg@ietf.org, zahed.sarker.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DCCP Extensions for Multipath Operation with Multiple Addresses) to Proposed Standard


The IESG has received a request from the Transport and Services Working Group
WG (tsvwg) to consider the following document: - 'DCCP Extensions for
Multipath Operation with Multiple Addresses'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-10-17. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  DCCP communications as defined in RFC 4340 are restricted to a single
  path per connection, yet multiple paths often exist between peers.
  The simultaneous use of available multiple paths for a DCCP session
  could improve resource usage within the network and, thus, improve
  user experience through higher throughput and improved resilience to
  network failures.  Use cases for Multipath DCCP (MP-DCCP) are mobile
  devices (e.g., handsets, vehicles) and residential home gateways
  simultaneously connected to distinct networks as, e.g., a cellular
  and a Wireless Local Area (WLAN) network or a cellular and a fixed
  access network.  Compared to existing multipath protocols such as
  MPTCP, MP-DCCP offers special support for latency-sensitive services
  with different requirements for reliability and in-order delivery.

  This document specifies a set of extensions to DCCP to support
  multipath operations.  The protocol offers the same type of service
  to applications as DCCP and provides the components necessary to
  establish and use multiple DCCP flows across different paths
  simultaneously.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-multipath-dccp/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/5025/
  https://datatracker.ietf.org/ipr/3639/

This is a shepherd report for: draft-ietf-tsvwg-multipath-dccp-16
DCCP Extensions for Multipath Operation with Multiple Addresses

Document History

    1. Was the document considered in any WG, and if so, why was it not adopted as a
    work item there?

DCCP is maintained by TSVWG.

    2. Was there controversy about particular points that caused the WG to not adopt
    the document?

There was discussion about whether the requirements as represented by
ATSSS from 3GPP would be addressed by this spec or by other means.  It
was not the responsibility of the IETF to decide on the different
technologies that might be used, and there was support for progressing
this specification as one alternative that could be realised.

    3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
    so, please summarize the areas of conflict in separate email messages to the
    responsible Area Director. (It should be in a separate email because this
    questionnaire is publicly available.)

No.

    4. For protocol documents, are there existing implementations of the contents of
    the document? Have a significant number of potential implementers indicated
    plans to implement? Are any existing implementations reported somewhere,
    either in the document itself (as RFC 7942 recommends) or elsewhere
    (where)?

There is one fork of the Linux tree that includes support for this
extension. This was demonstrated at IETF Hackathons and the results
reported to the TSVWG. See also: https://multipath-dccp.org/.

Additional Reviews

    5. Do the contents of this document closely interact with technologies in other
    IETF working groups or external organizations, and would it therefore benefit
    from their review? Have those reviews occurred? If yes, describe which
    reviews took place.

No. There is also multi-path work for MP-TCP and for MP-QUIC, but this
specification related to use with DCCP.

    6. Describe how the document meets any required formal expert review criteria,
    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

There were no reviews.

    7. If the document contains a YANG module, has the final version of the module
    been checked with any of the recommended validation tools for syntax and
    formatting validation? If there are any resulting errors or warnings, what is
    the justification for not fixing them at this time? Does the YANG module
    comply with the Network Management Datastore Architecture (NMDA) as specified
    in RFC 8342?

There is no Yang module.

    8. Describe reviews and automated checks performed to validate sections of the
    final version of the document written in a formal language, such as XML code,
    BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks needed to be performed.

Document Shepherd Checks

    9. Based on the shepherd's review of the document, is it their opinion that this
    document is needed, clearly written, complete, correctly designed, and ready
    to be handed off to the responsible Area Director?

The document completed review within the WG included invited reviews and
WG feedback after which it was revised. There was a final WGLC in
02/2024, in which no significant changes were requested.  Rev 14 of this
document is now thought to be complete.

    10. Several IETF Areas have assembled lists of common issues that their
    reviewers encounter. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

    11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard,
    Informational, Experimental or Historic)? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This document was originally charted as Experimental. However, once the
work had progressed there was a request to move this to PS. This case
was presented to the WG and was discussed. Finally a consensus call
confirmed that the WG wished to publish this as a PS in 07/2023.

    12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in BCP 79? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The current IPR disclosures were discussed by TSVWG. All authors have
declared that they are not aware of any undisclosed IPR.

    13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, all authors have confirmed this.

    14. Document any remaining I-D nits in this document. Simply running the idnits
    tool is not enough; please review the "Content Guidelines" on
    authors.ietf.org. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is one unused Reference: 'I-D.muley-network-based-bonding-hybrid-access',
but no explicit reference was found in the text. This ID has expired and
as far as I know is not adopted by any IETF group. This could be removed
prior to publication if unused.

    15. Should any informative references be normative or vice-versa? See the IESG
    Statement on Normative and Informative References.

Checked.

    16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

    17. Are there any normative downward references (see RFC 3967 and BCP
    97) that are not already listed in the DOWNREF registry? If so,
    list them.

There is a DOWNREF.
This is a Normative reference to an Informational RFC: RFC 6234, SHA256 is used to generate a HMAC.
This RFC is listed in the DOWNREF registry.

    18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

    19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

    20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see RFC 8126).

The IANA considerations were reviewed by the Shepherd, and have been
reviewed by IANA. IANA is in the course of preparing a provisional
allocation of the codepoints based on this spec.

    21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

See above, IANA provisional allocation is in progress.

---

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

This is a shepherd report for: draft-ietf-tsvwg-multipath-dccp-16
DCCP Extensions for Multipath Operation with Multiple Addresses

Document History

    1. Was the document considered in any WG, and if so, why was it not adopted as a
    work item there?

DCCP is maintained by TSVWG.

    2. Was there controversy about particular points that caused the WG to not adopt
    the document?

There was discussion about whether the requirements as represented by
ATSSS from 3GPP would be addressed by this spec or by other means.  It
was not the responsibility of the IETF to decide on the different
technologies that might be used, and there was support for progressing
this specification as one alternative that could be realised.

    3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
    so, please summarize the areas of conflict in separate email messages to the
    responsible Area Director. (It should be in a separate email because this
    questionnaire is publicly available.)

No.

    4. For protocol documents, are there existing implementations of the contents of
    the document? Have a significant number of potential implementers indicated
    plans to implement? Are any existing implementations reported somewhere,
    either in the document itself (as RFC 7942 recommends) or elsewhere
    (where)?

There is one fork of the Linux tree that includes support for this
extension. This was demonstrated at IETF Hackathons and the results
reported to the TSVWG. See also: https://multipath-dccp.org/.

Additional Reviews

    5. Do the contents of this document closely interact with technologies in other
    IETF working groups or external organizations, and would it therefore benefit
    from their review? Have those reviews occurred? If yes, describe which
    reviews took place.

No. There is also multi-path work for MP-TCP and for MP-QUIC, but this
specification related to use with DCCP.

    6. Describe how the document meets any required formal expert review criteria,
    such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

There were no reviews.

    7. If the document contains a YANG module, has the final version of the module
    been checked with any of the recommended validation tools for syntax and
    formatting validation? If there are any resulting errors or warnings, what is
    the justification for not fixing them at this time? Does the YANG module
    comply with the Network Management Datastore Architecture (NMDA) as specified
    in RFC 8342?

There is no Yang module.

    8. Describe reviews and automated checks performed to validate sections of the
    final version of the document written in a formal language, such as XML code,
    BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks needed to be performed.

Document Shepherd Checks

    9. Based on the shepherd's review of the document, is it their opinion that this
    document is needed, clearly written, complete, correctly designed, and ready
    to be handed off to the responsible Area Director?

The document completed review within the WG included invited reviews and
WG feedback after which it was revised. There was a final WGLC in
02/2024, in which no significant changes were requested.  Rev 14 of this
document is now thought to be complete.

    10. Several IETF Areas have assembled lists of common issues that their
    reviewers encounter. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

    11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard,
    Informational, Experimental or Historic)? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This document was originally charted as Experimental. However, once the
work had progressed there was a request to move this to PS. This case
was presented to the WG and was discussed. Finally a consensus call
confirmed that the WG wished to publish this as a PS in 07/2023.

    12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in BCP 79? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The current IPR disclosures were discussed by TSVWG. All authors have
declared that they are not aware of any undisclosed IPR.

    13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, all authors have confirmed this.

    14. Document any remaining I-D nits in this document. Simply running the idnits
    tool is not enough; please review the "Content Guidelines" on
    authors.ietf.org. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is one unused Reference: 'I-D.muley-network-based-bonding-hybrid-access',
but no explicit reference was found in the text. This ID has expired and
as far as I know is not adopted by any IETF group. This could be removed
prior to publication if unused.

    15. Should any informative references be normative or vice-versa? See the IESG
    Statement on Normative and Informative References.

Checked.

    16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

    17. Are there any normative downward references (see RFC 3967 and BCP
    97) that are not already listed in the DOWNREF registry? If so,
    list them.

There is a DOWNREF.
This is a Normative reference to an Informational RFC: RFC 6234, SHA256 is used to generate a HMAC.
This RFC is listed in the DOWNREF registry.

    18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

    19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

    20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see RFC 8126).

The IANA considerations were reviewed by the Shepherd, and have been
reviewed by IANA. IANA is in the course of preparing a provisional
allocation of the codepoints based on this spec.

    21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

See above, IANA provisional allocation is in progress.

---

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

There was WG consensus to adopt as a PS (07/2023).
A WGLC in 02/2024 received reviews by:
Kevin Smith, read and ready
Franisco Fontes, read and ready
Hang,  read and ready
Chris Box, ready and review comments

There were no WGLC comments indicating that this document was not ready for publication.

This started a 2 week WG Last Call call to determine if the following TSVWG ID is ready to publish:

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-multipath-dccp/

This document targets PROPOSED STANDARD.

The document shepherd for the MP-DCCP will be: Gorry Fairhurst.

The WGLC will end at midnight UTC on 5th March 2024.

Request for posting confirmation emailed to previous authors: Andreas Kassler , Anna Brunstrom , Dirk Hugo , Markus Amend , Stephen Johnson , Veselin Rakocevic , tsvwg-chairs@ietf.org