Re: on HTTP/QUIC and HTTPBis

hi Adrien - I wanted to address your good comment about source address

On Sun, Mar 12, 2017 at 5:28 PM, Adrien de Croy <> wrote:

> I can see the strong desire to reduce latency / RTTs in setup phase pre
> application data, but it makes me worry about a few things.  SYN flood
> attacks were rendered ineffective by SYN cookies, which meant the server
> didn't need to maintain state about a connection until after the ACK to the
> SYN ACK was received, thereby precluding spoofing source IP.
> However if the initial packet has crypto setup as well, the server will
> need to record and retain client state from the initial packet which will
> open it up to a SYN flood style of resource consumption attack?
QUIC worries a lot about DoS and amplification attacks including what you
are describing (and more!). These are certainly practical problems.

A server worried about growing amounts of outstanding handshake state can
choose to insert a round trip in order to accomplish source address
validation. Basically proof of receipt is done with a TLS extension and a
Client Hello can be stretched out for another RTT to include this "source
address validation token" via the TLS 1.3 Hello Retry Request mechanism.
0-RTT connections would always include the validation token, but if this
mitigation were being applied it would turn 1-RTT connects back into the
TCP/TLS style 2-RTT.

The token can be anything the server likes (the client just has to echo it)
as long as it is unguessable. There are obvious ways to do that which don't
require state per conn.

the obvious question is can't we just fix TCP so that lots of connections
> isn't so bad?

>From time to time QUIC is described as fixing TCP and being a general
successor. Eye of the beholder I guess.

Received on Tuesday, 14 March 2017 15:48:44 UTC