idnits 2.17.1 draft-tbd-masque-connect-ip-ext-flow-00.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 972 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-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MASQUE T.B. Determined 3 Internet-Draft MASQUE Enthusiasts LLC 4 Intended status: Standards Track 27 August 2021 5 Expires: 28 February 2022 7 A Flow Forwarding Mode Extension to CONNECT-IP 8 draft-tbd-masque-connect-ip-ext-flow-00 10 Abstract 12 This document describes an extension to the CONNECT-IP HTTP method. 13 This extension defines a new Flow Forwarding Mode which supports 14 optimization for individual IP flows forwarded to the targeted peer. 16 * IMPORTANT NOTE: This draft exists only to demonstrate the 17 feasibility of defining CONNECT-IP Flow Forwarding Mode as an 18 extension to CONNECT-IP. The overwhelming majority of the content 19 in this draft was copied from draft-kuehlewind-masque-connect-ip- 20 01. A list of changes from that design is available in an 21 appendix to this document. All credit for flow forwarding should 22 go to the authors of that document. However, all blame for any 23 errors in this draft should be attributed to its editor. The 24 editor's intent is to step down as editor of this draft and have 25 the authors of draft-kuehlewind-masque-connect-ip take on that 26 role. 28 Discussion Venues 30 This note is to be removed before publishing as an RFC. 32 Discussion of this document takes place on the Multiplexed 33 Application Substrate over QUIC Encryption Working Group mailing list 34 (masque@ietf.org), which is archived at 35 https://mailarchive.ietf.org/arch/browse/masque/. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on 28 February 2022. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Simplified BSD License text 65 as described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Motivation of IP flow model for flow forwarding . . . . . 5 72 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 74 2. Negotiating Flow Forwarding Mode . . . . . . . . . . . . . . 7 75 3. HTTP Datagram Multiplexing and Encoding . . . . . . . . . . . 7 76 3.1. IP Payloads . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.1.1. IP Payload Capsule . . . . . . . . . . . . . . . . . 8 78 3.1.2. IP Payload HTTP Datagram Format . . . . . . . . . . . 8 79 3.2. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 3.2.1. ICMP Capsule . . . . . . . . . . . . . . . . . . . . 8 81 3.2.2. ICMP HTTP Datagram Format . . . . . . . . . . . . . . 9 82 4. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . . 9 83 4.1. Flow-Forwarding header for CONNECT-IP . . . . . . . . . . 9 84 4.2. IP-Protocol Header for CONNECT-IP . . . . . . . . . . . . 9 85 4.3. IP-Version header for CONNECT-IP . . . . . . . . . . . . 9 86 4.4. IP-Address header for CONNECT-IP . . . . . . . . . . . . 10 87 4.5. IP-Address-Handling Header for CONNECT-IP . . . . . . . . 10 88 4.6. Conn-ID Header for CONNECT-IP . . . . . . . . . . . . . . 11 89 5. MASQUE server behavior . . . . . . . . . . . . . . . . . . . 11 90 5.1. Error handling . . . . . . . . . . . . . . . . . . . . . 12 91 5.2. IP address selection . . . . . . . . . . . . . . . . . . 12 92 5.3. Constructing the IP header . . . . . . . . . . . . . . . 13 93 5.4. Receiving an IP packet . . . . . . . . . . . . . . . . . 13 94 6. Additional signalling . . . . . . . . . . . . . . . . . . . . 13 95 6.1. ECN . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 96 6.2. ICMP handling . . . . . . . . . . . . . . . . . . . . . . 14 97 6.3. MTU considerations . . . . . . . . . . . . . . . . . . . 15 98 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 99 8. Security considerations . . . . . . . . . . . . . . . . . . . 15 100 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 101 9.1. HTTP Header . . . . . . . . . . . . . . . . . . . . . . . 16 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 103 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 104 10.2. Informative References . . . . . . . . . . . . . . . . . 17 105 Changes from draft-kuehlewind-masque-connect-ip-01 . . . . . . . 18 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 108 1. Introduction 110 This document describes an extension to the CONNECT-IP HTTP method 111 [CONNECT-IP]. This extension defines a new Flow Forwarding Mode 112 which supports optimization for individual IP flows forwarded to the 113 targeted peer. 115 In flow forwarding mode the CONNECT-IP method establishes an outgoing 116 IP flow, from the MASQUE server's external address to the target 117 server's address specified by the client for a particular upper layer 118 protocol. This mode also enables reception and relaying of the 119 reverse IP flow from the target address to the MASQUE server to 120 ensure that return traffic can be received by the client. However, 121 it does not support flow establishment by an external peer. This 122 specification supports forwarding of incoming traffic to one of the 123 clients only if an active mapping has previously been created based 124 on an CONNECT-IP request. Clients that need to support reception of 125 flows established by external peer need to use regular CONNECT-IP. 127 This mode allows for flow-based optimizations and a larger effective 128 maximum packet size through the tunnel. The target IP address is 129 provided by the client as part of the CONNECT-IP request. The source 130 address is either independently selected by the proxy or can be 131 requested to be either the same as used in a previous and currently 132 active CONNECT-IP request or different from currently requests by the 133 same client. The client also indicates the upper layer protocol, 134 thus defining the three tuple used as primary selector for the flow. 136 In this mode the payload between the client and proxy does not 137 contain the IP header in order to reduce overhead. Any additional 138 information (other than the source and destination IP addresses and 139 ports as well as the upper layer protocol identifier) that is needed 140 to construct the IP header or to inform the client about information 141 from received IP packets can be signalled as part of the CONNECT-IP 142 request or using HTTP/3 Datagram [HTTP-DGRAM] later. 144 In flow forwarding mode, usually one upper-layer end-to-end 145 connection is associated to one CONNECT-IP forwarding association. 146 While it would be possible for a client to use the same forwarding 147 association for multiple end-to-end connections to the same target 148 server, as long as they all require the same Protocol (IPv4) / Next 149 Header (IPv6) value, this would lead to the use of the same flow ID 150 for all connections. As such, this is not recommended for 151 connection-oriented transmissions. In order to enable multiple flow 152 forwarding associations to the same server, the flow forwarding mode 153 supports a way to specify some additional upper layer protocol 154 selectors, e.g. TCP source and destination port, to enable multiple 155 CONNECT-IP request for the same three tuple, see CONN-ID header 156 (Section 4.6). 158 The default model for address handling in this specification is that 159 the proxy (MASQUE Server) will have a pool of one or more IP 160 addresses that it can lend to the MASQUE client and routable over its 161 external interface. Other potential use cases and address handling 162 are possible, potentially requiring further extensions. 164 This proposal is based on the analysis provided in 165 [I-D.westerlund-masque-transport-issues] indicating that most 166 information in the IP header is either IP flow related or can or even 167 should be provided by the proxy as the IP communication endpoint 168 without the need for input from the client. The most crucial 169 information identified that requires client interaction is ECN 170 [RFC3168] and ICMP [RFC0792] [RFC4443] handling. 172 This document defines the following IP header field treatment. 174 Required to be determined in CONNECT-IP request and response: 176 * IP version 178 * IP Source Address 180 * IP Destination Address (target address) 182 * Upper Layer Protocol (IPv4 Protocol field / IPv6 Next Header 183 field) 185 Can be chosen by Proxy on transmission: 187 * IPv6 Flow label (per CONNECT-IP flow mode request) 189 * IPv4 Time to live / IPv6 Hop Limit (proxy configured) 191 * Diffserv Codepoint, default is set to 0 (Best Effort) 192 May optionally be provided on a per packet basis 194 * Explicit Congestion Notification in both directions. 196 The consequence of this is certain limitations that future extension 197 can address. For packets that are sent from the target server to the 198 client, the client will not get any information on the actual value 199 of TTL/Hop Count, DSCP, or flow label when received by the proxy. 200 Instead these field are set and consumed by the proxy only. 202 Signalling of other dedicated values may be desired in certain 203 deployments, e.g for DCSP [RFC2474]. However, DSCP is in any case a 204 challenge due to local domain dependency of the used DSCP values and 205 the forwarding behavior and traffic treatment they represent. Future 206 use cases for DSCP, as well as new IPv6 extension headers or 207 destination header options [RFC8200] may require additional 208 signaling. Therefore, it is important that the signaling is 209 extensible. 211 1.1. Motivation of IP flow model for flow forwarding 213 The chosen IP flow model is selected due to several advantages: 215 * Minimized per packet overhead: The per packet overhead is reduced 216 to basic framing of the IP payload for each IP packet and flow 217 identifiers. This enables a larger effective Maximum Transmission 218 Unit (MTU) than regular CONNECT-IP. 220 * Shared functionality with CONNECT-UDP: The UDP flow proxying 221 functionality of CONNECT-UDP will need to establish, store and 222 process the same IP header related fields and state. So this can 223 be accomplished by simply removing the UDP specific processing of 224 packets. 226 * CONNECT-IP can establish a new IP flow in 0-RTT: No network 227 related latencies in establishing new flow. 229 Disadvantages of this model are the following: 231 * Client to server focused solution: Accepting non-solicited peer- 232 initiated traffic is not supported. 234 1.2. Definitions 236 * Proxy: This document uses proxy as synonym for the MASQUE Server 237 or an HTTP proxy, depending on context. 239 * Client: The endpoint initiating a MASQUE tunnel and IP relaying 240 with the proxy. 242 * Target host: A remote endpoint the client wishes to establish bi- 243 directional communication with via tunnelling over the proxy. 245 * IP proxying: A proxy forwarding IP payloads to a target for an IP 246 flow. Data is decapsulate at the proxy and amended by a IP header 247 before forwarding to the target. Packet boundaries need to be 248 preserved or signalled between the client and proxy. 250 * IP flow: A flow of IP packets between two hosts as identified by 251 their IP addresses, and where all the packets share some 252 properties. These properties include source/destination address, 253 protocol / next header field, flow label (IPv6 only), and DSCP per 254 direction. 256 * Address = IP address 258 Target Address --+ 259 \ 260 +--------+ +--------+ \ +--------+ 261 | | Path #1 | | Path #2 V| | 262 | Client |<--------->| Proxy |<--------->| Target | 263 | | ^| |^ | | 264 +--------+ / +--------+ \ +--------+ 265 / \ 266 / +-- Proxy's external address 267 / 268 +-- Proxy's service address 270 Figure 1: The nodes and their addresses 272 Figure 1 provides an overview figure of the involved nodes, i.e. 273 client, proxy, and target host. There are also two network paths. 274 Path #1 is the client to proxy path, where IP proxying is provided 275 over an HTTP/3 session, usually over QUIC, to tunnel IP flow(s). 276 Path #2 is the path between the proxy and the target. 278 The client will use the proxy's service address to establish a 279 transport connection on which to request IP proxying using HTTP/3 280 CONNECT-IP. The proxy will then relay the client's IP flows to the 281 target host. The IP header from the proxy to the target carries the 282 proxy's external address as source address and the target's address 283 as destination address. 285 1.3. Conventions 287 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 288 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 289 "OPTIONAL" in this document are to be interpreted as described in BCP 290 14 [RFC2119] [RFC8174] when, and only when, they appear in all 291 capitals, as shown here. 293 2. Negotiating Flow Forwarding Mode 295 To request flow forwarding, the client sends a CONNECT-IP request to 296 the forwarding proxy indicating the target host and port in the Flow- 297 Forwarding header field (Section 4.1). The host portion is either an 298 IP literal encapsulated within square brackets, an IPv4 address in 299 dotted-decimal form, or a registered name. Further the CONNECT-IP 300 request MUST contain the IP-Protocol header (Section 4.2) and MAY 301 contain the IP-Address-Handling (Section 4.5) or the Conn-ID 302 (Section 4.6) header. 304 If the server accepts the request, it responds with a 2xx 305 (Successful) response that echoes the Flow-Forwarding header field 306 (Section 4.1). The client can optimistically register its IP payload 307 context ID (Section 3.1.1) and start sending IP payloads 308 (Section 3.1.2) before it receives the server response. If the 309 server rejects the request or does not support flow forwarding mode, 310 those datagrams will be dropped. 312 3. HTTP Datagram Multiplexing and Encoding 314 Flow forwarding mode requires multiplexing multiple types of HTTP 315 Datagrams over a single CONNECT-IP request: IP payloads and ICMP 316 messages. To allow this, clients register HTTP Datagram Context IDs 317 using capsules [HTTP-DGRAM]. 319 3.1. IP Payloads 321 In order to exchange IP payloads, the client starts by using its 322 context ID allocation service [HTTP-DGRAM] to allocate a context ID. 323 It then communicates that context ID to the server using a 324 REGISTER_DATAGRAM_CONTEXT_IP_PAYLOAD capsule (Section 3.1.1). Once 325 that is done, both endpoints can exchange IP Payloads 326 (Section 3.1.2). 328 3.1.1. IP Payload Capsule 330 The REGISTER_DATAGRAM_CONTEXT_IP_PAYLOAD capsule (type=0xfff801) 331 allows an endpoint to inform its peer of the encoding and semantics 332 of IP Payload datagrams associated with a given context ID. Its 333 Capsule Data field consists of: 335 REGISTER_DATAGRAM_CONTEXT_IP_PAYLOAD Capsule { 336 Context ID (i), 337 } 339 Figure 2: REGISTER_DATAGRAM_CONTEXT_IP_PAYLOAD Capsule Format 341 Context ID: The context ID to register. 343 3.1.2. IP Payload HTTP Datagram Format 345 HTTP Datagrams registered to carry IP Payloads contain the IP 346 payload. This is defined as the payload following the IPv4 header 347 and any options for IPv4, and for IPv6 as the payload following the 348 IPv6 header and any extension header. 350 3.2. ICMP 352 In order to exchange ICMP messages, the client starts by using its 353 context ID allocation service [HTTP-DGRAM] to allocate a context ID. 354 It then communicates that context ID to the server using a 355 REGISTER_DATAGRAM_CONTEXT_ICMP capsule (Section 3.2.1). Once that is 356 done, both endpoints can exchange ICMP messages (Section 3.2.2). 358 3.2.1. ICMP Capsule 360 The REGISTER_DATAGRAM_CONTEXT_ICMP capsule (type=0xfff802) allows an 361 endpoint to inform its peer of the encoding and semantics of ICMP 362 datagrams associated with a given context ID. Its Capsule Data field 363 consists of: 365 REGISTER_DATAGRAM_CONTEXT_ICMP Capsule { 366 Context ID (i), 367 } 369 Figure 3: REGISTER_DATAGRAM_CONTEXT_ICMP Capsule Format 371 Context ID: The context ID to register. 373 3.2.2. ICMP HTTP Datagram Format 375 HTTP Datagrams registered to carry ICMP messages contain a summary 376 message of the ICMP message received and validated for the respective 377 IP flow. The message format carries the ICMP packet for ICMPv4 378 [RFC0792] or ICMPv6 [RFC4443]. This format is chosen for forward 379 compatibility. From an implementation perspective the client don't 380 need to verify the checksum or validate the header fields because 381 that is done by the server. However, some type codes, like IMCPv4 382 type 2, (Packet Too Big) carries an MTU field that the implementation 383 want to read beyond understanding the meaning of the type and code 384 combination. 386 4. HTTP Headers 388 Note: This section should be improved by clarifying if headers are in 389 request, response or both. 391 4.1. Flow-Forwarding header for CONNECT-IP 393 Flow-Forwarding is an Item Structured Header [RFC8941]. Its value 394 MUST be a String containing either an IPv6 literal encapsulated 395 within square brackets, an IPv4 address in dotted-decimal form, or a 396 registered name. 398 Flow-Forwarding = sf-string 400 4.2. IP-Protocol Header for CONNECT-IP 402 In order to construct the IP header the the proxy needs to fill the 403 "Protocol" field in the IPv4 header or "Next header" field in the 404 IPv6 header. As the IP payload is otherwise mostly opaque to the 405 proxy, this information has to be provided by the client for each 406 CONNECT-IP request for flow forwarding. 408 IP-Protocol is a Item Structured Header [RFC8941]. Its value MUST be 409 an Integer. Its ABNF is: 411 IP-Protocol = sf-integer 413 4.3. IP-Version header for CONNECT-IP 415 IP-Version is a Item Structured Header [RFC8941]. Its value MUST be 416 an Integer and either 4 or 6. This information is used by the proxy 417 to check if the requested IP version is supported by the network that 418 the proxy is connected to, as well as to check the destination or 419 source IP address for compliance. 421 IP-Version = sf-integer 423 4.4. IP-Address header for CONNECT-IP 425 IP-Address is an Item Structured Header [RFC8941]. Its value MUST be 426 an String contain an IP address or IP address range of the same IP 427 version as indicated in the IP-Version header. The address must be 428 specified in the format specified by TBD. 430 This header is used to request the use of a certain IP address or IP 431 address range by the client to be used as source IP address. If the 432 IP-Address header is not presented, the proxy is implicitly requested 433 to assign an IP address or IP address range and provide this 434 information to the client with the HTTP response. 436 If the the client does not provide an IP address or IP address range 437 is has to wait for the proxy response before any payload data can be 438 sent. If the request is denied by the proxy, any sent payload data 439 will be discarded and a new CONNECT-IP request has to be sent. 441 The header is also used as a response header from the proxy to the 442 client to indicate the actual IP address or IP address range that 443 will be used by the proxy. 445 IP-Address = sf-string 447 4.5. IP-Address-Handling Header for CONNECT-IP 449 This header can be used to request the use of a stable address for 450 multiple active flow forwarding associations. The first association 451 will be established with an IP selected by the proxy unless also the 452 IP-Address header (Section 4.4) is provided and accepted by proxy. 453 However, additional forwarding association can be requested by the 454 client to use the same IP address as a previous request by specifying 455 the stream ID as value in this header. This header can also be used 456 to ensure that a "new", not yet for this client used address is 457 selected by setting a value that is larger than the maximum stream 458 ID. 460 IP-Address-Handling is a Item Structured Header [RFC8941]. Its value 461 MUST be an Integer and indicates the stream ID of the corresponding 462 active flow forwarding association. Its ABNF is: 464 IP-Address-Handling = sf-integer 466 4.6. Conn-ID Header for CONNECT-IP 468 This document further defines a new header field to be used with 469 CONNECT-IP "Conn-ID". The Conn-ID HTTP header field indicates the 470 value, offset, and length of a field in the IP payload that can be 471 used by the proxy as a connection identifier in addition to the IP 472 address and protocol tuple when multiple connections are proxied to 473 the same target server for incoming traffic on the service address. 475 Conn-ID is a Item Structured Header [RFC8941]. Its value MUST be a 476 Byte Sequence. Its ABNF is: 478 Conn-ID = sf-binary 480 The following parameters are defined: 482 * A parameter whose name is "offset", and whose value is an Integer 483 indicating the offset of the identifier field starting from the 484 beginning of a datagram or HTTP frame on the forwarding stream. 486 * A parameter whose name is "length", and whose value is an Integer 487 indicating the length of the identifier field starting from the 488 offset. 490 Both parameters MUST be present and the header MUST be ignored if 491 these parameter are not present. 493 This function can be used to e.g. indicate the source port field in 494 the IP payload when containing a TCP packet. 496 5. MASQUE server behavior 498 A MASQUE server that receives an CONNECT-IP request examines the 499 request headers to determine if this request is for flow forwarding 500 mode or regular CONNECT-IP. If flow forwarding mode is in use, the 501 server determines if the required headers are present and which of 502 the optional headers that are included. 504 A server that supports flow forwarding mode MUST echo the client's 505 Flow-Forwarding header to indicate support. 507 The proxy maintains a database with mappings between the HTTP 508 connections and stream IDs and the IP level selectors and Conn-ID 509 information. Using this database and the pool of available addresses 510 and the requests IP-Address-Handling, Conn-ID, IP-Version, IP-Address 511 headers (if included) to select a source IP address. This selection 512 for flow forwarding mode is further discussed below in Section 5.2. 514 Once the mapping is successfully established, the proxy sends a 515 HEADERS frame containing a 2xx series status code to the client. The 516 response MUST contain an IP-Address header indicating the outgoing 517 source IP address or IP address range selected by the proxy. 519 All Datagram capsules received on that stream as well as all HTTP/3 520 datagrams belonging to this CONNECT-IP association are processed for 521 forwarding to the target server. Datagrams are processed as 522 specified in Section 5.3 to produce IP packets that can be forwarded. 524 IP packets received from the target server are mapped to an active 525 forwarding connection and are respectively forwarded in an HTTP 526 datagram to the client (see Section 5.4). 528 5.1. Error handling 530 TBD (e.g. out of IP address, conn-id collision) 532 5.2. IP address selection 534 In flow forwarding mode the proxy constructs the IP header when 535 sending the IP payload towards the target server and it selects an 536 source IP address from its pool of IP addresses that are routed to 537 the MASQUE server. 539 If no additional information about a payload field that can be used 540 as an identifier based on Conn-ID header is provided by the client, 541 the proxy uses the source/destination address and protocol ID 3-tuple 542 in order to map an incoming IP packet to an active forwarding 543 connection. The proxy MUST also consider if IP-Address-Handling 544 header (Section 4.5) is included and its value. If the IP-Address- 545 Handling header is not included and the there has been prior request 546 the proxy SHOULD give the client the same source Address as the first 547 flow forwarding request. Given these constraints the MASQUE proxy 548 MUST select a source IP address that leads to a unique tuple, and if 549 that is not possible an error response is generated. The same IP 550 address MAY be used for different clients when those client connect 551 to different target servers. However, this also means that 552 potentially multiple IP address are used for the same client when 553 multiple connection to one target server are needed. This can be 554 problematic if the source address is used by the target as an 555 identifier. Therefore it is RECOMMENDED that clients are given 556 unique addresses unless a large fraction of the pool has been 557 exhausted. 559 If the Conn-ID header is provided, the proxy should use that field as 560 an connection identifier together with protocol ID, source and 561 destination address, as a 4-tuple. In this case it is recommended to 562 use a stable IP address for each client, while the same IP address 563 might still be used for multiple clients, if not indicated 564 differently by the client in the configuration file. Note that if 565 the same IP address is used for multiple clients, this can still lead 566 to an identifier collision and the CONNECT-IP request MUST be reject 567 if such a collision is detect. 569 Note: Are we allowing multiple client's to share the same 3-tuple 570 when using Conn-ID? It might be good for privacy reasons however, it 571 significantly increases the collision risk. 573 5.3. Constructing the IP header 575 To retrieve the source and destination address the proxy looks up the 576 mapping for the datagram flow ID or stream identifier. The IP 577 version, flow label, DiffServ codepoint (DSCP), and hop limit/TTL is 578 selected by the proxy. The IPv4 Protocol or IPv6 Next Header field 579 is set based on the information provided by the IP-Protocol header in 580 the CONNECT-IP request. 582 The proxy MUST set the Don't Fragment (DF) flag in the IPv4 header. 583 Payload that does not fit into one IP packet MUST be dropped. A 584 dropping indication should be provided to the client. Further the 585 proxy should provide MTU information. 587 The ECN field is by default set to non-ECN capable transport (non- 588 ECT). Further ECN handling is described in Section 6.1. 590 5.4. Receiving an IP packet 592 When the proxy receives an incoming IP packet on the external 593 interface(s), it checks the packet selectors to find the mappings 594 that match the given packet. 596 If one or more mappings exists, it further checks if this mapping 597 contains additional identifier information as provided by the Conn-ID 598 Header of the CONNECT-IP request. If this field maps as well, the IP 599 payload is forwarded to the client. If no active mapping is found, 600 the IP packet is discarded. 602 The above is achieve by using the selector with the most number of 603 fields that match the packet. 605 6. Additional signalling 606 6.1. ECN 608 ECN requires coordination with the end-to-end communication points as 609 it should only be used if the endpoints are also capable and willing 610 to signal congestion notifications to the other end and react 611 accordingly if a congestion notification is received. 613 The probing and verification in the upper layer protocol of end-to- 614 end ECN requires per packet control over what value is set on IP 615 packet transmission as well as which of all values are received by 616 the proxy. The QUIC specification is providing one such example in 617 Section 13.4 of [RFC9000]. Thus in flow forwarding mode the proxy 618 needs to be able to set and read the ECN values in sent and received 619 IP packets respectively. This may motivate that this functionality 620 is optional to implement, even if supporting CONNECT-IP 621 implementations in general will need to handle IP packets and their 622 fields with fine grained control. If optional some negotiation 623 mechanism is needed. 625 Possible realizations are: 627 * always have two bits before payload in flow forwarding model, e.g. 628 by including the whole Type of Service (TOS) byte, which would 629 also enable DSCP setting and reading. 631 * use 4 different context IDs depending on what ECN field value was 632 received or should be set. 634 This is work in process and will be further specified in a future 635 version of this document. 637 6.2. ICMP handling 639 In flow forwarding mode a ICMP datagram format (Section 3.2.2) is 640 used to send the information from some ICMP message to the client. 642 The proxy upon receiving an ICMP message with a destination of an IP 643 address it performs flow forwarding on it needs to process the ICMP 644 message. First it should validate that the ICMP message and find if 645 it matches any of its IP flow selectors (including Conn-ID). In case 646 there are multiple matching use the IP selector with the most number 647 of field that matches fully. 649 Some messages may be applicable both to the proxy and the client. 650 For example an verified ICMPv6 Packet Too Big is applicable both to 651 the proxy and the client. Others like ICMPv6 Destination Unreachable 652 (Type=1), Code=3 (Address unreachable) and Code=4 (Port unreachable) 653 is only possible to act on by the client. 655 QUESTION: Which ICMP messages should be suppressed by the proxy? 657 If a matching IP selector was chosen, then lookup the mapping for the 658 HTTP connection and Stream ID which this message should be sent to. 659 Encapsulate the received ICMP message in the ICMP datagram format and 660 send it to the client. 662 6.3. MTU considerations 664 The use of QUIC as a encapsulation between the client and proxy 665 introduces additional overhead. If datagrams are used to encapsulate 666 packets between the proxy and client, the end-to-end packets must fit 667 within one datagram but the size of the datagrams is limited by the 668 tunneling encapsulation overhead. 670 In flow forwarding mode the client is usually also the tunnel 671 endpoint that knows about the tunnel overhead and can therefore 672 restrict the size of the packets on the end-to-end connection 673 accordingly. However, the target endpoint is usually not aware of 674 the tunnel overhead. Additional signalling on the end-to-end 675 connection from the client to the target endpoint might be needed to 676 restrict the packet size. If QUIC is also used as end-to-end 677 protocol, this could be realized by the transport parameter. In 678 additional, signal from the proxy to the client could be provided as 679 an extension to indicate the tunnel overhead more accurately and 680 flexibly over time. Such signalling might the realized on the HTTP 681 layer in order to take any additional limitations by HTTP 682 intermediates into account. 684 If the proxy receives an incoming packet from a target endpoint that 685 is too big to fit within a datagram on the tunnel connection, the 686 proxy MAY either forward the packet encapsulated in the CAPSULE 687 frames on the respective stream or, if IPv4 with DF bit set or IPv6 688 is used, the proxy MAY reject the packet and send an ICMPv4 Packet 689 type 3 code 4, or ICMPv6 Too Big (PTB) message. 691 7. Examples 693 TBD 695 8. Security considerations 697 This document does currently not discuss risks that are generic to 698 the MASQUE approach. 700 Any CONNECT-IP specific risks need further consideration in future, 701 especially when the handling of IP functions is defined in more 702 detail. 704 9. IANA considerations 706 9.1. HTTP Header 708 This document (if published as RFC) registers the following headers 709 in the "Permanent Message Header Field Names" registry maintained at 710 https://www.iana.org/assignments/message-headers 711 (https://www.iana.org/assignments/message-headers). 713 +---------------------+----------+--------+---------------+ 714 | Header Field Name | Protocol | Status | Reference | 715 +---------------------+----------+--------+---------------+ 716 | Flow-Forwarding | http | exp | This document | 717 +---------------------+----------+--------+---------------+ 718 | Conn-ID | http | exp | This document | 719 +---------------------+----------+--------+---------------+ 720 | IP-Protocol | http | exp | This document | 721 +---------------------+----------+--------+---------------+ 722 | IP-Address | http | exp | This document | 723 +---------------------+----------+--------+---------------+ 724 | IP-Address-Handling | http | exp | This document | 725 +---------------------+----------+--------+---------------+ 726 | IP-Version | http | exp | This document | 727 +---------------------+----------+--------+---------------+ 729 10. References 731 10.1. Normative References 733 [CONNECT-IP] 734 Chernyakhovsky, A., McCall, D., and D. Schinazi, "The 735 CONNECT-IP HTTP Method", Work in Progress, Internet-Draft, 736 draft-cms-masque-connect-ip-02, 27 August 2021, 737 . 740 [HTTP-DGRAM] 741 Schinazi, D. and L. Pardue, "Using Datagrams with HTTP", 742 Work in Progress, Internet-Draft, draft-ietf-masque-h3- 743 datagram-03, 12 July 2021, 744 . 747 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 748 RFC 792, DOI 10.17487/RFC0792, September 1981, 749 . 751 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 752 Requirement Levels", BCP 14, RFC 2119, 753 DOI 10.17487/RFC2119, March 1997, 754 . 756 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 757 of Explicit Congestion Notification (ECN) to IP", 758 RFC 3168, DOI 10.17487/RFC3168, September 2001, 759 . 761 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 762 Control Message Protocol (ICMPv6) for the Internet 763 Protocol Version 6 (IPv6) Specification", STD 89, 764 RFC 4443, DOI 10.17487/RFC4443, March 2006, 765 . 767 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 768 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 769 May 2017, . 771 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 772 (IPv6) Specification", STD 86, RFC 8200, 773 DOI 10.17487/RFC8200, July 2017, 774 . 776 [RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for 777 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, 778 . 780 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 781 Multiplexed and Secure Transport", RFC 9000, 782 DOI 10.17487/RFC9000, May 2021, 783 . 785 10.2. Informative References 787 [I-D.westerlund-masque-transport-issues] 788 Westerlund, M., Ihlar, M., Sarker, Z., and M. Kuehlewind, 789 "Transport Considerations for IP and UDP Proxying in 790 MASQUE", Work in Progress, Internet-Draft, draft- 791 westerlund-masque-transport-issues-02, 12 July 2021, 792 . 795 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 796 "Definition of the Differentiated Services Field (DS 797 Field) in the IPv4 and IPv6 Headers", RFC 2474, 798 DOI 10.17487/RFC2474, December 1998, 799 . 801 Changes from draft-kuehlewind-masque-connect-ip-01 803 The overwhelming majority of the content in this draft was copied 804 from draft-kuehlewind-masque-connect-ip-01. The editor made the 805 following minor changes in order to make Flow Forwarding Mode 806 compatible with CONNECT-IP: 808 Negotiation of Flow Forwarding Mode: draft-kuehlewind-masque- 809 connect-ip-01 uses the ":authority" pseudo-header to differentiate 810 between flow forwarding mode and regular CONNECT-IP. Since many 811 HTTP servers are responsible for multiple authorities, this 812 document instead uses a new HTTP header "Flow-Forwarding" to 813 communicate whether flow forwarding mode is in use. 815 HTTP Datagram Context IDs: draft-kuehlewind-masque-connect-ip-01 816 left registration of context IDs as future work, which prevented 817 implementing the proposal. This draft defines two new capsules to 818 register context IDs and register their associated formats. 820 Author's Address 822 To Be Determined 823 MASQUE Enthusiasts LLC 825 Email: dschinazi.ietf@gmail.com