Pad to 38 if you want a stateless reset #1682
Conversation
martinthomson
added
editorial
|
The point with ACK-only is that you aren't expecting a response, so there is no point in asking for one. Maybe it's best to say nothing on that point anyway. I was not 100% on that bit. |
draft-ietf-quic-transport.md
Outdated
| @@ -2733,6 +2733,9 @@ a small packet might result in Stateless Reset not being useful in detecting | |||
| cases of broken connections where only very small packets are sent; such | |||
| failures might only be detected by other means, such as timers. | |||
|
|
|||
| An endpoint that wants to improve the chances that it triggers a Stateless Reset | |||
| when its peer loses state can pad all packets it sends to 38 octets. | |||
There was a problem hiding this comment.
All packets seems like a lot of padding. In practice, I'd only expect people to pad timer-initiated packets like PING for keepalive or TLP/RTO packets.
There was a problem hiding this comment.
Yes. Mikkel pointed out that if you do that, all short packets are 38 bytes, except for stateless reset which are exactly 37, and therefore stand out. That's not a hugely useful property. What Ian suggests makes more sense, and in that case you want to pad to something unpredictable, for example between 38 and 256. But this is of course a game of smoke and mirrors, so you want the peer to also randomly pad the responses to ping and tlp/rto. Oh well...
There was a problem hiding this comment.
Maybe instead of talking about the all-time case, we just say that "An endpoint can increase the odds that a packet will trigger a Stateless Reset if it cannot be processed by padding it to at least 38 octets."? Then we leave the decision of which packets deserve that treatment to the implementation.
draft-ietf-quic-transport.md
Outdated
| @@ -2733,8 +2733,8 @@ a small packet might result in Stateless Reset not being useful in detecting | |||
| cases of broken connections where only very small packets are sent; such | |||
| failures might only be detected by other means, such as timers. | |||
|
|
|||
| An endpoint that wants to improve the chances that it triggers a Stateless Reset | |||
| when its peer loses state can pad all packets it sends to 38 octets. | |||
| An endpoint can increase the odds that a packet will trigger a Stateless Reset | |||
There was a problem hiding this comment.
Does increasing it above 38 not ensure it will trigger a Stateless Reset? If so, I'd prefer "An endpoint can ensure that a packet will trigger..."
There was a problem hiding this comment.
I would hope that stateless reset is an optional feature and when it is on, resets can be send at senders discretion, e.g. implementing rate limiting.
There was a problem hiding this comment.
@mikkelfj is right, this doesn't guarantee that you get a stateless reset. The point here is that the odds of receiving one for packets below 38 octets is much lower.
|
Good enough for me. |
But there isn't much point in doing that if you aren't expecting a response, so ACK-only packets don't need the same treatment (unless, like @huitema, you are doing that for a measure of traffic analysis protection).
Closes #1681.