Subject: [quicwg/base-drafts] Subsequent Initial Packets with Token Field (#1649)

From: Nick Banks <[email-masked]>
Date: Fri, 10 Aug 2018 17:51:52 +0000 (UTC)

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.

-- 
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/1649

---

From: Martin Thomson <[email-masked]>
Date: Sun, 12 Aug 2018 17:31:04 -0700

@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.

-- 
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/1649#issuecomment-412382605

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 12 Aug 2018 20:36:32 -0700

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.

-- 
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/1649#issuecomment-412400638

---

From: Nick Banks <[email-masked]>
Date: Mon, 13 Aug 2018 14:59:26 +0000 (UTC)

@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.

-- 
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/1649#issuecomment-412548573

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 13 Aug 2018 08:07:25 -0700

@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?

-- 
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/1649#issuecomment-412551467

---

From: Nick Banks <[email-masked]>
Date: Mon, 13 Aug 2018 08:16:59 -0700

@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?

-- 
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/1649#issuecomment-412554882

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 13 Aug 2018 15:46:16 +0000 (UTC)

@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.

-- 
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/1649#issuecomment-412564709