Subject: [quicwg/base-drafts] How big should the first client packet be? (#136)

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Jan 2017 21:48:55 -0800

We need a certain size to avoid amplification attacks.  See also #38.

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

---

From: Brian Trammell <[email-masked]>
Date: Thu, 12 Jan 2017 02:47:16 -0800

Generalizing this issue a bit: it seems to be a requirement to make it difficult for an attacker to create an apparently-valid first client packet through a reflection or amplification attack (though it occurs to me on third reading that this might be what you mean above, Martin...)

Careful design of the packet header (e.g. through restriction of the version number space to also act as a magic number containing bit patterns difficult to induce in the first few bytes of an NTP or UDP packet, for example) might be useful here, in addition to size checks.

-- 
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/136#issuecomment-272132254

---

From: Martin Thomson <[email-masked]>
Date: Thu, 12 Jan 2017 16:21:31 -0800

That wasn't what I was thinking, though that was the subject of #135.  The reason that we need a big first client packet is so that the server won't end up sending more (or much more) than the client sent.  With source address spoofing, that's the amplification attack.

I don't know if it's worth doing a lot about reflections off other protocols onto a QUIC server.  It's pretty hard to fake a ClientHello because of the need to get lengths correct all the way down, the right extensions in the right places, cipher suites that make sense, etc...  But the front of the packet (where this probably matters more) can pretty much be random gunk and get past at least basic filters.

The exception being the flags octet and the version field.  Screw up the version field and your packet ends up on the floor, screw up the version field and you get version negotiation.  Is 32 bits enough?

You might have more luck with 0-RTT packets, which are basically random noise, but those are just going to get dumped.  They might get saved, but only up to a certain limit.  Now, I would insist they include a version field, which helps if you think 32 bits is enough, but @janaiyengar disagrees for reasons I am incapable of understanding apparently.

Open a separate issue if you think that there's something to chase up here.

-- 
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/136#issuecomment-272325793

---

From: Brian Trammell <[email-masked]>
Date: Fri, 13 Jan 2017 00:41:27 -0800

re: reduction of amplification: okay, that's what I thought on the first two readings. :)

I think we can safely assume that reflecting a valid ClientHello is probably not doable. I tend to agree that at least a version (and probably connection ID) should appear on 0-RTT: the work behind the SPUD magic number showed 32 bits are more than enough to give you a fairly large low-probability-reflectable number space when they appear at the start of a packet; adding a byte of flags first probably changes the math a bit (because you can't do things like collide with the NTP version number, for instance). I'll look into both 24- and 32-bit versions of this at offset one.

-- 
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/136#issuecomment-272389966

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Jan 2017 19:57:47 -0800

We already discussed this and decided that it was 1280 plus some if you were feeling lucky.

-- 
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/136#issuecomment-275302689