Where does RFC9000 talk about "refusing a path"?

[mirjak]

We have section on "Refusing a New Path" and it says this:

An endpoint may deny the establishment of a new path initiated by its peer during the address validation procedure. According to {{QUIC-TRANSPORT}}, the standard way to deny the establishment of a path is to not send a PATH_RESPONSE in response to the peer's PATH_CHALLENGE.

However, I don't think RFC9000 talks about refusing a path anywhere. Or can someone point me at the right section?

[MikeBishop]

The closest I see is in 9.3, where this statement occurs:

Receiving a packet from a new peer address containing a non-probing frame indicates that the peer has migrated to that address.

If the recipient permits the migration, it MUST send subsequent packets to the new peer address and MUST initiate path validation....

RFC 9000 doesn't discuss what happens if the peer migrates and the recipient does not permit the migration, but I'd class that as refusal of a path. Presumably the recipient ignores the incoming packets and the connection eventually times out for both sides if the peer can no longer use the original path.

However, that doesn't match the text in multipath. On the contrary, "On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame."

So I interpret this as a two-step process:

• Upon receipt of a packet which matches a connection but is from/to an unexpected address, the server decides whether it is willing to process the packet. If not, the packet is dropped.
  • See also 5.2, "Packets that are matched to an existing connection are discarded if the packets are inconsistent with the state of that connection."
• Only after processing the packet will it know what frames are inside. If it encounters a PATH_CHALLENGE frame, sending a PATH_RESPONSE frame is obligatory.

Of course, you don't know whether it's a non-probing packet until you've started to process it, so this isn't 100% perfect either.

[mirjak]

Okay, so I think we need to change the sentence above in any case. I actually propose to remove this whole small section and rather say that a path can be closed at any time using a path abandon, even if the path response was not sent.

[mirjak]

PR #388 now clarifies that a PATH _ABANDON should be sent instead