Re: [Masque] Updated proposed charter text

[Eric Rescorla <[e-mail]>]

On Mon, Apr 6, 2020 at 8:43 AM Mirja Kuehlewind <mirja.kuehlewind=
[e-mail]> wrote:

> Hi Chris,
>
> In draft-schinazi-masque-protocol I would say that the QUIC, UDP, and IP
> proxying services run directly on top of QUIC without any HTTP in between
> (HTTP is only used only for the negotiation part but not for the
> forwarding/multiplexing).


Philosophy aside, do we agree that these messages would be carried in QUIC
Datagram frames (https://tools.ietf.org/html/draft-ietf-quic-datagram-00)?


Therefore I think it would be more correct to actually change this one
> occurrence of HTTP3 back to  QUIC in the following sentence:
>
> "The primary goal of this working group is to develop mechanisms that
> allow configuring and concurrently running multiple proxied stream- and
> datagram-based flows inside a HTTP/3 connection"
>

I'm not sure that this is right. If you use the H3 ALPN token and then use
H3 to negotiate but also negotiate datagram, this seems like an H3
connection to me.

-Ekr


Mirja
>
>
>
>
>
> On 06.04.20, 15:43, "Masque on behalf of Christopher Wood" <
> [e-mail] on behalf of [e-mail]> wrote:
>
>     Hi Marcus,
>
>     For what it's worth, this change reflects the mechanism currently
> proposed in [1]. This seemed to have some measure of rough consensus based
> on comments we (chairs) heard before, during, and after the meeting. There
> are of course pros and cons with this change, e.g., it can re-use existing
> machinery (pro!), but that machinery might not always exist or can be too
> complex (con!).
>
>     Best,
>     Chris
>
>     [1] https://tools.ietf.org/html/draft-schinazi-masque-protocol-01
>
>     On Fri, Apr 3, 2020, at 6:06 AM, Marcus Ihlar wrote:
>     > Hi,
>     > The previous charter proposal, shown in the BoF slides, refers to
> using
>     > QUIC as a candidate protocol for proxying traffic.
>     > In the text you propose below, all mentions of QUIC are replaced
> with
>     > HTTP/3.
>     > I'm afraid that specifying that HTTP/3 should serve as the substrate
>     > for the proxied traffic at this point will limit the possible
> solutions
>     > the working group can consider. Using the word QUIC instead of
> HTTP/3
>     > in the charter text would allow the wg to consider a broader
> solution
>     > space, including something based on HTTP/3.
>     >
>     > Marcus
>     >
>     > -----Original Message-----
>     > From: Masque <[e-mail]> On Behalf Of Christopher Wood
>     > Sent: den 31 mars 2020 18:43
>     > To: [e-mail]
>     > Subject: [Masque] Updated proposed charter text
>     >
>     > Based on last week's meeting, it seems folks are generally
> enthusiastic
>     > about some form of MASQUE moving forward. To help scope that
> particular
>     > form, here's an update to the proposed charter.
>     >
>     > ~~~
>     > Many network topologies lead to situations where transport protocol
>     > proxying is beneficial. For example, proxying enables endpoints to
>     > communicate when end-to-end connectivity is not possible and can
> apply
>     > additional encryption where desirable (such as a VPN). Proxying can
>     > also improve client privacy, e.g., by hiding a client's IP address
> from
>     > a target server.
>     >
>     > Proxying technologies such as SOCKS and HTTP(S) CONNECT exist,
> albeit
>     > with their own shortcomings. For example, SOCKS signalling is not
>     > encrypted and HTTP CONNECT is currently limited to TCP. In contrast,
>     > HTTP/3 is a viable candidate protocol for proxying arbitrary
> traffic,
>     > as it provides secure connectivity, multiplexed streams, and
> migration
>     > for a single connection while taking advantage of a unified
> congestion
>     > controller. HTTP/3 datagrams provide for unreliable data
> transmission,
>     > which enables transporting UDP and other unreliable flows via a
> proxy
>     > without introducing potentially redundant or unnecessary recovery
>     > mechanisms. Further, HTTP/3 supports an established request/response
>     > semantic that can set up and configure flows for different services.
>     >
>     > The primary goal of this working group is to develop mechanisms that
>     > allow configuring and concurrently running multiple proxied stream-
> and
>     > datagram-based flows inside a HTTP/3 connection. The group will
> specify
>     > an HTTP-based signaling protocol for creating and configuring each
>     > service flow. The group will first focus on a limited set of
>     > client-initiated services such as IP, UDP, and TCP proxying.
> Specifying
>     > proxy server discovery mechanisms is out of scope for the group.
>     > However, the group may specify techniques for identifying proxy
> servers
>     > to aid future discovery mechanisms.
>     >
>     > The group will coordinate closely with other working groups
> responsible
>     > for maintaining relevant protocol extensions, such as HTTPBIS, QUIC,
> or
>     > TLS.
>     > ~~~
>     >
>     > This should address most of the issues raised during the meeting
> [1].
>     > We'd like to hear what people think about this as a viable path
> forward.
>     >
>     > Thanks,
>     > Chris, on behalf of the chairs
>     >
>     > [1] These issues include, though are not limited to:
>     >
>     > 1. Whether or not this is a new protocol or an extension of an
> existing
>     > protocol must be clear before moving forward.
>     > 2. Motivation for proxy technologies requires improvement. In
>     > particular, there’s no mention of privacy objectives.
>     > 3. The proxy threat model is unclear or underspecified. Does it
> model
>     > Tor’s threat model, or is it something simpler? (Meta question:
> should
>     > this be part of an existing document?) 4. Why are services beyond
>     > simple “CONNECT for UDP or IP” in scope? Should we focus on the
> simple
>     > datagram proxy case first and carve out room for extensibility?
>     > 5. To what extent is discovery out of scope?
>     > 6. Framework is perhaps not the best word to describe MASQUE.
>     >
>     > Any errors or omissions from this list are entirely my fault!
>     >
>     > --
>     > Masque mailing list
>     > [e-mail]
>     > https://www.ietf.org/mailman/listinfo/masque
>     > --
>     > Masque mailing list
>     > [e-mail]
>     > https://www.ietf.org/mailman/listinfo/masque
>     >
>
>     --
>     Masque mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/masque
>
>
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>