Subject: [quicwg/base-drafts] Be more conservative about migration? (#2143)

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 13:41:04 +0000 (UTC)

I've been reading through the migration mechanism and it seems to me
that assuming that a packet from a given IP address is evidence of
migration creates a pretty easy DoS attack from an on-path attacker.
Consider the case where we have a quiescent connection between A and B
and an on-path attacker and then B sends a packet to A.

In the diagram below, the notation [X:Y]: Z -> means a packet with a
source addr of A, a dest addr of B, and a payload of Z

A                       Attacker (Z)                  B

                                         <- [B:A]: Data
                     <- [B:A]: Data
[A:B]: ACK ->
                        [Z:B]: ACK ->

                                       X <- [B:Z]: Data
                                       X <- [B:Z]: Probe
                                       
As long as A doesn't try to send a data packet, B will continue to
think that A is at Z for the duration of the validation timer
(currently 3 RTO?) [0]. That's not the worst thing in the world, but
it's a pretty good cost/benefit for an on-path attacker who only has
to forge one packet; I'm not sure that that's a great design tradeoff
for a protocol where we're otherwise trying to stop on-path attacker
from interfering with the connection after the handshake completes.

The reason this works is the receipt of a packet from addr X is a
trigger for abandoning the previous path and trying migration. Another
time this can happen is at the tail of a client transmission,
though that will presumably recover faster.

At a high level, it seems like there are two major types of
migration:

1. Unknown migration (e.g., NAT re-binding)
2. Known migration (e.g., transferring from WiFi to 3G)

In the latter case, we can have the client give notice that it's
migrating, even if it doesn't know it's visible IP address, and have
the server refuse to change peer addresses unless it sees that
indication, so it's just the former case we have to deal with, and as
above. The present design does that but at the cost of creating the
situation above.

I wonder if we should be more conservative about initiating migration.
I don't have a fully worked out proposal, but here are some ideas:

- Send packets to both the original and new addresses during the
  validation period.
  
- If you receive an apparent migration that looks like a rebinding
  (e.g., same address, different port) within X seconds of a previous
  packet, then probe first (or in parallel as above).

- Have the client send some packet that indicates it thinks it's
  migrating (this seems tricky to get right)

[0] Note that if we were to allow migration on the client and the
server, even worse attacks are possible.

-- 
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/2143

---

From: MikkelFJ <[email-masked]>
Date: Thu, 13 Dec 2018 06:10:35 -0800

When you say on-path, do you mean observer? I.e. with the ability to race a packet, or to drop or replace a packet.

I suppose a race will not be successful in this attack.

So the effectiveness on the attack builds on it being cheaper to confuse the connection rather than to actively drop packets. I'm not sure that is a strong case for additional complexity. However, a related attack might be used for amplification attacks by changing the IP to that of the indented victim.

Attacks that can be instigated by observers are much more severe because they are far easier to achieve, especially undetected.

-- 
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/2143#issuecomment-446981296

---

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 06:15:06 -0800

For the purposes of this discussion, I'm talking about an attacker who can drop-and-replace, but I'm not sure why you think a race won't work, as it depends quite a bit on the network topoligy

-- 
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/2143#issuecomment-446982820

---

From: MikkelFJ <[email-masked]>
Date: Thu, 13 Dec 2018 06:45:36 -0800

To prevent a race from being successful the probe needs to checksum the visible address and have that checksum be reflected back by the client rather than just ACK'ing the probe. Once the reflected checksum is seen the path must be valid.

For true on path, the attacker can drop packets from client to server to maintain the illusion of a different client address, but then the probe will never be reflected correctly. It will eventually time out.

BTW: the description on notation is confusing, mixing [A:B] with [X:Y] and sometimes having Z as payload and sometimes as an 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/2143#issuecomment-446993259

---

From: MikkelFJ <[email-masked]>
Date: Thu, 13 Dec 2018 14:47:38 +0000 (UTC)

No that is not sufficient. The attacker can just race the reflected probe checksum.

-- 
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/2143#issuecomment-446994003

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Dec 2018 15:31:19 -0800

What we have in practice is this:
```
A                       Attacker (Z)                  B

                                         <- [B:A]: Data
                     <- [B:A]: Data
[A:B]: ACK ->
                        [Z:B]: ACK ->

                                       X <- [B:Z]: Data
                                         <- [B:A]: Probe
                                       X <- [B:Z]: Probe
```

Provided the attacker isn't on path (where they could deny service anyway), the result is that the migration will fail as soon as the probe response arrives.

-- 
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/2143#issuecomment-447159386

---

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 23:35:57 +0000 (UTC)

Why is it probing B->A?

-- 
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/2143#issuecomment-447160355

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Dec 2018 15:38:12 -0800

Because we [told it to](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#off-path-forward): 

> In response to an apparent migration, endpoints MUST validate the previously active path using a PATH_CHALLENGE frame. 

-- 
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/2143#issuecomment-447160789

---

From: MikkelFJ <[email-masked]>
Date: Thu, 13 Dec 2018 15:41:16 -0800

> That is, I think that we have all of what you suggest already, with the exception of the message saying "I think that I'm migrating". I don't know how to do that. We don't really create any signals that A might use to learn that it is migrating.

If you see a new CID on a packet that is not Initial, you are probably migrating. You can win races by copying and spoofing source address without having the ability to drop packets. A spoofed packet will cause the real packet to be dropped by the endpoint if it arrives late.

-- 
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/2143#issuecomment-447161340

---

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 15:45:07 -0800

> > In response to an apparent migration, endpoints MUST validate the previously active path using a PATH_CHALLENGE frame.

OK. I missed that section. However, I'm not sure how much it changes thing, though. The question is how much impact an on-path attacker can cheaply have (and of course, this goes back to what we claim our security guarantees are). 

-- 
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/2143#issuecomment-447162130

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Dec 2018 21:08:13 -0800

The properties we want from migration are distinct from those during the handshake.  I'd like to resolve that discussion first.  Then we can talk about what we might be willing to tolerate during migration.

-- 
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/2143#issuecomment-447215052