Re: Mike Bishop's Discuss on draft-ietf-quic-multipath-19: (with DISCUSS and COMMENT)

[Mike Bishop <[e-mail]>]

Well, I guess I'm consistent across two years' time.... I'll defer to the WG on that one then. I think if we can resolve the question of how the anti-amplification limit applies, we should be good.
________________________________
From: Mirja Kuehlewind <[e-mail]>
Sent: Wednesday, February 4, 2026 8:00 AM
To: Christian Huitema <[e-mail]>; Mike Bishop <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Mike Bishop's Discuss on draft-ietf-quic-multipath-19: (with DISCUSS and COMMENT)

Just one comment on the active_connection_id_limit parameter. We did discuss this some some extend. Mike, you even commented on it in the issue. The outcome of the group discussion in the session was that we don't want a new parameter. See here:

https://github.com/quicwg/multipath/issues/332



On 29.01.26, 00:44, "Christian Huitema" <[e-mail] <mailto:[e-mail]>> wrote:




On 1/28/2026 12:54 PM, Mike Bishop via Datatracker wrote:
> Mike Bishop has entered the following ballot position for
> draft-ietf-quic-multipath-19: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ <https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/>
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/ <https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/>
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> # IESG review of draft-ietf-quic-multipath-19
>
> CC @MikeBishop
>
> I have previously reviewed this draft as a working group member, and appreciate
> the work that has been put into it so far. I have a few comments from my most
> recent review, but in general am quite pleased with how the draft has
> progressed since I last read it.
>
> ## Discuss
>
> ### Section 2.2, paragraph 1
> ```
> When the QUIC multipath extension is used, the
> active_connection_id_limit transport parameter [QUIC-TRANSPORT]
> limits the maximum number of active connection IDs per path. As
> defined in Section 5.1.1 of [QUIC-TRANSPORT] connection IDs that are
> issued and not retired are considered active.
> ```
> This seems to present a conundrum to clients trying to manage their memory
> consumption. active_connection_id_limit can't be changed after the handshake. So
> if a constrained implementation wants to manage no more than N CIDs total, but
> also supports multipath, it cannot advertise N for this value, because its total
> memory commitment is active_connection_id_limit x the current maximum number of
> paths.


The `active_connection_id_limit` is set to enable migrations of paths,
and the limit will restrain how many potential 4-tuple can be tested in
parallel for a migration attempt. You argue that if multipath is
negotiated, endpoints would use creation of new paths in preference to
migrations of existing paths, and thus could use a lower limit when
multipath is negotiated. However, we do not have any data about that. We
have at least one example with "preferred address migration" of a
scenario that requires path migration even if multipath is supported.
Another example would be NAT rebinding of an existing path.


So yes, we could speculate that having separate negotiation of two
parameters would result in lower resource consumption. However, this is
speculation, and it is hard to quantify how much resource this would
actually save. The protocol is complex enough, we tried not to introduce
complexity if the requirement is fuzzy, which is why we did not define a
separate option.


> But if it takes the conservative approach and advertises N / M for
> active_connection_id_limit, then when it establishes a non-multipath QUIC
> connection, it will be understating its willingness to handle CIDs and therefore
> hampering its ability to rotate/migrate.
>
> Did the WG discuss this and reach consensus on reusing the transport parameter
> despite this challenge? I would have expected either a transport parameter that
> supersedes active_connection_id_limit when multipath is negotiated, or some
> post-handshake way to adjust the limit.


This point was not discussed, and did not appear to be an actual problem
in any of the interop tests.


I suspect that most memory limited implementations will converge to a
small limit, between 2 and 4 per path, satisfying both multipath and
most unipath scenarios. The one exception may be P2P extensions, but
again we do not have a lot of experience. If the "ICE in QUIC" scenarios
turn out to require many CIDs, then perhaps we can think of extensions
to allow larger number of parallel tests as part of these designs.


>
> ### Section 3.1, paragraph 2
> ```
> A client that wants to use a new path MUST validate the peer's
> address before sending any data as described in Section 8.2 of
> [QUIC-TRANSPORT], unless it has previously validated the 4-tuple used
> for that path.
> ```
> Can you point me to the text in Section 8.2 of RFC 9000 you're referencing for
> this prohibition on sending data? What I find there is:
>
>> An endpoint MAY include other frames with the PATH_CHALLENGE and PATH_RESPONSE
>> frames used for path validation.
> ...and more explicitly in Section 9.3:
>
>> An endpoint MAY send data to an unvalidated peer address, but it MUST protect
>> against potential attacks as described in Sections 9.3.1 and 9.3.2.
> In fact, in Section 3.1.2 of this document, "any frame can be sent on a new path
> with a new path ID at any time...."


The intent is definitely to follow RFC 9000 here. Do you have a
suggestion for improving the text?




>
> ### Section 5.8, paragraph 1
> ```
> [QUIC-TRANSPORT] the DPLPMTUD Maximum Packet Size (MPS) is maintained
> for each combination of local and remote IP addresses. Note that
> with the multipath extension multiple paths could use the same
> 4-tuple but might have different MPS. One simple option, if the
> ```
> How would two paths with "the same 4-tuple" ever have a different "combination
> of local and remote IP address"? Isn't that a subset of the 4-tuple by
> definition?


If they have different diffserv class of service, for example.


> ### Section 7.2, paragraph 2
> ```
> Further, multiple paths could be initialized simultaneously. The
> anti-amplification limits as specified in Section 8 of
> [QUIC-TRANSPORT] limit the amplification risk for a given path, but
> multiple paths could be used to further amplify an attack.
> ```
> Why then is the anti-amplification limit per-path rather than per-address?


We never have the concept of per-address limit. Asking implementations
to perform special treatment per IP address would be rather error prone,
given NATs. We could investigate other limits, such as limiting the
number of concurrent path establishment, but I think we really need
implementation experience before writing more rules.


>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> ## Comments
>
> ### Section 1, paragraph 7
>
> Consider pulling some of the introduction into a Scope subsection. The
> discussion of what this document does *not* cover seems excessive for an overall
> introduction.
>
> ### Section 2.1, paragraph 7
> ```
> together with the multipath extension. If such a cipher suite is
> selected and the use of the multipath extension is supported,
> ```
> ...is negotiated, perhaps?
>
> ### Section 3.1.1, paragraph 5
>
> Your figure shows bidirectional address validation, but the prose only
> describes one direction. Consider adding a sentence or two that the server does
> the same thing alongside its response.
>
> ### Sections 4.1, 4.4, and 4.5
>
> It is generally recommended that figures be illustrative, rather than normative.
> However, without referring to the figures, a reader cannot determine where in the
> frames this additional field is inserted.
>
> ### Section 4.2.1, paragraph 0
>
> Presumably any error code is valid here? Might be worth clarifying that
> these codes are defined for situations in which a path might be abandoned, but
> this can be any QUIC error code, as well as the usual disclaimer that any
> lower-level error can also be used as a reason for closing a connection.
>
> ### Section 5.6, paragraph 3
>
> A reference to Section 13.3 of RFC 9000 might be more useful here:
>
>> QUIC packets that are determined to be lost are not retransmitted whole. The
>> same applies to the frames that are contained within lost packets. Instead, the
>> information that might be carried in frames is sent again in new frames as
>> needed.
> This manifests as new STREAM frames for the missing data (which
> don't guarantee the same frame boundaries) and either not retransmitting stale frames
> which have been superseded by newer information (PATH_ACK, PATH_STATUS_*, etc.)
> or sending the most current status when an older frame was lost.
> In general, examine references in the document to retransmitting frames rather than
> the information they carry.
>
> ## Nits
>
> 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 <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.
>
> ### Typos
>
> #### Section 2.3, paragraph 2
> ```
> - After the handshake concluded with support for the multipath
> - ^
> + After the handshake concludes with support for the multipath
> + ^
> ```
>
> #### Section 2.5, paragraph 3
> ```
> - [QUIC-TLS] which used three times the PTO of the sole single path.
> - -----
> ```
>
> #### Section 3.1, paragraph 6
> ```
> - Each endpoint MUST also validate that a minimum QUIC packet MTU of
> - ^
> + Each endpoint MUST also validate that the minimum QUIC packet MTU of
> + ^^^
> ```
>
> #### Section 3.1, paragraph 10
> ```
> - ID is anyway consumed, the endpoint MUST explicitly close the path,
> - -------
> + ID is consumed either way, the endpoint MUST explicitly close the path,
> + +++++++++++
> ```
>
> #### Section 3.1.1, paragraph 6
> ```
> - Respectively, the client chooses the connection ID S1 as the
> - ^^^^^^^^^^^^^^^
> + The client chooses the corresponding connection ID S1 as the
> + ^ ++++++++++++++
> ```
>
> #### Section 3.2.2, paragraph 2
> ```
> - An endpoint is supposed to retire any connection ID that is not being
> - ^
> + An endpoint is supposed to retire any connection ID that is no longer being
> + ^^^^^^^
> ```
>
> ### Section 3.4, paragraph 8
> ```
> short, limited time such as one PTO if a packet is received on a new
> path before sending the CONNECTION_CLOSE frame.
> ```
> Should this be "...to see if a packet..."?
>
> #### Section 5.1, paragraph 2
> ```
> - For any given path, connection ID rotation, NAT rebinding, or client
> - -------
> - initiated migration as specified in [QUIC-TRANSPORT] might occur,
> + client-initiated migration as specified in [QUIC-TRANSPORT] might occur,
> + +++++++
> ```
>
> ### Section 5.1, paragraph 5
> ```
> the endpoints set the path's congestion controller and round-trip
> ```
> reset?
>
> #### Section 5.3, paragraph 3
> ```
> - during the connection. As such, a sole change of the Connection ID
> - -----
> ```
>
> ### Section 3.1.1, paragraph 6
> ```
> bundled with the PATH_ACK using connection ID S1 associated with the
> same path ID.
> ```
> Shouldn't this be C1?
>
> ### Section 3.2.1, paragraph 7
> ```
> When an endpoint finds it has not enough available unused path IDs,
> ```
> Consider "cannot open a path because there are no unused path IDs" perhaps?
>
> ### Grammar/style
>
> #### Section 6, paragraph 1
> ```
> reased amplification risk for denial of service attacks if multiple paths are
> ^^^^^^^^^^^^^^^^^
> ```
> It appears that hyphens are missing.


Thanks for the editorial suggestions. We will incorporate them in the
next version of the draft.


-- Christian Huitema