CIDs don't limit much, since you can always send multiple probes with the same CID. But the parallel with establishing new connections is fair. The ICW provides a limit on how much a well-behaved client will send without validation, but there are many ways clients can be induced to open new connections (e.g. the Great Cannon), so it's true that inducing a client to attempt to open a path to an attack target's address is effectively no worse.
Let's just think through the cases and ensure we aren't opening anything new; if I misstate any of these, let me know. Same path, client changing address: Server applies anti-amplification limit, won't send more than 3x the amount received from the client's new address. If client sends many packets with many CIDs (up to ICW), the anti-amplification limit applies per client address (not per CID). A malicious client spoofing a target's IP address can only induce a 3x amplification (in theory, notwithstanding that many implementations violate this). Multipath, client changing address: Server applies anti-amplification limit (per path?), won't send more than 3x the amount received from (that address? That address with that path ID?). If the client initiates many new paths simultaneously, it can still only induce a 3x amplification because it has to send more traffic to do that. Multipath, client switching to new server address: Client is limited to ICW on the new path, which is no worse than opening a new connection. So I think this comes down to two pieces: # Clarifying how the anti-amplification limit is tracked with this extension RFC 9000 says it's per-remote-address (Sections 8 and 21.1.1.1); this specification points to that definition in RFC 9000 but also refers to the limit as applying "for a given path." I think you've convinced me that either interpretation will be safe, so let's just be clear which one we mean. If you're using the per-address sense unchanged, let's clarify Section 7.2; if you're modifying the definition, let's explicitly state the new one. (And if we disagree on how RFC 9000 gets interpreted, there may be an erratum in there as well.) If "path" here is used in the 4-tuple sense rather than the packet-flow-identified-by-path-ID sense, it would be consistent with RFC 9000; I see Kazuho raised that confusion in PR#566 and Christian clarified that "path" always means packet-flow-identified-by-path-ID, in which case I believe there's a conflict. # Requirement for Validation I remember (and concur with) the decision not to over-specify beyond the requirement to validate. The question is what specifically the client can send on the incipient path before validation completes. RFC 9000 imposes no restrictions on what can be sent, only how much; this specification prohibits sending "any data," apparently referencing Section 8.2 of RFC 9000 to define that restriction, but I don't see it there. If the intention is to match RFC 9000 and not restrict, then I think the wording needs a tweak to remove that implication​. If there is a new restriction being imposed, it should be explicitly stated and justified. ________________________________ From: Mirja Kuehlewind <[email protected]> Sent: Wednesday, February 4, 2026 12:06 PM To: Mike Bishop <[email protected]>; Christian Huitema <[email protected]>; The IESG <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: Mike Bishop's Discuss on draft-ietf-quic-multipath-19: (with DISCUSS and COMMENT) On the amplification attack, this was discussed here: https://github.com/quicwg/multipath/issues/564 In summary, this is not a new issue for this extension because you can also have multiple migration attempts in parallel with RFC9000. Also, effectively there is a limit because the number of CID is limited as well. And finally note that the amplification multiplier is still 3. You send 1 path challenge and can trigger 3 packets; or you send N path challenges and trigger Nx3 packets. This is also similar when trying to open N QUIC connections in parallel and there is no limit for that. From: Mike Bishop <[email protected]> Date: Wednesday, 4. February 2026 at 17:11 To: Mirja Kuehlewind <[email protected]>, Christian Huitema <[email protected]>, The IESG <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: Mike Bishop's Discuss on draft-ietf-quic-multipath-19: (with DISCUSS and COMMENT) 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 <[email protected]> Sent: Wednesday, February 4, 2026 8:00 AM To: Christian Huitema <[email protected]>; Mike Bishop <[email protected]>; The IESG <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> 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" <[email protected] <mailto:[email protected]>> 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
