idnits 2.17.1 draft-ietf-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 (8 January 2021) is 1204 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-01 ** Obsolete normative reference: RFC 7540 (ref. 'H2') (Obsoleted by RFC 9113) == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-33 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-33 == Outdated reference: A later version (-15) exists of draft-ietf-masque-connect-udp-03 Summary: 1 error (**), 0 flaws (~~), 5 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: 12 July 2021 Google LLC 6 8 January 2021 8 Requirements for a MASQUE Protocol to Proxy IP Traffic 9 draft-ietf-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/ietf-wg-masque/draft-ietf- 20 masque-ip-proxy-reqs. 22 Discussion Venues 24 This note is to be removed before publishing as an RFC. 26 Source for this draft and an issue tracker can be found at 27 https://github.com/ietf-wg-masque/draft-ietf-masque-ip-proxy-reqs. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 12 July 2021. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Consumer VPN . . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Point to Point Connectivity . . . . . . . . . . . . . . . 4 68 2.3. Point to Network Connectivity . . . . . . . . . . . . . . 4 69 2.4. Network to Network Connectivity . . . . . . . . . . . . . 4 70 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. IP Session Establishment . . . . . . . . . . . . . . . . 5 72 3.2. Proxying of IP packets . . . . . . . . . . . . . . . . . 5 73 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 5 74 3.4. IP Assignment . . . . . . . . . . . . . . . . . . . . . . 5 75 3.5. Route Negotiation . . . . . . . . . . . . . . . . . . . . 5 76 3.6. Identity . . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.7. Transport Security . . . . . . . . . . . . . . . . . . . 6 78 3.8. Flow Control . . . . . . . . . . . . . . . . . . . . . . 6 79 3.9. Indistinguishability . . . . . . . . . . . . . . . . . . 6 80 3.10. Support HTTP/2 and HTTP/3 . . . . . . . . . . . . . . . . 6 81 3.11. Multiplexing . . . . . . . . . . . . . . . . . . . . . . 6 82 4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 7 83 4.1. Load balancing . . . . . . . . . . . . . . . . . . . . . 7 84 4.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7 85 4.3. Reliable Transmission of IP Packets . . . . . . . . . . . 7 86 4.4. Configuration of Congestion and Flow Control . . . . . . 7 87 4.5. Data Transport Compression . . . . . . . . . . . . . . . 8 88 5. Non-requirements . . . . . . . . . . . . . . . . . . . . . . 8 89 5.1. Addressing Architecture . . . . . . . . . . . . . . . . . 8 90 5.2. Translation . . . . . . . . . . . . . . . . . . . . . . . 8 91 5.3. IP Packet Extraction . . . . . . . . . . . . . . . . . . 9 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 95 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 96 Normative References . . . . . . . . . . . . . . . . . . . . . 9 97 Informative References . . . . . . . . . . . . . . . . . . . . 10 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 100 1. Introduction 102 There exist several IETF standards for proxying IP in a way that is 103 authenticated and confidential, such as IKEv2/IPsec [IKEV2]. 104 However, those are distinguishable from common Internet traffic and 105 often blocked. Additionally, large server deployments have expressed 106 interest in using a VPN solution that leverages existing security 107 protocols such as QUIC [QUIC] or TLS [TLS] to avoid adding another 108 protocol to their security posture. 110 This document describes the set of requirements for a protocol that 111 can proxy IP traffic over HTTP. The requirements outlined below are 112 similar to the considerations made in designing the CONNECT-UDP 113 method [CONNECT-UDP], additionally including IP-specific 114 requirements, such as a means of negotiating the routes that should 115 be advertised on either end of the connection. 117 Discussion of this work is encouraged to happen on the MASQUE IETF 118 mailing list masque@ietf.org or on the GitHub repository which 119 contains the draft: https://github.com/ietf-wg-masque/draft-ietf- 120 masque-ip-proxy-reqs. 122 1.1. Conventions 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 1.2. Definitions 132 * Data Transport: The mechanism responsible for transmitting IP 133 packets over HTTP. This can involve streams or datagrams. 135 * IP Session: An association between client and server whereby both 136 agree to proxy IP traffic given certain configuration properties. 137 This is similar to a Child Security Association in IKEv2 138 terminology. An IP Session uses Data Transports to transmit 139 packets. 141 2. Use Cases 143 There are multiple reasons to deploy an IP proxying protocol. This 144 section discusses some examples of use cases that MUST be supported 145 by the protocol. Note that while the protocol needs to support these 146 use cases, the protocol elements that allow them may be optional. 148 2.1. Consumer VPN 150 Consumer VPNs refer to network applications that allow a user to hide 151 some properties of their traffic from some network observers. In 152 particular, it can hide the identity of servers the client is 153 connecting to from the client's network provider, and can hide the 154 client's IP address (and derived geographical information) from the 155 servers they are communicating with. Note that this hidden 156 information is now available to the VPN service provider, so is only 157 beneficial for clients who trust the VPN service provider more than 158 other entities. 160 2.2. Point to Point Connectivity 162 Point-to-point connectivity creates a private, encrypted and 163 authenticated network between two IP addresses. This is useful, for 164 example, with container networking to provide a virtual (overlay) 165 network with addressing separate from the physical transport. An 166 example of this is Wireguard. 168 2.3. Point to Network Connectivity 170 Point-to-Network connectivity is the more traditional remote-access 171 "VPN" use case, frequently used when a user needs to connect to a 172 different network (such as an enterprise network) for access to 173 resources that are not exposed to the public Internet. 175 2.4. Network to Network Connectivity 177 Network-to-Network connectivity is also called a site-to-site VPN. 178 Similar to the point-to-network use case, the goal is to connect two 179 networks that are not exposed publicly. The site-to-site aspects 180 make this transparent to the user; the entire networks are connected 181 to each other and route packets transparently without a VPN client 182 installed on the user's device. This style of connectivity can also 183 be used to connect devices that cannot run VPN clients through to the 184 network. 186 3. Requirements 188 This section lists requirements for a protocol that can proxy IP over 189 an HTTP connection. 191 3.1. IP Session Establishment 193 The protocol will allow the client to request establishment of an IP 194 Session, along with configuration options and one or more associated 195 Data Transports. The server will have the ability to accept or deny 196 the client's request. 198 3.2. Proxying of IP packets 200 The protocol will establish Data Transports, which will be able to 201 forward IP packets. The Data Transports MUST be able to forward 202 packets in their unmodified entirety, although extensions may enable 203 the use of modified packet formats (e.g., compression). The protocol 204 will support both IPv6 [IPV6] and IPv4 [IPV4]. 206 3.3. Maximum Transmission Unit 208 The protocol will allow endpoints to inform each other of the Maximum 209 Transmission Unit (MTU) they are willing to forward. This will allow 210 avoiding IP fragmentation, especially as IPv6 does not allow IP 211 fragmentation by nodes along the path. 213 3.4. IP Assignment 215 The client will be able to request to be assigned an IP address 216 range, optionally specifying a preferred range. In response to that 217 request, the server will either assign a range of its choosing to the 218 client, or decline the request. For symmetry, the server may request 219 assignment of an IP address range from the client, and the client 220 will either assign a range or decline the request. 222 3.5. Route Negotiation 224 At any point in an IP Session (not limited to its initial 225 negotiation), the protocol will allow both client and server to 226 inform its peer that it can route a set of IP prefixes. Both 227 endpoints can also request a route to a given prefix, and the peer 228 can choose to provide that route or not. 230 Note that if an endpoint provides its peer with a route, the peer is 231 in no way obligated to route its traffic through the endpoint. 233 3.6. Identity 235 When negotiating the creation of an IP Session, the protocol will 236 allow both endpoints to exchange an identifier. As examples, the 237 identity could be a user name, an email address, a token, or a fully- 238 qualified domain name. Note that this requirement does not cover 239 authenticating the identifier. 241 3.7. Transport Security 243 The protocol MUST be run over a protocol that provides mutual 244 authentication, confidentiality and integrity. Using QUIC or TLS 245 would meet this requirement. 247 3.8. Flow Control 249 The protocol will allow the ability to proxy IP packets without flow 250 control, at least when HTTP/3 is in use. QUIC DATAGRAM frames are 251 not flow controlled and would meet this requirement. The document 252 defining the protocol will provide guidance on how best to use flow 253 control to improve IP Session performance. 255 3.9. Indistinguishability 257 A passive network observer not participating in the encrypted 258 connection should not be able to distinguish IP proxying from regular 259 encrypted HTTP Web traffic by only observing non-encrypted parts of 260 the traffic. Specifically, any data sent unencrypted (such as 261 headers, or parts of the handshake) should look like the same 262 unencrypted data that would be present for Web traffic. Traffic 263 analysis is out of scope for this requirement. 265 3.10. Support HTTP/2 and HTTP/3 267 The IP proxying protocol discussed in this document will run over 268 HTTP. The protocol SHOULD strongly prefer to use HTTP/3 [H3] and 269 SHOULD use the QUIC DATAGRAM frames [DGRAM] when available to improve 270 performance. The protocol SHOULD also support HTTP/2 [H2] as a 271 fallback when UDP is blocked on the network path. Proxying IP over 272 HTTP/2 MAY result in lower performance than over HTTP/3. 274 3.11. Multiplexing 276 Since recent HTTP versions support concurrently running multiple 277 requests over the same connection, the protocol SHOULD support 278 multiple independent instances of IP proxying over a given HTTP 279 connection. 281 4. Extensibility 283 The protocol will provide a mechanism by which clients and servers 284 can add extension information to the exchange that establishes the IP 285 Session. If the solution uses an HTTP request and response, this 286 could be accomplished using HTTP headers. 288 Once the IP Session is established, the protocol will provide a 289 mechanism that allows reliably exchanging extension messages in both 290 directions at any point in the lifetime of the IP Session. 292 The subsections below list possible extensions that designers of the 293 protocol will keep in mind to ensure it will be possible to design 294 such extensions. 296 4.1. Load balancing 298 This extension would allow for load balancing of the traffic sent 299 across the IP Session, such as to another server. This allows the IP 300 proxying mechanisms to scale-out to multiple servers. 302 4.2. Authentication 304 Since the protocol will offer a way to convey identity, extensions 305 will allow authenticating that identity, from both the client and 306 server, during the establishment of the IP Session. For example, an 307 extension could allow a client to offer an OAuth Access Token [OAUTH] 308 when requesting an IP Session. As another example, another extension 309 could allow an endpoint to demonstrate knowledge of a cryptographic 310 secret. 312 4.3. Reliable Transmission of IP Packets 314 While it is desirable to transmit IP packets unreliably in most 315 cases, an extension could provide a mechanism to allow forwarding 316 some packets reliably. For example, when using HTTP/3, this can be 317 accomplished by allowing Data Transports to run over both DATAGRAM 318 and STREAM frames. 320 4.4. Configuration of Congestion and Flow Control 322 An extension will allow exchanging congestion and flow control 323 parameters to improve performance. For example, an extension could 324 disable congestion control for non-retransmitted Data Transports if 325 it knows that the proxied traffic is itself congestion-controlled. 327 4.5. Data Transport Compression 329 While the core protocol Data Transports will transmit IP packets in 330 their unmodified entirety, an extension can allow compressing these 331 packets. 333 5. Non-requirements 335 This section discusses topics that are explicitly out of scope for 336 the IP Proxying protocol. These topics MAY be handled by 337 implementers or future extensions. 339 5.1. Addressing Architecture 341 This document only describes the requirements for a protocol that 342 allows IP proxying. It does not discuss how the IPs assigned are 343 determined, managed, or translated. While these details are 344 important for producing a functional system, they do not need to be 345 handled by the protocol beyond the ability to convey those 346 assignments. 348 Similarly, "ownership" of an IP range is out of scope. If an 349 endpoint communicates to its peer that it can allocate addresses from 350 a range, or route traffic to a range, the peer has no obligation to 351 trust that information. Whether or not to trust this information is 352 left to individual implementations and deployments. 354 5.2. Translation 356 Some servers may wish to perform Network Address Translation (NAT) or 357 any other modification to packets they forward. Doing so is out of 358 scope for the proxying protocol. In particular, the ability to 359 discover the presence of a NAT, negotiate NAT bindings, or check 360 connectivity through a NAT is explicitly out of scope and left to 361 future extensions. 363 Servers that do not perform NAT will commonly forward packets 364 similarly to how a traditional IP router would, but the specific of 365 that are considered out of scope. In particular, decrementing the 366 Hop Limit (or TTL) field of the IP header is out of scope for MASQUE 367 and expected to be performed by a router behind the MASQUE server, or 368 collocated with it. 370 5.3. IP Packet Extraction 372 How packets are forwarded between the IP proxying connection and the 373 physical network is out of scope. For example, this can be 374 accomplished on some operating systems using a TUN interface. How 375 this is done is deliberately not specified and will be left to 376 individual implementations. 378 6. Security Considerations 380 This document only discusses requirements on a protocol that allows 381 IP proxying. That protocol will need to document its security 382 considerations. 384 7. IANA Considerations 386 This document requests no actions from IANA. 388 Acknowledgments 390 The authors would like to thank participants of the MASQUE working 391 group for their feedback. 393 References 395 Normative References 397 [DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 398 Datagram Extension to QUIC", Work in Progress, Internet- 399 Draft, draft-ietf-quic-datagram-01, 24 August 2020, 400 . 403 [H2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 404 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 405 DOI 10.17487/RFC7540, May 2015, 406 . 408 [H3] Bishop, M., "Hypertext Transfer Protocol Version 3 409 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 410 quic-http-33, 15 December 2020, . 413 [IPV4] Postel, J., "Internet Protocol", STD 5, RFC 791, 414 DOI 10.17487/RFC0791, September 1981, 415 . 417 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 418 (IPv6) Specification", STD 86, RFC 8200, 419 DOI 10.17487/RFC8200, July 2017, 420 . 422 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 423 and Secure Transport", Work in Progress, Internet-Draft, 424 draft-ietf-quic-transport-33, 13 December 2020, 425 . 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, 430 DOI 10.17487/RFC2119, March 1997, 431 . 433 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 434 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 435 May 2017, . 437 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 438 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 439 . 441 Informative References 443 [CONNECT-UDP] 444 Schinazi, D., "The CONNECT-UDP HTTP Method", Work in 445 Progress, Internet-Draft, draft-ietf-masque-connect-udp- 446 03, 5 January 2021, . 449 [IKEV2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 450 Kivinen, "Internet Key Exchange Protocol Version 2 451 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 452 2014, . 454 [OAUTH] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 455 RFC 6749, DOI 10.17487/RFC6749, October 2012, 456 . 458 Authors' Addresses 459 Alex Chernyakhovsky 460 Google LLC 461 1600 Amphitheatre Parkway 462 Mountain View, California 94043, 463 United States of America 465 Email: achernya@google.com 467 Dallas McCall 468 Google LLC 469 1600 Amphitheatre Parkway 470 Mountain View, California 94043, 471 United States of America 473 Email: dallasmccall@google.com 475 David Schinazi 476 Google LLC 477 1600 Amphitheatre Parkway 478 Mountain View, California 94043, 479 United States of America 481 Email: dschinazi.ietf@gmail.com