idnits 2.17.1 draft-schinazi-masque-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 January 2020) is 1541 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-24 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-24 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Schinazi 3 Internet-Draft Google LLC 4 Intended status: Experimental 8 January 2020 5 Expires: 11 July 2020 7 The MASQUE Protocol 8 draft-schinazi-masque-02 10 Abstract 12 This document describes MASQUE (Multiplexed Application Substrate 13 over QUIC Encryption). MASQUE is a framework that allows 14 concurrently running multiple networking applications inside an 15 HTTP/3 connection. For example, MASQUE can allow a QUIC client to 16 negotiate proxying capability with an HTTP/3 server, and subsequently 17 make use of this functionality while concurrently processing HTTP/3 18 requests and responses. 20 This document is a straw-man proposal. It does not contain enough 21 details to implement the protocol, and is currently intended to spark 22 discussions on the approach it is taking. Discussion of this work is 23 encouraged to happen on the MASQUE IETF mailing list masque@ietf.org 24 (mailto:masque@ietf.org) or on the GitHub repository which contains 25 the draft: https://github.com/DavidSchinazi/masque-drafts 26 (https://github.com/DavidSchinazi/masque-drafts). 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 11 July 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 63 2. MASQUE Negotiation . . . . . . . . . . . . . . . . . . . . . 3 64 3. MASQUE Applications . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. HTTP Proxy . . . . . . . . . . . . . . . . . . . . . . . 3 66 3.2. DNS over HTTPS . . . . . . . . . . . . . . . . . . . . . 4 67 3.3. QUIC Proxying . . . . . . . . . . . . . . . . . . . . . . 4 68 3.4. UDP Proxying . . . . . . . . . . . . . . . . . . . . . . 4 69 3.5. IP Proxying . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.6. Service Registration . . . . . . . . . . . . . . . . . . 5 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 75 6.2. Informative References . . . . . . . . . . . . . . . . . 6 76 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 79 1. Introduction 81 This document describes MASQUE (Multiplexed Application Substrate 82 over QUIC Encryption). MASQUE is a framework that allows 83 concurrently running multiple networking applications inside an 84 HTTP/3 connection (see [HTTP3]). For example, MASQUE can allow a 85 QUIC client to negotiate proxying capability with an HTTP/3 server, 86 and subsequently make use of this functionality while concurrently 87 processing HTTP/3 requests and responses. 89 MASQUE Negotiation is performed using HTTP mechanisms, but MASQUE 90 applications can subsequently leverage QUIC [QUIC] features without 91 using HTTP. 93 This document is a straw-man proposal. It does not contain enough 94 details to implement the protocol, and is currently intended to spark 95 discussions on the approach it is taking. Discussion of this work is 96 encouraged to happen on the MASQUE IETF mailing list masque@ietf.org 97 (mailto:masque@ietf.org) or on the GitHub repository which contains 98 the draft: https://github.com/DavidSchinazi/masque-drafts 99 (https://github.com/DavidSchinazi/masque-drafts). 101 1.1. Conventions and Definitions 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 2. MASQUE Negotiation 111 In order to negotiate the use of the MASQUE protocol, the client 112 starts by sending a MASQUE request in the HTTP data of an HTTP POST 113 request to "/.well-known/masque/initial". The client can use this to 114 request specific MASQUE applications and advertise support for MASQUE 115 extensions. The MASQUE server indicates support for MASQUE by 116 sending an HTTP status code 200 response, and can use the data to 117 inform the client of which MASQUE applications are now in use, and 118 various configuration parameters. 120 Both the MASQUE negotiation initial request and its response carry a 121 list of type-length-value fields. The type field is a number 122 corresponding to a MASQUE application, and is encoded as a QUIC 123 variable-length integer. The length field represents the length in 124 bytes of the value field, encoded as a QUIC variable-length integer. 125 The contents of the value field or defined by its corresponding 126 MASQUE application. When parsing, endpoints MUST ignore unknown 127 MASQUE applications. 129 3. MASQUE Applications 131 As soon as the server has accepted the client's MASQUE initial 132 request, it can advertise support for MASQUE Applications, which will 133 be multiplexed over this HTTP/3 connection. 135 3.1. HTTP Proxy 137 The client can make proxied HTTP requests through the server to other 138 servers. In practice this will mean using the CONNECT method to 139 establish a stream over which to run TLS to a different remote 140 destination. The proxy applies back-pressure to streams in both 141 directions. 143 3.2. DNS over HTTPS 145 The client can send DNS queries using DNS over HTTPS [DOH] to the 146 MASQUE server. 148 3.3. QUIC Proxying 150 By leveraging QUIC client connection IDs, a MASQUE server can act as 151 a QUIC proxy while only using one UDP port. The server informs the 152 client of a scheme for client connection IDs (for example, random of 153 a minimum length or vended by the MASQUE server) and then the server 154 can forward those packets to further web servers. 156 This mechanism can elide the connection IDs on the link between the 157 client and MASQUE server by negotiating a mapping between 158 DATAGRAM_IDs and the tuple (client connection ID, server connection 159 ID, server IP address, server port). 161 Compared to UDP proxying, this mode has the advantage of only 162 requiring one UDP port to be open on the MASQUE server, and can lower 163 the overhead on the link between client and MASQUE server by 164 compressing connection IDs. 166 3.4. UDP Proxying 168 In order to support WebRTC or QUIC to further servers, clients need a 169 way to relay UDP onwards to a remote server. In practice for most 170 widely deployed protocols other than DNS, this involves many 171 datagrams over the same ports. Therefore this mechanism implements 172 that efficiently: clients can use the MASQUE protocol stream to 173 request an UDP association to an IP address and UDP port pair. In 174 QUIC, the server would reply with a DATAGRAM_ID that the client can 175 then use to have UDP datagrams sent to this remote server. Datagrams 176 are then simply transferred between the DATAGRAMs with this ID and 177 the outer server. There will also be a message on the MASQUE 178 protocol stream to request shutdown of a UDP association to save 179 resources when it is no longer needed. 181 3.5. IP Proxying 183 For the rare cases where the previous mechanisms are not sufficient, 184 proxying can be performed at the IP layer. This would use a 185 different DATAGRAM_ID and IP datagrams would be encoded inside it 186 without framing. 188 3.6. Service Registration 190 MASQUE can be used to make a home server accessible on the wide area. 191 The home server authenticates to the MASQUE server and registers a 192 domain name it wishes to serve. The MASQUE server can then forward 193 any traffic it receives for that domain name (by inspecting the TLS 194 Server Name Indication (SNI) extension) to the home server. This 195 received traffic is not authenticated and it allows non-modified 196 clients to communicate with the home server without knowing it is not 197 colocated with the MASQUE server. 199 To help obfuscate the home server, deployments can use Encrypted 200 Server Name Indication [ESNI]. That will require the MASQUE server 201 sending the cleartext SNI to the home server. 203 4. Security Considerations 205 Here be dragons. TODO: slay the dragons. 207 5. IANA Considerations 209 This document will request IANA to register the "/.well-known/ 210 masque/" URI (expert review) https://www.iana.org/assignments/well- 211 known-uris/well-known-uris.xhtml (https://www.iana.org/assignments/ 212 well-known-uris/well-known-uris.xhtml). 214 This document will request IANA to create a new MASQUE Applications 215 registry which governs a 62-bit space of MASQUE application types. 217 6. References 219 6.1. Normative References 221 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 222 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 223 quic-http-24, 4 November 2019, . 226 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 227 and Secure Transport", Work in Progress, Internet-Draft, 228 draft-ietf-quic-transport-24, 3 November 2019, 229 . 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, 234 DOI 10.17487/RFC2119, March 1997, 235 . 237 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 238 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 239 May 2017, . 241 [DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 242 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 243 . 245 6.2. Informative References 247 [ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 248 "Encrypted Server Name Indication for TLS 1.3", Work in 249 Progress, Internet-Draft, draft-ietf-tls-esni-05, 4 250 November 2019, . 253 Acknowledgments 255 This proposal was inspired directly or indirectly by prior work from 256 many people. The author would like to thank Nick Harper, Christian 257 Huitema, Marcus Ihlar, Eric Kinnear, Mirja Kuehlewind, Brendan Moran, 258 Lucas Pardue, Tommy Pauly, Zaheduzzaman Sarker, Ben Schwartz, and 259 Christopher A. Wood for their input. 261 Author's Address 263 David Schinazi 264 Google LLC 265 1600 Amphitheatre Parkway 266 Mountain View, California 94043, 267 United States of America 269 Email: dschinazi.ietf@gmail.com