I guess we're gonna see a lot of these issues over the years. Even TCP still has some novel attack vector for a DoS once a decade or so today, and it is a dinosaur conceived when the default assumption was that everyone is playing nice on the Internet.<p>Surprising to see that a protocol designed today still allows for such trivial resource exhaustion attacks. And thanks to the protocol living in user space, we're guaranteed that vulnerable implementations will live on for years to come in docker containers, smartphone apps, etc. (Granted in this case it seems not that bad at least for the latter since this affects servers.)
Good writeup, but can you point to <i>where</i> 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:<p>> 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.<p>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.<p>So this strikes me as an implementation flaw, not an inherent weakness of the protocol.