Good writeup, but can you point to where in the spec this behavior is mandated? I'm looking at section 8.2 of RFC 9000, and I see nothing implying a requirement to maintain an unbounded queue of un-acked PATH_CHALLENGE packets. The closest I can find is the final sentence in 8.2.1:
> Unlike other cases where datagrams are expanded, endpoints MUST NOT discard datagrams that appear to be too small when they contain PATH_CHALLENGE or PATH_RESPONSE.
But I don't read it as saying never to discard PATH_CHALLENGE packets, only that the implementation should refrain from filtering out such packets on the basis of them being too small.
So this strikes me as an implementation flaw, not an inherent weakness of the protocol.
Yeah, seems suspicious. PATH_CHALLENGE frame is used to determine if a path is valid in the first place. It seems like the correct operation of a client can not possibly depend on lossless responses since, by its very nature, the client must expect that it might be sending packets on a path to the void.
There is no way for a client to distinguish between a invalid path and a server packet drop, so a server that randomly drops such frames seems externally indistinguishable from a “compliant” one. For that matter, you can even characterize that as a path to the server that is “temporarily invalid” which follows the letter of the spec.
The only problem that may exist here is if the spec actually demands such a undetectable, unenforceable, irrelevant requirement.
> Unlike other cases where datagrams are expanded, endpoints MUST NOT discard datagrams that appear to be too small when they contain PATH_CHALLENGE or PATH_RESPONSE.
But I don't read it as saying never to discard PATH_CHALLENGE packets, only that the implementation should refrain from filtering out such packets on the basis of them being too small.
So this strikes me as an implementation flaw, not an inherent weakness of the protocol.