idnits 2.17.1 draft-ietf-masque-ip-proxy-reqs-03.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 (27 August 2021) is 973 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-03 ** Obsolete normative reference: RFC 7540 (ref. 'H2') (Obsoleted by RFC 9113) == Outdated reference: A later version (-15) exists of draft-ietf-masque-connect-udp-04 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-10 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: 28 February 2022 Google LLC 6 27 August 2021 8 Requirements for a MASQUE Protocol to Proxy IP Traffic 9 draft-ietf-masque-ip-proxy-reqs-03 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 28 February 2022. 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 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. IP Session Establishment . . . . . . . . . . . . . . . . 4 71 3.2. Proxying of IP packets . . . . . . . . . . . . . . . . . 5 72 3.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 5 73 3.4. IP Assignment . . . . . . . . . . . . . . . . . . . . . . 5 74 3.5. Identity . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.6. Transport Security . . . . . . . . . . . . . . . . . . . 5 76 3.7. Flow Control . . . . . . . . . . . . . . . . . . . . . . 6 77 3.8. Indistinguishability . . . . . . . . . . . . . . . . . . 6 78 3.9. Support HTTP/2 and HTTP/3 . . . . . . . . . . . . . . . . 6 79 3.10. Multiplexing . . . . . . . . . . . . . . . . . . . . . . 6 80 3.11. Statefulness . . . . . . . . . . . . . . . . . . . . . . 6 81 4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 6 82 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . 7 83 4.2. Reliable Transmission of IP Packets . . . . . . . . . . . 7 84 4.3. Configuration of Congestion and Flow Control . . . . . . 7 85 4.4. Data Transport Compression . . . . . . . . . . . . . . . 7 86 5. Non-requirements . . . . . . . . . . . . . . . . . . . . . . 7 87 5.1. Addressing Architecture . . . . . . . . . . . . . . . . . 8 88 5.2. Translation . . . . . . . . . . . . . . . . . . . . . . . 8 89 5.3. IP Packet Extraction . . . . . . . . . . . . . . . . . . 8 90 5.4. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 93 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 94 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 95 Normative References . . . . . . . . . . . . . . . . . . . . . 9 96 Informative References . . . . . . . . . . . . . . . . . . . . 10 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 99 1. Introduction 101 There exist several IETF standards for proxying IP in a way that is 102 authenticated and confidential, such as IKEv2/IPsec [IKEV2]. 103 However, those are distinguishable from common Internet traffic and 104 often blocked. Additionally, large server deployments have expressed 105 interest in using a VPN solution that leverages existing security 106 protocols such as QUIC [QUIC] or TLS [TLS] to avoid adding another 107 protocol to their security posture. 109 This document describes the set of requirements for a protocol that 110 can proxy IP traffic over HTTP. The requirements outlined below are 111 similar to the considerations made in designing the CONNECT-UDP 112 method [CONNECT-UDP], additionally including IP-specific 113 requirements, such as a means of negotiating the routes that should 114 be advertised on either end of the connection. 116 Discussion of this work is encouraged to happen on the MASQUE IETF 117 mailing list masque@ietf.org or on the GitHub repository which 118 contains the draft: https://github.com/ietf-wg-masque/draft-ietf- 119 masque-ip-proxy-reqs. 121 1.1. Conventions 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 1.2. Definitions 131 * Data Transport: The mechanism responsible for transmitting IP 132 packets over HTTP. This can involve streams or datagrams. 134 * IP Session: An association between client and server whereby both 135 agree to proxy IP traffic given certain configuration properties. 136 This is similar to a Child Security Association in IKEv2 137 terminology. An IP Session uses Data Transports to transmit 138 packets. 140 2. Use Cases 142 There are multiple reasons to deploy an IP proxying protocol. This 143 section discusses some examples of use cases that MUST be supported 144 by the protocol. Note that while the protocol needs to support these 145 use cases, the protocol elements that allow them may be optional. 147 2.1. Consumer VPN 149 Consumer VPNs refer to network applications that allow a user to hide 150 some properties of their traffic from some network observers. In 151 particular, it can hide the identity of servers the client is 152 connecting to from the client's network provider, and can hide the 153 client's IP address (and derived geographical information) from the 154 servers they are communicating with. Note that this hidden 155 information is now available to the VPN service provider, so is only 156 beneficial for clients who trust the VPN service provider more than 157 other entities. 159 2.2. Point to Point Connectivity 161 Point-to-point connectivity creates a private, encrypted and 162 authenticated network between two IP addresses. This is useful, for 163 example, with container networking to provide a virtual (overlay) 164 network with addressing separate from the physical transport. An 165 example of this is Wireguard. 167 2.3. Point to Network Connectivity 169 Point-to-Network connectivity is the more traditional remote-access 170 "VPN" use case, frequently used when a user needs to connect to a 171 different network (such as an enterprise network) for access to 172 resources that are not exposed to the public Internet. 174 3. Requirements 176 This section lists requirements for a protocol that can proxy IP over 177 an HTTP connection. 179 3.1. IP Session Establishment 181 The protocol will allow the client to request establishment of an IP 182 Session, along with configuration options and one or more associated 183 Data Transports. The server will have the ability to accept or deny 184 the client's request. 186 3.2. Proxying of IP packets 188 The protocol will establish Data Transports, which will be able to 189 forward IP packets. The Data Transports MUST be able to take IP 190 datagrams input on one side and egress them unmodified in their 191 entirety on the other side, although extensions may enable IP packets 192 to be modified in transit. The protocol will support both IPv6 193 [IPV6] and IPv4 [IPV4]. 195 3.3. Maximum Transmission Unit 197 The protocol will allow tunnel endpoints to inform each other of the 198 Maximum Transmission Unit (MTU) they are willing to forward. This 199 will allow avoiding some IP fragmentation, especially as IPv6 does 200 not allow IP fragmentation by nodes along the path. In cases where 201 the tunnel endpoint is not the same as the communication endpoint, 202 tunnel endpoints are expected to apply the guidance on UDP tunnels in 203 [TUNNELS]. 205 3.4. IP Assignment 207 The client will be able to request to be assigned an IP address 208 range, optionally specifying a preferred range. In response to that 209 request, the server will either assign a range of its choosing to the 210 client, or decline the request. For symmetry, the server may request 211 assignment of an IP address range from the client, and the client 212 will either assign a range or decline the request. Endpoints will 213 also have the ability to assign an IP address range to their peer, 214 and to communicate that assignment to the peer, without having 215 received a request. 217 3.5. Identity 219 When negotiating the creation of an IP Session, the protocol will 220 allow both endpoints to exchange an identifier. As examples, the 221 identity could be a user name, an email address, a token, or a fully- 222 qualified domain name. Note that this requirement does not cover 223 authenticating the identifier. 225 3.6. 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.7. Flow Control 233 The protocol will allow the ability to proxy IP packets without flow 234 control, at least when HTTP/3 is in use. QUIC DATAGRAM frames are 235 not flow controlled and would meet this requirement. The document 236 defining the protocol will provide guidance on how best to use flow 237 control to improve IP Session performance. 239 3.8. Indistinguishability 241 A passive network observer not participating in the encrypted 242 connection should not be able to distinguish IP proxying from regular 243 encrypted HTTP Web traffic by only observing non-encrypted parts of 244 the traffic. Specifically, any data sent unencrypted (such as 245 headers, or parts of the handshake) should look like the same 246 unencrypted data that would be present for Web traffic. Traffic 247 analysis is out of scope for this requirement. 249 3.9. Support HTTP/2 and HTTP/3 251 The IP proxying protocol discussed in this document will run over 252 HTTP. The protocol SHOULD strongly prefer to use HTTP/3 [H3] and 253 SHOULD use the QUIC DATAGRAM frames [DGRAM] when available to improve 254 performance. The protocol MUST also support HTTP/2 [H2] as a 255 fallback when UDP is blocked on the network path. Proxying IP over 256 HTTP/2 MAY result in lower performance than over HTTP/3. 258 3.10. Multiplexing 260 Since recent HTTP versions support concurrently running multiple 261 requests over the same connection, the protocol SHOULD support 262 multiple independent instances of IP proxying over a given HTTP 263 connection. 265 3.11. Statefulness 267 The protocol should limit the amount of state a MASQUE client or 268 server needs to operate. Keeping minimal state simplifies 269 reconnection in the presence of failures and can facilitate 270 extensibility. 272 4. Extensibility 274 The protocol will provide a mechanism by which clients and servers 275 can add extension information to the exchange that establishes the IP 276 Session. If the solution uses an HTTP request and response, this 277 could be accomplished using HTTP headers. 279 Once the IP Session is established, the protocol will provide a 280 mechanism that allows reliably exchanging extension messages in both 281 directions at any point in the lifetime of the IP Session. 283 The subsections below list possible extensions that designers of the 284 protocol will keep in mind to ensure it will be possible to design 285 such extensions. 287 4.1. Authentication 289 Since the protocol will offer a way to convey identity, extensions 290 will allow authenticating that identity, from both the client and 291 server, during the establishment of the IP Session. For example, an 292 extension could allow a client to offer an OAuth Access Token [OAUTH] 293 when requesting an IP Session. As another example, another extension 294 could allow an endpoint to demonstrate knowledge of a cryptographic 295 secret. 297 4.2. Reliable Transmission of IP Packets 299 While it is desirable to transmit IP packets unreliably in most 300 cases, an extension could provide a mechanism to allow forwarding 301 some packets reliably. For example, when using HTTP/3, this can be 302 accomplished by allowing Data Transports to run over both DATAGRAM 303 and STREAM frames. 305 4.3. Configuration of Congestion and Flow Control 307 An extension will allow exchanging congestion and flow control 308 parameters to improve performance. For example, an extension could 309 disable congestion control for non-retransmitted Data Transports if 310 it knows that the proxied traffic is itself congestion-controlled. 312 4.4. Data Transport Compression 314 While the core protocol Data Transports will transmit IP packets in 315 their unmodified entirety, an extension can allow compressing these 316 packets. 318 5. Non-requirements 320 This section discusses topics that are explicitly out of scope for 321 the IP Proxying protocol. These topics MAY be handled by 322 implementers or future extensions. 324 5.1. Addressing Architecture 326 This document only describes the requirements for a protocol that 327 allows IP proxying. It does not discuss how the IPs assigned are 328 determined, managed, or translated. While these details are 329 important for producing a functional system, they do not need to be 330 handled by the protocol beyond the ability to convey those 331 assignments. 333 Similarly, "ownership" of an IP range is out of scope. If an 334 endpoint communicates to its peer that it can allocate addresses from 335 a range, or route traffic to a range, the peer has no obligation to 336 trust that information. Whether or not to trust this information is 337 left to individual implementations and extensions: the protocol will 338 be extensible enough to allow the development of extensions that 339 assist in assessing this trust. 341 5.2. Translation 343 Some servers may wish to perform Network Address Translation (NAT) or 344 any other modification to packets they forward. Doing so is out of 345 scope for the proxying protocol. In particular, the ability to 346 discover the presence of a NAT, negotiate NAT bindings, or check 347 connectivity through a NAT is explicitly out of scope and left to 348 future extensions. 350 Servers that do not perform NAT will commonly forward packets 351 similarly to how a traditional IP router would, but the specific of 352 that are considered out of scope. In particular, decrementing the 353 Hop Limit (or TTL) field of the IP header is out of scope for MASQUE 354 and expected to be performed by a router behind the MASQUE server, or 355 collocated with it. 357 5.3. IP Packet Extraction 359 How packets are forwarded between the IP proxying connection and the 360 physical network is out of scope. For example, this can be 361 accomplished on some operating systems using a TUN interface. How 362 this is done is deliberately not specified and will be left to 363 individual implementations. 365 5.4. Trust 367 All the use-cases described in Section 2 require some level of trust 368 between endpoints. However, how this trust is established and what 369 decisions endpoints make based on this trust is considered out of 370 scope. For example, if an endpoint doesn't sufficiently trust its 371 peer, it would be well advised to validate the IP addresses used by 372 that peer - however that is considered out of scope for the document 373 that will describe an IP proxying protocol. 375 6. Security Considerations 377 This document only discusses requirements on a protocol that allows 378 IP proxying. That protocol will need to document its security 379 considerations. 381 7. IANA Considerations 383 This document requests no actions from IANA. 385 Acknowledgments 387 The authors would like to thank participants of the MASQUE working 388 group for their feedback. 390 References 392 Normative References 394 [DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 395 Datagram Extension to QUIC", Work in Progress, Internet- 396 Draft, draft-ietf-quic-datagram-03, 12 July 2021, 397 . 400 [H2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 401 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 402 DOI 10.17487/RFC7540, May 2015, 403 . 405 [H3] Bishop, M., "Hypertext Transfer Protocol Version 3 406 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 407 quic-http-34, 2 February 2021, 408 . 411 [IPV4] Postel, J., "Internet Protocol", STD 5, RFC 791, 412 DOI 10.17487/RFC0791, September 1981, 413 . 415 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 416 (IPv6) Specification", STD 86, RFC 8200, 417 DOI 10.17487/RFC8200, July 2017, 418 . 420 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 421 and Secure Transport", Work in Progress, Internet-Draft, 422 draft-ietf-quic-transport-34, 14 January 2021, 423 . 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, 428 DOI 10.17487/RFC2119, March 1997, 429 . 431 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 432 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 433 May 2017, . 435 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 436 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 437 . 439 Informative References 441 [CONNECT-UDP] 442 Schinazi, D., "The CONNECT-UDP HTTP Method", Work in 443 Progress, Internet-Draft, draft-ietf-masque-connect-udp- 444 04, 12 July 2021, . 447 [IKEV2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 448 Kivinen, "Internet Key Exchange Protocol Version 2 449 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 450 2014, . 452 [OAUTH] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 453 RFC 6749, DOI 10.17487/RFC6749, October 2012, 454 . 456 [TUNNELS] Touch, J. and M. Townsley, "IP Tunnels in the Internet 457 Architecture", Work in Progress, Internet-Draft, draft- 458 ietf-intarea-tunnels-10, 12 September 2019, 459 . 462 Authors' Addresses 464 Alex Chernyakhovsky 465 Google LLC 466 1600 Amphitheatre Parkway 467 Mountain View, California 94043, 468 United States of America 470 Email: achernya@google.com 472 Dallas McCall 473 Google LLC 474 1600 Amphitheatre Parkway 475 Mountain View, California 94043, 476 United States of America 478 Email: dallasmccall@google.com 480 David Schinazi 481 Google LLC 482 1600 Amphitheatre Parkway 483 Mountain View, California 94043, 484 United States of America 486 Email: dschinazi.ietf@gmail.com