Allow rate limiting of Version Negotiation #1891
Conversation
As discussed in #1758, we only need to allow rate limiting. However, the particular example I draw on will become critical if we adopt the proposed changes to version negotiation in #1755 (or something like it), because the only packet a server can confidently respond to with Version Negotiation in that case is the Initial. If we adopt an iteration of #1755, then this text would need to be expanded to explain that also. Closes #1758.
martinthomson
added
editorial
|
I think it's incorrect to mention specific packet types here, since a VN packet implies that the server doesn't speak this version (and therefore doesn't know what packet types exist). Implying otherwise encourages bugs in which servers wait until they see the packet type which matches v1:Initial, which might not be used in vX. #1758 caveats this risky text with "If the server has knowledge of the version," which at least acknowledges the problem. I think a simple permission to rate-limit the number of VN packets sent in response to the same SCID:DCID tuple, or the same 5-tuple, should be sufficient and also less tempting to wrong assumptions. |
|
The method in #1755 assumes a precondition, which is that the server can speak the proposed version (i.e. doesn't need to send VN), but found a mutually- supported preferable version it would like to switch to. That's a different state than pure VN. |
|
This is a for instance. And I think that this will become crucial if we go with #1755. In that case, a server that might read the Initial and change the version as a result cannot send Version Negotiation in response to 0-RTT packets. |
As discussed in #1758, we only need to allow rate limiting.
However, the particular example I draw on will become critical if we
adopt the proposed changes to version negotiation in #1755 (or something
like it), because the only packet a server can confidently respond to
with Version Negotiation in that case is the Initial. If we adopt an
iteration of #1755, then this text would need to be expanded to explain
that also.
Closes #1758.
(I marked this editorial so that we can include it in -16. I do that on the basis that a server can always feign packet loss, so this isn't really a testable requirement. That's only slightly dishonest, I think.)