idnits 2.17.1 draft-ietf-masque-ip-proxy-reqs-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 (30 April 2021) is 1093 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-02 ** Obsolete normative reference: RFC 7540 (ref. 'H2') (Obsoleted by RFC 9113) == Outdated reference: A later version (-15) exists of draft-ietf-masque-connect-udp-03 Summary: 1 error (**), 0 flaws (~~), 3 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: 1 November 2021 Google LLC 6 30 April 2021 8 Requirements for a MASQUE Protocol to Proxy IP Traffic 9 draft-ietf-masque-ip-proxy-reqs-02 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 1 November 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 3.12. Statefulness . . . . . . . . . . . . . . . . . . . . . . 7 83 4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 7 84 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . 7 85 4.2. Reliable Transmission of IP Packets . . . . . . . . . . . 7 86 4.3. Configuration of Congestion and Flow Control . . . . . . 7 87 4.4. 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 take IP 202 datagrams input on one side and egress them unmodified in their 203 entirety on the other side, although extensions may enable IP packets 204 to be modified in transit. The protocol will support both IPv6 205 [IPV6] and IPv4 [IPV4]. 207 3.3. Maximum Transmission Unit 209 The protocol will allow endpoints to inform each other of the Maximum 210 Transmission Unit (MTU) they are willing to forward. This will allow 211 avoiding IP fragmentation, especially as IPv6 does not allow IP 212 fragmentation by nodes along the path. 214 3.4. IP Assignment 216 The client will be able to request to be assigned an IP address 217 range, optionally specifying a preferred range. In response to that 218 request, the server will either assign a range of its choosing to the 219 client, or decline the request. For symmetry, the server may request 220 assignment of an IP address range from the client, and the client 221 will either assign a range or decline the request. 223 3.5. Route Negotiation 225 At any point in an IP Session (not limited to its initial 226 negotiation), the protocol will allow both client and server to 227 inform its peer that it can route a set of IP prefixes. Both 228 endpoints can also request a route to a given prefix, and the peer 229 can choose to provide that route or not. This can be used to inform 230 peers of a default route for all prefixes. 232 Note that if an endpoint provides its peer with a route, the peer is 233 in no way obligated to route its traffic through the endpoint. 235 3.6. Identity 237 When negotiating the creation of an IP Session, the protocol will 238 allow both endpoints to exchange an identifier. As examples, the 239 identity could be a user name, an email address, a token, or a fully- 240 qualified domain name. Note that this requirement does not cover 241 authenticating the identifier. 243 3.7. Transport Security 245 The protocol MUST be run over a protocol that provides mutual 246 authentication, confidentiality and integrity. Using QUIC or TLS 247 would meet this requirement. 249 3.8. 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.9. Indistinguishability 259 A passive network observer not participating in the encrypted 260 connection should not be able to distinguish IP proxying from regular 261 encrypted HTTP Web traffic by only observing non-encrypted parts of 262 the traffic. Specifically, any data sent unencrypted (such as 263 headers, or parts of the handshake) should look like the same 264 unencrypted data that would be present for Web traffic. Traffic 265 analysis is out of scope for this requirement. 267 3.10. Support HTTP/2 and HTTP/3 269 The IP proxying protocol discussed in this document will run over 270 HTTP. The protocol SHOULD strongly prefer to use HTTP/3 [H3] and 271 SHOULD use the QUIC DATAGRAM frames [DGRAM] when available to improve 272 performance. The protocol MUST also support HTTP/2 [H2] as a 273 fallback when UDP is blocked on the network path. Proxying IP over 274 HTTP/2 MAY result in lower performance than over HTTP/3. 276 3.11. Multiplexing 278 Since recent HTTP versions support concurrently running multiple 279 requests over the same connection, the protocol SHOULD support 280 multiple independent instances of IP proxying over a given HTTP 281 connection. 283 3.12. Statefulness 285 The protocol should limit the amount of state a MASQUE client or 286 server needs to operate. Keeping minimal state simplifies 287 reconnection in the presence of failures and can facilitate 288 extensibility. 290 4. Extensibility 292 The protocol will provide a mechanism by which clients and servers 293 can add extension information to the exchange that establishes the IP 294 Session. If the solution uses an HTTP request and response, this 295 could be accomplished using HTTP headers. 297 Once the IP Session is established, the protocol will provide a 298 mechanism that allows reliably exchanging extension messages in both 299 directions at any point in the lifetime of the IP Session. 301 The subsections below list possible extensions that designers of the 302 protocol will keep in mind to ensure it will be possible to design 303 such extensions. 305 4.1. Authentication 307 Since the protocol will offer a way to convey identity, extensions 308 will allow authenticating that identity, from both the client and 309 server, during the establishment of the IP Session. For example, an 310 extension could allow a client to offer an OAuth Access Token [OAUTH] 311 when requesting an IP Session. As another example, another extension 312 could allow an endpoint to demonstrate knowledge of a cryptographic 313 secret. 315 4.2. Reliable Transmission of IP Packets 317 While it is desirable to transmit IP packets unreliably in most 318 cases, an extension could provide a mechanism to allow forwarding 319 some packets reliably. For example, when using HTTP/3, this can be 320 accomplished by allowing Data Transports to run over both DATAGRAM 321 and STREAM frames. 323 4.3. Configuration of Congestion and Flow Control 325 An extension will allow exchanging congestion and flow control 326 parameters to improve performance. For example, an extension could 327 disable congestion control for non-retransmitted Data Transports if 328 it knows that the proxied traffic is itself congestion-controlled. 330 4.4. Data Transport Compression 332 While the core protocol Data Transports will transmit IP packets in 333 their unmodified entirety, an extension can allow compressing these 334 packets. 336 5. Non-requirements 338 This section discusses topics that are explicitly out of scope for 339 the IP Proxying protocol. These topics MAY be handled by 340 implementers or future extensions. 342 5.1. Addressing Architecture 344 This document only describes the requirements for a protocol that 345 allows IP proxying. It does not discuss how the IPs assigned are 346 determined, managed, or translated. While these details are 347 important for producing a functional system, they do not need to be 348 handled by the protocol beyond the ability to convey those 349 assignments. 351 Similarly, "ownership" of an IP range is out of scope. If an 352 endpoint communicates to its peer that it can allocate addresses from 353 a range, or route traffic to a range, the peer has no obligation to 354 trust that information. Whether or not to trust this information is 355 left to individual implementations and extensions: the protocol will 356 be extensible enough to allow the development of extensions that 357 assist in assessing this trust. 359 5.2. Translation 361 Some servers may wish to perform Network Address Translation (NAT) or 362 any other modification to packets they forward. Doing so is out of 363 scope for the proxying protocol. In particular, the ability to 364 discover the presence of a NAT, negotiate NAT bindings, or check 365 connectivity through a NAT is explicitly out of scope and left to 366 future extensions. 368 Servers that do not perform NAT will commonly forward packets 369 similarly to how a traditional IP router would, but the specific of 370 that are considered out of scope. In particular, decrementing the 371 Hop Limit (or TTL) field of the IP header is out of scope for MASQUE 372 and expected to be performed by a router behind the MASQUE server, or 373 collocated with it. 375 5.3. IP Packet Extraction 377 How packets are forwarded between the IP proxying connection and the 378 physical network is out of scope. For example, this can be 379 accomplished on some operating systems using a TUN interface. How 380 this is done is deliberately not specified and will be left to 381 individual implementations. 383 6. Security Considerations 385 This document only discusses requirements on a protocol that allows 386 IP proxying. That protocol will need to document its security 387 considerations. 389 7. IANA Considerations 391 This document requests no actions from IANA. 393 Acknowledgments 395 The authors would like to thank participants of the MASQUE working 396 group for their feedback. 398 References 400 Normative References 402 [DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 403 Datagram Extension to QUIC", Work in Progress, Internet- 404 Draft, draft-ietf-quic-datagram-02, 16 February 2021, 405 . 407 [H2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 408 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 409 DOI 10.17487/RFC7540, May 2015, 410 . 412 [H3] Bishop, M., "Hypertext Transfer Protocol Version 3 413 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 414 quic-http-34, 2 February 2021, 415 . 417 [IPV4] Postel, J., "Internet Protocol", STD 5, RFC 791, 418 DOI 10.17487/RFC0791, September 1981, 419 . 421 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 422 (IPv6) Specification", STD 86, RFC 8200, 423 DOI 10.17487/RFC8200, July 2017, 424 . 426 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 427 and Secure Transport", Work in Progress, Internet-Draft, 428 draft-ietf-quic-transport-34, 14 January 2021, 429 . 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, 434 DOI 10.17487/RFC2119, March 1997, 435 . 437 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 438 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 439 May 2017, . 441 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 442 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 443 . 445 Informative References 447 [CONNECT-UDP] 448 Schinazi, D., "The CONNECT-UDP HTTP Method", Work in 449 Progress, Internet-Draft, draft-ietf-masque-connect-udp- 450 03, 5 January 2021, . 453 [IKEV2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 454 Kivinen, "Internet Key Exchange Protocol Version 2 455 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 456 2014, . 458 [OAUTH] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 459 RFC 6749, DOI 10.17487/RFC6749, October 2012, 460 . 462 Authors' Addresses 463 Alex Chernyakhovsky 464 Google LLC 465 1600 Amphitheatre Parkway 466 Mountain View, California 94043, 467 United States of America 469 Email: achernya@google.com 471 Dallas McCall 472 Google LLC 473 1600 Amphitheatre Parkway 474 Mountain View, California 94043, 475 United States of America 477 Email: dallasmccall@google.com 479 David Schinazi 480 Google LLC 481 1600 Amphitheatre Parkway 482 Mountain View, California 94043, 483 United States of America 485 Email: dschinazi.ietf@gmail.com