idnits 2.17.1 draft-westerlund-masque-transport-issues-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 January 2021) is 1199 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-33 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-09 == Outdated reference: A later version (-15) exists of draft-ietf-6man-mtu-option-04 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MASQUE M. Westerlund 3 Internet-Draft M. Ihlar 4 Intended status: Informational Z. Sarker 5 Expires: 16 July 2021 M. Kuehlewind 6 Ericsson 7 12 January 2021 9 Transport Considerations for IP and UDP Proxying in MASQUE 10 draft-westerlund-masque-transport-issues-01 12 Abstract 14 The HTTP Connect method uses back-to-back TCP connections to and from 15 a proxy. Such a solution takes care of many transport aspects as 16 well as IP Flow related concerns. With UDP and IP proxying on the 17 other hand, there are several per-packet and per-flow aspects that 18 need consideration to preserve the properties of end- to-end IP/UDP 19 flows. The aim of this document is to highlight and provide 20 solutions for these issues related to UDP and IP proxying. 22 Discussion Venues 24 This note is to be removed before publishing as an RFC. 26 Discussion of this document takes place on the MASQUE Working Group 27 mailing list (masque@ietf.org), which is archived at 28 https://mailarchive.ietf.org/arch/browse/masque/ 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/gloinul/draft-westerlund-masque-transport-issues 33 (https://github.com/gloinul/draft-westerlund-masque-transport- 34 issues). 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 16 July 2021. 53 Copyright Notice 55 Copyright (c) 2021 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Simplified BSD License text 64 as described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.2. HTTP Connect . . . . . . . . . . . . . . . . . . . . . . 5 72 1.3. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.4. HTTP Connect-UDP . . . . . . . . . . . . . . . . . . . . 6 74 2. Review of IP Header . . . . . . . . . . . . . . . . . . . . . 7 75 2.1. Base Header Fields . . . . . . . . . . . . . . . . . . . 7 76 2.1.1. Version . . . . . . . . . . . . . . . . . . . . . . . 8 77 2.1.2. DSCP . . . . . . . . . . . . . . . . . . . . . . . . 8 78 2.1.3. ECN . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 2.1.4. Identification, Flags, and Fragmentation offset (IPv4 80 Only) . . . . . . . . . . . . . . . . . . . . . . . . 10 81 2.1.5. Flow Label (IPv6 Only) . . . . . . . . . . . . . . . 10 82 2.1.6. Total Length / Payload length . . . . . . . . . . . . 10 83 2.1.7. Protocol / Next Header . . . . . . . . . . . . . . . 11 84 2.1.8. Time to Live / Hop Limit . . . . . . . . . . . . . . 11 85 2.1.9. Header Checksum (IPv4 Only) . . . . . . . . . . . . . 11 86 2.1.10. Source and Destination Address . . . . . . . . . . . 12 87 2.2. IPv4 Options Header . . . . . . . . . . . . . . . . . . . 12 88 2.3. IPv6 Extension Headers . . . . . . . . . . . . . . . . . 12 89 3. Review of UDP Header . . . . . . . . . . . . . . . . . . . . 13 90 3.1. Source and Destination Port . . . . . . . . . . . . . . . 13 91 3.2. UDP Length . . . . . . . . . . . . . . . . . . . . . . . 13 92 3.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 14 93 4. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 5. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . . . 15 95 5.1. IPv6 Fragmentation . . . . . . . . . . . . . . . . . . . 16 96 5.2. IPv4 Fragmentation . . . . . . . . . . . . . . . . . . . 16 97 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 6.1. UDP Flow Information and configuration . . . . . . . . . 17 99 6.2. Potential Per Packet Information . . . . . . . . . . . . 18 100 6.3. Event based Interactions . . . . . . . . . . . . . . . . 18 101 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 19 102 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 103 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 104 8.2. Informative References . . . . . . . . . . . . . . . . . 20 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 107 1. Introduction 109 This document examines several aspects related to UDP [RFC0768] over 110 IP [RFC0791] [RFC8200] (IP/UDP) flows when they are proxied according 111 to the MASQUE proposal over QUIC and using HTTP CONNECT method for 112 flow establishment (Connect-UDP) [I-D.schinazi-masque-connect-udp]. 113 It also looks at how transport protocols on top of UDP use this 114 information and contrast that with both the HTTP Connect method 115 [RFC7231] using either TCP [RFC0793] or QUIC 116 [I-D.ietf-quic-transport] as well as the methods used by the TURN 117 protocol [RFC8656]. 119 Aspects discussed include ECN [RFC3168], Differentiated Services 120 Field and its codepoint (DSCP) [RFC2474], Fragmentation and MTU, ICMP 121 [RFC0792], IPv6 FLOW ID [RFC8200], IPv6 Extension headers, and IPv4 122 Options [RFC0791]. This document also discusses the use of the UDP 123 checksum and the UDP Length field usage related to UDP Options 124 [I-D.ietf-quic-transport]. 126 1.1. Definitions 128 * UDP Flow: A sequence of UDP packets sharing a 5-tuple. 130 * ECN: Explicit Congestion Notification [RFC3168]. 132 * DSCP: Differentiated Service Code Point [RFC2474]. 134 * Proxy: This document uses proxy as synonym for the MASQUE Server 135 or an HTTP proxy, depending on context. 137 * Client: The endpoint initiating a MASQUE tunnel and UDP/IP 138 relaying with the proxy. 140 * Target: A remote endpoint the client wishes to establish bi- 141 directional communication with. 143 * UDP proxying: A proxy forwarding data to a target over an UDP 144 "connection". Data is decapsulate at the proxy and amended by a 145 UDP and IP header before forwarding to the target. Datagram 146 boundaries need to be preserved or signalled between the client 147 and proxy. 149 * IP proxying: A proxy forwarding data to a target over an IP 150 "connection". Data is decapsulate at the proxy and amended by a 151 IP header before forwarding to the target. Packet boundaries need 152 to be preserved or signalled between the client and proxy. 154 Address = IP address + UDP port 156 Target Address --+ 157 \ 158 +--------+ +--------+ \ +--------+ 159 | | Path #1 | | Path #2 V| | 160 | Client |<--------->| Proxy |<--------->| Target | 161 | | ^| |^ | | 162 +--------+ / +--------+ \ +--------+ 163 / \ 164 / +-- Proxy's external address 165 / 166 +-- Proxy's service address 168 Figure 1: The nodes and their addresses 170 Figure 1 provides an overview figure of the involved nodes, i.e. 171 Client, Proxy, and Target, that are discussed below. We use the name 172 target for the node or endpoint the client intends to communicate 173 with via the proxy. There are also two network paths. Path #1 is 174 the client to proxy path, where the MASQUE protocol will be used over 175 an HTTP/3 session, usually over QUIC, to tunnel IP/UDP flow(s). Path 176 #2 is the path between the Proxy and the Target. 178 The client will use the proxy's service address to establish a 179 transport connection on which to communicate with the proxy using the 180 MASQUE protocol. The MASQUE protocol will be used to establish the 181 relaying of a IP/UDP flow from the client using as the source address 182 the proxy's external address and sending to the target address. In 183 addition, after establishment, the reverse is also configured on the 184 proxy; IP/UDP packets sent from the target address to the proxy's 185 external address will be relayed to the client. 187 1.2. HTTP Connect 189 The HTTP Connect method [RFC7231] is defined such that the HTTP proxy 190 that receives the request will set up a TCP connection towards a 191 provided (or resolved) target address. After the TCP connection has 192 been established, the proxy will connect the byte stream from the 193 client to the byte stream of the new TCP connection. On byte stream 194 level this is only tunneling. On the transport level on the other 195 hand, two distinct transport connections are established. If the 196 client to proxy connection is HTTP/3, i.e. over QUIC, the basic HTTP 197 Connect method will still lead to TCP connection establishment from 198 proxy to the target servers. In this case the client to proxy QUIC 199 stream's byte stream is connected to the proxy to server TCP 200 connection. For simplicity and clarify the rest of the document will 201 use back to back TCP sessions as a comparison. 203 Due to the byte stream semantics and the use of transport protocol 204 proxying, most of the transport implications of the header fields and 205 their values are handled on a per path basis, e.g. response to ECN 206 Congestion Experienced (CE) marks. Some information that may be end- 207 to-end related, such as DSCP values, can be copied or translated 208 between the connections if supported by the proxy. MTU is mostly 209 irrelevant and handled fully due to the byte stream nature of the 210 data flowing in the connection. If the MTU differs between the two 211 paths the number of packets required to send a particular data object 212 may differ as well. However, the impact of that is small and depends 213 on the amount of buffering between the two connections. There is no 214 requirement to have a one-to-one correspondence of packets between 215 the two TCP connections. 217 1.3. TURN 219 "Traversal Using Relays around NAT (TURN): Relay Extensions to 220 Session Traversal Utilities for NAT (STUN)" [RFC8656] is a solution 221 for relaying UDP datagrams. However, it is a hybrid between a purely 222 encapsulating tunnel and proxying. A somewhat simplified description 223 of the protocol follows below. 225 A client makes a TURN request over a TCP/TLS connection to a TURN 226 server to authenticate itself and acquire a long-term secret. Note 227 that subsequent requests are secured using keying material from the 228 long term secret exchange. Next, the client can send a request over 229 UDP to be allocated a UDP port number on one of the server's external 230 IP addresses. After that, the client knows the IP address and UDP 231 port number that will be used for the TURN server's side of any UDP 232 flow sent to or received from the remote target. 234 A TURN client can send UDP packets in two ways. The first solution 235 is to include a send indication for each UDP packet to be relayed. 236 The send indications contains the target destination address and 237 port. The other solution is to create a binding, where a channel ID 238 between the client and TURN server is bound to a specific 5-tuple 239 from the TURN Server to the target destination. The established 240 channel is bi-directional. When a channel has been established, UDP 241 packets can be relayed with a low overhead of 4 bytes. 243 To receive UDP packets on the allocated port, the client must specify 244 what source address and port (target address) is to be allowed, this 245 is called establishing a permission. Binding a channel creates a 246 permission at the same time. When the TURN server receives a UDP 247 packet from an external source where permission exists but no 248 channel, it will relay the data using a DATA indication, which 249 includes the source address. 251 A relevant aspect for the rest of the discussion in this document is 252 that TURN has a one to one mapping between IP/UDP/TURN messages 253 between client and TURN server and the IP/UDP packet received or sent 254 on the external side. Also, though TURN messages and indications 255 include header information in the UDP payload, there are distinct IP/ 256 UDP headers on each side of the TURN server. Because of this the 257 TURN protocol is able to preserve the per flow and per packet 258 functionalities that exist in IP/UDP headers. For instance, ECN and 259 DSCP markings associated with specific packets are preserved by the 260 relay by copying or translating them from incoming packets to 261 outgoing packets. 263 1.4. HTTP Connect-UDP 265 The MASQUE WG is chartered to work on the tunneling of UDP datagrams 266 in a QUIC connection between client and a MASQUE server (We will 267 refer to the MASQUE server as a proxy in the rest of this document to 268 align with the basic HTTP Connect terminology). The proxy forwards 269 tunneled UDP payload to the correct target address. An HTTP Connect- 270 UDP request is used to establish the tunnel and provide the required 271 addressing information. 273 In the review performed in this document we make the assumption that 274 it is desirable to minimize the per-packet overhead. Specifically, 275 we assume that IP/UDP header information from packets exchanged 276 between the proxy and target will not be sent within the tunnel. The 277 initial relay exchange establishment needs to be performed for each 278 target the client wants to communicate with, i.e. one relay exchange 279 per IP/UDP flow on the proxy to target path. Keeping this state in 280 the proxy on a per UDP flow basis appears trivial. Therefore, the 281 review will determine what IP/UDP state is required per flow and what 282 is per per packet information. 284 In this review we also aim to identify the impact on the end-to-end 285 flows by using QUIC as a tunneling protocol, both in stream and/or 286 datagram mode. Properties of IP/UDP flows and higher level transport 287 protocols such as QUIC or RTP will be considered. 289 Two high level observations need to be made when comparing Connect- 290 UDP to TURN. The first is that QUIC is a proper transport protocol 291 with congestion control. This means that there might not be a one- 292 to-one mapping between events that impact the transport, such as 293 congestion indications, on either path relative to the proxy. The 294 second observation is that tunneled UDP datagrams can be coalesced in 295 a single UDP datagram with either multiple QUIC packets, or multiple 296 QUIC datagram frames in a single QUIC packet. If reliable streams 297 are used instead of datagram frames, then a UDP payload may even be 298 fragmented over multiple UDP packets containing QUIC packets. 300 This all motivates a very careful consideration of the IP and UDP 301 header information and how that needs to be handled on flow level or 302 per packet level to avoid breaking end-to-end transport properties 303 for the flow. 305 2. Review of IP Header 307 2.1. Base Header Fields 309 This section reviews the header fields in IPv4 [RFC0791] and IPv6 310 [RFC8200]. It will note which field are version specific. Size 311 differences are not considered in the review as it is focused on 312 functionality and impact. 314 2.1.1. Version 316 The proxy needs to know which IP version to use on the proxy to 317 target path. If an explicit IP address is included in the Connect- 318 UDP request, the proxy would know this directly from the IP address 319 format. In the case where a domain name is used to obtain the target 320 IP address, the IP version needs to be specified or be based on 321 preferences when resolving the domain name. 323 It should be noted that different IP versions may be used on the two 324 paths requiring the proxy to do translation. This can also lead to 325 scenarios whereby version specific information carried on one path 326 does not translate to the version used on the other path. 328 2.1.2. DSCP 330 Diffserv code points are primarily used to indicate forwarding 331 behavior. Codepoints on IP/UDP flows on the proxy to target path are 332 either set on a flow level or packet level. Codepoints set on a flow 333 level are set at flow instantiation and can be updated during ongoing 334 relaying. 336 A DSCP value received on IP/UDP packets in the target to proxy 337 direction may be propagated to the Proxy to client path. However, 338 that is problematic when the datagram is tunneled in QUIC. The DART 339 considerations [RFC7657] for connection oriented transport applies 340 here. If multiple DSCPs are used for a single connection, then there 341 would be a need for having separate congestion control states for the 342 different forwarding behaviors, which would likely require QUIC 343 protocol extensions. The same issue exists for packets sent by the 344 client on the client to proxy path. 346 Different forwarding behaviors in both directions of the path 347 connecting the client and the proxy could be enabled without a QUIC 348 extension by establishing individual QUIC connections per forwarding 349 behavior used. However, this requires that the proxy is able to bind 350 multiple QUIC connections received from the client into a single IP/ 351 UDP flow on the proxy to target path. This could have significant 352 security model implications as authorization would be needed to add 353 subsequent bindings to an existing flow. 355 Let's consider the capability for the proxy to send packets with 356 packet-level DSCP marks towards the target. That would require at a 357 minimum a per packet indication mechanism and would enable different 358 forwarding behaviors on the proxy to target path. Similarly, a per 359 packet mechanism would be needed for the proxy to be able to relay 360 DSCP values received from the target towards the client. The 361 usefulness of the latter would be to ensure that the transport 362 protocol on top of MASQUE is able to determine whether there is a 363 need for multiple congestion control states for different sub-sets of 364 packets within the received IP/UDP flow. WebRTC IP/UDP flows could 365 have this property. 367 The most basic DSCP relay capability would be to set the same DSCP 368 value on all IP/UDP packets sent by the proxy to the same target for 369 a specific IP/UDP flow. This capability would only require 370 signalling of the desired value at flow establishment. A mechanism 371 to update the DSCP value for an ongoing flow should also be 372 considered. 374 Another issue with DSCP mapping to forwarding behaviors is that the 375 mappings are defined per network location, typically within one 376 administrative domain of routing. Therefore they may be remapped on 377 the different paths relative to the proxy. When the client and proxy 378 reside in two different administrative domains there will be an 379 additional challenge for the client to use the right DSCP value. 380 Thus, support for DSCP in the MASQUE protocol should either be 381 limited to consider per hop behavior or the use of a mapping table 382 such that the proxy can translate an incoming DSCP value to a locally 383 used value. 385 2.1.3. ECN 387 The Explicit Congestion Notification (ECN) [RFC3168] field carries 388 per packet path signals about congestion. The discussion of ECN 389 capability can be split into two parts, one for each path relative to 390 the proxy. On the client to proxy path the QUIC connection used for 391 tunneling the UDP datagrams can enable and use ECN on that path 392 specifically. Any congestion experienced (ECN-CE) marking on that 393 path impacts the congestion window of the client to proxy QUIC 394 connection, thus indirectly affecting the end-to-end flow. 396 The capability to use ECN on the proxy to target path requires proxy 397 protocol support. This will enable the end-to-end usage of ECN in 398 the upper layer transport protocol. To support ECN end-to-end when 399 using MASQUE proxy two functionalities need to exist. 401 First, the capability of setting the ECN field value (Not-ECT, 402 ECT(1), ECT(0)) on any IP/UDP packets sent from proxy to target. 403 This value can be set initially but may be changed during ongoing IP/ 404 UDP flow proxying, as the end-to-end transport may subsequently 405 determine that the path is not ECN capable. 407 Secondly, the client must be able to receive per packet indications 408 of the ECN field value for every packet received by the proxy from 409 the target. This ensures that the upper layer transport protocol 410 receives ECN information per relayed UDP datagram. The information 411 will be used to react to ECN-CE (Congestion Experienced) marks and 412 for validation of the ECN path capability. 414 A solution like TURN's [RFC8656] translation of ECN markings between 415 the two paths is not possible for multiple reasons. First, ECN marks 416 on the client to proxy path will be consumed and reacted to by the 417 QUIC connection used for tunneling. Second, the previously discussed 418 lack of a one-to-one relationship of IP/UDP packets prevents accurate 419 tracking of the ECN markings and will make the end-to-end validation 420 fail. Therefore additional explicit signaling between the proxy and 421 the client would be needed. 423 2.1.4. Identification, Flags, and Fragmentation offset (IPv4 Only) 425 These fields are used for the IPv4 fragmentation solution. The 426 authors are of the opinion that IP level fragmentation should be 427 avoided. However, since there are no guarantees for a one-to-one 428 packet relation between the two paths relative to the proxy, any IPv4 429 fragments will need re-assembly upon reception by the endpoints and 430 the proxy. 432 To support Path MTU Discovery the Don't Fragment (DF) bit needs to be 433 set for all outgoing IP/UDP packets from the proxy to the target. 434 Per flow or per packet setting of this bit needs to be supported. 436 2.1.5. Flow Label (IPv6 Only) 438 The IPv6 flow label is used by the network to identify flows, for 439 example to prevent a single flow to be spread over multiple paths 440 when load balancing based on Equal Cost Multipath (ECMP) routing 441 [RFC6438] is performed. The flow label should be set by the endpoint 442 originating the IP/UDP flow, as it knows when a flow qualifies for a 443 unique IPv6 flow label. Thus, it is expected that one IPv6 flow 444 label will be used for the IP/UDP flow that carries the client to 445 proxy QUIC connection, and one for each IP/UDP flow established by 446 the MASQUE protocol to different target addresses. 448 Based on the above reasoning it does not seem like there is a need 449 for the MASQUE protocol to explicitly signal or indicate flow labels. 451 2.1.6. Total Length / Payload length 453 The Total Length (IPv4) / Payload length (IPv6) fields contain the 454 size of the IP packet, either directly for IPv4, or indirectly in 455 IPv6 (by providing the length after the fixed 40-byte header, i.e. 456 for extension headers and data). 458 These field are necessary for the processing on reception, however it 459 does not need to be communicated on a per packet-basis to the client, 460 or be provided by the client, with a single potential exception that 461 is discussed in the context of the UDP length field (Section 3.2). 463 2.1.7. Protocol / Next Header 465 The Protocol (IPv4) and Next Header (IPv6) fields provide the 466 identification of the upper layer protocol, in this case UDP. For 467 IPv6 one or more extension headers may first be identified in a chain 468 before arriving at UDP. 470 The use of UDP relaying will need to be signalled explicitly to 471 separate it from other types of relaying, such as the IP tunneling/ 472 relaying discussed in the MASQUE charter. 474 2.1.8. Time to Live / Hop Limit 476 The purpose of the Time to Live (IPv4) and Hop Limit (IPv6) fields is 477 to prevent packets from having an infinite life time in case of 478 routing loops. The acronym TTL is used from here on to describe any 479 of these fields. TTL limits the number of routing hops a packet 480 survives and should result in an ICMP message back to the sender when 481 it expires. Therefore, it is possible to use TTL for investigating 482 network paths. 484 It is not clear if such a mechanism needs to be supported in a MASQUE 485 protocol context. If something like trace-route is to be supported, 486 per packet setting of the TTL field would be needed. 488 The need for echoing the TTL field value on reception of a IP/UDP 489 packet from the target to the client appears also very limited. The 490 value set on transmission of a packet is usually an operating system 491 set default value. 493 The authors believe that the proxy's default values are sufficient 494 for the MASQUE protocol functionality. 496 2.1.9. Header Checksum (IPv4 Only) 498 The IPv4 checksum field verifies the integrity against non- 499 intentional errors in transmission or processing of the IP header. 500 IPv6 lacks this checksum and instead relies on the transport protocol 501 checksum. 503 The value is generated when an IP packet is transmitted from the 504 proxy and verified on reception. No further functionality required. 506 2.1.10. Source and Destination Address 508 On the path from the proxy to the target, the source address will be 509 the proxy's external address applied when relaying the IP/UDP 510 packets. This address will be determined as part of the IP/UDP flow 511 tunneling establishment and should be signalled back to the client by 512 the proxy. The destination address used will be the target's IP 513 address. 515 The source addresses used on the client to proxy path are only needed 516 for the communication between the client and proxy and are part of 517 the QUIC connection's state. Thus, the possibility to change it will 518 depend on the mechanisms in QUIC for dealing with client address 519 migration or multi-path. Further discussion should not be needed. 521 In case of IP proxying, as the proxy cannot utilize port numbers, the 522 proxy might need to maintain multiple external IP addresses in order 523 to identify different forwarding processes for packet received from 524 multiple target servers. If the proxy is guaranteed to be on-path 525 between the client and server the proxy could also conserve the 526 client's source IP address as it's external address. 528 The source and destination addresses are therefore part of the 529 fundamental state for IP/UDP flow relaying and need to be established 530 at initiation. The 2 (IP proxying) or 5-tuple (IP/UDP proxying) from 531 the proxy to the target and the reverse tuple needs to be explicitly 532 signalled. The client either needs to explicitly provide the target 533 IP address or a domain name that the proxy can resolve to a target IP 534 address. The proxy needs to notify the client about which source IP 535 address it uses when sending on the proxy to target path. 537 2.2. IPv4 Options Header 539 The use of IPv4 Options header on the general Internet is very 540 limited. It is therefore likely that no functionality is required. 542 2.3. IPv6 Extension Headers 544 One IPv6 Extension header that needs discussion here is the 545 fragmentation header. Although it is the IP originating node that 546 adds the fragmentation header, the MASQUE protocol will likely need 547 to control whether IPv6 fragmentation should be used or not, in the 548 same way as for the IPv4 DF bit. 550 Some existing IPv6 extension headers could be added by the 551 originating node. Whether they require any explicit signalling or 552 relaying of data to the client needs to be investigated further. 553 Especially Hop-by-Hop options, such as the IPv6 Minimum Path MTU Hop- 554 by-Hop Option [I-D.ietf-6man-mtu-option]. 556 There are also some individual proposals for extension header that 557 might matter in the future: Network Tokens 558 [I-D.yiakoumis-network-tokens], IPv6 Truncate Option 559 [I-D.leddy-6man-truncate]. Thus, consideration needs to be made if 560 there are necessary to future proof the Masque protocol, at least to 561 enable future extensions to support per packet Extension headers. 563 3. Review of UDP Header 565 3.1. Source and Destination Port 567 For UDP proxying, the UDP destination port is used by endpoints to 568 locate the destination process that should consume a specific UDP 569 datagram. Source Ports can be used by the receiving application to 570 separate flows based on the 5-tuple. 572 As discussed in Section 2.1.10 the UDP source and destination ports 573 are part of the 5-tuple and needs to be communicated on IP/UDP flow 574 establishment. 576 3.2. UDP Length 578 The UDP length field specifies the UDP payload length in octets. 580 The UDP length field normally indicates that the UDP payload fills up 581 the remainder of the IP packet. However, this is not always the 582 case. Specifically, UDP options [I-D.ietf-tsvwg-udp-options] are 583 designed to make use of the surplus area between the end of the UDP 584 data section and the end of the IP packet. 586 Thus, for the MASQUE protocol to preserve the capability to carry UDP 587 options in UDP relaying this surplus area and the UDP payload data 588 length field need to transmitted from client to proxy in both 589 directions. 591 3.3. UDP Checksum 593 The UDP checksum verifies the UDP datagram headers and payload and 594 the pseudo header with IP layer information. The UDP checksum should 595 always be verified by the receiving party. The UDP checksum may also 596 be set to zero to provide no verification. This is primarily used by 597 tunnel encapsulation formats. If it is desired to send IP/UDP flows 598 from the proxy to the target address with a zero UDP checksum, the 599 MASQUE protocol needs to support an indication of this desire. 601 The use of zero UDP checksum for IPv6 is more restricted than for 602 IPv4 due to the lack of a IP header checksum [RFC6936]. 604 The authors do not believe it is necessary to be able to send IP/UDP 605 datagrams with a zero UDP checksum. It is also not necessary to 606 relay the UDP checksum generated by the target, since the QUIC 607 protocol will provide stronger cryptographic integrity verification 608 of the UDP datagram payload. Also, for the target generated checksum 609 to be meaningful to the client the complete datagram and pseudo 610 header would need to be reconstructed, which in would likely require 611 extra processing and copying of data. Though some cases of erroneous 612 handling of IP/UDP header fields by the MASQUE protocol could be 613 detected in this way, it is not deemed to be worth the effort. 615 For the packets the client sends to be relayed to the target 616 destination, having the client create a UDP checksum would provide 617 some protection against processing or implementation errors, although 618 the overhead and extra processing is likely not worth the effort. 620 In addition the calculation and verification of the transport header 621 checksum is one of these aspects that can be offloaded to hardware in 622 a proxy. 624 4. ICMP 626 Internet Control Message Protocol (ICMP) [RFC0792][RFC4443] messages 627 are useful hints on why sent IP packets appear to disappear in the 628 network. Especially for what might appear to be intermittent issues, 629 such as exceeding the MTU of the path. 631 Lets start with clarifying which ICMP messages may be relevant to 632 handle in the MASQUE protocol. The primary concern is to ensure that 633 the client receives any ICMP responses that are sent back to the 634 proxy as result of packets the client had relayed through the proxy 635 towards the target destination. The proxy should validate and 636 identify ICMP messages that relate to a particular IP/UDP flow that 637 the proxy sends. The relevant ICMP information, i.e. Type and Code 638 as well as any included bytes from the packets that can be used to 639 identify the actual IP/UDP packet in the client, should be sent to 640 the client. Such a functionality would enable the the client to 641 receive Packet Too Big messages that speeds up Path MTU Discovery 642 (Section 5). It also enables the client to learn when there appears 643 to be no one at the target address, i.e. the port, host or network 644 unreachable codes. 646 IP/UDP packets reaching the proxy from a target address may result in 647 that ICMP messages are sent back to the target. For example a port 648 unreachable message would be sent if a packet arrives after the 649 client has terminated the tunneling session. 651 Any ICMP packets that result from IP/UDP packets exchanged between 652 the client and the proxy, related to the QUIC connection is to be 653 validated and consumed by the QUIC implementation. 655 Thus, depending on the ICMP message, the MASQUE protocol needs to 656 consider a mechanism for the proxy to indicate to the client that it 657 has received and validated ICMP messages. If the ICMP message 658 indicates a connection failure, HTTP response error codes can be 659 used. However, for HTTP Connect-UDP the response code was sent when 660 the UDP socket was created, while an ICMP message would only be 661 received after UDP packets have been relayed. 663 5. Maximum Transmission Unit (MTU) 665 The MTU available for the UDP payload depends on whether the QUIC 666 connection uses datagrams or streams to carry the UDP payload on the 667 client to proxy path. When streams are used, the outer QUIC 668 connection can fragment and re-assembly UDP Payloads of any size. In 669 this case any MTU issues will arise on the proxy to target path. 671 When using datagrams, unless the QUIC datagram extension provides a 672 fragmentation solution, then the outer QUIC connection will provide a 673 MTU that is dependent on the largest datagram payload that can be 674 transmitted. A potential issue is that this might be variable over 675 time, both due to underlying path changes, and to variable elements 676 of the QUIC protocol. However, a base overhead from the QUIC headers 677 should be possible to calculate based on the maximum QUIC packet 678 size. Depending on the amount of per packet information needed to be 679 provided additional headroom for the MASQUE encapsulation may be 680 required. 682 To enable PMTUD discovery certain aspects are needed or greatly 683 simplify the process. 685 * Ensure that the DF bit is set to Don't Fragment on outgoing IPv4/ 686 UDP packets from the proxy to the target. For IPv6 the use of the 687 fragmentation header needs to be prevented. 689 * Have the proxy signal back to the client its current interface MTU 690 limit for packets that will be sent from proxy to target. 692 * Have the tunneling QUIC connection expose the current MTU for 693 datagrams to the MASQUE implementation. This is likely dynamic 694 and can be updated at any point. 696 * Returning ICMP Packet Too Big (PTB) message from the proxy to the 697 client when packets are dropped due to MTU on the proxy to target 698 path. 700 It should be noted that unless the QUIC datagram extension provides a 701 fragmentation mechanism this will in many scenarios be the most 702 likely MTU bottleneck and there is no work around for it, the IP/UDP 703 tunneled traffic will need to fit or be dropped. 705 5.1. IPv6 Fragmentation 707 Reassembly of received traffic will occur on each node, Client, 708 Proxy, and Target. The need for IP level fragmentation should be 709 avoided, by having the working MTU be propagated up. Initial MTU 710 signaling should exist for the flow. However, this is potentially 711 dynamic and a PMTUD process running for the outer QUIC tunnel on the 712 client to proxy path will update the supported MTU. 714 An option for controlling if fragmentation should occur or not by the 715 Proxy should be considered. 717 5.2. IPv4 Fragmentation 719 As IPv4 fragmentation is flexible and allows an on-path node to 720 fragment a packet, enabling fragmentation may reduce the MTU issues. 721 However, Path MTU Discovery is recommended instead, for the following 722 reasons: 724 * Fragmentation increases the packet loss rate. 726 * IP fragments do not traverse NATs and Firewalls well. Which is 727 especially relevant for MASQUE as significant deployments will be 728 clients in access or residential networks that have NATs or 729 Firewalls on the path from the client to the proxy. 731 6. Summary 733 Lets sum up the aspects of the IP/UDP header fields and related 734 protocols in a couple of categorizes. 736 6.1. UDP Flow Information and configuration 738 This section contains header fields whose value either will be static 739 for a given IP/UDP flow, apply until changes, or can be used as 740 default values when per packet values are not given. 742 First of all, the IP source and destination address as well as UDP 743 source and port information is directly related to the establishment 744 of a bi-directional IP/UDP flow between proxy and the target. The 745 desired IP version also needs to be indicated if the address is 746 expressed as hostname, but otherwise would be given by the format of 747 the address. The target always needs to be provided by the client. 748 Since there are cases where the client would need to know the 749 external address used by the proxy towards the target, there needs to 750 be a way for the client to request this information. 752 The upper layer protocols between the client and the target might 753 have different capabilities of using ECN. Therefore it is necessary 754 to be able to signal whether the ECN fields in proxy to target 755 packets should be set to Not-ECT, ECT(0) or ECT(1). 757 If a DSCP marking other than 0, i.e. best effort, is desired then a 758 default value could be set as part of the relay establishment. This 759 value could potentially be overridden on a per packet basis or be 760 changed at a future point in the relayed flows lifetime. 762 A don't fragment setting could likely be defaulted to be always true. 763 However, we invite further discussion if there are cases where it 764 would be better to enable IP level fragmentation for some packets, or 765 for all. 767 The Hop Limit could likely be using node default values, unless 768 someone raises a use case where they actually want to modulate the 769 value on per packet basis or set an explicit value for the IP/UDP 770 flow. 772 The MTU known by the proxy towards the indicated target should be 773 signalled back at relay establishment by the proxy. 775 6.2. Potential Per Packet Information 777 This section contains information that would be necessary to 778 associate with a specific packet when the client request sending or 779 the proxy relays a received packet. 781 For each packet the proxy receives the ECN field's value need to be 782 relayed to the client so that the upper layer can respond to either a 783 CE marking indicating congestion, or any remarking. 785 There are examples where IP/UDP flows contain packets that do not 786 have uniform DSCP marking. To enable sending of such streams, any 787 DSCP value other the default value would need to be indicated by the 788 client to the proxy. 790 If it is desired to verify the UDP Checksum in the client to avoid 791 any potential errors the MASQUE protocol implementation may cause the 792 received UDP checksum value would need to be relayed to the client. 793 The UDP checksum value could also be calculated by the client and 794 included. 796 To support UDP Options, the UDP option and their values needs to be 797 signalled. 799 If support for including IPv6 Extension Headers that needs client 800 side information then the extension header information would need to 801 be indicated by the client and also tunnelled. 803 6.3. Event based Interactions 805 This section summarizes information that are triggered by events and 806 not directly connected to a specific packet in the IP/UDP flow being 807 relayed. Instead these are more of the nature of asynchronous events 808 caused by the network, the upper layer transport protocol, or 809 application. 811 The ECN setting for packets sent by the proxy to the target may need 812 to change. If the upper layer transport protocol determines that the 813 end-to-end path is not ECN capable it will need to change an ECT 814 marking to Not-ECT. Some protocols may defer probing for ECT 815 capability until after some initial handshake and packet exchange has 816 occurred. 818 The upper layer application may change its desired forwarding 819 behavior for the packets in the IP/UDP stream, thus the need for the 820 client to change the default applied DSCP value on packets sent by 821 the proxy to target. 823 The reception of ICMP messages by the proxy will likely be the result 824 of a packet sent to the target but the cause is likely in the 825 network. When this occurs the client needs to be informed of this 826 ICMP message, especially when this event leads to a connection 827 failure. 829 The proxy may detect an MTU change on the proxy to target path due to 830 received ICMP messages that are consumed in the IP stack of the proxy 831 and affecting the MTU for outgoing packets. Thus, the proxy may need 832 to indicate to the client that it no longer can send non-fragmented 833 packets larger than the new MTU. 835 7. Conclusion 837 This document shows that many of the fields in the IP/UDP header can 838 be signaled initially at flow establishment. Especially IP addresses 839 and potentially ports need to be communicated as those also need to 840 be used for flow identification. It also shows that certain field 841 values or related information needs to be relayed or signalled based 842 on asynchronous application or network events. Other field 843 information could need per packet relaying. The latter requires a 844 more active bidirectional communication channel between the proxy and 845 the client. 847 These aspects need to be taken into account in the future protocol 848 development of the CONNECT-UDP method to ensure that the MASQUE 849 protocol doesn't prevent future IP and transport protocol evolution. 851 8. References 853 8.1. Normative References 855 [I-D.ietf-quic-transport] 856 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 857 and Secure Transport", Work in Progress, Internet-Draft, 858 draft-ietf-quic-transport-33, 13 December 2020, 859 . 862 [I-D.ietf-tsvwg-udp-options] 863 Touch, J., "Transport Options for UDP", Work in Progress, 864 Internet-Draft, draft-ietf-tsvwg-udp-options-09, 25 865 November 2020, . 868 [I-D.schinazi-masque-connect-udp] 869 Schinazi, D., "The CONNECT-UDP HTTP Method", Work in 870 Progress, Internet-Draft, draft-schinazi-masque-connect- 871 udp-00, 16 April 2020, . 874 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 875 DOI 10.17487/RFC0768, August 1980, 876 . 878 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 879 DOI 10.17487/RFC0791, September 1981, 880 . 882 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 883 RFC 792, DOI 10.17487/RFC0792, September 1981, 884 . 886 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 887 "Definition of the Differentiated Services Field (DS 888 Field) in the IPv4 and IPv6 Headers", RFC 2474, 889 DOI 10.17487/RFC2474, December 1998, 890 . 892 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 893 of Explicit Congestion Notification (ECN) to IP", 894 RFC 3168, DOI 10.17487/RFC3168, September 2001, 895 . 897 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 898 (IPv6) Specification", STD 86, RFC 8200, 899 DOI 10.17487/RFC8200, July 2017, 900 . 902 8.2. Informative References 904 [I-D.ietf-6man-mtu-option] 905 Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop- 906 by-Hop Option", Work in Progress, Internet-Draft, draft- 907 ietf-6man-mtu-option-04, 23 October 2020, 908 . 911 [I-D.leddy-6man-truncate] 912 Leddy, J., Bonica, R., and I. Lubashev, "IPv6 Packet 913 Truncation", Work in Progress, Internet-Draft, draft- 914 leddy-6man-truncate-05, 10 October 2018, 915 . 918 [I-D.yiakoumis-network-tokens] 919 Yiakoumis, Y., McKeown, N., and F. Sorensen, "Network 920 Tokens", Work in Progress, Internet-Draft, draft- 921 yiakoumis-network-tokens-02, 22 December 2020, 922 . 925 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 926 RFC 793, DOI 10.17487/RFC0793, September 1981, 927 . 929 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 930 Control Message Protocol (ICMPv6) for the Internet 931 Protocol Version 6 (IPv6) Specification", STD 89, 932 RFC 4443, DOI 10.17487/RFC4443, March 2006, 933 . 935 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 936 for Equal Cost Multipath Routing and Link Aggregation in 937 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 938 . 940 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 941 for the Use of IPv6 UDP Datagrams with Zero Checksums", 942 RFC 6936, DOI 10.17487/RFC6936, April 2013, 943 . 945 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 946 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 947 DOI 10.17487/RFC7231, June 2014, 948 . 950 [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services 951 (Diffserv) and Real-Time Communication", RFC 7657, 952 DOI 10.17487/RFC7657, November 2015, 953 . 955 [RFC8656] Reddy, T., Ed., Johnston, A., Ed., Matthews, P., and J. 956 Rosenberg, "Traversal Using Relays around NAT (TURN): 957 Relay Extensions to Session Traversal Utilities for NAT 958 (STUN)", RFC 8656, DOI 10.17487/RFC8656, February 2020, 959 . 961 Authors' Addresses 963 Magnus Westerlund 964 Ericsson 966 Email: magnus.westerlund@ericsson.com 968 Marcus Ihlar 969 Ericsson 971 Email: marcus.ihlar@ericsson.com 973 Zaheduzzaman Sarker 974 Ericsson 976 Email: zaheduzzaman.sarker@ericsson.com 978 Mirja Kuehlewind 979 Ericsson 981 Email: mirja.kuehlewind@ericsson.com