quicwg
What if a packet with a CID belonging to a new Path ID without path challenge is received?
Now that we have an explicit Path ID, it might be easier to expect that a packet with a new path ID has to also contain a path challenge. Therefore if a packet for a non-validated path ID is received that does not contain a path challenge, we could say it should be ignore. Or we could also say that the receiving peer should send a path challenge. But I think we have to same something more.
I would note that usage of PATH_CHALLENGE is optional if the path already have been validated. See Section 3.1:
When the multipath extension is negotiated, a client that wants to use an additional path MUST first initiate the Address Validation procedure with PATH_CHALLENGE and PATH_RESPONSE frames as described in Section 8.2 of [QUIC-TRANSPORT], unless it has previously validated that address.
Thus, I think ignoring it is wrong. It is okay to send a PC to validate it in the other direction. I guess the question boils down to if the endpoint have any say in the peer considering the path validated towards itself. I would think no. Thus, an endpoint would need to create a path and send ACKs to confirm reception if the packet contain non-probing frames.
It is true that if an address was previously validated, your don't need to do it again. However, I was talking about the case where the path was not validated yet. In the multipath extension we requirement path validation by the path opening peer, so effectively receiving a packet with an new path ID (which cannot migration through NAT rebinding) on an unvalidated path is a protocol violation and we don't say what to do in this case. This is the current text:
When the multipath extension is negotiated, a client that wants to use an additional path MUST first initiate the Address Validation procedure with PATH_CHALLENGE and PATH_RESPONSE frames as described in Section 8.2 of [QUIC-TRANSPORT], unless it has previously validated that address.
This issue was discussed at IETF-120. Conclusion was to require a MUST to do some way of path validation before sending but then rather refer to RFC9000 and don't be specific about requiring PATH_CHALLENGE. Also note that this is a requirement on the sending but there is no requirement to enforce this on the receiver side. A receiver must assume that the other end has validated the path when it receives something else than a path challenge and of course it must ensure itself that the path is validated before it can sent.
The sentences above needs to be adapted accordingly and potentially more clarification is needed.
Yes, I think that's what we agreed. Each endpoint is independently obligated to perform address validation, but not to police that the peer has performed path validation. (And where things like address validation tokens were involved, you can't know what addresses the peer considers validated anyway.)
Therefore, we should talk about receiving packets with a previously-unused Path ID, not receiving PATH_CHALLENGEs (unless we're specifically talking about handing the frame itself, of course). A PATH_CHALLENGE always generates a corresponding PATH_RESPONSE, but if it's not possible to send on that path (no CID, no CC, anti-amplification, path already abandoned, whatever) then the frame gets dropped.
There are two issues: shall the packet be accepted; and, shall the receiver then use that path?
I am tempted to say that as long as a packet decrypts properly, it should be accepted. If it is accepted, it must be acknowledged. If it must be acknowledged, then the receiver needs to allocate at least the "receive" half of a path context.
I don't think that there is a resource control issue. The sender can only send these "out of challenge" packets if it has a valid CID for a new group ID, and that CID has to be provided by the receiver. The sender could have sent a challenge, and the receiver would have to allocate the resource.
If the receiver cannot create the path, then it should deny it -- we have a whole discussion about that.
In the discussion in Vancouver we said that a valid (possible to decrypt) packet should be accepted as we don't/can't police if and how the other end validated the address. Also a sender can/must only use a path if it has validated the address somehow. If you need to send an ACK you have to wait until the path is validated on your side (or bundle it with the path challenge) or send it on another path.
If you can't send on a path for whatever reason, you should sooner or later explicitly close the path by sending a path abandon. So to Mike's point, the only case from your example list above where you receive a path challenge (or any other packet with a certain path ID) and ignore the packet instead of sending a path abandon on another path, is the case where the path ID was already abandoned. The only other case where you ignore the path challenge/packet with a certain path ID is when the path ID is larger than the max path ID. However, in those cases where you have an invalid path ID you ignore the whole packet and don't even try to decrypt it.