Subject: Draft response to Liaison Statement, "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group"

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Sep 2020 10:12:28 +0300

Hi,

FYI, below is a draft of our intended response to the Liaison Statement "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group" which we intend to send next week.

Please feel free to send comments.

Thanks,
Lars, Lucas and Mark

--

Thank you for the update on your progress and your questions. Please find our
responses below.

On Qn-1: The future of multipath support for QUIC is currently under active
discussion in the IETF QUIC working group. While it was part of the original
charter due to its inclusion in the pre-IETF "Google QUIC" protocol, several
participants have argued during the last year that QUIC's connection migration
support is sufficient for the majority of our use cases, and that full-blown
support for multipath QUIC should consequently be abandoned as a WG deliverable.
Other WG participants remain of the opinion that multipath support for QUIC is
very important. Due to this active ongoing discussion, we do not have an estimate
at this time whether WG drafts for multipath QUIC will be available in 1Q2021.

On Qn-2: The QUIC WG is chartered to provide an encrypted transport protocol.
An option to disable encryption will hence not be standardized.

Kind regards,
Mark Nottingham, Lucas Pardue and Lars Eggert, QUIC Working Group chairs

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 30 Sep 2020 08:41:10 +0000

Hi Lars,

So I think your comment about discussion of abandoning Multi-path may have come
as a surprise to some people. Where has that discussion occurred? 

It wasn't on this mailing list what I can find. It doesn't like like an
exstensive discussion on the QUICDEV slack either, I did find 10 messages in
total. And that is not official WG resource either. I did find one github issue
that have some discussion. But larger issues like this really should be brought
to the WG mailing list. 

So I think before you do send a LS reply lets conclude on the now started
discussion here on the mailing list. 

Cheers

Magnus Westerlund

On Wed, 2020-09-30 at 10:12 +0300, Lars Eggert wrote:
> Hi,
> 
> FYI, below is a draft of our intended response to the Liaison Statement "LS on
> ATSSS Phase 2 Requirements to IETF QUIC Working Group" which we intend to send
> next week.
> 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Mobile +46 73 0949079
Torshamnsgatan 23           |
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Sep 2020 11:48:20 +0300

Hi,

> as a surprise to some people. Where has that discussion occurred?

it was in the context of the rechartering discussion last December. Matt linked to this message from Jana (https://mailarchive.ietf.org/arch/msg/quic/R-uJhzzXBz-93OTmYupXu8ooJdA/) which seems to summarize the standpoint of the group that is questioning support for multipath in QUIC. I think there were other related messages in that thread.

Thanks,
Lars

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 30 Sep 2020 11:23:45 +0200

Lars, Lucas and Mark,
> Please feel free to send comments.

I'm very surprised by this sentence. It gives the impression that 
multipath was a feature of Google's proprietary QUIC protocol. My 
understanding based on the public documents that Google released and the 
source code is that multipath was considered by Google as they reserved 
one bit in the header to indicate multipath but that this was not fully 
implemented nor tested within Google QUIC. If Google had a specification 
of multipath QUIC, I'd be very interested in seeing this document.

My understanding of the initial charter discussion was that multipath 
was a desired feature by many of the participants in the initial charter.

> Mark Nottingham, Lucas Pardue and Lars Eggert, QUIC Working Group chairs

Best regards,

Olivier

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Wed, 30 Sep 2020 11:27:42 +0000

Hello Lars

It seems to me that the response to Qn-2 is a too categorial. Also the question Qn-2 in LS is not well formulated either. What they really ask is about avoidance of avoid multiple encryption layers that occur in QUIC in QUIC tunneling. The motivation for their question is also mentioned in the ATSSS-draft. And maybe the question should be answered by MASQUE WG instead.

Best regards
Hannu

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Lars Eggert
Sent: Wednesday, September 30, 2020 10:12 AM
To: QUIC WG <[email-masked]>
Subject: Draft response to Liaison Statement, "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group" 

Hi,

Thanks,
Lars, Lucas and Mark

--

Thank you for the update on your progress and your questions. Please find our responses below.

On Qn-1: The future of multipath support for QUIC is currently under active discussion in the IETF QUIC working group. While it was part of the original charter due to its inclusion in the pre-IETF "Google QUIC" protocol, several participants have argued during the last year that QUIC's connection migration support is sufficient for the majority of our use cases, and that full-blown support for multipath QUIC should consequently be abandoned as a WG deliverable.
Other WG participants remain of the opinion that multipath support for QUIC is very important. Due to this active ongoing discussion, we do not have an estimate at this time whether WG drafts for multipath QUIC will be available in 1Q2021.

Kind regards,

---

From: Lars Eggert <[email-masked]>
Date: Wed, 30 Sep 2020 14:43:19 +0300

Hi,

On 2020-9-30, at 14:27, Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]> wrote:
> It seems to me that the response to Qn-2 is a too categorial.

how so? An unencrypted QUIC variant is obviously out-of-charter.

> Also the question Qn-2 in LS is not well formulated either. What they really ask is about avoidance of avoid multiple encryption layers that occur in QUIC in QUIC tunneling. The motivation for their question is also mentioned in the ATSSS-draft. And maybe the question should be answered by MASQUE WG instead.

Well, they asked us, so we are answering. And even when QUIC is tunneled in QUIC, we are not chartered to standardize a method to disable encryption for one of those QUICs.

Thanks,
Lars

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 30 Sep 2020 08:40:16 -0500

Dear Magnus/QUIC and Martin/MASQUE,

> [email-masked]> wrote:

...

>
>
> Also the question Qn-2 in LS is not well formulated either. What they
> really ask is about avoidance of avoid multiple encryption layers that
> occur in QUIC in QUIC tunneling. The motivation for their question is also
> mentioned in the ATSSS-draft. And *maybe the question should be answered
> by MASQUE WG instead*.
>
> * Well, they asked us, so we are answering. *And even when QUIC is
> tunneled in QUIC, we are not chartered to standardize a method to disable
> encryption for one of those QUICs.
>

Hannu and Lars are both right. Is there a better way for the IETF to react
to a question that would have gone to QUIC before MASQUE was chartered, but
would now be better addressed to MASQUE?

We can send a liaison from QUIC to 3GPP, and 3GPP can send back the same
question in a liaison to MASQUE in a month or two, but we're an engineering
SDO and that seems like bad engineering :-)

In the IETF 108 minutes for MASQUE at
https://datatracker.ietf.org/doc/minutes-108-masque/, I see this (with no
edits on my part)

## QUIC Proxying
*Tommy Pauly*

[Slides](
https://www.ietf.org/proceedings/108/slides/slides-108-masque-optimizing-proxies-for-quic-00
)

Tommy Pauly: No draft yet on this, but we're working on it

Tommy Pauly: This is particularly interesting for multi-hop forward proxying
like Tor.

Tommy Pauly: "CONNECT-QUIC" is a placeholder here, separate from the
question
of whether to use one method or many.

Tommy Pauly: The new mode here is "forwarding" instead of "tunneling".

Martin Thomson: From what I've seen on the slides, I have serious
reservations
as to whether this is going to achieve the goals you've set.  What are those
goals?

*Tommy Pauly: The goal is to allow multiple proxy hops for QUIC without*
*encapsulation and encryption overhead for each hops.  We don't have to
keep*
*adding DATAGRAM frames and reducing MTU and adding encryptions.*

Martin Thomson: That's a reasonable goal, but I don't think this is going to
work for a proxy that has to manage multiple connections.  Did you say that
the
client sets the connection IDs that the proxy expects to use?

Tommy Pauly: Whenever the client becomes aware of a connection ID, it
informs
the proxy and requires a confirmation before it will start using that
connection ID.

Eric Rescorla: I understand the performance objective, but I don't think I
understand the security objective.  You said "tor-like", but Tor has some
extremely specific properties and I don't understand how this prevent
private
collusion.

Tommy Pauly: It won't have the same security properties as a Tor-like thing,
especially because you may see the same content going through on both sides
of
the proxy.  You won't  see more than if you were on path already.  The goal
is
to get IP address obfuscation but we're not necessarily concerned about
reconstructing the path if you can see all the links.

Eric Rescorla: I think this needs a clearer threat model.

Tommy Pauly: We're just trying to point out that this mode exists, and
could be
used when it's appropriate.

Eric Rescorla: I'm trying to figure out whether this has interesting
security
properties.

Tommy Pauly: Connection ID mapping is especially difficult when multiplexing
connections onto a single client-proxy 5-tuple.  Beyond collusion
protection,
we also need to make sure that you're not vulnerable to forwarding replayed
packets.

Ben Schwartz: This is not so similar to CONNECT-UDP or old-fashioned
CONNECT,
because it breaks out of the TLS stream.  Recommend focusing on a non-HTTP
proxy substrate like SOCKS-6.

---

From: Ian Swett <[email-masked]>
Date: Wed, 30 Sep 2020 10:49:05 -0400

On Wed, Sep 30, 2020 at 5:24 AM Olivier Bonaventure <
[email-masked]> wrote:

> Lars, Lucas and Mark,
> >
> > FYI, below is a draft of our intended response to the Liaison Statement
> "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group" which we
> intend to send next week.
> >

There was a design and part of an implementation, but it was never
completed because there were no customers for it and it added substantial
complexity.

IETF QUIC has changed quite a bit from Google QUIC, so I think basing any
design on the more recent multipath proposal(
draft-deconinck-quic-multipath-05
<https://tools.ietf.org/html/draft-deconinck-quic-multipath-05>) would be a
better starting point.

---

From: David Schinazi <[email-masked]>
Date: Wed, 30 Sep 2020 09:21:33 -0700

To add to what Ian said, I really think that the following
statement from the draft reply is an overstatement:
<<[multipath support for QUIC] was part of the original
charter due to its inclusion in the pre-IETF
"Google QUIC" protocol>>. As Ian said, the team was
considering it but it never made it into the protocol.
Perhaps you could rephrase it to something like:
<<[multipath support for QUIC] was part of the original
charter because it was of interest to authors of the
pre-IETF "Google QUIC" protocol>>?

Other than that, the reply looks good to me, I think
figuring out whether to do multipath in the WG, and
refusing to remove encryption are the right calls.

David

On Wed, Sep 30, 2020 at 7:49 AM Ian Swett <ianswett=
[email-masked]> wrote:

> <https://tools.ietf.org/html/draft-deconinck-quic-multipath-05>) would be
> a better starting point.
>
>>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 30 Sep 2020 10:30:02 -0700

Has it been considered to add a tunnel prefix header, or more generally a
virtual path header to QUIC? That would avoid nested QUIC connections with
dual loss control etc. in favor or a simpler virtual routing context that
might re-encrypt just the actual QUIC header along the virtual path. This
side steps the issue of having an unencrypted inner or outer QUIC
connection. Generally allowing unencrypted QUIC is probably a can of Worms,
especially wrt. big firewalls.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 30 September 2020 at 18.22.19, David Schinazi ([email-masked])
wrote:

David

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 01 Oct 2020 07:35:22 +1000

Wasn't it of interest to the working group? I mean, a Google's interest is relevant, but only to the extent that it contributed to the overall interest in the feature.

On Thu, Oct 1, 2020, at 02:21, David Schinazi wrote:
> On Wed, Sep 30, 2020 at 7:49 AM Ian Swett 
> <ianswett=[email-masked]> wrote:
> > 
> > 
> > On Wed, Sep 30, 2020 at 5:24 AM Olivier Bonaventure <[email-masked]> wrote:
> >> Lars, Lucas and Mark,
> >> > 
> > There was a design and part of an implementation, but it was never completed because there were no customers for it and it added substantial complexity.
> > 
> > IETF QUIC has changed quite a bit from Google QUIC, so I think basing any design on the more recent multipath proposal(draft-deconinck-quic-multipath-05 <https://tools.ietf.org/html/draft-deconinck-quic-multipath-05>) would be a better starting point.
> >>

---

From: David Schinazi <[email-masked]>
Date: Wed, 30 Sep 2020 15:08:32 -0700

On Wed, Sep 30, 2020 at 2:35 PM Martin Thomson <[email-masked]> wrote:

> Wasn't it of interest to the working group? I mean, a Google's interest is
> relevant, but only to the extent that it contributed to the overall
> interest in the feature.
>

Sure! I was just objecting to the existing text that overstated
Google's involvement in multipath. Saying that there was
WG interest sounds fine by me.

David

On Thu, Oct 1, 2020, at 02:21, David Schinazi wrote:
> > >> > FYI, below is a draft of our intended response to the Liaison
> Statement "LS on ATSSS Phase 2 Requirements to IETF QUIC Working Group"
> which we intend to send next week.
> > >> >
> > > IETF QUIC has changed quite a bit from Google QUIC, so I think basing
> any design on the more recent multipath
> proposal(draft-deconinck-quic-multipath-05 <
> https://tools.ietf.org/html/draft-deconinck-quic-multipath-05>) would be
> a better starting point.
> > >>