Subject: Independent QUIC Firewall

From: Nick Banks <[email-masked]>
Date: Mon, 27 Nov 2017 22:03:11 +0000

Hello,

With the current state of the QUIC protocol, it seems impossible to have an independent QUIC firewall perform source address validation before letting packets through to the server. Ideally, the firewall might have special hardware to generate the Retry packet in response to Initial packets received and then only let traffic through once the client responded to the Retry packet. This wouldn't work though, because TLS authenticates the transcript of the connection. The actual QUIC server would drop the connection if it didn't original the Retry packet and associated HelloRetryRequest. Is this something that QUIC should support?

And if this is something that QUIC should support, I have a follow up question. Because all packets are encrypted, how would we expect a hardware firewall to ever get close to matching the performance of a TCP equivalent firewall? It seems to be a lot more difficult (expensive) to protect QUIC from attacks than TCP.

Thanks,
- Nick Banks

---

From: Ted Hardie <[email-masked]>
Date: Mon, 27 Nov 2017 15:57:55 -0800

Hi Nick,

On Mon, Nov 27, 2017 at 2:03 PM, Nick Banks <[email-masked]> wrote:

> Hello,
>
>
>
> With the current state of the QUIC protocol, it seems impossible to have
> an independent QUIC firewall perform source address validation before
> letting packets through to the server.
>

So, there are clearly classes of source address validation, some of which
simply verify that the source address is from a subnet appropriate to the
packet ingress port.  Those are unaffected by QUIC and, depending on where
you put the firewall/NFV instance doing this work, they may be sufficient
for many use cases.

If you place the firewall further away the access nodes, this gets more
difficult as there is a higher chance that the device emitting the packet
is on your network but not entitled to use the source address.  In that
case, you apparently want an on-path device to be able to signal to the
origin that it requires verification that the origin sent the packet.
Absent a signalling path, you seem to have two classes of verification:
drop the initial packet and confirm intent by watching for a retry after a
timeout period.  (This is absolutely hideous from a latency perspective,
and I can hear all the HTTP use case people screaming about bandwidth delay
products in my head, so don't do this or they may show up at your office
with whiteboards and colored ink).  The other option is to allow the
initial packet and watch for the handshake completion, closing the pinhole
when it fails to complete.  This does not have a latency impact, but it
will allow some single-packet traffic flows to egress if standard BCP 38
rules did not catch them.  The working group is trying pretty hard to make
sure that those attacks don't turn in to amplification attacks, and I hope
you'll help in that endeavor.

Ideally, the firewall might have special hardware to generate the Retry
> packet in response to Initial packets received and then only let traffic
> through once the client responded to the Retry packet. This wouldn’t work
> though, because TLS authenticates the transcript of the connection. The
> actual QUIC server would drop the connection if it didn’t original the
> Retry packet and associated HelloRetryRequest. Is this something that QUIC
> should support?
>
>
If you're asking if there should be an explicit signal than an on-path
device could send that asked for verification, the short answer is a
question:  how do you instantiate the trust to prevent that from being an
avenue of attack?  (Split client models and server farms that share roots
of trust or keys more or less know how to do this.  But a firewall
typically isn't trusted to be a party to the communication, for the Random
WiFi attachment use case and many others).

>
> And if this is something that QUIC should support, I have a follow up
> question. Because all packets are encrypted, how would we expect a hardware
> firewall to ever get close to matching the performance of a TCP equivalent
> firewall? It seems to be a lot more difficult (expensive) to protect QUIC
> from attacks than TCP.
>
>
>
I think source address validation mainly protects the network from spoof
traffic (See RFC 6959 for much better and more complete descriptions),
rather than protecting the traffic.  So when you say "protect QUIC from
attacks", I'm not sure exactly what you mean.  Would you mind going into a
bit more detail on what you need?

regards,

Ted Hardie

---

From: Nick Banks <[email-masked]>
Date: Tue, 28 Nov 2017 00:29:25 +0000

Thanks for the info Ted. I’m sorry I wasn’t clear about the attack. I was referring mostly to a Slowloris attack. A specialized HW firewall could be made to just use source address validation to try to reduce half open connections and reduce the actual load on the real server.

I was also thinking of the attack surface where the attacker sends a valid long header with junk payload. The server will waste cycles trying to decrypt it.

Sent from my Windows 10 phone

________________________________
From: Ted Hardie <[email-masked]>
Sent: Monday, November 27, 2017 3:57:55 PM
To: Nick Banks
Cc: [email-masked]
Subject: Re: Independent QUIC Firewall

Hi Nick,

On Mon, Nov 27, 2017 at 2:03 PM, Nick Banks <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

With the current state of the QUIC protocol, it seems impossible to have an independent QUIC firewall perform source address validation before letting packets through to the server.

So, there are clearly classes of source address validation, some of which simply verify that the source address is from a subnet appropriate to the packet ingress port.  Those are unaffected by QUIC and, depending on where you put the firewall/NFV instance doing this work, they may be sufficient for many use cases.

If you place the firewall further away the access nodes, this gets more difficult as there is a higher chance that the device emitting the packet is on your network but not entitled to use the source address.  In that case, you apparently want an on-path device to be able to signal to the origin that it requires verification that the origin sent the packet.  Absent a signalling path, you seem to have two classes of verification:  drop the initial packet and confirm intent by watching for a retry after a timeout period.  (This is absolutely hideous from a latency perspective, and I can hear all the HTTP use case people screaming about bandwidth delay products in my head, so don't do this or they may show up at your office with whiteboards and colored ink).  The other option is to allow the initial packet and watch for the handshake completion, closing the pinhole when it fails to complete.  This does not have a latency impact, but it will allow some single-packet traffic flows to egress if standard BCP 38 rules did not catch them.  The working group is trying pretty hard to make sure that those attacks don't turn in to amplification attacks, and I hope you'll help in that endeavor.

Ideally, the firewall might have special hardware to generate the Retry packet in response to Initial packets received and then only let traffic through once the client responded to the Retry packet. This wouldn’t work though, because TLS authenticates the transcript of the connection. The actual QUIC server would drop the connection if it didn’t original the Retry packet and associated HelloRetryRequest. Is this something that QUIC should support?

If you're asking if there should be an explicit signal than an on-path device could send that asked for verification, the short answer is a question:  how do you instantiate the trust to prevent that from being an avenue of attack?  (Split client models and server farms that share roots of trust or keys more or less know how to do this.  But a firewall typically isn't trusted to be a party to the communication, for the Random WiFi attachment use case and many others).

I think source address validation mainly protects the network from spoof traffic (See RFC 6959 for much better and more complete descriptions), rather than protecting the traffic.  So when you say "protect QUIC from attacks", I'm not sure exactly what you mean.  Would you mind going into a bit more detail on what you need?

regards,

Ted Hardie

Thanks,
- Nick Banks

---

From: Ted Hardie <[email-masked]>
Date: Tue, 28 Nov 2017 10:10:37 -0800

On Mon, Nov 27, 2017 at 4:29 PM, Nick Banks <[email-masked]> wrote:

> Thanks for the info Ted. I’m sorry I wasn’t clear about the attack. I was
> referring mostly to a Slowloris attack. A specialized HW firewall could be
> made to just use source address validation to try to reduce half open
> connections and reduce the actual load on the real server.
>
>
A common mitigation for slowloris-style attacks puts a load-balancer or
proxy in front of an affected web server, so that these attacks are caught
before being passed to the content server.  Doing so in a firewall doesn't
work quite as well, because it is not trusted by the content server (and
may not be trusted by the client, depending on the network).  It's also not
clear that source address validation would help that much; after all, in a
TCP/TLS connection, the TCP 3-way handshake would have completed before the
attack starts (since slowloris sends partial HTTP requests to keep the
connection open, it occurs after the source address is deemed valid by all
parties).

>
>
> I was also thinking of the attack surface where the attacker sends a valid
> long header with junk payload. The server will waste cycles trying to
> decrypt it.
>
>
Here's the current format of the long header (from section 5.1 of the
transport draft)

  0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+
   |1|  Type (7)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Connection ID (64)                      +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Packet Number (32)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Version (32)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Payload (*)                        ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Which bits do you see as the subject of the attack?

regards,

Ted

> ------------------------------
> *From:* Ted Hardie <[email-masked]>
> *Sent:* Monday, November 27, 2017 3:57:55 PM
> *To:* Nick Banks
> *Cc:* [email-masked]
> *Subject:* Re: Independent QUIC Firewall
>
> Hi Nick,
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 28 Nov 2017 10:24:03 -0800

Proof of work could be added as a negotiated facility - but can it be done
without introducing latency while negotiating? Nobody would want to
volunteer unnecessary work.

> I was also thinking of the attack surface where the attacker sends a
valid long header with junk payload. The server will waste cycles trying to
decrypt it.

I have earlier suggested a short verifiable crypto tag in the packet header
that must validate otherwise the packet would be dropped. The response on
the list was that it was cheap enough to verify the entire packet, so it
would not be worthwhile doing. If such a feature was present, it would
prevent random content attacks, but not deliberate QUIC aware attacks. Such
a verifiable tag could also be proof of work.

One option could be to prioritise headers that volunteer proof of work -
that would be helpful in DDoS scenarios. Perhaps a load balancer could even
verify the proof of work without being aware of the TLS handshake level
encryption?

Mikkel