Re: on HTTP/QUIC and HTTPBis

[Willy Tarreau <[e-mail]>]

Hi Patrick,

On Tue, Mar 14, 2017 at 11:48:01AM -0400, Patrick McManus wrote:
> On Sun, Mar 12, 2017 at 5:28 PM, Adrien de Croy <[e-mail]> 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.
> 
> https://quicwg.github.io/base-drafts/draft-ietf-quic-
> transport.html#client-address-validation-procedure
> https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.
> html#source-address-validation
> https://tlswg.github.io/tls13-spec/#rfc.section.4.1.4
> 
> 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.

In fact that's an area where I think we have an opportunity to fix this
TCP flood problem. The current remediations for TCP are limited. Against
SYN floods we have SYN cookies which are not perfect since they're limited
by the client's capabilities and are not *that* secure (but often enough
to limit the impact of massive attacks).

We also face the risk that a sequence number is guessed to establish a
connection from spoofing. That's rare and difficult but much easier once
the server starts to emit SYN cookies. And such an abused TCP connection
can be used to flood the server with many pipelined HTTP requests. Given
that most servers OSes have large outgoing TCP windows, the server can
push a lot of responses before the outgoing buffer is full and the
processing stalls. This can be used to abuse CPU/resources and/or as an
amplification attack (but good luck for making use of this).

Here by redesigning the transport layer we do have opportunities for
improving the situation. The risk is to overlook some robust points of
TCP that are considered as granted and which protect it. But if TCP is
mostly imitated with larger tokens instead of just SYN cookies, there
is an opportunity to keep its robustness by design and improve it by
limiting the risk of guessing some sensitive numbers.

The other risk I'm seeing is having the server perform too expensive
validations on incoming datagrams. Sometimes using multiple algorithms
at once can considerably help. Eg a token is made by the concatenation
of XXH32(udp endpoints) and its SHA256. You only validate the SHA256
part when the XXH32 is fine (it's much cheaper). This way you don't
have to perform expensive operations to deal with massive attacks.

Cheers,
Willy