[quicwg/base-drafts] Backoff of CONNECTION_CLOSE needs to be a MUST (#3095)

[Kazuho Oku <[e-mail]>]

At the moment, the backoff is merely a recommendation. Quoting from [section 10.3](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.10.3): _endpoints SHOULD limit the number of packets they generate containing a CONNECTION_CLOSE frame._

However, there is a DoS attack vector unless we make this a MUST, as an attacker can create bounce of packets carrying CONNECTION_CLOSE frames between two servers.

Consider the case where you have two servers (A, B) that use the original DCIDs supplied by the client as the server CIDs.

The attacker sends the following two Initial packets:
* srcaddr=A, destaddr=B, srcCID=X, destCID=Y
* srcaddr=B, destaddr=A, srcCID=Y, destCID=X

Both of the two packets would contain an invalid payload.

Then, both server A and server B would enter the CLOSING state sending CONNECTION_CLOSE frame to the peer. While in the CLOSING state, the specification allows endpoints to respond to packets from peer without decrypting them. Therefore, this creates a ping-pong.

To prevent this type of attack, I think we need to change "SHOULD limit" of the quoted text to "MUST limit". The alternative might be to forbid servers adopting the DCID given by the clients as their server CIDs.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3095