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

From: Martin Thomson <[email-masked]>
Date: Sun, 04 Nov 2018 04:01:57 -0800

@erickinnear can you take a look at this please?

-- 
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-435663816

---

From: erickinnear <[email-masked]>
Date: Mon, 05 Nov 2018 18:57:02 -0800

> 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. 

-- 
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-436114479

---

From: erickinnear <[email-masked]>
Date: Mon, 05 Nov 2018 19:14:01 -0800

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.

-- 
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-436117121

---

From: MikkelFJ <[email-masked]>
Date: Tue, 06 Nov 2018 02:23:09 -0800

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.

-- 
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-436203463