Subject: [quicwg/base-drafts] Attacks Against Address Migration (#2582)

From: martinduke <[email-masked]>
Date: Mon, 01 Apr 2019 21:16:36 -0700

There are a few DoS vectors in migration that aren't well addressed in the draft. @erickinnear will follow soon with a short PR to address this issue.

The current draft presents a specific case of a general attack. The generalized form of the attack is that the attacker observes both paths. He clones all packets from the client so that they appear to be from both addresses, and makes sure that all packets the server sends to each address both arrive at the client. He has the capability to out-race packets he observes.

The attacker might fabricate a NAT rebinding that didn't happen, or spoof the old address during a rebinding. 

With PATH_CHALLENGE going out on both paths, these duplicate packets create four outcomes depending on which packets arrive first: both paths appear to be valid, the right path only is valid, the wrong path only is valid, or neither path is valid. The current requirement that the source address of PATH_RESPONSE matches the destination of the PATH_CHALLENGE can cause validation of the correct path to fail.

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

---

From: Lars Eggert <[email-masked]>
Date: Tue, 16 Apr 2019 00:55:32 -0700

Waiting for @erickinnear to land this PR so a discussion can happen.

-- 
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/2582#issuecomment-483552420

---

From: erickinnear <[email-masked]>
Date: Tue, 16 Apr 2019 09:17:39 -0700

Is coming, apologies for the delay, been caught up in a few things immediately post-Prague. 

-- 
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/2582#issuecomment-483730715

---

From: erickinnear <[email-masked]>
Date: Tue, 16 Apr 2019 09:19:11 -0700

The biggest change here to what’s already in the draft is the perspective that the “old” path may not always be the desired one. 

That being said, I think we’re still pretty well covered by the existing text describing the properties that already existed around new traffic from the client triggering it to go back to where it was previously, etc. such that an attacker would find it difficult to substantially interrupt a connection. 

-- 
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/2582#issuecomment-483731281

---

From: Mike Bishop <[email-masked]>
Date: Thu, 18 Apr 2019 16:08:33 -0700

I think the attacker's ability to do this argues for ignoring PATH_RESPONSE frames that mismatch rather than actively considering the validation to have failed; we added that text already:

> Note that receipt on a different local address does not result in path validation failure, as it might be a result of a forwarded packet (see Section 9.3.3) or misrouting. It is possible that a valid PATH_RESPONSE might be received in the future.

This text perhaps needs to be broadened to talk about both source and destination address rather than simply "local 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/2582#issuecomment-484718471

---

From: erickinnear <[email-masked]>
Date: Fri, 19 Apr 2019 17:45:01 -0700

@MikeBishop Thanks for pulling up that text! I think you're correct in that we need to stop requiring remote address to match as well. 

That's essentially removal of this paragraph talking about what a successful validation is: 
```
- It was sent from the same remote address to which the corresponding
	  PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received from a different
	  remote address than the one to which the PATH_CHALLENGE was sent, path
	  validation is considered to have failed, even if the data matches that sent in
	  the PATH_CHALLENGE.
```

-- 
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/2582#issuecomment-485045007

---

From: erickinnear <[email-masked]>
Date: Fri, 19 Apr 2019 18:13:54 -0700

I think the summary in the context of new information to do with these attacks is that an attacker can attack the NAT to effectively "take over" your port. Therefore, using the remote address isn't super useful.

So far, we've got some language that says you have to validate both the old and new path on any migration and use the old one if the new path fails to validate. Even if the old path isn't necessarily correct, an off-path attacker should not be able to cause validation of a path to fail -- it can either win the race with the packets and cause it to succeed over a different path, or it can lose that race and it validates on original path.
That text is in {{on-path-spoofing}}:
```
To protect the connection from failing due to such a spurious migration, an
endpoint MUST revert to using the last validated peer address when validation of
a new peer address fails.
```

At the end of the day, the concern with an attacker migrating from off-path to on-path is pretty well covered by the existing text in {{off-path-forward}}: 
```
In response to an apparent migration, endpoints MUST validate the previously
active path using a PATH_CHALLENGE frame.  This induces the sending of new
packets on that path.  If the path is no longer viable, the validation attempt
will time out and fail; if the path is viable, but no longer desired, the
validation will succeed, but only results in probing packets being sent on the
path.

An endpoint that receives a PATH_CHALLENGE on an active path SHOULD send a
non-probing packet in response.  If the non-probing packet arrives before any
copy made by an attacker, this results in the connection being migrated back to
the original path.  Any subsequent migration to another path restarts this
entire process.

This defense is imperfect, but this is not considered a serious problem. If the
path via the attack is reliably faster than the original path despite multiple
attempts to use that original path, it is not possible to distinguish between
attack and an improvement in routing.

An endpoint could also use heuristics to improve detection of this style of
attack.  For instance, NAT rebinding is improbable if packets were recently
received on the old path, similarly rebinding is rare on IPv6 paths.  Endpoints
can also look for duplicated packets.  Conversely, a change in connection ID is
more likely to indicate an intentional migration rather than an attack.
```

In all cases here, either the attacker continues to forward your packets faster than before (they could always view them, so that's not a new privilege for them), or they stop being faster/drop all the packets. 
As long as we've induced traffic onto the connection such that it will "migrate" back to the correct/working path, then it's not perfect, but we're okay.

======

All that to say, I think the requirements that are currently in the text are pretty much right, even taking into account the additional cases outlined in this issue. The few minor tweaks necessary should be covered by PR #2637.

-- 
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/2582#issuecomment-485047208

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 22 Apr 2019 23:45:48 -0700

Any objection to just calling this editorial?

-- 
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/2582#issuecomment-485664772

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Apr 2019 20:34:08 -0700

Yeah, we gotta go full design here.  This is a major change to the path validation logic.

There's a good case here for the change: path validation is currently unnecessarily symmetric. The decision to consider a path valid is a decision each peer makes unilaterally.  That is, for the path to be used, both peers need to independently validate that packets sent on that path reach the other side.  We don't need the PATH_RESPONSE to follow the path because we expect the peer to also send a PATH_CHALLENGE down that path.

The requirement that PATH_RESPONSE follow the path is a case of trying to attain or enforce behaviour from a peer unnecessarily.  An endpoint doesn't need to be assured that its peer has also validated the path, but that is what the existing text attempts to assure.  If a peer decides not to validate a path, then that is on them.

The fix here prevents an attacker from using the fact that duplicate packets are dropped to prevent path validation.  And I can't see a down side.

-- 
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/2582#issuecomment-486054142