idnits 2.17.1 draft-banks-quic-cibir-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 : ---------------------------------------------------------------------------- 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (1 March 2022) is 786 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC N. Banks 3 Internet-Draft Microsoft Corporation 4 Intended status: Experimental 1 March 2022 5 Expires: 2 September 2022 7 QUIC Connection ID Based Initial Routing 8 draft-banks-quic-cibir-01 10 Abstract 12 This document defines an extension to the QUIC transport protocol to 13 consistently route all packets from a client to the appropriate 14 server on a shared UDP port. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 2 September 2022. 33 Copyright Notice 35 Copyright (c) 2022 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Revised BSD License text as 44 described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Revised BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 2 51 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2.1. Transport Parameter . . . . . . . . . . . . . . . . . . . 3 53 2.2. Packet Encoding and Routing . . . . . . . . . . . . . . . 3 54 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. QUIC Transport Parameter . . . . . . . . . . . . . . . . 4 57 5. Normative References . . . . . . . . . . . . . . . . . . . . 4 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1. Introduction 62 Several scenarios exist where multiple independent or isolated 63 servers need to run in the same environment, but cannot use 64 independent local UDP ports. For instance, in server deployments 65 that have hundreds or thousands of machines, each with tens or 66 hundreds of different QUIC servers running on them, the server 67 infrastructure may not be able to support the number of local UDP 68 ports it would require to give each server a unique one. 69 Additionally, because of infrastructure requirements additional IP 70 addresses may not be able to be used as a solution either. 72 In these scenarios, the server infrastructure needs a way to 73 essentially NAT QUIC packets on a shared local UDP port between all 74 servers using that port. This document defines a mechanism for using 75 QUIC connection IDs to encode the necessary information for all 76 client to server QUIC packets to be correctly routed to the 77 appropriate server. A cooperating client can then use this to 78 specifically target a server on a shared port. 80 1.1. Terms and Definitions 82 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 84 "OPTIONAL" in this document are to be interpreted as described in BCP 85 14 [RFC2119] [RFC8174] when, and only when, they appear in all 86 capitals, as shown here. 88 2. Specification 89 2.1. Transport Parameter 91 Support for encoding CIBIR information is negotiated by means of a 92 QUIC Transport Parameter (name=cibir_encoding, value=0x1000). The 93 cibir_encoding transport parameter consists of two integer values 94 (represented as variable-length integers) that represent the length 95 and offset to the well-known identifier encoded into the client's 96 source connection ID. 98 Servers that share a local UDP port using the CIBIR extension 99 unconditionally route received packets according to the CIBIR 100 extension's protocol. The cibir_encoding transport parameter is used 101 on the server side after the routing has already happened to validate 102 the intent of the client. Servers MUST validate the client sent the 103 cibir_encoding transport parameter with the matching offset and 104 length that has been configured locally. If the transport parameter 105 is missing or contains incorrect values the server MUST terminate the 106 connection with an error of type CONNECTION_REFUSED. 108 No special routing is done on the client side, but client MUST also 109 validate the server sent the cibir_encoding transport parameter with 110 the matching offset and length so as to verify the server is 111 cooperating in the expected routing scheme. If the transport 112 parameter is missing or contains incorrect values the client MUST 113 terminate the connection with an error of type 114 TRANSPORT_PARAMETER_ERROR. 116 2.2. Packet Encoding and Routing 118 The base QUIC transport protocol provides no way to consistently 119 route long header packets to the correct server in a shared UDP 120 environment. The only possibly way a server's infrastructure has to 121 identify which server the client is trying to connect to is the ALPN 122 or SNI, but these are not included in all long header packets. 123 Additionally, the destination connection ID in packets sent to the 124 server cannot be used because there is no stateless way determine if 125 the CID is client or server chosen, not to mention the complexities 126 around server chosen CIDs in a load balanced environment (which the 127 client does not necessarily know anything about). 129 To achieve consistent routing for these long header packets, the 130 client encodes a well-known identifier into its source connection ID. 131 The length and offset of the well-known ID must be pre-agreed upon 132 between the client and server, and is validated via the 133 cibir_encoding transport parameter as described above. When the 134 server infrastructure receives a QUIC long header packet on the 135 shared UDP port it uses the well-known identifier to route the packet 136 to the correct server. 138 No special routing is necessary for short header packets. These 139 packets always use server chosen destination connection IDs, and the 140 logic by which these CIDs are chosen, created and interpreted is 141 purely up to the server and server infrastructure. The client 142 doesn't need to be involved in this logic beyond the normal use of 143 destination connection IDs. 145 3. Security Considerations 147 The client encodes well-known IDs in the QUIC connection ID that may 148 expose information to an observer. 150 4. IANA Considerations 152 4.1. QUIC Transport Parameter 154 This document registers a new value in the QUIC Transport Parameter 155 Registry maintained at https://www.iana.org/assignments/quic/ 156 quic.xhtml#quic-transport. 158 Value: 0x1000 160 Parameter Name: cibir_encoding 162 Status: permanent 164 Specification: This document 166 5. Normative References 168 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 169 Requirement Levels", BCP 14, RFC 2119, 170 DOI 10.17487/RFC2119, March 1997, 171 . 173 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 174 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 175 May 2017, . 177 Author's Address 179 Nick Banks 180 Microsoft Corporation 181 Email: nibanks@microsoft.com