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

[erickinnear <[e-mail]>]

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