Connection migration failure mode

[martinthomson]

From @ekr,

To add to my previous comment about attacks, in cases where one side has totally migrated (i.e., only one path is valid), then an attacker can also mess things up pretty severely by just spoofing a response to a PATH_CHALLENGE. I.e.,

1. I am receiving packets from A
2. A migrates and so sends me a packet from A'
3. I send a PATH_CHALLENGE to A'
4. If the attacker forwards the next packet from A' (likely a PATH_RESPONSE) but rewrites the source address to B, then I will consider the validation failed.

What is especially pernicious here is that the migration might not be voluntary, and so there is no option to repair the condition. Multiple challenges make this harder to effect the attack, but that's all. Currently the draft seems to imply that a single PATH_RESPONSE like this is enough to cause the path to be marked as invalid, see #1277.

We could decide that this is akin to messing with a handshake and decide to limit our reaction to this to documentating it. But we could also try to make the process more robust, with the caution that pulling on this thread potentially leads to a reiteration of RFC 5245.

[janaiyengar]

From editors' meeting:

1. A MITM can cause migration to fail by modifying or dropping path validation packets.
2. Change text to reflect that endpoints MUST ignore PATH_RESPONSE frames that do not satisfy any outstanding PATH_CHALLENGE frames.

This also resolves #1265 and #1277.

[martinthomson]

Not sure if that comment helps, if we misunderstood when we met, or if it is just missing something important.

The second point doesn't seem connected to the problem, though the first might be sufficient.

If an attacker can capture a packet and send it from a new address twice, with a similar rewrite of the packet containing PATH_CHALLENGE, then it might be reasonable to say that they are on the path. But this is possible from the side.

Given that most traffic patterns have at least some (non-probing) activity in both directions (an ACK suffices here), the genuine path might naturally reassert itself naturally as the victim sends more packets. The problem is that the attacker might be able to find a natural stop in the cadence of the protocol where the victim has no further data to send. For instance, a HTTP request was sent, acknowledged, and now the victim is only waiting for the response. If the victim stops receiving packets, and has no natural triggers for sending its own packets, then the connection could time out as being apparently broken.

The suggested defense was to do post-hoc validation of a migration by sending a message on the original path as well indicating that migration happened. That might get lost (which is OK if the path really is dead), but if the migration was spurious and the packet got through then the victim might be able to reassert their use of the valid path by sending more data on that path. In effect, they would migrate back. Of course, then there is the question of how often and how many of those you might send.

We might agree that this is an attack not worth building specific countermeasures for and that documenting it is sufficient. I'm undecided here. I really don't like the idea that connections could be broken so trivially by rewriting the IP header, but the mitigations aren't especially strong.

[martinthomson]

@erickinnear can you take a look at this please?

[erickinnear]

the genuine path might naturally reassert itself naturally as the victim sends more packets

If memory serves, this was part of the thinking about how this would work -- you'd naturally "migrate" back to the real path.

[erickinnear]

One of the things that was really nice about uninitiated migration (such as NAT rebinding) generating PATH_CHALLENGE frames was that the endpoint has a potential indication that something like a rebinding may have occurred.

I think that we allowed the endpoint to omit PATH_CHALLENGE when switching back to the "old" path for cases like these where a packet may have been raced or otherwise interfered with by an attacker, but perhaps we should always require it, which would cover this case as well.

That still doesn't necessarily cover the case where an attacker can race both a path challenge and a path response, but at some point they're on path and forwarding your packets.

[mikkelfj]

Is there a related attack where an attacker takes a valid packet and makes it appear from a new path triggering path validation probe to which the attacker responds?

On the original attack:

It was already mentioned that invalid probes could be ignored. Why would that not be sufficient, combined with a timeout on the probe?

Another attack:

An attack could make a probe appear successful even when it isn't - but that is probably far down the list of worthwhile attacks.