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

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Jan 2018 09:33:27 +1100

Thanks for doing this Christian.

The think that I'm most interested in here is how this relates to the
invariants we have established.  I don't think that it has any impact and
you seem to agree.  So I think we're good.

I don't think that the section on flow control makes any sense, since flow
control operates at your stream layer.

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.

On Thu, Dec 28, 2017 at 8:11 AM, Christian Huitema <[email-masked]>
wrote:

> Yes, I know full well that multipath is not in scope for V1. But since we
> are dabbling in connection migration anyhow, I thought we could just as
> well have a document listing multipath requirements and issues...
>
> -- Christian Huitema
>
>
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-huitema-quic-mpath-req-00.txt
> Date: Wed, 27 Dec 2017 13:07:17 -0800
> From: [email-masked]
> To: Christian Huitema <[email-masked]> <[email-masked]>
>
> A new version of I-D, draft-huitema-quic-mpath-req-00.txt
> has been successfully submitted by Christian Huitema and posted to the
> IETF repository.
>
> Name:		draft-huitema-quic-mpath-req
> Revision:	00
> Title:		QUIC Multipath Requirements
> Document date:	2017-12-27
> Group:		Individual Submission
> Pages:		11
> URL:            https://www.ietf.org/internet-drafts/draft-huitema-quic-mpath-req-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-req/
> Htmlized:       https://tools.ietf.org/html/draft-huitema-quic-mpath-req-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-huitema-quic-mpath-req-00
>
>
> Abstract:
>    This document describes the requirement and plausible architecture of
>    QUIC multipath extensions.  While the first version of QUIC is not
>    scheduled to include multipath extensions, there are risks that
>    decisions made in this first version might preclude some options that
>    we may later find attractive.  An early review of multipath extension
>    requirements and issues should minimize that risk.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>

---

From: Christian Huitema <[email-masked]>
Date: Mon, 1 Jan 2018 20:32:07 -0800

> On Jan 1, 2018, at 2:33 PM, Martin Thomson <[email-masked]> wrote:
> 
> ...
> 
> I don't think that the section on flow control makes any sense, since flow control operates at your stream layer.

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

-- Christian Huitema

---

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Jan 2018 15:44:24 +1100

With the notice here that we're probably getting ahead of things a little...

> 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 se…

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.

> 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 mas…

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.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 1 Jan 2018 20:56:54 -0800

> On Jan 1, 2018, at 8:44 PM, Martin Thomson <[email-masked]> wrote:
> 

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

> no key phase bit.  There are a few downsides of course, but those can

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Jan 2018 16:17:30 +1100

> 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 th…

In order rotations might still be valuable to allow for some
predictability.  I think that I'd still want to retain the ordering,
if only to retain the post-compromise security.  Parallel flows can
still work with that.

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

Well, they are probably still on a break, as I realize that I should also be.