Clarify client anti-amplification response #3445
Conversation
Clarifies why a client might send a Handshake packet, as well as generally tries to improve the anti-deadlock text. Fixes #2598
| this deadlock, clients MUST send a packet on a probe timeout, or PTO; | ||
| see Section 5.3 of {{QUIC-RECOVERY}}. In this case, the client MUST send an | ||
| Initial packet in a UDP datagram of at least 1200 bytes if it does not have | ||
| Handshake keys, and otherwise send a Handshake packet. | ||
|
|
There was a problem hiding this comment.
Yes. The next question is, what content shall the client place in the Initial or Handshake packet? Just PAD? Ping and PAD?
There was a problem hiding this comment.
It seems to me that this doesn't matter. Probing generally goes for ack-eliciting, and some might favour sending data over just a PING, but if the server only needs more bytes, it shouldn't matter if this is PADDING, PING, or CRYPTO.
There was a problem hiding this comment.
I would favor pure pad, personally, so as to not require its own ack, retransmit, etc. Also, sending it with the proper DCID will get the server out of the DOD amplification control mode.
There was a problem hiding this comment.
A proper, updated DCID isn't guaranteed to unblock the server. That is why we haven't expressly allowed for that to be used.
There was a problem hiding this comment.
I am not asking for a change in the current text. This PR is fine.
martinthomson
added
the
editorial
Co-Authored-By: Jana Iyengar <jri.ietf@gmail.com>
Clarifies why a client might send a Handshake packet, as well as improving the surrounding anti-deadlock text.
Changes 2 SHOULDs to MUSTs to line up with recovery.
Fixes #2598