Re: Preparing for discussion on what to do about the multipath extension milestone

[Christian Huitema <[e-mail]>]

I am not sure that the current "mpquic" draft is the right approach.
Specifically, I do not agree that having one packet number space per
path is the right approach. This contradicts the design of QUIC V1, in
which data sent on multiple paths shares a common packet number space.
For example, in QUIC V1, we can start a connection on one path, migrate
to another path, and keep the same packet number space throughout. I
find that a very nice property -- and also an essential property if we
want to support NAT rebinding. Handling multipath with a single number
space requires some book-keeping on the sender side to match
acknowledgements and sending paths, but we have working code for that.

I am also not convinced that we properly understand the concept of
"path". There is very little in the QUIC V1 protocol that requires
transmission paths to be symmetric: any packet sent from a node to a
valid address of the peer will be accepted, provided the crypto works.
The linkage such requirement comes from the statement that a server
starts directing traffic to a validated path when it sees the client
using the same pair of addresses. This is an "implicit" linkage; I would
expect that the first role of a multipoint extension would be to replace
that by an "explicit" statement of preferences.

I am worried that we have a set of unresolved security issues around
paths, largely linked to the requirement to support NAT rebinding. If we
support NAT, the IP headers must be outside the authentication envelope
of the crypto. There are plausible attacks in which the attacker splices
a cryptographically valid packet and a forged IP header. We have some
defensive heuristics, but if we study multipath I hope we will end up
with something better.

-- Christian Huitema

On 9/30/2020 5:51 PM, Ian Swett wrote:
> Given the responses, can we narrow down the way forward(ideally on a
> different thread) to directions that are less open-ended?  I'll
> suggest some options, but the chairs and/or ADs need to decide.
>  1) No future work on multipath in the QUIC WG, in the belief the
> existing connection migration functionality is sufficient.
>  2) Adopt the existing draft as a starting point for QUIC
> multipath(draft-deconinck-multipath-quic
> <https://tools.ietf.org/html/draft-deconinck-multipath-quic>),
> with the explicit goal of not expanding the scope of the document.
>  3) Adopting multipath as a core QUIC WG deliverable.
>
> I favor #2, but these may not be the right options.  Normally I'd say
> people should work this out in person, but that doesn't seem viable at
> the moment.  I'm happy to set up a long(3-4+hr) Google Meet to discuss
> this via videoconference if that helps move the discussion forward.
>
> Or we can form a design team, which typically takes O(3 months) to finish.
>
> Ian
>
> On Wed, Sep 30, 2020 at 3:15 PM Spencer Dawkins at IETF
> <[e-mail] <mailto:[e-mail]>>
> wrote:
>
>     Hi, Martin, 
>
>     Just a couple of thoughts here: 
>
>     On Wed, Sep 30, 2020 at 12:16 PM Martin Duke
>     <[e-mail] <mailto:[e-mail]>> wrote:
>
>         (Speaking as an individual)
>
>         There is some back-and-forth as to whether these are useful
>         cases are not. I'll take it on faith, given the proponents,
>         that there is a real hope of deploying this. However, I share
>         the desire to not have the WG fully consumed by MP-QUIC for
>         the foreseeable future.
>
>
>     That sounds right. I'm assuming that getting the core QUIC
>     specifications published and doing any cleanup work necessary
>     SHOULD/MUST take priority, in the BCP 14 sense of those words. 
>
>     As Lars' initial note said, I'd also like to see the
>     manageability, applicability, and datagram extension working group
>     drafts, already adopted by QUIC, moving forward. 
>      
>
>         I don't think the community has well-established solutions for
>         many problems in this space (e.g. scheduling). However, I
>         think QUIC is a far better platform for experimentation than
>         the alternatives, and would support a draft
>         similar to draft-deconinck-multipath-quic
>         <https://tools.ietf.org/html/draft-deconinck-multipath-quic> that
>         provided the required protocol extensions to make that happen [1].
>
>
>     I agree that scheduling is challenging - 3GPP is certainly
>     spending time defining different strategies for behaviors, even in
>     addition to the ones we described
>     in https://datatracker.ietf.org/doc/draft-bonaventure-quic-atsss-overview/.
>
>     And I agree that the QUIC protocol would be a better platform for
>     experimentation than anything I can think of (other suggestions
>     are, of course, welcome). 
>      
>
>         IIUC the hard, unsolved problems are common to all MP
>         protocols, so I don't think further research and future
>         standards in this area are specific to QUIC or appropriate for
>         the QUIC Working Group. But experimental QUIC extensions would
>         accelerate this work, are appropriate for the WG, and may get
>         us to a place where we could confidently develop standards
>         about it.
>
>
>     Targeting Experimental status for work in this area sounds like a
>     fine plan to me (much better than not thinking about multicast in
>     the IETF for a while longer). 
>
>     I know you have a variety of tools at your disposal to direct this
>     work (MP-TCP was done in its own working group, for both
>     Experimental and Standards-Track versions of the protocol
>     specifications). Do the right thing, of course.  
>
>     What do you and Magnus need from members of the community, to help
>     move forward on this?
>
>     Best,
>
>     Spencer
>      
>
>         Martin Duke
>
>         [1] I would prefer that this draft be Experimental, and have
>         numerous nits about the design that are not relevant to this
>         thread.
>
>
>      
>