Re: New Version Notification for draft-huitema-quic-mpath-req-00.txt

[Christian Huitema <[e-mail]>]

> On Jan 1, 2018, at 8:44 PM, Martin Thomson <[e-mail]> wrote:
> 
> With the notice here that we're probably getting ahead of things a little...
> 
>> On Tue, Jan 2, 2018 at 3:32 PM, Christian Huitema <[e-mail]> wrote:
>> Actually, flow control in TCP is used both as an application layer tool, e.g. don't send faster than the printer can print, and as a transport level tool to limit the speed at which the peer can send. If we just look at the application level, then of course this is purely a stream layer issue. But if we consider the transport function, then it makes sense to tie it to a path.
> 
> I'm not sure that I see the logical connection here.  If the intent is
> to govern send rate on a given path, then we probably want a different
> mechanism, but it's not really flow control any more.  I think that
> our TCP heritage might be more of a liability in this case and we
> should be clear what properties we're seeking - plus some new names
> for these functions.

Yes. Probably something to develop a bit in the next iteration of my draft.

> 
>>> I'm going to have to think on it some more, but your suggestion in 4.7 might be a good idea.  We don't have to do that now, though we might choose to do so if we can work through the design and implications.
>> 
>> Either separate encryption keys for separate connection ID, or mix IV with connection ID and sequence number for the nonce. The latter might work better, because it does not require keeping the master secret around. But it leaks one bit for correlation if the phase bit changes at the same time on all paths after a key rotation.
> 
> A simpler design has a key rotation for every connection ID change and
> no key phase bit.  There are a few downsides of course, but those can
> be managed.

One downside is that rotations have to be performed in order, probably using a connection ID sequence like the current packet gap spec. Hashing the connection ID in the key gets rid of that, and that's nice. Plus it allows starting using several connection ID in parallel, which is needed for multi path.

But yes, we are getting a bit ahead, and I expect the chairs to try rein in that discussion at any moment now.

-- Christian Huitema