- From: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Date: Sun, 26 Jan 2020 19:46:46 +0000
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Mirja Kuehlewind <ietf@kuehlewind.net>
- Message-ID: <CALGR9obTZD_JGFM3xbw6HDxr_4G8M2RoS0xR_pkQy9OTs9cWzw@mail.gmail.com>
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=40ericsson.com@dmarc.ietf.org> Date: Fri, Jan 24, 2020 at 11:34 PM Subject: FW: [Masque] Proposed draft charter To: quic@ietf.org <quic@ietf.org>, tsvwg <tsvwg-bounces@ietf.org> 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" < masque-bounces@ietf.org on behalf of mirja.kuehlewind= 40ericsson.com@dmarc.ietf.org> 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 Masque@ietf.org https://www.ietf.org/mailman/listinfo/masque
Received on Sunday, 26 January 2020 19:47:06 UTC