idnits 2.17.1 draft-schinazi-masque-connect-udp-ecn-02.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 (28 March 2022) is 758 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 (-15) exists of draft-ietf-masque-connect-udp-08 == Outdated reference: A later version (-11) exists of draft-ietf-masque-h3-datagram-08 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MASQUE D. Schinazi 3 Internet-Draft Google LLC 4 Intended status: Standards Track 28 March 2022 5 Expires: 29 September 2022 7 An ECN Extension to CONNECT-UDP 8 draft-schinazi-masque-connect-udp-ecn-02 10 Abstract 12 CONNECT-UDP allows proxying UDP packets over HTTP. This document 13 describes an extension to CONNECT-UDP that allows conveying ECN 14 information on proxied UDP packets. 16 Discussion Venues 18 This note is to be removed before publishing as an RFC. 20 Source for this draft and an issue tracker can be found at 21 https://github.com/DavidSchinazi/draft-connect-udp-ecn. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 29 September 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 2 58 2. Context Identifiers . . . . . . . . . . . . . . . . . . . . . 2 59 3. ECN Header Definition . . . . . . . . . . . . . . . . . . . . 3 60 4. Encoding of ECN bits . . . . . . . . . . . . . . . . . . . . 3 61 5. A Note about Future Extensions . . . . . . . . . . . . . . . 4 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 65 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 CONNECT-UDP [CONNECT-UDP] allows proxying UDP packets over HTTP. 71 This document describes an extension to CONNECT-UDP that allows 72 conveying ECN [ECN] information on proxied UDP packets. 74 1.1. Conventions and Definitions 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 78 "OPTIONAL" in this document are to be interpreted as described in 79 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 80 capitals, as shown here. 82 2. Context Identifiers 84 The "Context Identifiers" section of [CONNECT-UDP] defines the 85 concept of context IDs and how they can be used to extend CONNECT- 86 UDP. When a client wishes to use ECN with CONNECT-UDP, it generates 87 an unique client-allocated context ID. In this document, we'll refer 88 to that context ID as the "chosen context ID". Note that, by 89 definition of client-allocated context IDs, the chosen context ID 90 will always be a non-zero even number. We also add the restriction 91 that the chosen context ID MUST be strictly less than 10^15. If the 92 client has run out of available context ID values that match this 93 requirement for this CONNECT-UDP request, it MUST NOT use the ECN 94 extension with this CONNECT-UDP request. 96 3. ECN Header Definition 98 The "ECN" header field is an Item Structured Field, see Section 3.3 99 of [STRUCT-FIELD]; its value MUST be a Integer; any other value type 100 MUST be handled as if the field were not present by recipients (for 101 example, if this field is included multiple times, its type will 102 become a List and the field will therefore be ignored). This 103 document does not define any parameters for the "ECN" header field 104 value, but future documents might define parameters. Receivers MUST 105 ignore unknown parameters. 107 When present, the "ECN" header indicates that the sender supports 108 this extension, and communicates the chosen context ID as the "ECN" 109 field value. 111 For example, if the client chosen context ID is 42, it would send the 112 following: 114 ECN: 42; foo=bar 116 Figure 1: Example Client ECN Field 118 Clients MUST NOT indicate support for this extension unless they know 119 that the protocol running over UDP that is being proxied supports 120 ECN, and will react appropriately to Congestion Experienced (CE) 121 markings. 123 Proxies MUST NOT indicate support for this extension unless they know 124 they have the ability to read and write the IP ECN bits on its 125 target-bound UDP sockets. 127 This extension is said to have been negotiated when both client and 128 proxy indicated support for it in their CONNECT-UDP request and 129 response. When indicating support for this extension, the proxy send 130 the client's chosen context ID as the "ECN" field value. 132 For example, the proxy could reply with: 134 ECN: 42 136 Figure 2: Example Proxy ECN Field 138 4. Encoding of ECN bits 140 When an HTTP Datagram [HTTP-DGRAM] associated with a CONNECT-UDP 141 stream uses the chosen context ID as its context ID, its "Payload" 142 field contains the following format (using the notation from the 143 "Notational Conventions" section of [QUIC]): 145 CONNECT-UDP Payload with ECN { 146 Must be Zero (6), 147 ECN Bits (2), 148 UDP Payload (..), 149 } 151 Figure 3: CONNECT-UDP Payload with ECN 153 Must be Zero: 6 bits that MUST be sent as zero. Receivers MUST 154 validate that these bits are zero and MUST silently drop the HTTP 155 Datagram if they have any other value. Extensions to this 156 mechanism MAY relax this requirement. 158 ECN Bits: The ECN bits, sent in the same order as they appear in the 159 IP header. 161 UDP Payload: The UDP Payload, as defined in the "HTTP Datagram 162 Payload Format" section of [CONNECT-UDP]. 164 When the proxy receives a datagram with the chosen context ID, it 165 sets the IP packet's ECN bits accordingly on the UDP packet it sends 166 to the target. Similarly, in the other direction the ECN Bits field 167 represents which ECN bits were seen on the UDP packets received from 168 the target. 170 5. A Note about Future Extensions 172 This CONNECT-UDP extension uses an HTTP field to register its chosen 173 context ID. Future extensions to CONNECT-UDP can use the same 174 strategy to register their chosen context ID(s) via another HTTP 175 field. This strategy is best for CONNECT-UDP extensions that only 176 need to register context IDs during the HTTP request and response. 178 Some extensions may need to register context IDs after the request 179 and response have been exchanged, for example an extension that 180 wishes to compress QUIC connection IDs [QUIC] is not aware of all 181 connection IDs at request time. In such cases, extensions can use 182 new Capsule Types (see [HTTP-DGRAM]) to perform context ID 183 registration. 185 6. Security Considerations 187 This document does not have additional security considerations beyond 188 those defined in [CONNECT-UDP]. 190 7. IANA Considerations 192 This document will request IANA to register the following entry in 193 the "HTTP Field Name" registry: 195 Field Name: ECN 197 Template: None 199 Status: provisional (permanent if this document is approved) 201 Reference: This document 203 Comments: None 205 8. Normative References 207 [CONNECT-UDP] 208 Schinazi, D., "UDP Proxying Support for HTTP", Work in 209 Progress, Internet-Draft, draft-ietf-masque-connect-udp- 210 08, 21 March 2022, . 213 [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 214 of Explicit Congestion Notification (ECN) to IP", 215 RFC 3168, DOI 10.17487/RFC3168, September 2001, 216 . 218 [HTTP-DGRAM] 219 Schinazi, D. and L. Pardue, "HTTP Datagrams and the 220 Capsule Protocol", Work in Progress, Internet-Draft, 221 draft-ietf-masque-h3-datagram-08, 28 March 2022, 222 . 225 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 226 Multiplexed and Secure Transport", RFC 9000, 227 DOI 10.17487/RFC9000, May 2021, 228 . 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, 232 DOI 10.17487/RFC2119, March 1997, 233 . 235 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 236 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 237 May 2017, . 239 [STRUCT-FIELD] 240 Nottingham, M. and P-H. Kamp, "Structured Field Values for 241 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, 242 . 244 Acknowledgments 246 This proposal was inspired directly or indirectly by prior work from 247 many people. The author would like to thank contributors the MASQUE 248 working group. 250 Author's Address 252 David Schinazi 253 Google LLC 254 1600 Amphitheatre Parkway 255 Mountain View, California 94043, 256 United States of America 257 Email: dschinazi.ietf@gmail.com