Re: [quicwg/base-drafts] Path Migration makes unjustified assumptions about a new path. (#2909)

[Eric Kinnear <[e-mail]>]

For 1,2,4:
> In keeping with the first resolution, it's a new CC, and whether a new CC is created or the existing one is reset is an implementation decision.

I think this was always the intent -- some implementations don't want to have two CC contexts so they can reset it and start with zero assumptions about the new path. Implementations that are okay with having more than one will make a new one and use that on the new path, switching back to the old one if they use the old path and the information is still relevant (i.e. it's been <1 RTT and you decided the new path wasn't actually better -- pick some threshold I don't have a strong preference).

3: 
Yes, it's not necessarily exactly the same path. An endpoint that wants to put in extra effort in determining which paths are equivalent to make a smarter decision can do so while the default behavior is a complete reset every time (after confirming the migration). This also impacts (5) around some of the attacks. 

5: 
I agree with @janaiyengar we should be a bit more explicit about preventing an off-path attacker from being able to cause continuous resets as you go back and forth between paths, that's a good case where you would want to keep CC state around (if you're being told to swap multiple times per-RTT you've got other issues, too, which are mostly addressed but might need some more text, likely in transport).

-- 
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/2909#issuecomment-513575528