Subject: [quicwg/base-drafts] Anti-amplification limits should count junk too (#3340)

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Jan 2020 03:50:42 -0800

>  In determining this limit, servers only count the size of successfully processed packets.

This is wrong.  If the server receives 0-RTT packets that it is discarding, it won't receive enough bytes to clear the 3x multiplier.  This needs to explicitly count all bytes received from the given address, even junk bytes.

I think that this is just editorial; this is just a mistake in transcription.  I'll defer to chairs.

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

---

From: Marten Seemann <[email-masked]>
Date: Tue, 14 Jan 2020 20:47:29 -0800

I'd like us to be a little bit more specific than "junk bytes". I can imagine that for many implementations, it would be hard to associate random junk sent from the same 4-tuple with the newly established connection, since implementations will track connections by their CID, not by 4-tuple.

If our intention is to include 0-RTT packets, it would be sufficient to count all datagrams that are received with the same QUIC DCID (no matter if they're actually processed or not).

-- 
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/3340#issuecomment-574494186

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 14 Jan 2020 20:59:21 -0800

> If our intention is to include 0-RTT packets, it would be sufficient to count all datagrams that are received with the same QUIC DCID (no matter if they're actually processed or not).

I might actually prefer this definition (i.e. sum of QUIC packets sent on the correct path using correct CIDs, regardless of if they were processable), above a definition that states that the amplification limit is 3x the sum of the size of UDP datagrams that an endpoint has received on the correct path.

It is easier to implement (because all the logic can be implemented at the QUIC packet processing layer), and it has the nice side-effect of deterring padding outside QUIC packets (#3333).

-- 
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/3340#issuecomment-574496577

---

From: ianswett <[email-masked]>
Date: Wed, 15 Jan 2020 07:25:17 -0800

I have no objection to requiring both CID and path to match, though I'll note that if the server changes the CID in an Initial packet, but the client doesn't receive enough data to generate handshake keys, it'll need to match against both CIDs.

-- 
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/3340#issuecomment-574710123