idnits 2.17.1 draft-kuehlewind-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1009 lines 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 (12 July 2021) is 1018 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 (-19) exists of draft-ietf-httpbis-messaging-16 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-messaging' == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-16 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-semantics' == Outdated reference: A later version (-15) exists of draft-ietf-masque-connect-udp-03 == Outdated reference: A later version (-11) exists of draft-ietf-masque-h3-datagram-02 == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-02 == Outdated reference: A later version (-03) exists of draft-ietf-masque-ip-proxy-reqs-02 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MASQUE M. Kuehlewind 3 Internet-Draft M. Westerlund 4 Intended status: Standards Track M. Ihlar 5 Expires: 13 January 2022 Z. Sarker 6 Ericsson 7 12 July 2021 9 The CONNECT-IP HTTP method for proxying IP traffic 10 draft-kuehlewind-masque-connect-ip-01 12 Abstract 14 This draft specifies a new HTTP method CONNECT-IP to proxy IP 15 traffic. CONNECT-IP uses HTTP/3 Datagrams to use QUIC Datagrams for 16 efficient transport of proxied IP packets, with the possibility to 17 fallback to HTTP/3 over reliable QUIC streams, or even HTTP 1.x and 18 2. 20 CONNECT-IP supports two modes: a tunneling mode where IP packets are 21 forwarded without modifications and flow forwarding mode which 22 supports optimization for individual IP flows forwarded to the 23 targeted peer. To request tunneling or flow forwarding, a client 24 connects to a proxy server by initiating a HTTP/3 connection and 25 sends a CONNECT-IP request which either indicates the address of the 26 proxy or the target peer. The proxy then forwards payload received 27 on that stream or in an HTTP datagram with a certain stream ID. 29 Discussion Venues 31 This note is to be removed before publishing as an RFC. 33 Discussion of this document takes place on the MASQUE Working Group 34 mailing list (masque@ietf.org), which is archived at 35 https://mailarchive.ietf.org/arch/browse/masque/. 37 Source for this draft and an issue tracker can be found at 38 https://github.com/mirjak/draft-kuehlewind-masque-connect-ip. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on 13 January 2022. 57 Copyright Notice 59 Copyright (c) 2021 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 64 license-info) in effect on the date of publication of this document. 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. Code Components 67 extracted from this document must include Simplified BSD License text 68 as described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction 74 1.1. Tunnel mode 75 1.2. Flow Forwarding mode 76 1.2.1. Motivation of IP flow model for flow forwarding 77 1.3. Definitions 78 2. The CONNECT-IP method 79 2.1. Data encapsulation 80 2.2. Datagram Formats 81 2.2.1. Tunnel Mode IPv4 Format 82 2.2.2. Tunnel Mode IPv6 Format 83 2.2.3. Flow Forwarding Format 84 2.2.4. ICMP Message Format 85 3. HTTP Headers 86 3.1. IP-Protocol Header for CONNECT-IP 87 3.2. IP-Version header for CONNECT-IP 88 3.3. IP-Address header for CONNECT-IP 89 3.4. IP-Address-Handling Header for CONNECT-IP 90 3.5. Conn-ID Header for CONNECT-IP 91 4. Client Connect-IP Request 92 4.1. Requesting flow forwarding 93 4.2. Requesting tunnel mode 94 5. MASQUE server behavior 95 5.1. Error handling 96 5.2. IP address selection in flow forwarding mode 97 5.3. Constructing the IP header in flow forwarding mode 98 5.4. Decapsulation of tunnel mode IP Packets 99 5.5. Receiving an IP packet 100 6. Additional signalling 101 6.1. ECN 102 6.2. ICMP handling 103 6.3. MTU considerations 104 7. Examples 105 8. Security considerations 106 9. IANA considerations 107 9.1. HTTP Method 108 9.2. HTTP Header 109 Acknowledgments 110 References 111 Normative References 112 Informative References 113 Authors' Addresses 115 1. Introduction 117 This document specifies the CONNECT-IP method for IPv4 [RFC0791] and 118 IPv6 [RFC8200] tunneling and flow forwarding over HTTP/3. 120 CONNECT-IP supports two modes: a tunneling mode where IP packets are 121 forwarded without modifications and flow forwarding mode which 122 supports optimization for individual IP flows forwarded to the 123 targeted peer. 125 1.1. Tunnel mode 127 In tunnel mode the client requests to tunnel IP packets to and from 128 one or more servers via the proxy. The Connect-IP request to the 129 proxy establishes such a tunnel and optionally indicates the IP 130 address or IP address range that will be allowed to be used by and 131 forwarded to the client. 133 The tunnel mode is indicated by the ":authority" pseudo-header field 134 of the CONNECT-IP request contain the host and listing port of the 135 proxy itself. In this mode the proxy just blindly forwards all 136 payload on its external interface without any modification and also 137 forwards all incoming traffic to registered clients as payload within 138 the respective tunnel association. That means all incoming traffic, 139 where the destination address matches an by the client indicated IP 140 address or range of IP addresses, is forwarded to the client over the 141 tunnel association, except a more specific flow forwarding 142 association exists where both destination and source IP address as 143 well as any additionally used identifier match (see section 144 Section 5.5). 146 However, a proxy MUST offer this service only for known clients and 147 clients MUST be authenticated during connection establishment. The 148 proxy SHOULD inspect the source IP address of the IP packet in the 149 tunnel payload and only forward if the IP address matches the set of 150 client IP addresses. Optionally, a proxy also MAY offer this service 151 only for a limited set of target addresses. In such a case the proxy 152 SHOULD also inspect the destination IP address of the tunnel payload 153 as well as the source address of incoming packets from target servers 154 and reject packets with unknown addresses with an error. 156 1.2. Flow Forwarding mode 158 In flow forwarding mode the CONNECT-IP method establishes an outgoing 159 IP flow, from the MASQUE server's external address to the target 160 server's address specified by the client for a particular upper layer 161 protocol. This mode also enables reception and relaying of the 162 reverse IP flow from the target address to the MASQUE server to 163 ensure that return traffic can be received by the client. However, 164 it does not support flow establishment by an external peer. This 165 specification supports forwarding of incoming traffic to one of the 166 clients only if an active mapping has previously been created based 167 on an IP-CONNECT request. Clients that need to support reception of 168 flows established by external peer need to use tunnel mode. 170 This mode covers the point-to-point use case 171 [I-D.ietf-masque-ip-proxy-reqs] and allows for flow-based 172 optimizations and a larger effective maximum packet size through the 173 tunnel. The target IP address is provided by the client as part of 174 the CONNECT-IP request. The sources address is either independently 175 selected by the proxy or can be requested to be either the same as 176 used in a previous and currently active CONNECT-IP request or 177 different from currently requests by the same client. The client 178 also indicates the upper layer protocol, thus defining the three 179 tuple used as primary selector for the flow. 181 In this mode the payload between the client and proxy does not 182 contain the IP header in order to reduce overhead. Any additional 183 information (other than the source and destination IP addresses and 184 ports as well as the upper layer protocol identifier) that is needed 185 to construct the IP header or to inform the client about information 186 from received IP packets can be signalled as part of the CONNECT-IP 187 request or using HTTP/3 Datagram [I-D.ietf-masque-h3-datagram] later. 189 In flow forwarding mode, usually one upper-layer end-to-end 190 connection is associated to one CONNECT-IP forwarding association. 191 While it would be possible for a client to use the same forwarding 192 association for multiple end-to-end connections to the same target 193 server, as long as they all require the same Protocol (IPv4) / Next 194 Header (IPv6) value, this would lead to the use of the same flow ID 195 for all connections. As such, this is not recommended for 196 connection-oriented transmissions. In order to enable multiple flow 197 forwarding associations to the same server, the flow forwarding mode 198 supports a way to specify some additional upper layer protocol 199 selectors, e.g. TCP source and destination port, to enable multiple 200 CONNECT-IP request for the same three tuple, see CONN-ID header 201 Section 3.5. 203 The default model for address handling in this specification is that 204 the proxy (Masque Server) will have a pool of one or more IP 205 addresses that it can lend to the MASQUE client and routable over its 206 external interface. Other potential use cases and address handling 207 are possible, potentially requiring further extensions. 209 This proposal is based on the analysis provided in 210 [I-D.westerlund-masque-transport-issues] indicating that most 211 information in the IP header is either IP flow related or can or even 212 should be provided by the proxy as the IP communication endpoint 213 without the need for input from the client. The most crucial 214 information identified that requires client interaction is ECN 215 [RFC3168] and ICMP [RFC0792] [RFC4443] handling. 217 This document defines the following IP header field treatment. 219 Required to be determined in Connect-IP request and response: 221 * IP version 223 * IP Source Address 225 * IP Destination Address (target address) 227 * Upper Layer Protocol (IPv4 Protocol field / IPv6 Next Header 228 field) 230 Can be chosen by Proxy on transmission: 232 * IPv6 Flow label (per Connect-IP flow mode request) 234 * IPv4 Time to live / IPv6 Hop Limit (proxy configured) 236 * Diffserv Codepoint, default is set to 0 (Best Effort) 238 May optionally be provided on a per packet basis 240 * Explicit Congestion Notification in both directions. 242 The consequence of this is certain limitations that future extension 243 can address. For packets that are sent from the target server to the 244 client, the client will not get any information on the actual value 245 of TTL/Hop Count, DSCP, or flow label when received by the proxy. 246 Instead these field are set and consumed by the proxy only. 248 Signalling of other dedicated values may be desired in certain 249 deployments, e.g for DCSP [RFC2474]. However, DSCP is in any case a 250 challenge due to local domain dependency of the used DSCP values and 251 the forwarding behavior and traffic treatment they represent. Future 252 use cases for DSCP, as well as new IPv6 extension headers or 253 destination header options [RFC8200] may require additional 254 signaling. Therefore, it is important that the signaling is 255 extensible. 257 1.2.1. Motivation of IP flow model for flow forwarding 259 The chosen IP flow model is selected due to several advantages: 261 * Minimized per packet overhead: The per packet overhead is reduced 262 to basic framing of the IP payload for each IP packet and flow 263 identifiers. This enables a larger effective Maximum Transmission 264 Unit (MTU) than tunnel mode. 266 * Shared functionality with CONNECT-UDP: The UDP flow proxying 267 functionality of CONNECT-UDP will need to establish, store and 268 process the same IP header related fields and state. So this can 269 be accomplished by simply removing the UDP specific processing of 270 packets. 272 * CONNECT-IP can establish a new IP flow in 0-RTT: No network 273 related latencies in establishing new flow. 275 Disadvantages of this model are the following: 277 * Client to server focused solution: Accepting non-solicited peer- 278 initiated traffic is not supported. 280 1.3. Definitions 282 * Proxy: This document uses proxy as synonym for the MASQUE Server 283 or an HTTP proxy, depending on context. 285 * Client: The endpoint initiating a MASQUE tunnel and IP relaying 286 with the proxy. 288 * Target host: A remote endpoint the client wishes to establish bi- 289 directional communication with via tunnelling over the proxy. 291 * IP proxying: A proxy forwarding IP payloads to a target for an IP 292 flow. Data is decapsulate at the proxy and amended by a IP header 293 before forwarding to the target. Packet boundaries need to be 294 preserved or signalled between the client and proxy. 296 * IP flow: A flow of IP packets between two hosts as identified by 297 their IP addresses, and where all the packets share some 298 properties. These properties include source/destination address, 299 protocol / next header field, flow label (IPv6 only), and DSCP per 300 direction. 302 Address = IP address 304 Target Address --+ 305 \ 306 +--------+ +--------+ \ +--------+ 307 | | Path #1 | | Path #2 V| | 308 | Client |<--------->| Proxy |<--------->| Target | 309 | | ^| |^ | | 310 +--------+ / +--------+ \ +--------+ 311 / \ 312 / +-- Proxy's external address 313 / 314 +-- Proxy's service address 316 Figure 1: The nodes and their addresses 318 Figure 1 provides an overview figure of the involved nodes, i.e. 319 client, proxy, and target host. There are also two network paths. 320 Path #1 is the client to proxy path, where IP proxying is provided 321 over an HTTP/3 session, usually over QUIC, to tunnel IP flow(s). 322 Path #2 is the path between the proxy and the target. 324 The client will use the proxy's service address to establish a 325 transport connection on which to request IP proxying using HTTP/3 326 CONNECT-IP. The proxy will then relay the client's IP flows to the 327 target host. The IP header from the proxy to the target carries the 328 proxy's external address as source address and the target's address 329 as destination address. 331 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 332 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 333 "OPTIONAL" in this document are to be interpreted as described in BCP 334 14 [RFC2119] [RFC8174] when, and only when, they appear in all 335 capitals, as shown here. 337 2. The CONNECT-IP method 339 This document defines a new HTTP [I-D.ietf-httpbis-semantics] method 340 CONNECT-IP to convert streams into tunnels or initialize HTTP 341 datagram flows [I-D.ietf-masque-h3-datagram] to a forwarding proxy. 342 Each stream can be used separately to establish forwarding to 343 potentially different remote hosts. Unlike the HTTP CONNECT method, 344 CONNECT-IP does not request the proxy to establish a TCP connection 345 to the remote target host. Instead the tunnel payload will be 346 forwarded as individual IP packets (tunnel mode) or right on top of 347 the IP layer (flow forwarding), meaning the proxy has to identify 348 messages boundaries to each message before forwarding (see section 349 Section 5). 351 This document specifies CONNECT-IP for HTTP following the same 352 semantics as the CONNECT method. As such a CONNECT-IP request MUST 353 be constructed as follows: 355 * The ":method" pseudo-header field is set to "CONNECT-IP" 357 * The ":scheme" and ":path" pseudo-header fields are omitted 359 * The ":authority" pseudo-header field contains either the host 360 address to connect to (equivalent to the authority-form of the 361 request-target of CONNECT-UDP [I-D.ietf-masque-connect-udp] or 362 CONNECT requests; see Section 3.2.3 of 363 [I-D.ietf-httpbis-messaging]) or the host and port of the proxy if 364 tunnel mode is requested 366 A CONNECT request that does not conform to these restrictions is 367 malformed; see Section 4.1.3 of [I-D.ietf-quic-http]. 369 Unlike the CONNECT method, CONNECT-IP does not sequentially trigger a 370 connection establishment process from the proxy to the target host. 371 Therefore, the client does not need to wait for an HTTP response in 372 order to send forwarding data, unless in tunnel mode and requesting 373 assignment of an external IP address. However, the client, 374 especially on tunnel mode, SHOULD limit the amount of traffic sent to 375 the proxy before a 2xx (Successful) response is received. 377 The forwarding stays active as long as the respective stream is open. 378 A Forwarded IP packet can be either an encapsulated HTTP datagram on 379 the same HTTP stream as the CONNECT-IP request, or as a HTTP datagram 380 sent over QUIC datagram. 382 2.1. Data encapsulation 384 Once the CONNECT-IP method has completed, only CAPSULE 385 [I-D.ietf-masque-h3-datagram] frames are permitted to be sent on that 386 stream. Extension frames MAY be used if specifically permitted by 387 the definition of the extension. Receipt of any other known frame 388 type MUST be treated as a connection error of type 389 H3_FRAME_UNEXPECTED. 391 Each HTTP Datagram frame contains one of the below specified data 392 formats (Section 2.2) depending on request forwarding mode and given 393 headers and parameters. 395 Stream based forwarding provides in-order and reliable delivery but 396 may introduce Head of Line (HoL) Blocking if independent messages are 397 send over the same CONNECT-IP association. On streams payload data 398 is encapsulated in the CAPSULE Frame using the DATAGRAM capsule 399 (type=0x02) [I-D.ietf-masque-h3-datagram]. 401 The client can, in addition to stream-based forwarding, request use 402 of HTTP/3 datagrams [I-D.ietf-masque-h3-datagram]. 404 To request datagram support the client sends H3_DATAGRAM SETTINGS 405 parameter with a value of 1 [I-D.ietf-masque-h3-datagram]. Datagram 406 support MUST only be requested when the QUIC datagram extension 407 [I-D.ietf-quic-datagram] was successfully negotiated during the QUIC 408 handshake. 410 Datagrams provide un-ordered and unreliable delivery. In theory 411 both, stream- as well as datagram-based forwarding, can be used in 412 parallel, however, for most transmissions it is expected to only use 413 one. 415 While IP packets sent over streams only have to respect the end-to- 416 end MTU between the client and the target server, packets sent in 417 datagrams are further restricted by the QUIC packet size of the QUIC 418 tunnel and any overhead within the QUIC tunnel packet. Ideally, the 419 proxy can provide MTU and overhead information to the client. The 420 client MUST take the estimated overhead into account when indicating 421 the MTU to the application (see section Section 6.3). 423 2.2. Datagram Formats 425 This section defines the different datagram formats used by Connect- 426 IP. Even if only one format is currently used it is expected that 427 for some usages future extension may require the flexibility to use 428 multiple different formats for a given CONNECT-IP request. 430 2.2.1. Tunnel Mode IPv4 Format 432 The Datagram contains one full IPv4 Packet per [RFC0791]. Used in 433 tunnel mode and when the IP Version is 4 per the IP-Version header or 434 explicit given target address. 436 2.2.2. Tunnel Mode IPv6 Format 438 The Datagram contains one full IPv6 Packet per [RFC8200]. Used in 439 tunnel mode and when the IP Version is 6 per the IP-Version header or 440 explicit given target address. 442 2.2.3. Flow Forwarding Format 444 The Datagram contains only the IP payload. This is defined as the 445 payload following the IPv4 header and any options for IPv4, and for 446 IPv6 as the payload following the IPv6 header and any extension 447 header. Used for Flow Forwarding mode. 449 2.2.4. ICMP Message Format 451 This datagram contains a summary message of the ICMP message received 452 and validated for the respective IP flow. The message format carries 453 the ICMP packet for ICMPv4 [RFC0792] or ICMPv6 [RFC4443]. This 454 format is chosen for forward compatibility. From an implementation 455 perspective the client don't need to verify the checksum or validate 456 the header fields because that is done by the server. However, some 457 type codes, like IMCPv4 type 2, (Packet Too Big) carries an MTU field 458 that the implementation want to read beyond understanding the meaning 459 of the type and code combination. 461 3. HTTP Headers 463 Note: This section should be improved by clarifying if headers are in 464 request, response or both. 466 3.1. IP-Protocol Header for CONNECT-IP 468 In order to construct the IP header the the proxy needs to fill the 469 "Protocol" field in the IPv4 header or "Next header" field in the 470 IPv6 header. As the IP payload is otherwise mostly opaque to the 471 proxy, this information has to be provided by the client for each 472 CONNECT-IP request for flow forwarding. 474 IP-Protocol is a Item Structured Header [RFC8941]. Its value MUST be 475 an Integer. Its ABNF is: 477 IP-Protocol = sf-integer 479 3.2. IP-Version header for CONNECT-IP 481 IP-Version is a Item Structured Header [RFC8941]. Its value MUST be 482 an Integer and either 4 or 6. This information is used by the proxy 483 to check if the requested IP version is supported by the network that 484 the proxy is connected to, as well as to check the destination or 485 source IP address for compliance. 487 IP-Version = sf-integer 489 3.3. IP-Address header for CONNECT-IP 491 IP-Address is an Item Structured Header [RFC8941]. Its value MUST be 492 an String contain an IP address or IP address range of the same IP 493 version as indicated in the IP-Version header. The address must be 494 specified in the format specified by TBD. 496 This header is used to request the use of a certain IP address or IP 497 address range by the client to be used as source IP address in tunnel 498 mode. If the IP-Address header is not presented, the proxy is 499 implicitly requested to assign an IP address or IP address range and 500 provide this information to the client with the HTTP response. 502 If the the client does not provide an IP address or IP address range 503 is has to wait for the proxy response before any payload data can be 504 sent in tunnel mode. If the request is denied by the proxy, any sent 505 payload data will be discarded and a new CONNECT-IP request has to be 506 sent. 508 The header is also used as a response header from the proxy to the 509 client to indicate the actual IP address or IP address range that 510 should be used by the client in tunnel mode or will be used by the 511 proxy in flow forwarding mode. 513 IP-Address = sf-string 515 3.4. IP-Address-Handling Header for CONNECT-IP 517 This header can be used to request the use of a stable address for 518 multiple active flow forwarding associations. The first association 519 will be established with an IP selected by the proxy unless also the 520 IP-Address header (Section 3.3) is provided and accepted by proxy. 521 However, additional forwarding association can be requested by the 522 client to use the same IP address as a previous request by specifying 523 the stream ID as value in this header. This header can also be used 524 to ensure that a "new", not yet for this client used address is 525 selected by setting a value that is larger than the maximum stream 526 ID. 528 IP-Address-Handling is a Item Structured Header [RFC8941]. Its value 529 MUST be an Integer and indicates the stream ID of the corresponding 530 active flow forwarding association. Its ABNF is: 532 IP-Address-Handling = sf-integer 534 3.5. Conn-ID Header for CONNECT-IP 536 This document further defines a new header field to be used with 537 CONNECT-IP "Conn-ID". The Conn-ID HTTP header field indicates the 538 value, offset, and length of a field in the IP payload that can be 539 used by the proxy as a connection identifier in addition to the IP 540 address and protocol tuple when multiple connections are proxied to 541 the same target server for incoming traffic on the service address. 543 Conn-ID is a Item Structured Header [RFC8941]. Its value MUST be a 544 Byte Sequence. Its ABNF is: 546 Conn-ID = sf-binary 548 The following parameters are defined: 550 * A parameter whose name is "offset", and whose value is an Integer 551 indicating the offset of the identifier field starting from the 552 beginning of a datagram or HTTP frame on the forwarding stream. 554 * A parameter whose name is "length", and whose value is an Integer 555 indicating the length of the identifier field starting from the 556 offset. 558 Both parameters MUST be present and the header MUST be ignored if 559 these parameter are not present. 561 This function can be used to e.g. indicate the source port field in 562 the IP payload when containing a TCP packet. 564 4. Client Connect-IP Request 566 4.1. Requesting flow forwarding 568 To request flow forwarding, the client sends a CONNECT-IP request to 569 the forwarding proxy indicating the target host and port in the 570 ":authority" pseudo-header field. The host portion is either an IP 571 literal encapsulated within square brackets, an IPv4 address in 572 dotted-decimal form, or a registered name. Further the CONNECT-IP 573 request MUST contain the IP-Protocol header (Section 3.1) and MAY 574 contain the IP-Address-Handling (Section 3.4) or the Conn-ID 575 (Section 3.5) header. 577 4.2. Requesting tunnel mode 579 In tunnel mode, the CONNECT-IP request MUST contain the IP-Version 580 header to indicate if IPv4 or IPv6 is used for the IP packet in the 581 tunnel payload. Further, the request MAY contain an IP-Address 582 header to request use of an IP address or IP address range. 584 5. MASQUE server behavior 586 Upon the establishment of a HTTP Connection with the proxy on its 587 service addresses. HTTP level capabilities will be exchanged in the 588 HTTP SETTINGS frame. This will determine if support of datagrams is 589 indicated. If indicated by the client, the MASQUE server SHALL send 590 a H3_DATAGRAM SETTINGS parameter with a value of 1 to indicates is 591 support. 593 A MASQUE server that receives an IP-CONNECT request examines the 594 target URL to determine if this request is for tunnel or flow 595 forwarding mode. Based on the mode it determines if the required 596 headers are present and which of the optional headers that are 597 included. 599 The proxy maintains a database with mappings between the HTTP 600 connections and stream IDs and the IP level selectors and Conn-ID 601 information. Using this database and the pool of available addresses 602 and the requests IP-Address-Handling, Conn-ID, IP-Version, IP-Address 603 headers (if included) to select a source IP address. This selection 604 for flow forwarding mode is further discussed below in Section 5.2. 605 For Tunnel Mode, the proxy determine if the proposed IP address per 606 IP-Version and IP-Address headers is possible to use if included, 607 else selects a otherwise unused address from its pool. For tunnel 608 mode the IP selector for incoming traffic for this HTTP Connection 609 and Stream ID is simply the IP destination address. 611 Once the mapping is successfully established, the proxy sends a 612 HEADERS frame containing a 2xx series status code to the client. The 613 response MUST contain an IP-Address header indicating the outgoing 614 source IP address or IP address range selected by the proxy. 616 All Datagram capsules received on that stream as well as all HTTP/3 617 datagrams belonging to this CONNECT-IP association are processed for 618 forwarding to the target server. For flow forwarding mode the 619 Datagram is processed as specified in Section 5.3 to produce IP 620 packets that can be forwarded. For tunnel-mode the complete IP 621 packet are extracted from the Datagram and then forwarded as 622 specified in Section 5.4. 624 IP packets received from the target server are mapped to an active 625 forwarding connection and are respectively forwarded in an CAPSULE 626 DATAGRAM frame or HTTP/3 datagram to the client (see section 627 Section 5.5 below). 629 5.1. Error handling 631 TBD (e.g. out of IP address, conn-id collision) 633 5.2. IP address selection in flow forwarding mode 635 In flow forwarding mode the proxy constructs the IP header when 636 sending the IP payload towards the target server and it selects an 637 source IP address from its pool of IP addresses that are routed to 638 the MASQUE server. 640 If no additional information about a payload field that can be used 641 as an identifier based on Conn-ID header is provided by the client, 642 the proxy uses the source/destination address and protocol ID 3-tuple 643 in order to map an incoming IP packet to an active forwarding 644 connection. The proxy MUST also consider if IP-Address-Handling 645 header Section 3.4 is included and its value. If the IP-Address- 646 Handling header is not included and the there has been prior request 647 the proxy SHOULD give the client the same source Address as the first 648 flow forwarding request. Given these constraints the MASQUE proxy 649 MUST select a source IP address that leads to a unique tuple, and if 650 that is not possible an error response is generated. The same IP 651 address MAY be used for different clients when those client connect 652 to different target servers. However, this also means that 653 potentially multiple IP address are used for the same client when 654 multiple connection to one target server are needed. This can be 655 problematic if the source address is used by the target as an 656 identifier. Therefore it is RECOMMENDED that clients are given 657 unique addresses unless a large fraction of the pool has been 658 exhausted. 660 If the Conn-ID header is provided, the proxy should use that field as 661 an connection identifier together with protocol ID, source and 662 destination address, as a 4-tuple. In this case it is recommended to 663 use a stable IP address for each client, while the same IP address 664 might still be used for multiple clients, if not indicated 665 differently by the client in the configuration file. Note that if 666 the same IP address is used for multiple clients, this can still lead 667 to an identifier collision and the IP-CONNECT request MUST be reject 668 if such a collision is detect. 670 Note: Are we allowing multiple client's to share the same 3-tuple 671 when using Conn-ID? It might be good for privacy reasons however, it 672 significantly increases the collision risk. 674 5.3. Constructing the IP header in flow forwarding mode 676 To retrieve the source and destination address the proxy looks up the 677 mapping for the datagram flow ID or stream identifier. The IP 678 version, flow label, DiffServ codepoint (DSCP), and hop limit/TTL is 679 selected by the proxy. The IPv4 Protocol or IPv6 Next Header field 680 is set based on the information provided by the IP-Protocol header in 681 the CONNECT-IP request. 683 The proxy MUST set the Don't Fragment (DF) flag in the IPv4 header. 684 Payload that does not fit into one IP packet MUST be dropped. A 685 dropping indication should be provided to the client. Further the 686 proxy should provide MTU information. 688 The ECN field is by default set to non-ECN capable transport (non- 689 ECT). Further ECN handling is described in Section Section 6.1. 691 5.4. Decapsulation of tunnel mode IP Packets 693 On receiving an HTTP Datagram containing any of the tunnel mode 694 formats for IPv4 or IPv6 the proxy extracts the full IP packet. 696 The proxy MUST verify that the extracted IP packet's source IP 697 address matches any address associated with this CONNECTION-IP 698 request, i.e. the assigned address or IP range. This is to prevent 699 source address spoofing in tunnel mode. 701 Further the proxy should verify that the IP header length field 702 correspond to the extracted packets length. 704 5.5. Receiving an IP packet 706 When the proxy receives an incoming IP packet on the external 707 interface(s), it checks the packet selectors to find the mappings 708 that match the given packet. 710 If a client has a tunnel as well as multiple flow forwarding 711 associations, the proxy need to check the mappings for the flow 712 forwarding associations first, and only send it over the the tunnel 713 association if no active flow forwarding is found. 715 If one or more mappings exists, it further checks if this mapping 716 contains additional identifier information as provided by the Conn-ID 717 Header of the CONNECT-IP request. If this field maps as well, the IP 718 payload is forwarded to the client. If no active mapping is found, 719 the IP packet is discarded. 721 The above is achieve by using the selector with the most number of 722 fields that match the packet. 724 If both datagram and stream based forwarding is supported, it is 725 recommended for the proxy to use the same encapsulation as most 726 recently used by the client or datagrams as default. Further 727 considerations might be needed here. 729 6. Additional signalling 731 Context ID as defined by [I-D.ietf-masque-h3-datagram] can be used to 732 provide additional per association or per-payload signals. As 733 [I-D.ietf-masque-h3-datagram] is still work in progress, registration 734 and use of Context IDs is left for future work at this point. 736 6.1. ECN 738 ECN requires coordination with the end-to-end communication points as 739 it should only be used if the endpoints are also capable and willing 740 to signal congestion notifications to the other end and react 741 accordingly if a congestion notification is received. 743 The probing and verification in the upper layer protocol of end-to- 744 end ECN requires per packet control over what value is set on IP 745 packet transmission as well as which of all values are received by 746 the proxy. The QUIC specification is providing one such example in 747 Section 13.4 of [RFC9000]. Thus in flow forwarding mode the proxy 748 needs to be able to set and read the ECN values in sent and received 749 IP packets respectively. This may motivate that this functionality 750 is optional to implement, even if supporting CONNECT-IP 751 implementations in general will need to handle IP packets and their 752 fields with fine grained control. If optional some negotiation 753 mechanism is needed. 755 Possible realizations are: 757 a) always have two bits before payload in flow forwarding model, e.g. 758 by including the whole Type of Service (TOS) byte, which would also 759 enable DSCP setting and reading. 761 b) use 4 different context IDs depending on what ECN field value was 762 received or should be set. 764 This is work in process and will be further specified in a future 765 version of this document. 767 6.2. ICMP handling 769 ICMP messages are directly forwarded in tunneling mode. In flow 770 forwarding mode a ICMP datagram format (Section 2.2.4) is used to 771 send the information from some ICMP message to the client. 773 The proxy upon receiving an ICMP message with a destination of an IP 774 address it performs flow forwarding on it needs to process the ICMP 775 message. First it should validate that the ICMP message and find if 776 it matches any of its IP flow selectors (including Conn-ID). In case 777 there are multiple matching use the IP selector with the most number 778 of field that matches fully. 780 Some messages may be applicable both to the proxy and the client. 781 For example an verified ICMPv6 Packet Too Big is applicable both to 782 the proxy and the client. Others like ICMPv6 Destination Unreachable 783 (Type=1), Code=3 (Address unreachable) and Code=4 (Port unreachable) 784 is only possible to act on by the client. 786 QUESTION: Which ICMP messages should be suppressed by the proxy? 788 If a matching IP selector was chosen, then lookup the mapping for the 789 HTTP connection and Stream ID which this message should be sent to. 790 Encapsulate the received ICMP message in the ICMP datagram format and 791 send it to the client. 793 6.3. MTU considerations 795 The use of QUIC as a encapsulation between the client and proxy 796 introduces additional overhead. If datagrams are used to encapsulate 797 packets between the proxy and client, the end-to-end packets must fit 798 within one datagram but the size of the datagrams is limited by the 799 tunneling encapsulation overhead. 801 In forwarding mode the client is usually also the tunnel endpoint 802 that knows about the tunnel overhead and can therefore restrict the 803 size of the packets on the end-to-end connection accordingly. 804 However, the target endpoint is usually not aware of the tunnel 805 overhead. Additional signalling on the end-to-end connection from 806 the client to the target endpoint might be needed to restrict the 807 packet size. If QUIC is also used as end-to-end protocol, this could 808 be realized by the transport parameter. In additional, signal from 809 the proxy to the client could be provided as an extension to indicate 810 the tunnel overhand more accurately and flexibly over time. Such 811 signalling might the realized on the HTTP layer in order to take any 812 additional limitations by HTTP intermediates into account. 814 If the proxy receives an incoming packet from a target endpoint that 815 is too big to fit within a datagram on the tunnel connection, the 816 proxy MAY either forward the packet encapsulated in the CAPSULE 817 frames on the respective stream or, if IPv4 with DF bit set or IPv6 818 is used, the proxy MAY reject the packet and send an ICMPv4 Packet 819 type 3 code 4, or ICMPv6 Too Big (PTB) message. 821 7. Examples 823 TBD 825 8. Security considerations 827 This document does currently not discuss risks that are generic to 828 the MASQUE approach. 830 Any CONNECT-IP specific risks need further consideration in future, 831 especially when the handling of IP functions is defined in more 832 detail. 834 9. IANA considerations 836 9.1. HTTP Method 838 This document (if published as RFC) registers "CONNECT-IP" in the 839 HTTP Method Registry maintained at . 842 +--------------+------+------------+---------------+ 843 | Method Name | Safe | Idempotent | Reference | 844 +--------------+------+------------+---------------+ 845 | CONNECT-IP | no | no | This document | 846 +--------------+------+------------+---------------+ 848 9.2. HTTP Header 850 This document (if published as RFC) registers the following header in 851 the "Permanent Message Header Field Names" registry maintained at 852 . 854 +---------------------+----------+--------+---------------+ 855 | Header Field Name | Protocol | Status | Reference | 856 +---------------------+----------+--------+---------------+ 857 | Conn-ID | http | exp | This document | 858 +---------------------+----------+--------+---------------+ 859 | IP-Protocol | http | exp | This document | 860 +---------------------+----------+--------+---------------+ 861 | IP-Address | http | exp | This document | 862 +---------------------+----------+--------+---------------+ 863 | IP-Address-Handling | http | exp | This document | 864 +---------------------+----------+--------+---------------+ 865 | IP-Verison | http | exp | This document | 866 +---------------------+----------+--------+---------------+ 868 Acknowledgments 870 References 872 Normative References 874 [I-D.ietf-httpbis-messaging] 875 Fielding, R. T., Nottingham, M., and J. Reschke, 876 "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- 877 httpbis-messaging-16, 27 May 2021, 878 . 881 [I-D.ietf-httpbis-semantics] 882 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 883 Semantics", Work in Progress, Internet-Draft, draft-ietf- 884 httpbis-semantics-16, 27 May 2021, 885 . 888 [I-D.ietf-masque-connect-udp] 889 Schinazi, D., "The CONNECT-UDP HTTP Method", Work in 890 Progress, Internet-Draft, draft-ietf-masque-connect-udp- 891 03, 5 January 2021, 892 . 895 [I-D.ietf-masque-h3-datagram] 896 Schinazi, D. and L. Pardue, "Using QUIC Datagrams with 897 HTTP/3", Work in Progress, Internet-Draft, draft-ietf- 898 masque-h3-datagram-02, 26 May 2021, 899 . 902 [I-D.ietf-quic-datagram] 903 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 904 Datagram Extension to QUIC", Work in Progress, Internet- 905 Draft, draft-ietf-quic-datagram-02, 16 February 2021, 906 . 909 [I-D.ietf-quic-http] 910 Bishop, M., "Hypertext Transfer Protocol Version 3 911 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 912 quic-http-34, 2 February 2021, 913 . 916 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 917 DOI 10.17487/RFC0791, September 1981, 918 . 920 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 921 RFC 792, DOI 10.17487/RFC0792, September 1981, 922 . 924 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 925 Requirement Levels", BCP 14, RFC 2119, 926 DOI 10.17487/RFC2119, March 1997, 927 . 929 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 930 of Explicit Congestion Notification (ECN) to IP", 931 RFC 3168, DOI 10.17487/RFC3168, September 2001, 932 . 934 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 935 Control Message Protocol (ICMPv6) for the Internet 936 Protocol Version 6 (IPv6) Specification", STD 89, 937 RFC 4443, DOI 10.17487/RFC4443, March 2006, 938 . 940 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 941 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 942 May 2017, . 944 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 945 (IPv6) Specification", STD 86, RFC 8200, 946 DOI 10.17487/RFC8200, July 2017, 947 . 949 [RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for 950 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, 951 . 953 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 954 Multiplexed and Secure Transport", RFC 9000, 955 DOI 10.17487/RFC9000, May 2021, 956 . 958 Informative References 960 [I-D.ietf-masque-ip-proxy-reqs] 961 Chernyakhovsky, A., McCall, D., and D. Schinazi, 962 "Requirements for a MASQUE Protocol to Proxy IP Traffic", 963 Work in Progress, Internet-Draft, draft-ietf-masque-ip- 964 proxy-reqs-02, 30 April 2021, 965 . 968 [I-D.westerlund-masque-transport-issues] 969 Westerlund, M., Ihlar, M., Sarker, Z., and M. Kuehlewind, 970 "Transport Considerations for IP and UDP Proxying in 971 MASQUE", Work in Progress, Internet-Draft, draft- 972 westerlund-masque-transport-issues-02, 12 July 2021, 973 . 976 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 977 "Definition of the Differentiated Services Field (DS 978 Field) in the IPv4 and IPv6 Headers", RFC 2474, 979 DOI 10.17487/RFC2474, December 1998, 980 . 982 Authors' Addresses 984 Mirja Kuehlewind 985 Ericsson 987 Email: mirja.kuehlewind@ericsson.com 989 Magnus Westerlund 990 Ericsson 992 Email: magnus.westerlund@ericsson.com 994 Marcus Ihlar 995 Ericsson 997 Email: marcus.ihlar@ericsson.com 999 Zaheduzzaman Sarker 1000 Ericsson 1002 Email: zaheduzzaman.sarker@ericsson.com