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/ 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/ ---------------------------------------------------------------------- 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. 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. ### 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...." ### 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? ### 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? ---------------------------------------------------------------------- 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), 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.
