Network Working Group D. Schinazi Internet-Draft Google LLC Intended status: Experimental 8 January 2020 Expires: 11 July 2020 The MASQUE Protocol draft-schinazi-masque-02 Abstract This document describes MASQUE (Multiplexed Application Substrate over QUIC Encryption). MASQUE is a framework that allows concurrently running multiple networking applications inside an HTTP/3 connection. For example, MASQUE can allow a QUIC client to negotiate proxying capability with an HTTP/3 server, and subsequently make use of this functionality while concurrently processing HTTP/3 requests and responses. This document is a straw-man proposal. It does not contain enough details to implement the protocol, and is currently intended to spark discussions on the approach it is taking. Discussion of this work is encouraged to happen on the MASQUE IETF mailing list masque@ietf.org (mailto:masque@ietf.org) or on the GitHub repository which contains the draft: https://github.com/DavidSchinazi/masque-drafts (https://github.com/DavidSchinazi/masque-drafts). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 11 July 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Schinazi Expires 11 July 2020 [Page 1] Internet-Draft MASQUE January 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 2. MASQUE Negotiation . . . . . . . . . . . . . . . . . . . . . 3 3. MASQUE Applications . . . . . . . . . . . . . . . . . . . . . 3 3.1. HTTP Proxy . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. DNS over HTTPS . . . . . . . . . . . . . . . . . . . . . 4 3.3. QUIC Proxying . . . . . . . . . . . . . . . . . . . . . . 4 3.4. UDP Proxying . . . . . . . . . . . . . . . . . . . . . . 4 3.5. IP Proxying . . . . . . . . . . . . . . . . . . . . . . . 4 3.6. Service Registration . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 6.2. Informative References . . . . . . . . . . . . . . . . . 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction This document describes MASQUE (Multiplexed Application Substrate over QUIC Encryption). MASQUE is a framework that allows concurrently running multiple networking applications inside an HTTP/3 connection (see [HTTP3]). For example, MASQUE can allow a QUIC client to negotiate proxying capability with an HTTP/3 server, and subsequently make use of this functionality while concurrently processing HTTP/3 requests and responses. MASQUE Negotiation is performed using HTTP mechanisms, but MASQUE applications can subsequently leverage QUIC [QUIC] features without using HTTP. This document is a straw-man proposal. It does not contain enough details to implement the protocol, and is currently intended to spark discussions on the approach it is taking. Discussion of this work is encouraged to happen on the MASQUE IETF mailing list masque@ietf.org (mailto:masque@ietf.org) or on the GitHub repository which contains Schinazi Expires 11 July 2020 [Page 2] Internet-Draft MASQUE January 2020 the draft: https://github.com/DavidSchinazi/masque-drafts (https://github.com/DavidSchinazi/masque-drafts). 1.1. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. MASQUE Negotiation In order to negotiate the use of the MASQUE protocol, the client starts by sending a MASQUE request in the HTTP data of an HTTP POST request to "/.well-known/masque/initial". The client can use this to request specific MASQUE applications and advertise support for MASQUE extensions. The MASQUE server indicates support for MASQUE by sending an HTTP status code 200 response, and can use the data to inform the client of which MASQUE applications are now in use, and various configuration parameters. Both the MASQUE negotiation initial request and its response carry a list of type-length-value fields. The type field is a number corresponding to a MASQUE application, and is encoded as a QUIC variable-length integer. The length field represents the length in bytes of the value field, encoded as a QUIC variable-length integer. The contents of the value field or defined by its corresponding MASQUE application. When parsing, endpoints MUST ignore unknown MASQUE applications. 3. MASQUE Applications As soon as the server has accepted the client's MASQUE initial request, it can advertise support for MASQUE Applications, which will be multiplexed over this HTTP/3 connection. 3.1. HTTP Proxy The client can make proxied HTTP requests through the server to other servers. In practice this will mean using the CONNECT method to establish a stream over which to run TLS to a different remote destination. The proxy applies back-pressure to streams in both directions. Schinazi Expires 11 July 2020 [Page 3] Internet-Draft MASQUE January 2020 3.2. DNS over HTTPS The client can send DNS queries using DNS over HTTPS [DOH] to the MASQUE server. 3.3. QUIC Proxying By leveraging QUIC client connection IDs, a MASQUE server can act as a QUIC proxy while only using one UDP port. The server informs the client of a scheme for client connection IDs (for example, random of a minimum length or vended by the MASQUE server) and then the server can forward those packets to further web servers. This mechanism can elide the connection IDs on the link between the client and MASQUE server by negotiating a mapping between DATAGRAM_IDs and the tuple (client connection ID, server connection ID, server IP address, server port). Compared to UDP proxying, this mode has the advantage of only requiring one UDP port to be open on the MASQUE server, and can lower the overhead on the link between client and MASQUE server by compressing connection IDs. 3.4. UDP Proxying In order to support WebRTC or QUIC to further servers, clients need a way to relay UDP onwards to a remote server. In practice for most widely deployed protocols other than DNS, this involves many datagrams over the same ports. Therefore this mechanism implements that efficiently: clients can use the MASQUE protocol stream to request an UDP association to an IP address and UDP port pair. In QUIC, the server would reply with a DATAGRAM_ID that the client can then use to have UDP datagrams sent to this remote server. Datagrams are then simply transferred between the DATAGRAMs with this ID and the outer server. There will also be a message on the MASQUE protocol stream to request shutdown of a UDP association to save resources when it is no longer needed. 3.5. IP Proxying For the rare cases where the previous mechanisms are not sufficient, proxying can be performed at the IP layer. This would use a different DATAGRAM_ID and IP datagrams would be encoded inside it without framing. Schinazi Expires 11 July 2020 [Page 4] Internet-Draft MASQUE January 2020 3.6. Service Registration MASQUE can be used to make a home server accessible on the wide area. The home server authenticates to the MASQUE server and registers a domain name it wishes to serve. The MASQUE server can then forward any traffic it receives for that domain name (by inspecting the TLS Server Name Indication (SNI) extension) to the home server. This received traffic is not authenticated and it allows non-modified clients to communicate with the home server without knowing it is not colocated with the MASQUE server. To help obfuscate the home server, deployments can use Encrypted Server Name Indication [ESNI]. That will require the MASQUE server sending the cleartext SNI to the home server. 4. Security Considerations Here be dragons. TODO: slay the dragons. 5. IANA Considerations This document will request IANA to register the "/.well-known/ masque/" URI (expert review) https://www.iana.org/assignments/well- known-uris/well-known-uris.xhtml (https://www.iana.org/assignments/ well-known-uris/well-known-uris.xhtml). This document will request IANA to create a new MASQUE Applications registry which governs a 62-bit space of MASQUE application types. 6. References 6.1. Normative References [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- quic-http-24, 4 November 2019, . [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", Work in Progress, Internet-Draft, draft-ietf-quic-transport-24, 3 November 2019, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Schinazi Expires 11 July 2020 [Page 5] Internet-Draft MASQUE January 2020 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . 6.2. Informative References [ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "Encrypted Server Name Indication for TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-esni-05, 4 November 2019, . Acknowledgments This proposal was inspired directly or indirectly by prior work from many people. The author would like to thank Nick Harper, Christian Huitema, Marcus Ihlar, Eric Kinnear, Mirja Kuehlewind, Brendan Moran, Lucas Pardue, Tommy Pauly, Zaheduzzaman Sarker, Ben Schwartz, and Christopher A. Wood for their input. Author's Address David Schinazi Google LLC 1600 Amphitheatre Parkway Mountain View, California 94043, United States of America Email: dschinazi.ietf@gmail.com Schinazi Expires 11 July 2020 [Page 6]