Subject: Amplification attack using the same connection id?

From: Jānis Čoders <[email-masked]>
Date: Thu, 11 May 2017 14:57:11 +0300

Hi, doesn't the "free to change source-ip and port" feature make
server vulnerable to amplification attacks? Imagine that there is
ongoing session and client spoofs source address, but sends the same
connection-id - and because it knows all the internal states of QUIC,
server should accept and respond to the "new spoofed" address (of
course it should be in a state where server's response is bigger than
request).
NOTE that I am talking about state after the ClientInitial has been verified.
Are my assumptions correct? If yes, then how could this be prevented?
Maybe by re-verifying that client really changed IP/port, but maybe
easier would be allowing to switch IP/port only every X seconds.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 May 2017 11:42:03 -0500

> easier would be allowing to switch IP/port only every X seconds.

If the received message does not cryptographically verify as being sent
by the peer, it is dropped and no reply is sent.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 May 2017 11:52:26 -0500

On 05/11/2017 11:42 AM, Benjamin Kaduk wrote:
> If the received message does not cryptographically verify as being
> sent by the peer, it is dropped and no reply is sent.

Rereading your message more carefully, maybe the "internal states of
QUIC" is supposed to include the relevant cryptographic material?

Some rate limiting of switching (maybe slightly clever to allow
multipath or similar schemes where a small set of routes is used
interchangeably) is probably advisable for implementations.

-Ben

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 11 May 2017 17:55:29 +0000

So this attack supposes that an attacker has established a QUIC connection and is using that connection’s cryptographic material for a reflection attack on a victim.  However, would not the victim simply reply with a Public Reset (or ICMP port unreachable), and that would kill this QUIC connection?  In the end, the attacker would had done a lot of work establishing the connection just to get a single reflected QUIC packet to the victim.

-          Igor

From: Benjamin Kaduk [mailto:[email-masked]]
Sent: Thursday, May 11, 2017 12:52 PM
To: Jānis Čoders <[email-masked]>; [email-masked]
Subject: Re: Amplification attack using the same connection id?

request).

If the received message does not cryptographically verify as being sent by the peer, it is dropped and no reply is sent.

Rereading your message more carefully, maybe the "internal states of QUIC" is supposed to include the relevant cryptographic material?

Some rate limiting of switching (maybe slightly clever to allow multipath or similar schemes where a small set of routes is used interchangeably) is probably advisable for implementations.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 May 2017 13:59:31 -0500

Would ICMP port unreachable kill the entire connection?  I thought we
were leaning towards treating that as just a path signal.

-Ben

On 05/11/2017 12:55 PM, Lubashev, Igor wrote:
>
> So this attack supposes that an attacker has established a QUIC
> connection and is using that connection’s cryptographic material for a
> reflection attack on a victim.  However, would not the victim simply
> reply with a Public Reset (or ICMP port unreachable), and that would
> kill this QUIC connection?  In the end, the attacker would had done a
> lot of work establishing the connection just to get a single reflected
> QUIC packet to the victim.
>
>  
>
> -          Igor
>
>  
>
> *From:*Benjamin Kaduk [mailto:[email-masked]]
> *Sent:* Thursday, May 11, 2017 12:52 PM
> *To:* Jānis Čoders <[email-masked]>; [email-masked]
> *Subject:* Re: Amplification attack using the same connection id?
>
>  
>

---

From: Roland Zink <[email-masked]>
Date: Thu, 11 May 2017 21:00:44 +0200

The victim has no state about the connection and probably can't send an 
authenticated public reset. Does this mean that public resets shouldn't 
be authenticated?

Roland

Am 11.05.2017 um 19:55 schrieb Lubashev, Igor:
> -Igor

---

From: Jānis Čoders <[email-masked]>
Date: Thu, 11 May 2017 22:03:03 +0300

Well the attack will most probably be made on device/host that doesnt
use QUIC or doesnt respond with ICMP because of firewall - but the
attacks goal is to saturate target's network. What about situation
where a protocol which runs over QUIC responds with big data payload
(e.g. client asks for HTTP GET and in the last QUIC packet, changes
IP. The HTTP layer doesn't know(care) about transport layer and just
sends multiple packets to target - probably until non anknowledget
window size is full - and as I understand QUIC should resend the
packets, because they are not acknowledget.

On 11 May 2017 at 20:55, Lubashev, Igor <[email-masked]> wrote:
> So this attack supposes that an attacker has established a QUIC connection
> and is using that connection’s cryptographic material for a reflection
> attack on a victim.  However, would not the victim simply reply with a
> Public Reset (or ICMP port unreachable), and that would kill this QUIC
> connection?  In the end, the attacker would had done a lot of work
> establishing the connection just to get a single reflected QUIC packet to
> the victim.
>
>
>
> -          Igor
>
>
>
> If the received message does not cryptographically verify as being sent by
> the peer, it is dropped and no reply is sent.
>
>
> Rereading your message more carefully, maybe the "internal states of QUIC"
> is supposed to include the relevant cryptographic material?
>
> Some rate limiting of switching (maybe slightly clever to allow multipath or
> similar schemes where a small set of routes is used interchangeably) is
> probably advisable for implementations.
>
> -Ben

-- 
Ar cieņu,
Jānis Čoders

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 11 May 2017 19:18:08 +0000

There are legitimate reasons why an endpoint loses state (app restart, for example).  The endpoint w/o state needs to be able to tell the other side of the connection that it cannot continue and must reset.  The only proof the endpoint w/o state can offer is that it received a packet to which it is replying by including data derived from the contents of that packet.

-          Igor

From: Roland Zink [mailto:[email-masked]]
Sent: Thursday, May 11, 2017 3:01 PM
To: [email-masked]
Subject: Re: Amplification attack using the same connection id?

The victim has no state about the connection and probably can't send an authenticated public reset. Does this mean that public resets shouldn't be authenticated?

Roland

-          Igor

From: Benjamin Kaduk [mailto:[email-masked]]
Sent: Thursday, May 11, 2017 12:52 PM
To: Jānis Čoders <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Amplification attack using the same connection id?

request).

-Ben

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 11 May 2017 19:21:08 +0000

You are right.  Killing the path is the proper way of stating this.

Maybe I need to catch up, but I would think that establishing an additional path (as in multi-path) is also a non-trivial process and would require work on the path of the attacker to establish a new path, “migrate it” and have it killed.

-          Igor

From: Benjamin Kaduk [mailto:[email-masked]]
Sent: Thursday, May 11, 2017 3:00 PM
To: Lubashev, Igor <[email-masked]>; Jānis Čoders <[email-masked]>; [email-masked]
Subject: Re: Amplification attack using the same connection id?

Would ICMP port unreachable kill the entire connection?  I thought we were leaning towards treating that as just a path signal.

-Ben

-          Igor

request).

-Ben

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 May 2017 10:40:19 +1000

> course it should be in a state where server's response is bigger than

FYI, this is an issue we are aware of:
https://github.com/quicwg/base-drafts/issues/161

First, the server resets its congestion state when it detects a new
path and this is obviously a new path.  That isn't sufficient in
practice because asymmetric traffic patterns could eventually lead to
some severe amplification.  Think video downloads for an example.

The main fix is that the server needs to verify that the client can
receive at this new address before it sends (significantly) more than
it receives *on this path*. This is not currently guaranteed, though
there is some discussion about using packet number skipping for this
in the draft.  I'm personally not especially happy about that
approach.

We've discussed several ideas for this, because it's the important one
for handling amplification.  A simple example of what has been
suggested: the server sends a ping that contains entropy and requires
an echo of that ping.

---

From: Jānis Čoders <[email-masked]>
Date: Fri, 12 May 2017 09:09:57 +0300

Thanks, so there is already discussion about this. I'll try to follow
it, but currently for me a "challenge ping" seems more reasonable
solution - clearer intention.

-- 
Ar cieņu,
Jānis Čoders