Re: [quicwg/base-drafts] Connection migration failure mode (#1278)

[Martin Thomson <[e-mail]>]

Not sure if [that comment](https://github.com/quicwg/base-drafts/issues/1278#issuecomment-394753339) 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.

-- 
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/1278#issuecomment-403713519