idnits 2.17.1 draft-ietf-masque-connect-ip-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 (5 March 2022) is 776 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-masque-h3-datagram-06 -- Possible downref: Normative reference to a draft: ref. 'SEMANTICS' -- Obsolete informational reference (is this intentional?): RFC 7235 (ref. 'AUTH') (Obsoleted by RFC 9110) == Outdated reference: A later version (-15) exists of draft-ietf-masque-connect-udp-07 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MASQUE T. Pauly, Ed. 3 Internet-Draft Apple Inc. 4 Intended status: Standards Track D. Schinazi 5 Expires: 6 September 2022 A. Chernyakhovsky 6 Google LLC 7 M. Kuehlewind 8 M. Westerlund 9 Ericsson 10 5 March 2022 12 IP Proxying Support for HTTP 13 draft-ietf-masque-connect-ip-01 15 Abstract 17 This document describes a method of proxying IP packets over HTTP. 18 This protocol is similar to CONNECT-UDP, but allows transmitting 19 arbitrary IP packets, without being limited to just TCP like CONNECT 20 or UDP like CONNECT-UDP. 22 Discussion Venues 24 This note is to be removed before publishing as an RFC. 26 Discussion of this document takes place on the Multiplexed 27 Application Substrate over QUIC Encryption Working Group mailing list 28 (masque@ietf.org), which is archived at 29 https://mailarchive.ietf.org/arch/browse/masque/. 31 Source for this draft and an issue tracker can be found at 32 https://github.com/tfpauly/draft-age-masque-connect-ip. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 6 September 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 68 3. Configuration of Clients . . . . . . . . . . . . . . . . . . 3 69 4. The CONNECT-IP Protocol . . . . . . . . . . . . . . . . . . . 4 70 4.1. Limiting Request Scope . . . . . . . . . . . . . . . . . 5 71 4.2. Capsules . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4.2.1. ADDRESS_ASSIGN Capsule . . . . . . . . . . . . . . . 6 73 4.2.2. ADDRESS_REQUEST Capsule . . . . . . . . . . . . . . . 7 74 4.2.3. ROUTE_ADVERTISEMENT Capsule . . . . . . . . . . . . . 7 75 5. Context Identifiers . . . . . . . . . . . . . . . . . . . . . 9 76 6. HTTP Datagram Payload Format . . . . . . . . . . . . . . . . 10 77 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 7.1. Remote Access VPN . . . . . . . . . . . . . . . . . . . . 11 79 7.2. IP Flow Forwarding . . . . . . . . . . . . . . . . . . . 13 80 7.3. Proxied Connection Racing . . . . . . . . . . . . . . . . 15 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 83 9.1. CONNECT-IP HTTP Upgrade Token . . . . . . . . . . . . . . 17 84 9.2. Capsule Type Registrations . . . . . . . . . . . . . . . 17 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 87 10.2. Informative References . . . . . . . . . . . . . . . . . 19 88 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 91 1. Introduction 93 This document describes a method of proxying IP packets over HTTP. 94 When using HTTP/2 or HTTP/3, IP proxying uses HTTP Extended CONNECT 95 as described in [EXT-CONNECT2] and [EXT-CONNECT3]. When using 96 HTTP/1.x, IP proxying uses HTTP Upgrade as defined in Section 7.8 of 97 [SEMANTICS]. This protocol is similar to CONNECT-UDP [CONNECT-UDP], 98 but allows transmitting arbitrary IP packets, without being limited 99 to just TCP like CONNECT [SEMANTICS] or UDP like CONNECT-UDP. 101 The HTTP Upgrade Token defined for this mechanism is "connect-ip", 102 which is also referred to as CONNECT-IP in this document. 104 The CONNECT-IP protocol allows endpoints to set up a tunnel for 105 proxying IP packets using an HTTP proxy. This can be used for 106 various solutions that include general-purpose packet tunnelling, 107 such as for a point-to-point or point-to-network VPN, or for limited 108 forwarding of packets to specific hosts. 110 Forwarded IP packets can be sent efficiently via the proxy using HTTP 111 Datagram support [HTTP-DGRAM]. 113 2. Conventions and Definitions 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 In this document, we use the term "proxy" to refer to the HTTP server 122 that responds to the CONNECT-IP request. If there are HTTP 123 intermediaries (as defined in Section 3.7 of [SEMANTICS]) between the 124 client and the proxy, those are referred to as "intermediaries" in 125 this document. 127 3. Configuration of Clients 129 Clients are configured to use IP Proxying over HTTP via an URI 130 Template [TEMPLATE]. The URI template MAY contain two variables: 131 "target" and "ip_proto". Examples are shown below: 133 https://masque.example.org/{target}/{ip_proto}/ 134 https://proxy.example.org:4443/masque?t={target}&p={ip_proto} 135 https://proxy.example.org:4443/masque{?target,ip_proto} 136 https://masque.example.org/?user=bob 138 Figure 1: URI Template Examples 140 4. The CONNECT-IP Protocol 142 This document defines the "connect-ip" HTTP Upgrade Token. "connect- 143 ip" uses the Capsule Protocol as defined in [HTTP-DGRAM]. 145 When sending its IP proxying request, the client SHALL perform URI 146 template expansion to determine the path and query of its request, 147 see Section 3. 149 When using HTTP/2 or HTTP/3, the following requirements apply to 150 requests: 152 * The ":method" pseudo-header field SHALL be set to "CONNECT". 154 * The ":protocol" pseudo-header field SHALL be set to "connect-ip". 156 * The ":authority" pseudo-header field SHALL contain the host and 157 port of the proxy, not an individual endpoint with which a 158 connection is desired. 160 * The contents of the ":path" pseudo-header SHALL be determined by 161 the URI template expansion, see Section 3. Variables in the URI 162 template can determine the scope of the request, such as 163 requesting full-tunnel IP packet forwarding, or a specific proxied 164 flow, see Section 4.1. 166 The client SHOULD also include the "Capsule-Protocol" header with a 167 value of "?1" to negotiate support for sending and receiving HTTP 168 capsules ([HTTP-DGRAM]). 170 Any 2xx (Successful) response indicates that the proxy is willing to 171 open an IP forwarding tunnel between it and the client. Any response 172 other than a successful response indicates that the tunnel has not 173 been formed. 175 A proxy MUST NOT send any Transfer-Encoding or Content-Length header 176 fields in a 2xx (Successful) response to the IP Proxying request. A 177 client MUST treat a successful response containing any Content-Length 178 or Transfer-Encoding header fields as malformed. 180 The lifetime of the forwarding tunnel is tied to the CONNECT stream. 181 Closing the stream (in HTTP/3 via the FIN bit on a QUIC STREAM frame, 182 or a QUIC RESET_STREAM frame) closes the associated forwarding 183 tunnel. 185 Along with a successful response, the proxy can send capsules to 186 assign addresses and advertise routes to the client (Section 4.2). 187 The client can also assign addresses and advertise routes to the 188 proxy for network-to-network routing. 190 4.1. Limiting Request Scope 192 Unlike CONNECT-UDP requests, which require specifying a target host, 193 CONNECT-IP requests can allow endpoints to send arbitrary IP packets 194 to any host. The client can choose to restrict a given request to a 195 specific host or IP protocol by adding parameters to its request. 196 When the server knows that a request is scoped to a target host or 197 protocol, it can leverage this information to optimize its resource 198 allocation; for example, the server can assign the same public IP 199 address to two CONNECT-IP requests that are scoped to different hosts 200 and/or different protocols. 202 CONNECT-IP uses URI template variables (Section 3) to determine the 203 scope of the request for packet proxying. All variables defined here 204 are optional, and have default values if not included. 206 The defined variables are: 208 target: The variable "target" contains a hostname or IP address of a 209 specific host to which the client wants to proxy packets. If the 210 "target" variable is not specified, the client is requesting to 211 communicate with any allowable host. If the target is an IP 212 address, the request will only support a single IP version. If 213 the target is a hostname, the server is expected to perform DNS 214 resolution to determine which route(s) to advertise to the client. 215 The server SHOULD send a ROUTE_ADVERTISEMENT capsule that includes 216 routes for all usable resolved addresses for the requested 217 hostname. 219 ipproto: The variable "ipproto" contains an IP protocol number, as 220 defined in the "Assigned Internet Protocol Numbers" IANA registry. 221 If present, it specifies that a client only wants to proxy a 222 specific IP protocol for this request. If the value is 0, or the 223 variable is not included, the client is requesting to use any IP 224 protocol. 226 4.2. Capsules 228 This document defines multiple new capsule types that allow endpoints 229 to exchange IP configuration information. Both endpoints MAY send 230 any number of these new capsules. 232 4.2.1. ADDRESS_ASSIGN Capsule 234 The ADDRESS_ASSIGN capsule (see Section 9.2 for the value of the 235 capsule type) allows an endpoint to inform its peer that it has 236 assigned an IP address or prefix to it. The ADDRESS_ASSIGN capsule 237 allows assigning a prefix which can contain multiple addresses. Any 238 of these addresses can be used as the source address on IP packets 239 originated by the receiver of this capsule. 241 ADDRESS_ASSIGN Capsule { 242 Type (i) = ADDRESS_ASSIGN, 243 Length (i), 244 IP Version (8), 245 IP Address (32..128), 246 IP Prefix Length (8), 247 } 249 Figure 2: ADDRESS_ASSIGN Capsule Format 251 IP Version: IP Version of this address assignment. MUST be either 4 252 or 6. 254 IP Address: Assigned IP address. If the IP Version field has value 255 4, the IP Address field SHALL have a length of 32 bits. If the IP 256 Version field has value 6, the IP Address field SHALL have a 257 length of 128 bits. 259 IP Prefix Length: The number of bits in the IP Address that are used 260 to define the prefix that is being assigned. This MUST be less 261 than or equal to the length of the IP Address field, in bits. If 262 the prefix length is equal to the length of the IP Address, the 263 receiver of this capsule is only allowed to send packets from a 264 single source address. If the prefix length is less than the 265 length of the IP address, the receiver of this capsule is allowed 266 to send packets from any source address that falls within the 267 prefix. 269 If an endpoint receives multiple ADDRESS_ASSIGN capsules, all of the 270 assigned addresses or prefixes can be used. For example, multiple 271 ADDRESS_ASSIGN capsules are necessary to assign both IPv4 and IPv6 272 addresses. 274 4.2.2. ADDRESS_REQUEST Capsule 276 The ADDRESS_REQUEST capsule (see Section 9.2 for the value of the 277 capsule type) allows an endpoint to request assignment of an IP 278 address from its peer. This capsule is not required for simple 279 client/proxy communication where the client only expects to receive 280 one address from the proxy. The capsule allows the endpoint to 281 optionally indicate a preference for which address it would get 282 assigned. 284 ADDRESS_REQUEST Capsule { 285 Type (i) = ADDRESS_REQUEST, 286 Length (i), 287 IP Version (8), 288 IP Address (32..128), 289 IP Prefix Length (8), 290 } 292 Figure 3: ADDRESS_REQUEST Capsule Format 294 IP Version: IP Version of this address request. MUST be either 4 or 295 6. 297 IP Address: Requested IP address. If the IP Version field has value 298 4, the IP Address field SHALL have a length of 32 bits. If the IP 299 Version field has value 6, the IP Address field SHALL have a 300 length of 128 bits. 302 IP Prefix Length: Length of the IP Prefix requested, in bits. MUST 303 be lesser or equal to the length of the IP Address field, in bits. 305 Upon receiving the ADDRESS_REQUEST capsule, an endpoint SHOULD assign 306 an IP address to its peer, and then respond with an ADDRESS_ASSIGN 307 capsule to inform the peer of the assignment. 309 4.2.3. ROUTE_ADVERTISEMENT Capsule 311 The ROUTE_ADVERTISEMENT capsule (see Section 9.2 for the value of the 312 capsule type) allows an endpoint to communicate to its peer that it 313 is willing to route traffic to a set of IP address ranges. This 314 indicates that the sender has an existing route to each address 315 range, and notifies its peer that if the receiver of the 316 ROUTE_ADVERTISEMENT capsule sends IP packets for one of these ranges 317 in HTTP Datagrams, the sender of the capsule will forward them along 318 its preexisting route. Any address which is in one of the address 319 ranges can be used as the destination address on IP packets 320 originated by the receiver of this capsule. 322 ROUTE_ADVERTISEMENT Capsule { 323 Type (i) = ROUTE_ADVERTISEMENT, 324 Length (i), 325 IP Address Range (..) ..., 326 } 328 Figure 4: ROUTE_ADVERTISEMENT Capsule Format 330 The ROUTE_ADVERTISEMENT capsule contains a sequence of IP Address 331 Ranges. 333 IP Address Range { 334 IP Version (8), 335 Start IP Address (32..128), 336 End IP Address (32..128), 337 IP Protocol (8), 338 } 340 Figure 5: IP Address Range Format 342 IP Version: IP Version of this range. MUST be either 4 or 6. 344 Start IP Address and End IP Address: Inclusive start and end IP 345 address of the advertised range. If the IP Version field has 346 value 4, these fields SHALL have a length of 32 bits. If the IP 347 Version field has value 6, these fields SHALL have a length of 128 348 bits. The Start IP Address MUST be lesser or equal to the End IP 349 Address. 351 IP Protocol: The Internet Protocol Number for traffic that can be 352 sent to this range. If the value is 0, all protocols are allowed. 354 Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start 355 routing IP packets in these ranges to its peer. 357 Each ROUTE_ADVERTISEMENT contains the full list of address ranges. 358 If multiple ROUTE_ADVERTISEMENT capsules are sent in one direction, 359 each ROUTE_ADVERTISEMENT capsule supersedes prior ones. In other 360 words, if a given address range was present in a prior capsule but 361 the most recently received ROUTE_ADVERTISEMENT capsule does not 362 contain it, the receiver will consider that range withdrawn. 364 If multiple ranges using the same IP protocol were to overlap, some 365 routing table implementations might reject them. To prevent overlap, 366 the ranges are ordered; this places the burden on the sender and 367 makes verification by the receiver much simpler. If an IP Address 368 Range A precedes an IP address range B in the same 369 ROUTE_ADVERTISEMENT capsule, they MUST follow these requirements: 371 * IP Version of A MUST be lesser or equal than IP Version of B 373 * If the IP Version of A and B are equal, the IP Protocol of A MUST 374 be lesser or equal than IP Protocol of B. 376 * If the IP Version and IP Protocol of A and B are both equal, the 377 End IP Address of A MUST be strictly lesser than the Start IP 378 Address of B. 380 If an endpoint received a ROUTE_ADVERTISEMENT capsule that does not 381 meet these requirements, it MUST abort the stream. 383 5. Context Identifiers 385 This protocol allows future extensions to exchange HTTP Datagrams 386 which carry different semantics from IP packets. For example, an 387 extension could define a way to send compressed IP header fields. In 388 order to allow for this extensibility, all HTTP Datagrams associated 389 with IP proxying request streams start with a context ID, see 390 Section 6. 392 Context IDs are 62-bit integers (0 to 2^62-1). Context IDs are 393 encoded as variable-length integers, see Section 16 of [QUIC]. The 394 context ID value of 0 is reserved for IP packets, while non-zero 395 values are dynamically allocated: non-zero even-numbered context IDs 396 are client-allocated, and odd-numbered context IDs are server- 397 allocated. The context ID namespace is tied to a given HTTP request: 398 it is possible for a context ID with the same numeric value to be 399 simultaneously assigned different semantics in distinct requests, 400 potentially with different semantics. Context IDs MUST NOT be re- 401 allocated within a given HTTP namespace but MAY be allocated in any 402 order. Once allocated, any context ID can be used by both client and 403 server - only allocation carries separate namespaces to avoid 404 requiring synchronization. 406 Registration is the action by which an endpoint informs its peer of 407 the semantics and format of a given context ID. This document does 408 not define how registration occurs. Depending on the method being 409 used, it is possible for datagrams to be received with Context IDs 410 which have not yet been registered, for instance due to reordering of 411 the datagram and the registration packets during transmission. 413 6. HTTP Datagram Payload Format 415 When associated with IP proxying request streams, the HTTP Datagram 416 Payload field of HTTP Datagrams (see [HTTP-DGRAM]) has the format 417 defined in Figure 6. Note that when HTTP Datagrams are encoded using 418 QUIC DATAGRAM frames, the Context ID field defined below directly 419 follows the Quarter Stream ID field which is at the start of the QUIC 420 DATAGRAM frame payload: 422 IP Proxying HTTP Datagram Payload { 423 Context ID (i), 424 Payload (..), 425 } 427 Figure 6: IP Proxying HTTP Datagram Format 429 Context ID: A variable-length integer that contains the value of the 430 Context ID. If an HTTP/3 datagram which carries an unknown 431 Context ID is received, the receiver SHALL either drop that 432 datagram silently or buffer it temporarily (on the order of a 433 round trip) while awaiting the registration of the corresponding 434 Context ID. 436 Payload: The payload of the datagram, whose semantics depend on 437 value of the previous field. Note that this field can be empty. 439 IP packets are encoded using HTTP Datagrams with the Context ID set 440 to zero. When the Context ID is set to zero, the Payload field 441 contains a full IP packet (from the IP Version field until the last 442 byte of the IP Payload). 444 Clients MAY optimistically start sending proxied IP packets before 445 receiving the response to its IP proxying request, noting however 446 that those may not be processed by the proxy if it responds to the 447 request with a failure, or if the datagrams are received by the proxy 448 before the request. 450 When a CONNECT-IP endpoint receives an HTTP Datagram containing an IP 451 packet, it will parse the packet's IP header, perform any local 452 policy checks (e.g., source address validation), check their routing 453 table to pick an outbound interface, and then send the IP packet on 454 that interface. 456 In the other direction, when a CONNECT-IP endpoint receives an IP 457 packet, it checks to see if the packet matches the routes mapped for 458 a CONNECT-IP forwarding tunnel, and performs the same forwarding 459 checks as above before transmitting the packet over HTTP Datagrams. 461 Note that CONNECT-IP endpoints will decrement the IP Hop Count (or 462 TTL) upon encapsulation but not decapsulation. In other words, the 463 Hop Count is decremented right before an IP packet is transmitted in 464 an HTTP Datagram. This prevents infinite loops in the presence of 465 routing loops, and matches the choices in IPsec [IPSEC]. 467 Endpoints MAY implement additional filtering policies on the IP 468 packets they forward. 470 7. Examples 472 CONNECT-IP enables many different use cases that can benefit from IP 473 packet proxying and tunnelling. These examples are provided to help 474 illustrate some of the ways in which CONNECT-IP can be used. 476 7.1. Remote Access VPN 478 The following example shows a point-to-network VPN setup, where a 479 client receives a set of local addresses, and can send to any remote 480 server through the proxy. Such VPN setups can be either full-tunnel 481 or split-tunnel. 483 +--------+ IP A IP B +--------+ +---> IP D 484 | |-------------------| | IP C | 485 | Client | IP Subnet C <-> * | Server |--------------+---> IP E 486 | |-------------------| | | 487 +--------+ +--------+ +---> IP ... 489 Figure 7: VPN Tunnel Setup 491 In this case, the client does not specify any scope in its request. 492 The server assigns the client an IPv4 address to the client 493 (192.0.2.11) and a full-tunnel route of all IPv4 addresses 494 (0.0.0.0/0). The client can then send to any IPv4 host using a 495 source address in its assigned prefix. 497 [[ From Client ]] [[ From Server ]] 499 SETTINGS 500 H3_DATAGRAM = 1 502 SETTINGS 503 SETTINGS_ENABLE_CONNECT_PROTOCOL = 1 504 H3_DATAGRAM = 1 506 STREAM(44): HEADERS 507 :method = CONNECT 508 :protocol = connect-ip 509 :scheme = https 510 :path = /vpn 511 :authority = server.example.com 512 capsule-protocol = ?1 514 STREAM(44): HEADERS 515 :status = 200 516 capsule-protocol = ?1 518 STREAM(44): CAPSULE 519 Capsule Type = ADDRESS_ASSIGN 520 IP Version = 4 521 IP Address = 192.0.2.11 522 IP Prefix Length = 32 524 STREAM(44): CAPSULE 525 Capsule Type = ROUTE_ADVERTISEMENT 526 (IP Version = 4 527 Start IP Address = 0.0.0.0 528 End IP Address = 255.255.255.255 529 IP Protocol = 0) // Any 531 DATAGRAM 532 Quarter Stream ID = 11 533 Context ID = 0 534 Payload = Encapsulated IP Packet 536 DATAGRAM 537 Quarter Stream ID = 11 538 Context ID = 0 539 Payload = Encapsulated IP Packet 541 Figure 8: VPN Full-Tunnel Example 543 A setup for a split-tunnel VPN (the case where the client can only 544 access a specific set of private subnets) is quite similar. In this 545 case, the advertised route is restricted to 192.0.2.0/24, rather than 546 0.0.0.0/0. 548 [[ From Client ]] [[ From Server ]] 550 STREAM(44): CAPSULE 551 Capsule Type = ADDRESS_ASSIGN 552 IP Version = 4 553 IP Address = 192.0.2.42 554 IP Prefix Length = 32 556 STREAM(44): CAPSULE 557 Capsule Type = ROUTE_ADVERTISEMENT 558 (IP Version = 4 559 Start IP Address = 192.0.2.0 560 End IP Address = 192.0.2.255 561 IP Protocol = 0) // Any 563 Figure 9: VPN Split-Tunnel Capsule Example 565 7.2. IP Flow Forwarding 567 The following example shows an IP flow forwarding setup, where a 568 client requests to establish a forwarding tunnel to 569 target.example.com using SCTP (IP protocol 132), and receives a 570 single local address and remote address it can use for transmitting 571 packets. A similar approach could be used for any other IP protocol 572 that isn't easily proxied with existing HTTP methods, such as ICMP, 573 ESP, etc. 575 +--------+ IP A IP B +--------+ 576 | |-------------------| | IP C 577 | Client | IP C <-> D | Server |---------> IP D 578 | |-------------------| | 579 +--------+ +--------+ 581 Figure 10: Proxied Flow Setup 583 In this case, the client specfies both a target hostname and an IP 584 protocol number in the scope of its request, indicating that it only 585 needs to communicate with a single host. The proxy server is able to 586 perform DNS resolution on behalf of the client and allocate a 587 specific outbound socket for the client instead of allocating an 588 entire IP address to the client. In this regard, the request is 589 similar to a traditional CONNECT proxy request. 591 The server assigns a single IPv6 address to the client 592 (2001:db8::1234:1234) and a route to a single IPv6 host 593 (2001:db8::3456), scoped to SCTP. The client can send and recieve 594 SCTP IP packets to the remote host. 596 [[ From Client ]] [[ From Server ]] 598 SETTINGS 599 H3_DATAGRAM = 1 600 SETTINGS 601 SETTINGS_ENABLE_CONNECT_PROTOCOL = 1 602 H3_DATAGRAM = 1 604 STREAM(52): HEADERS 605 :method = CONNECT 606 :protocol = connect-ip 607 :scheme = https 608 :path = /proxy?target=target.example.com&ipproto=132 609 :authority = server.example.com 610 capsule-protocol = ?1 612 STREAM(52): HEADERS 613 :status = 200 614 capsule-protocol = ?1 616 STREAM(52): CAPSULE 617 Capsule Type = ADDRESS_ASSIGN 618 IP Version = 6 619 IP Address = 2001:db8::1234:1234 620 IP Prefix Length = 128 622 STREAM(52): CAPSULE 623 Capsule Type = ROUTE_ADVERTISEMENT 624 (IP Version = 6 625 Start IP Address = 2001:db8::3456 626 End IP Address = 2001:db8::3456 627 IP Protocol = 132) 629 DATAGRAM 630 Quarter Stream ID = 13 631 Context ID = 0 632 Payload = Encapsulated SCTP/IP Packet 634 DATAGRAM 635 Quarter Stream ID = 13 636 Context ID = 0 637 Payload = Encapsulated SCTP/IP Packet 639 Figure 11: Proxied SCTP Flow Example 641 7.3. Proxied Connection Racing 643 The following example shows a setup where a client is proxying UDP 644 packets through a CONNECT-IP proxy in order to control connection 645 establishement racing through a proxy, as defined in Happy Eyeballs 646 [HEv2]. This example is a variant of the proxied flow, but 647 highlights how IP-level proxying can enable new capabilities even for 648 TCP and UDP. 650 +--------+ IP A IP B +--------+ IP C 651 | |-------------------| |<------------> IP E 652 | Client | IP C<->E, D<->F | Server | 653 | |-------------------| |<------------> IP F 654 +--------+ +--------+ IP D 656 Figure 12: Proxied Connection Racing Setup 658 As with proxied flows, the client specfies both a target hostname and 659 an IP protocol number in the scope of its request. When the proxy 660 server performs DNS resolution on behalf of the client, it can send 661 the various remote address options to the client as separate routes. 662 It can also ensure that the client has both IPv4 and IPv6 addresses 663 assigned. 665 The server assigns the client both an IPv4 address (192.0.2.3) and an 666 IPv6 address (2001:db8::1234:1234) to the client, as well as an IPv4 667 route (198.51.100.2) and an IPv6 route (2001:db8::3456), which 668 represent the resolved addresses of the target hostname, scoped to 669 UDP. The client can send and recieve UDP IP packets to the either of 670 the server addresses to enable Happy Eyeballs through the proxy. 672 [[ From Client ]] [[ From Server ]] 674 SETTINGS 675 H3_DATAGRAM = 1 677 SETTINGS 678 SETTINGS_ENABLE_CONNECT_PROTOCOL = 1 679 H3_DATAGRAM = 1 681 STREAM(44): HEADERS 682 :method = CONNECT 683 :protocol = connect-ip 684 :scheme = https 685 :path = /proxy?ipproto=17 686 :authority = server.example.com 687 capsule-protocol = ?1 689 STREAM(44): HEADERS 690 :status = 200 691 capsule-protocol = ?1 693 STREAM(44): CAPSULE 694 Capsule Type = ADDRESS_ASSIGN 695 IP Version = 4 696 IP Address = 192.0.2.3 697 IP Prefix Length = 32 699 STREAM(44): CAPSULE 700 Capsule Type = ADDRESS_ASSIGN 701 IP Version = 6 702 IP Address = 2001:db8::1234:1234 703 IP Prefix Length = 128 705 STREAM(44): CAPSULE 706 Capsule Type = ROUTE_ADVERTISEMENT 707 (IP Version = 4 708 Start IP Address = 198.51.100.2 709 End IP Address = 198.51.100.2 710 IP Protocol = 17), 711 (IP Version = 6 712 Start IP Address = 2001:db8::3456 713 End IP Address = 2001:db8::3456 714 IP Protocol = 17) 715 ... 717 DATAGRAM 718 Quarter Stream ID = 11 719 Context ID = 0 720 Payload = Encapsulated IPv6 Packet 722 DATAGRAM 723 Quarter Stream ID = 11 724 Context ID = 0 725 Payload = Encapsulated IPv4 Packet 727 Figure 13: Proxied Connection Racing Example 729 8. Security Considerations 731 There are significant risks in allowing arbitrary clients to 732 establish a tunnel to arbitrary servers, as that could allow bad 733 actors to send traffic and have it attributed to the proxy. Proxies 734 that support CONNECT-IP SHOULD restrict its use to authenticated 735 users. The HTTP Authorization header [AUTH] MAY be used to 736 authenticate clients. More complex authentication schemes are out of 737 scope for this document but can be implemented using CONNECT-IP 738 extensions. 740 Since CONNECT-IP endpoints can proxy IP packets send by their peer, 741 they SHOULD follow the guidance in [BCP38] to help prevent denial of 742 service attacks. 744 9. IANA Considerations 746 9.1. CONNECT-IP HTTP Upgrade Token 748 This document will request IANA to register "connect-ip" in the HTTP 749 Upgrade Token Registry maintained at 750 . 752 Value: connect-ip 754 Description: The CONNECT-IP Protocol 756 Expected Version Tokens: None 758 References: This document 760 9.2. Capsule Type Registrations 762 This document will request IANA to add the following values to the 763 "HTTP Capsule Types" registry created by [HTTP-DGRAM]: 765 +==========+=====================+====================+===========+ 766 | Value | Type | Description | Reference | 767 +==========+=====================+====================+===========+ 768 | 0xfff100 | ADDRESS_ASSIGN | Address Assignment | This | 769 | | | | Document | 770 +----------+---------------------+--------------------+-----------+ 771 | 0xfff101 | ADDRESS_REQUEST | Address Request | This | 772 | | | | Document | 773 +----------+---------------------+--------------------+-----------+ 774 | 0xfff102 | ROUTE_ADVERTISEMENT | Route | This | 775 | | | Advertisement | Document | 776 +----------+---------------------+--------------------+-----------+ 778 Table 1: New Capsules 780 10. References 782 10.1. Normative References 784 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 785 Defeating Denial of Service Attacks which employ IP Source 786 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 787 May 2000, . 789 [EXT-CONNECT2] 790 McManus, P., "Bootstrapping WebSockets with HTTP/2", 791 RFC 8441, DOI 10.17487/RFC8441, September 2018, 792 . 794 [EXT-CONNECT3] 795 Hamilton, R., "Bootstrapping WebSockets with HTTP/3", Work 796 in Progress, Internet-Draft, draft-ietf-httpbis-h3- 797 websockets-04, 8 February 2022, 798 . 801 [HTTP-DGRAM] 802 Schinazi, D. and L. Pardue, "Using Datagrams with HTTP", 803 Work in Progress, Internet-Draft, draft-ietf-masque-h3- 804 datagram-06, 4 March 2022, 805 . 808 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 809 Multiplexed and Secure Transport", RFC 9000, 810 DOI 10.17487/RFC9000, May 2021, 811 . 813 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 814 Requirement Levels", BCP 14, RFC 2119, 815 DOI 10.17487/RFC2119, March 1997, 816 . 818 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 819 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 820 May 2017, . 822 [SEMANTICS] 823 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 824 Semantics", Work in Progress, Internet-Draft, draft-ietf- 825 httpbis-semantics-19, 12 September 2021, 826 . 829 [TEMPLATE] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 830 and D. Orchard, "URI Template", RFC 6570, 831 DOI 10.17487/RFC6570, March 2012, 832 . 834 10.2. Informative References 836 [AUTH] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 837 Protocol (HTTP/1.1): Authentication", RFC 7235, 838 DOI 10.17487/RFC7235, June 2014, 839 . 841 [CONNECT-UDP] 842 Schinazi, D., "UDP Proxying Support for HTTP", Work in 843 Progress, Internet-Draft, draft-ietf-masque-connect-udp- 844 07, 4 March 2022, . 847 [HEv2] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 848 Better Connectivity Using Concurrency", RFC 8305, 849 DOI 10.17487/RFC8305, December 2017, 850 . 852 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 853 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 854 December 2005, . 856 [PROXY-REQS] 857 Chernyakhovsky, A., McCall, D., and D. Schinazi, 858 "Requirements for a MASQUE Protocol to Proxy IP Traffic", 859 Work in Progress, Internet-Draft, draft-ietf-masque-ip- 860 proxy-reqs-03, 27 August 2021, 861 . 864 Acknowledgments 866 The design of this method was inspired by discussions in the MASQUE 867 working group around [PROXY-REQS]. The authors would like to thank 868 participants in those discussions for their feedback. 870 Authors' Addresses 872 Tommy Pauly (editor) 873 Apple Inc. 874 Email: tpauly@apple.com 876 David Schinazi 877 Google LLC 878 Email: dschinazi.ietf@gmail.com 880 Alex Chernyakhovsky 881 Google LLC 882 Email: achernya@google.com 884 Mirja Kuehlewind 885 Ericsson 886 Email: mirja.kuehlewind@ericsson.com 888 Magnus Westerlund 889 Ericsson 890 Email: magnus.westerlund@ericsson.com