Does the new draft (06) allow servers to create new paths by receiving pkts without PATH_CHALLENGE?

[yangfurong]

According to 4.1 of the new draft, a "non-probing" packet's reception on a new path should be treated as a path initiation attempt.

If validation succeeds, the client can continue to use the path. If validation fails, the client MUST NOT use the path and can remove any status associated to the path initation attempt. Section 9.1 of [QUIC-TRANSPORT] introduces the concept of "probing" and "non-probing" frames. When the multipath extension is negotiated, the reception of "non-probing" packet on a new path needs to be considered as a path initiation attempt that does not impact the path status of any existing path. Therefore, any frame can be sent on a new path at any time as long as the anti-amplification limits (Section 21.1.1.1 of [QUIC-TRANSPORT]) and the congestion control limits for this path are respected.

What does it actually mean?

Previously, servers only create new paths if they receive packets with PATH_CHALLENGE on a new 4-tuple. Does this mean that servers should now create new paths as long as they receive "non-probing" packets on new 4-tuples?

[mirjak]

When a server receives a non-probing frame it needs to imitate path validation, similar as it has to validate the path if a probing frame is received. Does this clarify your question?

[yfmascgy]

This issue is related to #261 and #188. If I understand the situation correctly, the consensus is that utilizing PATH_CHALLENGE as a definitive indicator is usually a valid approach. However, we must also address cases where a packet arrives with both a new connection identifier (CID) and a new 4-tuple, but is devoid of a PATH_CHALLENGE. Disregarding such a packet is inappropriate; instead, we should regard it as initiating a new path. In circumstances where both NAT re-binding and CID rotation occur simultaneously, the server is advised to perform path validation for both the original and new paths. This dual validation process may also provide a solution for the issue described in figure 3 of #273 .

[yangfurong]

OK. I get it.