Fwd: FW: [Masque] Proposed draft charter

[Lucas Pardue <[e-mail]>]

Hello all,

A while back I present some thoughts on HTTP proxying in an era of QUIC and
HTTP/3 [1]. Since then several of us have been continuing proxy-related
discussion, including broadening scope, in MASQUE[2]. Since some of you may
not follow closely QUIC or MASQUE, please see Mirja's email below about a
draft charter we have prepared

Cheers,
Lucas

[1] -
https://tools.ietf.org/html/draft-pardue-httpbis-http-network-tunnelling-01
[2] - https://mailarchive.ietf.org/arch/browse/masque/


---------- Forwarded message ---------
From: Mirja Kuehlewind <mirja.kuehlewind=[e-mail]>
Date: Fri, Jan 24, 2020 at 11:34 PM
Subject: FW: [Masque] Proposed draft charter
To: [e-mail] <[e-mail]>, tsvwg <[e-mail]>


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