Subject: [quicwg/base-drafts] Address change and consent to send (#161)

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Jan 2017 17:01:06 -0800

When a client changes IP addresses (for any reason, including NAT rebinding), the server has no way of gaining an assurance that the client has actually seen its packets.  That opens an attack where the attacker establishes a connection, then starts spoofing source address.  If the server starts to send to that source address without verifying that the client can receive packets, that's potentially a powerful packet amplification attack.

It's not sufficient to look for ACKs or other such things, because no client message includes proof that the client has actually received a packet from the server.  A client can just generate ACK and WINDOW_UPDATE frames as necessary, even new requests.  The only risk a client runs is that it overestimates the number of packets that the server has sent and sends too many spurious ACK frames, which the server will then recognize and react to.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161

---

From: Marten Seemann <[email-masked]>
Date: Mon, 16 Jan 2017 17:14:14 -0800

This would be the equivalent of an Optimistic ACK attack, after completing the crypto handshake. If the server randomly skips packet numbers, the server will notice the attack **eventually** and close the connection.
The question is, will that happen soon enough to make this attack unpractical. In quic-go, we randomly skip one packet out of 500, so just ACKing random packets would make the server send about 800 kB of data before noticing the attack.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-272997099

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Jan 2017 17:27:45 -0800

Packet skipping would seem to be a possible answer, though the client only needs to ack a few packets to keep things moving along.  If it is eventually unlucky enough to hit a skipped packet the attack ends.  I'd need to do the math, but 800k sounds right for an expected value, which is pretty high when you compare it to the cost of a handshake (around 1400 octets and some crypto for clients).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-272998697

---

From: mirjak <[email-masked]>
Date: Tue, 17 Jan 2017 02:13:52 -0800

You could maybe send a ping frame with a random number if you see a new IP address...?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-273085306

---

From: ianswett <[email-masked]>
Date: Tue, 17 Jan 2017 07:33:58 -0800

In the case of port or IP address change, skipping a larger number of packets makes it much harder to guess.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-273202803

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Jan 2017 14:22:56 -0800

FWIW, PING doesn't work here.  The response to a PING is an ACK, which contains no information from the PING.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-273319728

---

From: mirjak <[email-masked]>
Date: Tue, 17 Jan 2017 14:49:56 -0800

Yes, I meant to actually extend the ping mechanism here to make it possible to reflect a random number chosen by the ping sender. Having this as an explicit check rather than doing some implicit guess-work might make sense given it's simple and the cost is low.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-273326029

---

From: ianswett <[email-masked]>
Date: Tue, 17 Jan 2017 15:20:39 -0800

The idea of a PING packet with an random number and a PONG in response seems reasonable, though if this is the only use case, I think skipping packet numbers is sufficient, given the 5-tuple is changing anyway.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-273333000

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Jan 2017 12:42:03 -0800

Having thought about this some more, skipping packet numbers does allow for some fairly high confidence that there is return routeability.  Since you are starting a new congestion state for the new path anyway, ACKs will be critical in driving the congestion window open.  I do think that we need to be a lot more aggressive in dropping, skipping packet numbers with high probability (> 0.5) for a short while.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/161#issuecomment-273595443