Subject: Common implementation bug in migration

From: "Martin Thomson" <[email-masked]>
Date: Thu, 05 Nov 2020 20:13:32 +1100

I've been writing up an implementation of migration in neqo.  It's non-trivial work, but I decided that I would add preferred addresses and use that to test it.

Almost every implementation I've tested had the same bug.  I'm still not sure about quant, but it seems likely that it is failing in the same way, so it's almost a clean sweep.  

If the client chooses a zero-length connection ID, it won't/can't send NEW_CONNECTION_ID.  Thus, when the server attempts to make a new "path" to respond to the PATH_CHALLENGE that it received at its preferred address, all implementations are failing because they cannot assign a connection ID to that path.  This caused connection errors in one cases, but mostly it just resulted in the preferred address not responding.

So it's probably worth noting: if the peer chooses a zero-length connection ID, that doesn't count as one connection ID, it's infinite.  You can always get another connection ID in that case.

This likely applies to migration in general.

One thing that is hard to determine from my testing is that no implementations (other than my own) seems to send probes on the old path after the client migrates to the preferred address.  This is probably OK, because my address isn't changing, or at least the port is the only change.  However, it's not clear that we have reliable implementations of that anti-DoS measure.

Other than that, migration seems to work well.  Implementations respond to probes without migrating and migrate properly when the client starts actively using a new path.  I'm also seeing some implementation of the new path validation requirements already, which is good.

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 5 Nov 2020 08:22:21 -0500

Thank you for this report, Martin.

On Thu, Nov 05, 2020 at 08:13:32PM +1100, Martin Thomson wrote:
> One thing that is hard to determine from my testing is that no
> implementations (other than my own) seems to send probes on the
> old path after the client migrates to the preferred address.
> This is probably OK, because my address isn't changing, or at
> least the port is the only change.  However, it's not clear
> that we have reliable implementations of that anti-DoS measure.

Here you must refer to Section 9.3.3: Off-Path Packet Forwarding.
I have to admit I had to go back to the draft and re-read the
Migration section to find the requirement you alluded to.  Even
though that section has been in the transport draft for two years,
we missed it and lsquic does not validate the old path.  One more
item for the TODO list!

  - Dmitri.