Can client open new path by sending packet without PATH_CHALLENGE frame on new local address?

[nandsky]

As described in Quic multipath Section-6.1

Before the client opens a new path by sending a packet on that path with a PATH_CHALLENGE frame, it has to check whether there is an unused Connection IDs available for each side.

What I confusing about is whether the PATH_CHALLENGE frame is necessary? Can client use a new path without validating the peer's address like RFC900 9.2. Initiating Connection Migration, because peer's address has been validated during connection establishment.

[kazuho]

I agree that this is an error in the current draft.

The requirement in RFC 9000 is that paths MUST be validated unless it has previously validated that address. There is no reason to deviate from v1 here.

[yfmascgy]

Including the PATH_CHALLENGE frame basically says that both endpoints need to ensure path reachability before using this path to send data. It also prevents address spoofing attacks. Over the public internet, the client's source port is usually unknown due to the NAT so it is necessary to have a PATH_CHALLENGE. But I think if you are using multi-path in a private network where your address has been validated and are stable, you can start using the path without probing it.

[kazuho]

I think the discussion here is not about private networks, it applies to traffic on public networks as well.

When a client migrates to a new address, it continues sending packets to an address that has been validated already. Therefore, a client does not have to validate the path prior to sending non-probing packets.

Per my understanding, that is why we state in RFC 9000 section 9.4 that path validation is not mandatory if an endpoint has previously validated that address.

The client still has to validate the path to test reachability, but it can do that while or after sending non-probing packets from a new local address. Quoting from section 9.2, an endpoint MAY defer path validation until after a peer sends the next non-probing frame to its new address.

[mirjak]

I think the next two paragraph are more relevant for this discussion:

When the multipath option is negotiated, clients that want to use an additional path MUST first initiate the Address Validation procedure with PATH_CHALLENGE and PATH_RESPONSE frames described in [Section 8.2](https://rfc-editor.org/rfc/rfc9000#section-8.2) of [[QUIC-TRANSPORT](https://quicwg.org/multipath/draft-ietf-quic-multipath.html#QUIC-TRANSPORT)]. After receiving packets from the client on a new path, if the server decides to use the new path, the server MUST perform path validation ([Section 8.2](https://rfc-editor.org/rfc/rfc9000#section-8.2) of [[QUIC-TRANSPORT](https://quicwg.org/multipath/draft-ietf-quic-multipath.html#QUIC-TRANSPORT)]) unless it has previously validated that address.[¶](https://quicwg.org/multipath/draft-ietf-quic-multipath.html#section-4.1-3)

If validation succeed, the client can send non-probing, 1-RTT packets on the new paths. In contrast with the specification in [Section 9](https://rfc-editor.org/rfc/rfc9000#section-9) of [[QUIC-TRANSPORT](https://quicwg.org/multipath/draft-ietf-quic-multipath.html#QUIC-TRANSPORT)], the server MUST NOT assume that receiving non-probing packets on a new path indicates an attempt to migrate to that path. Instead, servers SHOULD consider new paths over which non-probing packets have been received as available for transmission.

Currently, we require the client to send PATH_CHALLANGE ("MUST first initiate the Address Validation") because it's always better to be explicit when you want to open a new path and you already have another exiting path to send data which means it probably not that urgent to send data on the new path. However, if you have a concrete use case why you need to send application/non-probably data on a new path before address validation is concluded, please describe that use case in more details. This is also discussed in issue #50.

Also note, migration as described in RFC9000 is still possible any may lead to non-probing data packets on a non-validated path as describe din section 7.8.

[kazuho]

@mirjak Thank you for referring to the normative paragraph.

Currently, we require the client to send PATH_CHALLANGE ("MUST first initiate the Address Validation") because it's always better to be explicit when you want to open a new path and you already have another exiting path to send data which means it probably not that urgent to send data on the new path. However, if you have a concrete use case why you need to send application/non-probably data on a new path before address validation is concluded, please describe that use case in more details.

I think I would scope it differently.

QUIC multipath is based on QUIC v1, and we should not divert from what is defined in v1 unless there is a necessity. I do not think there is anything in multipath that requires us to tighten when clients have to validate.

[mirjak]

I think the case where the path was previously validated is still valid from RFC900 and we didn't meant to change that. We only talked about "new" paths. But I also that this phrase "unless it has previously validated that address" in PR #288 now to make that more explicit. Does this close this issue?