Subsequent Initial Packets with Token Field

[nibanks]

I was looking at the spec and it looks like we never explicitly indicated if subsequent Initial packets sent from the client should continue to populate the Token field. by subsequent packets, I mean responses to HRR and ACK only packets.

For the end server, I would assume it doesn't need the token for subsequent Initial packets, since it likely already has the state needed saved. But for a DDoS mitigation device in path, what is its logic supposed to be for these additional Initial packets it sees, assuming it wants to maintain a stateless design?

The DDoS mitigation device cannot really distinguish between the first Initial packet and subsequent ones. If the client always includes the token, the device would be able to statelessly verify it for every Initial packet, but that breaks if the end server also did a Retry. We could instead just assume full length (>1200 bytes) Initial packets are the first ones, and only they need to be validated. The device would just assume shorter packets should be let through untouched. I'm just not sure if that is too brittle an assumption.

[martinthomson]

@nibanks, maybe you can tell us what you think it should be.

We could instead just assume full length [...] Initial packets are the first ones, and only they need to be validated

This is not going to work if we allow for the possibility that HRR might request a large second attempt from a client.

[kazuho]

FWIW, my assumption has been that the token field will be empty for the subsequent Initial packets.

IIRC, we have thought that it is possible to split Initial into two packet types (i.e. client's first flight and other obfuscated ones) even though we decided not to. The reason such split has been considered possible is because we have assumed that the token is only required for the client's first flight.

My understanding is that DDoS mitigation devices are required to remember the 5-tuple (or the CIDs) that are permitted to flow though, so that other types of packets (i.e., 0-rtt, handshake, 1-rtt) can be exchanged. Then, I do not see a reason why we need to include tokens in subsequent Initial packets.

[nibanks]

@kazuho there is currently no such requirement that a DDoS mitigation device be stateful. My goal is to have a design where it could be stateless.

@martinthomson I think the easiest solution would be to do what @kazuho mentioned: separate out the first client Initial packet from all subsequent Initial packets. A different packet type would do the trick.

[kazuho]

@nibanks

there is currently no such requirement that a DDoS mitigation device be stateful. My goal is to have a design where it could be stateless.

Doesn't the mitigation device maintain state so that it could forward handshake, 0-rtt, 1-rtt packets that has certain properties (e.g. 5-tuple, CID)?

Also, IIUC, when multiple retries are involved, the device that issued the first Retry cannot verify the token contained in the second Retry (i.e. the one contained in the third Initial packet sent by the client).

So I would assume that a DDoS mitigation device (typically the first device to issue a Retry) will be required to create a state for the 5-tuple when it receives the second Initial, and keep forwarding the packets between the client and the server.

Am I missing something?

[nibanks]

@kazuho I guess you're right. I got so focused on the subsequent Initial packets I forgot about the multiple Retry case. The DDoS mitigation device cannot be completely stateless because it cannot rely on its own Token always being in the client's Initial packet, in the multiple Retry case.

As for how forwarding could work for all other non-Initial packets, the simplest design would be to just always let them through, and let the end server drop them if they don't correspond to an existing connection. With that type of design, the DDoS mitigation device just prevents new connections from being created, and ignores all other traffic.

All that being said, then should we be a bit more clear in the spec and say that only the first Initial packets (not sure how best to word that) need carry the server's Token?

[kazuho]

@nibanks

All that being said, then should we be a bit more clear in the spec and say that only the first Initial packets (not sure how best to word that) need carry the server's Token?

I agree that that is preferable. Also, we should better talk about the datagram size. There is no need to pad subsequent Initial packets up to MTU size.

[martinthomson]

The rule here is that the first packet that the server receives needs to be both padded to 1200+ AND include a token. All other Initial packets have neither requirement. So the "server receives" part here is funny because it encompasses Initial after Retry and Initial after Version Negotiation. We should write this down.

[martinthomson]

Rule here is, in light of #1764, that the client needs to send 1200+ datagram until it knows (for certain) that the server has validated the client source address. The way servers validate the client's source address in the handshake is by receiving packets with Handshake keys (or higher, but we know that 1-RTT packets aren't read until Handshake packets are all read). So the way the client learns that the server is OK is to get an ACK at the Handshake encryption level (or higher, see above).

The token only appears in the first one, and the packet sent in response to a Retry. That is probably more aggressive than necessary, but it keeps things simple.