idnits 2.17.1 draft-cms-masque-ip-proxy-reqs-01.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 (7 August 2020) is 1329 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-00 ** Obsolete normative reference: RFC 7540 (ref. 'H2') (Obsoleted by RFC 9113) == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-29 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-29 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Chernyakhovsky 3 Internet-Draft D. McCall 4 Intended status: Informational D. Schinazi 5 Expires: 8 February 2021 Google LLC 6 7 August 2020 8 Requirements for a MASQUE Protocol to Proxy IP Traffic 9 draft-cms-masque-ip-proxy-reqs-01 11 Abstract 13 There is interest among MASQUE working group participants in 14 designing a protocol that can proxy IP traffic over HTTP. This 15 document describes the set of requirements for such a protocol. 17 Discussion of this work is encouraged to happen on the MASQUE IETF 18 mailing list masque@ietf.org or on the GitHub repository which 19 contains the draft: https://github.com/DavidSchinazi/masque-drafts. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 8 February 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Consumer VPN . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Point to Point Connectivity . . . . . . . . . . . . . . . 4 60 2.3. Point to Network Connectivity . . . . . . . . . . . . . . 4 61 2.4. Network to Network Connectivity . . . . . . . . . . . . . 4 62 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. IP Session Establishment . . . . . . . . . . . . . . . . 5 64 3.2. Proxying of IP packets . . . . . . . . . . . . . . . . . 5 65 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 5 66 3.4. IP Assignment . . . . . . . . . . . . . . . . . . . . . . 5 67 3.5. Route Negotiation . . . . . . . . . . . . . . . . . . . . 5 68 3.6. Identity . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.7. Transport Security . . . . . . . . . . . . . . . . . . . 6 70 3.8. Authentication . . . . . . . . . . . . . . . . . . . . . 6 71 3.9. Reliable Transmission of IP Packets . . . . . . . . . . . 6 72 3.10. Flow Control . . . . . . . . . . . . . . . . . . . . . . 6 73 3.11. Indistinguishability . . . . . . . . . . . . . . . . . . 6 74 3.12. Support HTTP/2 and HTTP/3 . . . . . . . . . . . . . . . . 7 75 3.13. Multiplexing . . . . . . . . . . . . . . . . . . . . . . 7 76 3.14. Load balancing . . . . . . . . . . . . . . . . . . . . . 7 77 3.15. Extensibility . . . . . . . . . . . . . . . . . . . . . . 7 78 4. Non-requirements . . . . . . . . . . . . . . . . . . . . . . 7 79 4.1. Addressing Architecture . . . . . . . . . . . . . . . . . 8 80 4.2. Translation . . . . . . . . . . . . . . . . . . . . . . . 8 81 4.3. IP Packet Extraction . . . . . . . . . . . . . . . . . . 8 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 84 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 Normative References . . . . . . . . . . . . . . . . . . . . . 9 87 Informative References . . . . . . . . . . . . . . . . . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 90 1. Introduction 92 There exist several IETF standards for proxying IP in a way that is 93 authenticated and confidential, such as IKEv2/IPsec [IKEV2]. 94 However, those are distinguishable from common Internet traffic and 95 often blocked. Additionally, large server deployments have expressed 96 interest in using a VPN solution that leverages existing security 97 protocols such as QUIC [QUIC] or TLS [TLS] to avoid adding another 98 protocol to their security posture. 100 This document describes the set of requirements for a protocol that 101 can proxy IP traffic over HTTP. The requirements outlined below are 102 similar to the considerations made in designing the CONNECT-UDP 103 method [CONNECT-UDP], additionally including IP-specific 104 requirements, such as a means of negotiating the routes that should 105 be advertised on either end of the connection. 107 Discussion of this work is encouraged to happen on the MASQUE IETF 108 mailing list masque@ietf.org or on the GitHub repository which 109 contains the draft: https://github.com/DavidSchinazi/masque-drafts. 111 1.1. Conventions 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 1.2. Definitions 121 * Data Transport: The method by which IP packets are transmitted. 122 This can involve streams or datagrams. 124 * IP Session: An association between client and server whereby both 125 agree to proxy IP traffic given certain configuration properties. 126 This is similar to a Child Security Association in IKEv2 127 terminology. 129 2. Use Cases 131 There are multiple reasons to deploy an IP proxying protocol. This 132 section discusses some examples of use cases that MUST be supported 133 by the protocol. 135 2.1. Consumer VPN 137 Consumer VPNs refer to network applications that allow a user to hide 138 some properties of their traffic from some network observers. In 139 particular, it can hide the identity of servers the client is 140 connecting to from the client's network provider, and can hide the 141 client's IP address (and derived geographical information) from the 142 servers they are communicating with. Note that this hidden 143 information is now available to the VPN service provider, so is only 144 beneficial for clients who trust the VPN service provider more than 145 other entities. 147 2.2. Point to Point Connectivity 149 Point-to-point connectivity creates a private, encrypted and 150 authenticated network between two IP addresses. This is useful, for 151 example, with container networking to provide a virtual (overlay) 152 network with addressing separate from the physical transport. An 153 example of this is Wireguard. 155 2.3. Point to Network Connectivity 157 Point-to-Network connectivity is the more traditional remote-access 158 "VPN" use case, frequently used when a user needs to connect to a 159 different network (such as an enterprise network) for access to 160 resources that are not exposed to the public Internet. 162 2.4. Network to Network Connectivity 164 Network-to-Network connectivity is also called a site-to-site VPN. 165 Like the point-to-network use case, the goal is to connect to a 166 network that is not exposed publicly. The site-to-site aspects make 167 this transparent to the user; the entire networks are connected to 168 each other and route packets transparently without a VPN client 169 installed on the user's device. This style of connectivity can also 170 be used to connect devices that cannot run VPN clients through to the 171 network. 173 3. Requirements 175 This section lists requirements for a protocol that can proxy IP over 176 an HTTP connection. 178 3.1. IP Session Establishment 180 The protocol will allow the client to request establishment of an IP 181 Session, along with configuration options and one or more associated 182 Data Transports. The server will have the ability to accept or deny 183 the client's request. 185 3.2. Proxying of IP packets 187 The protocol will establish Data Transports, which will be able to 188 forward IP packets, in their unmodified entirety. The protocol will 189 support both IPv6 [IPV6] and IPv4 [IPV4]. 191 3.3. Maximum Transmission Unit 193 The protocol will allow endpoints to inform each other of the Maximum 194 Transmission Unit (MTU) they are willing to forward. This will allow 195 avoiding IP fragmentation, especially as IPv6 does not allow IP 196 fragmentation by nodes along the path. 198 3.4. IP Assignment 200 The client will be able to request to be assigned an IP address 201 range, optionally specifying a preferred range. In response to that 202 request, the server will either assign a range of its choosing to the 203 client, or decline the request. Similarly, to support the network- 204 to-network use case, the server will be able to request assignment of 205 an IP address range from the client, and the client will either 206 assign a range or decline the request. 208 3.5. Route Negotiation 210 At any point in an IP Session (not limited to its initial 211 negotiation), the protocol will allow both client and server to 212 inform its peer that it can route a set of IP prefixes. Both 213 endpoints can also request a route to a given prefix, and the peer 214 can choose to provide that route or not. 216 3.6. Identity 218 When negotiating the creation of an IP Session, the protocol will 219 allow both endpoints to exchange an identifier. For example, both 220 endpoints will be able to identify themselves by sending a fully- 221 qualified domain name. Note that the Identity requirement does not 222 cover authenticating the identifier; that requirement is covered by 223 Section 3.8. 225 3.7. Transport Security 227 The protocol MUST be run over a protocol that provides mutual 228 authentication, confidentiality and integrity. Using QUIC or TLS 229 would meet this requirement. 231 3.8. Authentication 233 Additionally to the authentication provided by the transport, the 234 protocol will have the ability to authenticate both client and server 235 during the establishment of the IP Session. In particular, it will 236 be possible for the client to offer an OAuth Access Token [OAUTH] to 237 the server when requesting IP proxying, potentially through an 238 extension of the protocol. The protocol will also have the ability 239 to support vendor-specific authentication mechanisms as extensions. 241 3.9. Reliable Transmission of IP Packets 243 While it is desirable to transmit IP packets unreliably in most 244 cases, the protocol will provide a mechanism to allow forwarding some 245 packets reliably. For example, when using HTTP/3, this can be 246 accomplished by allowing Data Transports to run over both DATAGRAM 247 and STREAM frames. 249 3.10. Flow Control 251 The protocol will allow the ability to proxy IP packets without flow 252 control, at least when HTTP/3 is in use. QUIC DATAGRAM frames are 253 not flow controlled and would meet this requirement. The document 254 defining the protocol will provide guidance on how best to use flow 255 control to improve IP Session performance. 257 3.11. Indistinguishability 259 A passive network observer not participating in the encrypted 260 connection should not be able to distinguish an IP proxying session 261 from regular encrypted HTTP Web traffic. Specifically, any data sent 262 unencrypted (such as headers, or parts of the handshake) should look 263 like the same unencrypted data that would be present for Web traffic. 264 Traffic analysis is out of scope for this requirement. 266 3.12. Support HTTP/2 and HTTP/3 268 The IP proxying protocol discussed in this document will run over 269 HTTP. The protocol SHOULD strongly prefer to use HTTP/3 [H3] and 270 SHOULD use the QUIC DATAGRAM frames [DGRAM] when available to improve 271 performance. The protocol SHOULD also support HTTP/2 [H2] as a 272 fallback when UDP is blocked on the network path. Proxying IP over 273 HTTP/2 MAY result in lower performance than over HTTP/3. 275 3.13. Multiplexing 277 Since recent HTTP versions support concurrently running multiple 278 requests over the same connection, the protocol SHOULD support 279 multiple independent instances of IP proxying over a given HTTP 280 connection. 282 3.14. Load balancing 284 Clients and servers should each be able to instantiate new Data 285 Transports. This facilitates multi-threaded servers being able to 286 handle a higher bandwidth of IP proxied packets. 288 The IP proxying mechanisms need to support load balancing of the 289 traffic sent across the session, such as to another server. The 290 document defining the new protocol should provide guidance for when 291 additional connections and/or sessions should be opened, as opposed 292 to reusing existing ones. 294 3.15. Extensibility 296 The protocol will provide a mechanism by which clients and servers 297 can add extension information to the exchange that establishes the IP 298 session. If the solution uses an HTTP request and response, this 299 could be accomplished using HTTP headers. 301 Once the session is established, the protocol will provide a 302 mechanism that allows reliably exchanging vendor-specific messages in 303 both directions at any point in the lifetime of the IP Session. 305 4. Non-requirements 307 This section discusses topics that are explicitly out of scope for 308 the IP Proxying protocol. These topics MAY be handled by 309 implementers or future extensions. 311 4.1. Addressing Architecture 313 This document only describes the requirements for a protocol that 314 allows IP proxying. It does not discuss how the IPs assigned are 315 determined, managed, or translated. While these details are 316 important for producing a functional system, they do not need to be 317 handled by the protocol beyond the ability to convey those 318 assignments. 320 4.2. Translation 322 Some servers may wish to perform Network Address Translation (NAT) or 323 any other modification to packets they forward. Doing so is out of 324 scope for the proxying protocol. In particular, the ability to 325 discover the presence of a NAT, negotiate NAT bindings, or check 326 connectivity through a NAT is explicitly out of scope and left to 327 future extensions. 329 Servers that do not perform NAT will commonly forward packets 330 similarly to how a traditionnal IP router would, but the specific of 331 that are considered out of scope. In particular, decrementing the 332 Hop Limit (or TTL) field of the IP header is out of scope for MASQUE 333 and expected to be performed by a router behind the MASQUE server, or 334 collocated with it. 336 4.3. IP Packet Extraction 338 How packets are forwarded between the IP proxying connection and the 339 physical network is out of scope. This is deliberately not specified 340 and will be left to individual implementations. 342 5. Security Considerations 344 This document only discusses requirements on a protocol that allows 345 IP proxying. That protocol will need to document its security 346 considerations. 348 6. IANA Considerations 350 This document requests no actions from IANA. 352 Acknowledgments 354 The authors would like to thank participants of the MASQUE working 355 group for their feedback. 357 References 358 Normative References 360 [DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 361 Datagram Extension to QUIC", Work in Progress, Internet- 362 Draft, draft-ietf-quic-datagram-00, 26 February 2020, 363 . 366 [H2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 367 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 368 DOI 10.17487/RFC7540, May 2015, 369 . 371 [H3] Bishop, M., "Hypertext Transfer Protocol Version 3 372 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 373 quic-http-29, 9 June 2020, . 376 [IPV4] Postel, J., "Internet Protocol", STD 5, RFC 791, 377 DOI 10.17487/RFC0791, September 1981, 378 . 380 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 381 (IPv6) Specification", STD 86, RFC 8200, 382 DOI 10.17487/RFC8200, July 2017, 383 . 385 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 386 and Secure Transport", Work in Progress, Internet-Draft, 387 draft-ietf-quic-transport-29, 9 June 2020, 388 . 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels", BCP 14, RFC 2119, 393 DOI 10.17487/RFC2119, March 1997, 394 . 396 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 397 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 398 May 2017, . 400 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 401 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 402 . 404 Informative References 406 [CONNECT-UDP] 407 Schinazi, D., "The CONNECT-UDP HTTP Method", Work in 408 Progress, Internet-Draft, draft-schinazi-masque-connect- 409 udp-00, 16 April 2020, . 412 [IKEV2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 413 Kivinen, "Internet Key Exchange Protocol Version 2 414 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 415 2014, . 417 [OAUTH] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 418 RFC 6749, DOI 10.17487/RFC6749, October 2012, 419 . 421 Authors' Addresses 423 Alex Chernyakhovsky 424 Google LLC 425 1600 Amphitheatre Parkway 426 Mountain View, California 94043, 427 United States of America 429 Email: achernya@google.com 431 Dallas McCall 432 Google LLC 433 1600 Amphitheatre Parkway 434 Mountain View, California 94043, 435 United States of America 437 Email: dallasmccall@google.com 439 David Schinazi 440 Google LLC 441 1600 Amphitheatre Parkway 442 Mountain View, California 94043, 443 United States of America 445 Email: dschinazi.ietf@gmail.com