idnits 2.17.1 draft-duke-masque-other-transport-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([CONNECTUDP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 January 2021) is 1187 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-masque-connect-udp-03 -- Obsolete informational reference (is this intentional?): RFC 4330 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MASQUE M. Duke 3 Internet-Draft F5, Inc. 4 Intended status: Experimental 25 January 2021 5 Expires: 29 July 2021 7 The Other-Transport Extension: Arbitrary Transports over CONNECT-UDP 8 draft-duke-masque-other-transport-00 10 Abstract 12 This document describes an extension to the HTTP CONNECT-UDP method 13 [CONNECTUDP] that supports tunneling of other transport protocols, as 14 long as the first four octets of those protocols encode the source 15 and destination ports. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 29 July 2021. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 52 2. Other-Transport Header Definition . . . . . . . . . . . . . . 3 53 3. Datagram Encoding of Proxied Packets . . . . . . . . . . . . 4 54 4. Stream Encoding of Proxied Packets . . . . . . . . . . . . . 4 55 5. HTTP Intermediaries . . . . . . . . . . . . . . . . . . . . . 4 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 7.1. HTTP Header . . . . . . . . . . . . . . . . . . . . . . . 5 59 7.2. Stream Chunk Type Registration . . . . . . . . . . . . . 5 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 8.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 The HTTP CONNECT method (section 4.3.6 of [RFC7231]) has long 69 provided a means of tunneling a TCP connection over an HTTP stream. 70 The CONNECT-UDP method [CONNECTUDP] extends this capability to 71 include UDP datagrams over a stream. 73 As CONNECT-UDP delivers discrete datagrams to each endpoint, it can 74 extend conceptually to any packetized protocol. The Other-Transport 75 extension allows a CONNECT-UDP proxy to tunnel packets with non-TCP, 76 non-UDP protocol numbers, as long as the corresponding protocol meets 77 minimal formatting requirements. 79 Specifically, any protocol header where the first four octets encode 80 the source and destination ports can be tunneled using this 81 framework. The client and proxy include all other protocol header 82 information in the datagrams delivered over the tunnel. For example, 83 33 (DCCP, [RFC4330]); 132 (SCTP, [RFC4960]); and 136 (UDPLite, 84 [RFC3828]) would all be valid candidates for Other-Transport. 86 In principle, TCP can be proxied using this extension as well. This 87 might provide advantages over traditional HTTP CONNECT if the 88 client's TCP implementation has features lacking at the proxy. 90 1.1. Conventions and Definitions 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in BCP 95 14 [RFC2119] [RFC8174] when, and only when, they appear in all 96 capitals, as shown here. 98 In this document, we use the term "proxy" to refer to the HTTP server 99 that opens the UDP socket and responds to the CONNECT-UDP request. 100 If there are HTTP intermediaries (as defined in Section 2.3 of 101 [RFC7230]) between the client and the proxy, those are referred to as 102 "intermediaries" in this document. 104 2. Other-Transport Header Definition 106 "Other-Transport" is an Item Structured Header [HDRSTRUCT]. Its ABNF 107 is: 109 Other-Transport = sf-integer 111 The value MUST be between 0 and 255, inclusive. Any other value is 112 malformed. This value indicates the value of the Protocol Number 113 (IPv4) or Next Header (IPv6) in IP headers corresponding to the 114 CONNECT-UDP stream. 116 An Other-Transport header is ignored in any method other than 117 CONNECT-UDP. 119 A client that sends this header MUST include the entire transport 120 header, with the exception of the first four octets, in each HTTP/3 121 DATAGRAM or Stream Chunk payload it sends. It MUST process incoming 122 datagrams with the same assumption. 124 When a client sends the Other-Transport header field, it MUST use a 125 value that corresponds to a protocol whose first four octets of each 126 packet correspond to the source and destination ports. For example, 127 33 (DCCP, [RFC4330]); 132 (SCTP, [RFC4960]); and 136 (UDPLite, 128 [RFC3828]) would all be valid choices. 130 A proxy MUST NOT include this header unless it will prepend and strip 131 port numbers instead of entire UDP headers, and use the Protocol 132 Number in IP headers for both packets to the server and for 133 demultiplexing incoming server packets. 135 A proxy MAY choose not to send the header due to policy regarding 136 specific protocol numbers. 138 This extension is said to have been negotiated when both client and 139 proxy indicate support for it in their CONNECT-UDP request and 140 response using the same value. 142 If the server responds without the Other-Transport header, the client 143 may either proceed with UDP datagrams or close the stream. 145 A response with a Other-Transport value other than that provided by 146 the client is malformed. 148 3. Datagram Encoding of Proxied Packets 150 All DATAGRAM frames corresponding to the negotiated Datagram-Flow-Id 151 headers are processed in accordance with the Other-Transport 152 extension, if negotiated. 154 All DATAGRAM frames MUST include the entire IP payload with the 155 exception of the first four octets. 157 If a client sent an Other-Transport header, it MUST NOT send DATAGRAM 158 frames until it confirms this extension has been negotiated. If the 159 proxy does not support Other-Transport, it will interpret DATAGRAM 160 frames as UDP payloads, with unpredictable results. 162 4. Stream Encoding of Proxied Packets 164 Endpoints use the 0x10 Stream Chunk Type to encode datagrams. 166 Clients MAY send payloads using Stream Chunks before negotiation is 167 complete. Proxies that do not support the extension will simply 168 ignore these chunks. 170 5. HTTP Intermediaries 172 HTTP Intermediaries that discover that an upstream proxy does not 173 support the Other-Transport header MUST abort the stream in the 174 direction of the client. 176 6. Security Considerations 178 CONNECT-UDP streams that use the Other-Transport header have similar 179 security properties to other CONNECT-UDP streams, as described in 180 [CONNECTUDP]. 182 However, as more of the transport header originates at the server, 183 and the tunneled protocols are less ubiquitous than UDP, these 184 headers may serve to fingerprint the protocol implementation that 185 generated them. 187 Furthermore, additional control over packet headers enhances the 188 ability of clients to induce the proxy to generate certain packets, 189 which might have undesirable effects in the network while being less 190 traceable to the client. 192 7. IANA Considerations 194 7.1. HTTP Header 196 This document requests that IANA registers the "Other-Transport" 197 header in the "Permanent Message Header Field Names" registry 198 maintained at . 200 +-------------------+----------+--------+---------------+ 201 | Header Field Name | Protocol | Status | Reference | 202 +-------------------+----------+--------+---------------+ 203 | Other-Transport | http | std | This document | 204 +-------------------+----------+--------+---------------+ 206 7.2. Stream Chunk Type Registration 208 This document will request IANA to register the following entry in 209 the "CONNECT-UDP Stream Chunk Type" registry [CONNECTUDP]: 211 +-------+-----------------+-------------------------+---------------+ 212 | Value | Type | Description | Reference | 213 +-------+-----------------+-------------------------+---------------+ 214 | 0x10 | OTHER_TRANSPORT | Other Transport Protocol| This document | 215 +-------+-----------------+-------------------------+---------------+ 217 8. References 219 8.1. Normative References 221 [CONNECTUDP] 222 Schinazi, D., "The CONNECT-UDP HTTP Method", Work in 223 Progress, Internet-Draft, draft-ietf-masque-connect-udp- 224 03, 5 January 2021, . 227 [HDRSTRUCT] 228 Nottingham, M. and P. Kamp, "Structured Field Values for 229 HTTP", Work in Progress, Internet-Draft, draft-ietf- 230 httpbis-header-structure-19, 3 June 2020, 231 . 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, 236 DOI 10.17487/RFC2119, March 1997, 237 . 239 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 240 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 241 May 2017, . 243 8.2. Informative References 245 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., 246 and G. Fairhurst, Ed., "The Lightweight User Datagram 247 Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 248 2004, . 250 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 251 for IPv4, IPv6 and OSI", RFC 4330, DOI 10.17487/RFC4330, 252 January 2006, . 254 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 255 RFC 4960, DOI 10.17487/RFC4960, September 2007, 256 . 258 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 259 Protocol (HTTP/1.1): Message Syntax and Routing", 260 RFC 7230, DOI 10.17487/RFC7230, June 2014, 261 . 263 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 264 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 265 DOI 10.17487/RFC7231, June 2014, 266 . 268 Acknowledgments 270 Author's Address 272 Martin Duke 273 F5, Inc. 274 801 5th Ave 275 Seattle, Washington, 98104, 276 United States of America 278 Email: martin.h.duke@gmail.com