Subject: [quicwg/base-drafts] Reducing the ease of reflected first packets (#147)

From: Brian Trammell <[email-masked]>
Date: Fri, 13 Jan 2017 01:24:36 -0800

The design of the QUIC packet header should consider the ease of creating an apparently-valid first packet via reflection against existing, widely deployed UDP protocols (DNS and NTP being the top two here). All easily reflectable packets off these services should be trivially droppable by a QUIC server. Otherwise, there exist a variety of possible DDoS attacks (of which #135 is one case).

For 1-RTT first packets, the probablity of creating a valid ClientHello would seem to be negligible, though there might be some value in reducing the processing necessary to recognize and reject reflected garbage, or to allow it to be rejected before delivery to the server process.

For 0-RTT first packets, the header layout should be defined such that a version number (or other magic pattern, though the version number space is sparse enough that it can do double duty as a magic pattern) has an offset and bit pattern that does not occur in traffic that can be generated via reflection off common UDP services.

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

---

From: ianswett <[email-masked]>
Date: Fri, 13 Jan 2017 09:23:07 -0800

This seems like a good item to think about.  I believe the 12 byte auth hash on 0RTT packets mitigates this in practice, but maybe there's a reason it's insufficient?

-- 
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/147#issuecomment-272495024

---

From: ianswett <[email-masked]>
Date: Fri, 13 Jan 2017 09:27:53 -0800

Apologies, the auth hash only helps the handshake packets, not 0RTT requests.

0RTT packets are typically sent with the version set, which would make fast identification of junk slightly easier, as you mention.

-- 
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/147#issuecomment-272496207

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 Jan 2017 13:03:02 -0800

What auth hash?

-- 
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/147#issuecomment-272723563

---

From: ianswett <[email-masked]>
Date: Mon, 16 Jan 2017 09:56:31 -0800

All the unencrypted packets all have a 12 byte hash to ensure they haven't been inadvertently modified in flight or they're random internet junk.  It also means all the encryptors have the same 12 byte overhead, which is nice.

I'm guessing from your comment this never got migrated from the QUIC crypto doc into the transport or tls docs?

-- 
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/147#issuecomment-272926946

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Jan 2017 18:02:28 -0800

Yes, this didn't get migrated.  It was intentional.  Given that no one noticed, I have to wonder whether it was needed.  Open an issue if you care.

-- 
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/147#issuecomment-273002904