Subject: Changing IPs and amplificiation

From: Subodh Iyengar <[email-masked]>
Date: Thu, 2 Mar 2017 19:49:43 +0000

A few colleagues, Kyle Nekritz, Alan Frindell and I were discussing QUIC's behavior when source IP changes.

After a QUIC connection is fully established, when a client's source IP changes due to a NAT, the server would need to cache the last known IP address because future UDP writes would go to the new source IP. How should the server validate that the new IP is a reasonable address to send traffic if the sender is actually an attacker?

Simply validating the cryptographic authenticity of packet doesn't seem like it is enough since an attacker can change their IP without violating the authenticity of their own packet. The server could use some heuristics to validate the source IP, for example, the client didn't change it's ASN or subnet. However, without any validation it would seem like an attacker could initially use the source token during connection establishment to prove possession of their IP, but later when a connection id is bound, they could change their IP to a target IP which they want to send amplification traffic to.

Do current deployments of QUIC use some other techniques to validate IP address when it does change? Do we need a feature for the server to be able to request revalidation in the middle of a connection?

Subodh Iyengar

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 2 Mar 2017 21:00:57 +0100

isnt this covered in the security considerations of 
draft-ietf-quic-transport-01
  or the attack yu are refferring is different?

El 02/03/17 a las 20:49, Subodh Iyengar escribió:
> After a QUIC connection is fully established, when a client's 
> source IP changes due to a NAT, the server would need to cache the 
> last known IP address because future UDP writes would go to the new 
> source IP. How should the server validate that the new IP is a 
> reasonable address to send traffic if the sender is actually an attacker?
>
> Simply validating the cryptographic authenticity of packet doesn't 
> seem like it is enough since an attacker can change their IP without 
> violating the authenticity of their own packet. The server could use 
> some heuristics to validate the source IP, for example, the client 
> didn't change it's ASN or subnet. However, without any validation it 
> would seem like an attacker could initially use the source token 
> during connection establishment to prove possession of their IP, but 
> later when a connection id is bound, they could change their IP to a 
> target IP which they want to send amplification traffic to.
>
> Do current deployments of QUIC use some other techniques to validate 
> IP address when it does change? Do we need a feature for the server to 
> be able to request revalidation in the middle of a connection?
>
>
> Subodh Iyengar
>

---

From: Subodh Iyengar <[email-masked]>
Date: Thu, 2 Mar 2017 21:23:21 +0000

In https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.section.6.4 the current language in the draft addresses the threat of source address spoofing during the 0-RTT handshake where the client has a chance to provide proof of the source address using the session ticket. This does not address how the client could prove possession of the source address after a handshake is finished and in the course of a regular connection.

It looks like the https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#migration section is meant to be a placeholder for putting up how to do validation if source address changes. More specifically I'm wondering if current deployments of QUIC use any techniques to do source address validation after the source address changes which are not specified here.

Subodh

________________________________
From: QUIC <[email-masked]> on behalf of marcelo bagnulo braun <[email-masked]>
Sent: Thursday, March 2, 2017 12:00:57 PM
To: [email-masked]
Subject: Re: Changing IPs and amplificiation

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Mar 2017 09:28:19 +1100

On 3 March 2017 at 06:49, Subodh Iyengar <[email-masked]> wrote:
> How should the server validate that the new IP is a reasonable address to
> send traffic if the sender is actually an attacker?

This is a question that already has an issue:

https://github.com/quicwg/base-drafts/issues/161

I don't believe that it has an answer.  The only possible answer that
was offered was some combination of the server skipping packet numbers
and then observing acks.  That's a pretty low bandwidth channel.

---

From: Subodh Iyengar <[email-masked]>
Date: Fri, 3 Mar 2017 02:18:54 +0000

Thanks Martin, missed that open issue.

Subodh

________________________________
From: QUIC <[email-masked]> on behalf of Martin Thomson <[email-masked]>
Sent: Thursday, March 2, 2017 2:28:19 PM
To: Subodh Iyengar
Cc: [email-masked]
Subject: Re: Changing IPs and amplificiation

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Mar 2017 13:26:53 +1100

Easy to miss given the number we have right now.  If you have any
ideas on how we might *solve* this, I'm sure we'd be interested to
discuss those ideas.  I have some ideas, but they are all either
kludgy or gross in some measure.

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 2 Mar 2017 23:02:52 -0800

Subodh,

AFAICT, there are three issues here, and I think they're solvable. (I'll
add this to the github issue.)

1. Amplification attack, where an attacker grows server's cwnd to a large
value and then sends a spoofed packet with the victim's IP, causing a large
amount of data to be dumped on the victim.
Solution: When a server observes a change in the client's IP address, it
records the current cwnd, clamps the cwnd down to MIN_CWND, and sends a
PING frame to the new IP. When a packet sent to the new IP address is
acked, the cwnd is restored.

2. Optimistic ack attack, where the attacker optimistically acks the PING
packet sent by the server to the victim's IP, causing the server to again
unleash it's large cwnd on the victim.
Solution: On a change in the client's IP address, the server introduces a
randomly sized gap in the packet sequence space. Any new data will now
still be sent to the new client IP, but the sequence numbers will be
discontiguous from transmissions to the old IP. Any acks for packets in the
gap will result in an immediate termination of the connection. A malicious
client will now have to either correctly guess the exact size of this gap
or read packets going to the victim.

3. There's a slightly tricky issue hidden in here. Say a server observes an
address change from IP A to B. What should a server do if it observes
another address change while it's in the middle of validating one?
Solution: There are three possible scenarios.
(i) If the new IP is different than A, then restart validation of the
newest IP.
(ii) If the new IP is the same as A and the packet is reordered, then
accept the packet and continue with the current validation.
(iii) If the new IP is  the same as A and the packet is newer than the one
that triggered the last validation, then close the connection, since this
doesn't look like a NAT rebinding. (This could be a MITM, who changes the
IP address of one client -> server packet, hoping that the server reduces
its cwnd or latches on to this new IP, causing a DoS of sorts.)

- jana

---

From: "Swindells, Thomas (Nokia - GB)" <[email-masked]>
Date: Fri, 3 Mar 2017 09:38:25 +0000

Presumably A->B->A would potentially happen commonly with devices which are flip flopping between a wifi and mobile connection? This would mean that NAT rebindings aren’t going to be the only common cause of IP address changes.

Apologies if this is a stupid question, but what level of authentication will the packet which is marked as coming from IP B undergo? Can an attacker simply replay a genuine packet to the server, modifying it with a different source address, or does the packet number and other information also need to be modified, and if so does this require them to have parts of the encryption context? If the packets are strongly authenticated then it seems like the probability is that it is a client (or gateway) flip-flopping between addresses rather than an attacker, and keeping the connection alive is the desired behaviour.

Thomas

From: QUIC [mailto:[email-masked]] On Behalf Of Jana Iyengar
Sent: 03 March 2017 07:03
To: Martin Thomson <[email-masked]>
Cc: Subodh Iyengar <[email-masked]>; [email-masked]
Subject: Re: Changing IPs and amplificiation

Subodh,

AFAICT, there are three issues here, and I think they're solvable. (I'll add this to the github issue.)

1. Amplification attack, where an attacker grows server's cwnd to a large value and then sends a spoofed packet with the victim's IP, causing a large amount of data to be dumped on the victim.
Solution: When a server observes a change in the client's IP address, it records the current cwnd, clamps the cwnd down to MIN_CWND, and sends a PING frame to the new IP. When a packet sent to the new IP address is acked, the cwnd is restored.

2. Optimistic ack attack, where the attacker optimistically acks the PING packet sent by the server to the victim's IP, causing the server to again unleash it's large cwnd on the victim.
Solution: On a change in the client's IP address, the server introduces a randomly sized gap in the packet sequence space. Any new data will now still be sent to the new client IP, but the sequence numbers will be discontiguous from transmissions to the old IP. Any acks for packets in the gap will result in an immediate termination of the connection. A malicious client will now have to either correctly guess the exact size of this gap or read packets going to the victim.

3. There's a slightly tricky issue hidden in here. Say a server observes an address change from IP A to B. What should a server do if it observes another address change while it's in the middle of validating one?
Solution: There are three possible scenarios.
(i) If the new IP is different than A, then restart validation of the newest IP.
(ii) If the new IP is the same as A and the packet is reordered, then accept the packet and continue with the current validation.
(iii) If the new IP is  the same as A and the packet is newer than the one that triggered the last validation, then close the connection, since this doesn't look like a NAT rebinding. (This could be a MITM, who changes the IP address of one client -> server packet, hoping that the server reduces its cwnd or latches on to this new IP, causing a DoS of sorts.)

- jana

On Thu, Mar 2, 2017 at 6:26 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

On 3 March 2017 at 13:18, Subodh Iyengar <[email-masked]<mailto:[email-masked]>> wrote:
> From: QUIC <[email-masked]<mailto:[email-masked]>> on behalf of Martin Thomson
> <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>
> On 3 March 2017 at 06:49, Subodh Iyengar <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Mar 2017 22:34:22 +1100

On 3 March 2017 at 20:38, Swindells, Thomas (Nokia - GB)
<[email-masked]> wrote:
> Can an attacker simply replay a genuine packet to the server, modifying it
> with a different source address, or does the packet number and other
> information also need to be modified, and if so does this require them to
> have parts of the encryption context? If the packets are strongly
> authenticated then it seems like the probability is that it is a client (or
> gateway) flip-flopping between addresses rather than an attacker, and
> keeping the connection alive is the desired behaviour.

Packets with duplicate numbers will be dropped (they will be decoded
with a vastly different packet number and decryption will then fail).

As it stands, IP and port are not authenticated.  I don't believe that
it is possible to have a functional protocol and authenticate these.
So an attacker could move packets from one path to another.  But it
requires an on-path attacker to receive the values on the return side.

As long as we can do the return routeability check as marcelo and Jana
observe, we can avoid sending too much down a path that neither the
client nor the attacker are on (noting that client and attacker may be
one and the same).

---

From: Michael Thornburgh <[email-masked]>
Date: Fri, 3 Mar 2017 19:09:10 +0000

> From: QUIC [[email-masked]] on behalf of Martin Thomson [[email-masked]]
> Sent: Friday, March 3, 2017 3:34 AM
> 

to safely verify an address change you need something like a "ping-reply" that
will return verbatim whatever was sent in a ping. just acking the ping isn't sufficient.

for the method RTMFP uses, see section 3.5.4.2 of RFC 7016:

   https://tools.ietf.org/html/rfc7016#section-3.5.4.2

this method is very conservative and doesn't send any data to a new address
(other than the connectivity check) until the connectivity check is received.  if you're
busy sending data, this costs you one RTT, and maybe even one RTO.  the method
could be modified a bit to optimistically change DESTADDR right away and set an alarm
(for "something that's probably enough" like N * RTO where N isn't too big) for
changing the address back.  if the alarm fires, someone was screwing with you and
you change the address back and don't try the optimistic method again.  if you get the
connectivity check reply then you clear the alarm and everything is awesome.

in every case, when changing the destination address, the safe thing to do is to
collapse the congestion window back to CWND_INIT, since you don't know
anything for sure about the new path.  only acks for newly sent
packets should increase the congestion window, so any acks that might be
draining out of the network wouldn't improperly increase the congestion window
for the new path.

-mike