Re: FW: [Masque] Proposed draft charter

[Ian Swett <[e-mail]>]

Some Q's.  This charter looks to be scoped such that it includes any
VPN/tunnel that goes over the QUIC transport, not just when HTTP/3 is
used.  However, it's only scoped to work on use cases when multiple
applications want to run over a single QUIC connection?

Two thoughts:
1) This seems to put a simple tunnel over QUIC functionality out of scope?
I've heard a fair bit of interest in this and I'm not aware of any other
group working on it.
2) Some people suggested that multiplexing multiple applications over a
single QUIC connection should be in scope for QUIC v2.  This charter seems
like it's moving that work out of the QUIC WG?

Thanks, Ian

On Fri, Jan 24, 2020 at 6:34 PM Mirja Kuehlewind <mirja.kuehlewind=
[e-mail]> wrote:

> Hi all,
>
> For your information, we've just sent a proposed draft charter text for
> MASQUE to the respective mailing list. If you are interested in this work
> and would like to comment, please use the MASQUE list. Feedback and
> community input is very welcome!
>
> Mirja
>
>
>
> On 25.01.20, 00:29, "Masque on behalf of Mirja Kuehlewind" <
> [e-mail] on behalf of mirja.kuehlewind=
> [e-mail]> wrote:
>
>     Hi everybody,
>
>     as already indicated by David in his last mail, some of us worked on a
> proposed draft charter for a new group. Please find the text below and
> provide comments!
>
>     Thanks!
>     Mirja
>
>     ---------------------------------
>     MASQUE draft charter text
>
>
>     Many network topologies lead to situations where transport protocol
> proxying is beneficial. For example: helping endpoints to communicate when
> end-to-end connectivity is not possible, applying additional encryption
> where desirable (such as a VPN), or accommodating differences in network
> segment characteristics (e.g. long paths such as satellite, or high-loss
> links). Many existing proxy solutions deployed today rely on transparent
> intermediation. However, an increasing amount of traffic is using QUIC, and
> QUIC's improved security model prevents transparent proxies. In order to
> allow transport protocol proxying when QUIC is in use, we will need a
> mechanism where at least one of the QUIC endpoints actively collaborates
> with the proxy. QUIC is a good candidate protocols for tunneling or
> forwarding this kind of traffic, as QUIC provides secure connection
> establishment, multiplexed streams, and connection migration. Further, use
> of HTTP/3 on top of QUIC enables HTTP-level proxying and caching.
>
>     This working group will work on MASQUE (Multiplexed Application
> Substrate over QUIC Encryption) - a framework that allows concurrently
> running multiple networking applications inside a QUIC connection. The
> MASQUE framework will specify the actions and processes for establishing
> tunneled proxy connectivity as well as a signaling protocol that is used
> between the endpoint(s) and the MASQUE server to negotiate and request
> proxy service capabilities and parameters, and realize services that
> require communication between endpoints and proxies. A proxy may provide
> simple forwarding with optional address translation only, or more advanced
> services like name resolution, multipath support, or assistance for
> congestion control on link segments with challenging characteristics, such
> as high loss or strongly varying delays.
>
>     As use-cases for deploying MASQUE have different security or
> performance requirements, the working group may define multiple MASQUE
> services for proxying to suit these disparate use-cases. In particular,
> some deployments may want to avoid double-encryption to reduce
> computational costs if the inner connection as well as the outer QUIC
> tunnel connection use encryption, while others might prefer to keep the
> double-encryption of user data to sure strong privacy guarantees. Such
> options will need to produce documentation of the resulting security and
> privacy properties.
>
>     Alongside the definition of the MASQUE framework, the group will
> further work on discovery mechanisms for MASQUE servers and which MASQUE
> services they support, taking into account deployment across network
> segments with different operability and end-user relationship
> characteristics.
>
>     Proxy services that extend the signaling of the base MASQUE protocol
> can be adopted by the group by creating a new milestone with AD review.
>
>     If MASQUE requires any extensions to existing protocols, the group
> will coordinate closely with the respective group responsible for
> maintaining that protocol, such as the HTTPBIS, QUIC, or TLS working groups.
>
>     Milestones
>
>     July 2021 MASQUE framework and base protocol to be submitted to the
> IESG for publication as PS
>     Nov 2021 Discovery mechanism for MASQUE servers to be submitted to the
> IESG for publication as PS
>     Nov 2021 [Example WG Item] Use Case specific extension to the MASQUE
> protocol be submitted to the IESG for publication as EXP or PS
>
>
>
>
>     --
>     Masque mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/masque
>
>
>