idnits 2.17.1 draft-ietf-quic-load-balancers-13.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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1343 has weird spacing: '...on-bits uin...' == Line 1349 has weird spacing: '...address ine...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (28 March 2022) is 760 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 (-18) exists of draft-ietf-tls-esni-14 -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC M. Duke 3 Internet-Draft Google 4 Intended status: Standards Track N. Banks 5 Expires: 29 September 2022 Microsoft 6 C. Huitema 7 Private Octopus Inc. 8 28 March 2022 10 QUIC-LB: Generating Routable QUIC Connection IDs 11 draft-ietf-quic-load-balancers-13 13 Abstract 15 QUIC address migration allows clients to change their IP address 16 while maintaining connection state. To reduce the ability of an 17 observer to link two IP addresses, clients and servers use new 18 connection IDs when they communicate via different client addresses. 19 This poses a problem for traditional "layer-4" load balancers that 20 route packets via the IP address and port 4-tuple. This 21 specification provides a standardized means of securely encoding 22 routing information in the server's connection IDs so that a properly 23 configured load balancer can route packets with migrated addresses 24 correctly. As it proposes a structured connection ID format, it also 25 provides a means of connection IDs self-encoding their length to aid 26 some hardware offloads. 28 Note to Readers 30 Discussion of this document takes place on the QUIC Working Group 31 mailing list (quic@ietf.org), which is archived at 32 https://mailarchive.ietf.org/arch/browse/quic/ 33 (https://mailarchive.ietf.org/arch/browse/quic/). 35 Source for this draft and an issue tracker can be found at 36 https://github.com/quicwg/load-balancers (https://github.com/quicwg/ 37 load-balancers). 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 29 September 2022. 56 Copyright Notice 58 Copyright (c) 2022 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Revised BSD License text as 67 described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Revised BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 74 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5 75 2. First CID octet . . . . . . . . . . . . . . . . . . . . . . . 6 76 2.1. Config Rotation . . . . . . . . . . . . . . . . . . . . . 6 77 2.2. Configuration Failover . . . . . . . . . . . . . . . . . 7 78 2.3. Length Self-Description . . . . . . . . . . . . . . . . . 7 79 2.4. Format . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 3. Load Balancing Preliminaries . . . . . . . . . . . . . . . . 8 81 3.1. Unroutable Connection IDs . . . . . . . . . . . . . . . . 8 82 3.2. Fallback Algorithms . . . . . . . . . . . . . . . . . . . 10 83 3.3. Server ID Allocation . . . . . . . . . . . . . . . . . . 10 84 4. Server ID Encoding in Connection IDs . . . . . . . . . . . . 11 85 4.1. CID format . . . . . . . . . . . . . . . . . . . . . . . 11 86 4.2. Configuration Agent Actions . . . . . . . . . . . . . . . 11 87 4.3. Server Actions . . . . . . . . . . . . . . . . . . . . . 11 88 4.3.1. Special Case: Single Pass Encryption . . . . . . . . 12 89 4.3.2. General Case: Four-Pass Encryption . . . . . . . . . 12 90 4.4. Load Balancer Actions . . . . . . . . . . . . . . . . . . 14 91 4.4.1. Special Case: Single Pass Encryption . . . . . . . . 15 92 4.4.2. General Case: Four-Pass Encryption . . . . . . . . . 15 93 5. Per-connection state . . . . . . . . . . . . . . . . . . . . 15 94 6. Additional Use Cases . . . . . . . . . . . . . . . . . . . . 16 95 6.1. Load balancer chains . . . . . . . . . . . . . . . . . . 16 96 6.2. Moving connections between servers . . . . . . . . . . . 17 98 7. Version Invariance of QUIC-LB . . . . . . . . . . . . . . . . 17 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 100 8.1. Attackers not between the load balancer and server . . . 19 101 8.2. Attackers between the load balancer and server . . . . . 19 102 8.3. Multiple Configuration IDs . . . . . . . . . . . . . . . 19 103 8.4. Limited configuration scope . . . . . . . . . . . . . . . 19 104 8.5. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 20 105 8.6. Connection ID Entropy . . . . . . . . . . . . . . . . . . 21 106 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 108 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 109 10.2. Informative References . . . . . . . . . . . . . . . . . 22 110 Appendix A. QUIC-LB YANG Model . . . . . . . . . . . . . . . . . 23 111 A.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 29 112 Appendix B. Load Balancer Test Vectors . . . . . . . . . . . . . 29 113 B.1. Unencrypted CIDs . . . . . . . . . . . . . . . . . . . . 30 114 B.2. Encrypted CIDs . . . . . . . . . . . . . . . . . . . . . 30 115 Appendix C. Interoperability with DTLS over UDP . . . . . . . . 30 116 C.1. DTLS 1.0 and 1.2 . . . . . . . . . . . . . . . . . . . . 30 117 C.2. DTLS 1.3 . . . . . . . . . . . . . . . . . . . . . . . . 31 118 C.3. Future Versions of DTLS . . . . . . . . . . . . . . . . . 32 119 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 32 120 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 32 121 E.1. since draft-ietf-quic-load-balancers-12 . . . . . . . . . 32 122 E.2. since draft-ietf-quic-load-balancers-11 . . . . . . . . . 32 123 E.3. since draft-ietf-quic-load-balancers-10 . . . . . . . . . 32 124 E.4. since draft-ietf-quic-load-balancers-09 . . . . . . . . . 33 125 E.5. since draft-ietf-quic-load-balancers-08 . . . . . . . . . 33 126 E.6. since draft-ietf-quic-load-balancers-07 . . . . . . . . . 33 127 E.7. since draft-ietf-quic-load-balancers-06 . . . . . . . . . 33 128 E.8. since draft-ietf-quic-load-balancers-05 . . . . . . . . . 33 129 E.9. since draft-ietf-quic-load-balancers-04 . . . . . . . . . 34 130 E.10. since-draft-ietf-quic-load-balancers-03 . . . . . . . . . 34 131 E.11. since-draft-ietf-quic-load-balancers-02 . . . . . . . . . 34 132 E.12. since-draft-ietf-quic-load-balancers-01 . . . . . . . . . 34 133 E.13. since-draft-ietf-quic-load-balancers-00 . . . . . . . . . 35 134 E.14. Since draft-duke-quic-load-balancers-06 . . . . . . . . . 35 135 E.15. Since draft-duke-quic-load-balancers-05 . . . . . . . . . 35 136 E.16. Since draft-duke-quic-load-balancers-04 . . . . . . . . . 35 137 E.17. Since draft-duke-quic-load-balancers-03 . . . . . . . . . 35 138 E.18. Since draft-duke-quic-load-balancers-02 . . . . . . . . . 35 139 E.19. Since draft-duke-quic-load-balancers-01 . . . . . . . . . 36 140 E.20. Since draft-duke-quic-load-balancers-00 . . . . . . . . . 36 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 143 1. Introduction 145 QUIC packets [RFC9000] usually contain a connection ID to allow 146 endpoints to associate packets with different address/port 4-tuples 147 to the same connection context. This feature makes connections 148 robust in the event of NAT rebinding. QUIC endpoints usually 149 designate the connection ID which peers use to address packets. 150 Server-generated connection IDs create a potential need for out-of- 151 band communication to support QUIC. 153 QUIC allows servers (or load balancers) to designate an initial 154 connection ID to encode useful routing information for load 155 balancers. It also encourages servers, in packets protected by 156 cryptography, to provide additional connection IDs to the client. 157 This allows clients that know they are going to change IP address or 158 port to use a separate connection ID on the new path, thus reducing 159 linkability as clients move through the world. 161 There is a tension between the requirements to provide routing 162 information and mitigate linkability. Ultimately, because new 163 connection IDs are in protected packets, they must be generated at 164 the server if the load balancer does not have access to the 165 connection keys. However, it is the load balancer that has the 166 context necessary to generate a connection ID that encodes useful 167 routing information. In the absence of any shared state between load 168 balancer and server, the load balancer must maintain a relatively 169 expensive table of server-generated connection IDs, and will not 170 route packets correctly if they use a connection ID that was 171 originally communicated in a protected NEW_CONNECTION_ID frame. 173 This specification provides common algorithms for encoding the server 174 mapping in a connection ID given some shared parameters. The mapping 175 is generally only discoverable by observers that have the parameters, 176 preserving unlinkability as much as possible. 178 As this document proposes a structured QUIC Connection ID, it also 179 proposes a system for self-encoding connection ID length in all 180 packets, so that crypto offload can efficiently obtain key 181 information. 183 While this document describes a small set of configuration parameters 184 to make the server mapping intelligible, the means of distributing 185 these parameters between load balancers, servers, and other trusted 186 intermediaries is out of its scope. There are numerous well-known 187 infrastructures for distribution of configuration. 189 1.1. Terminology 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in RFC 2119 [RFC2119]. 195 In this document, these words will appear with that interpretation 196 only when in ALL CAPS. Lower case uses of these words are not to be 197 interpreted as carrying significance described in RFC 2119. 199 In this document, "client" and "server" refer to the endpoints of a 200 QUIC connection unless otherwise indicated. A "load balancer" is an 201 intermediary for that connection that does not possess QUIC 202 connection keys, but it may rewrite IP addresses or conduct other IP 203 or UDP processing. A "configuration agent" is the entity that 204 determines the QUIC-LB configuration parameters for the network and 205 leverages some system to distribute that configuration. 207 Note that stateful load balancers that act as proxies, by terminating 208 a QUIC connection with the client and then retrieving data from the 209 server using QUIC or another protocol, are treated as a server with 210 respect to this specification. 212 For brevity, "Connection ID" will often be abbreviated as "CID". 214 1.2. Notation 216 All wire formats will be depicted using the notation defined in 217 Section 1.3 of [RFC9000]. There is one addition: the function len() 218 refers to the length of a field which can serve as a limit on a 219 different field, so that the lengths of two fields can be concisely 220 defined as limited to a sum, for example: 222 x(A..B) y(C..B-len(x)) 224 indicates that x can be of any length between A and B, and y can be 225 of any length between C and B provided that (len(x) + len(y)) does 226 not exceed B. 228 The example below illustrates the basic framework: 230 Example Structure { 231 One-bit Field (1), 232 7-bit Field with Fixed Value (7) = 61, 233 Field with Variable-Length Integer (i), 234 Arbitrary-Length Field (..), 235 Variable-Length Field (8..24), 236 Variable-Length Field with Dynamic Limit (8..24-len(Variable-Length Field)), 237 Field With Minimum Length (16..), 238 Field With Maximum Length (..128), 239 [Optional Field (64)], 240 Repeated Field (8) ..., 241 } 243 Figure 1: Example Format 245 2. First CID octet 247 The first octet of a Connection ID is reserved for two special 248 purposes, one mandatory (config rotation) and one optional (length 249 self-description). 251 Subsequent sections of this document refer to the contents of this 252 octet as the "first octet." 254 2.1. Config Rotation 256 The first two bits of any connection ID MUST encode an identifier for 257 the configuration that the connection ID uses. This enables 258 incremental deployment of new QUIC-LB settings (e.g., keys). 260 When new configuration is distributed to servers, there will be a 261 transition period when connection IDs reflecting old and new 262 configuration coexist in the network. The rotation bits allow load 263 balancers to apply the correct routing algorithm and parameters to 264 incoming packets. 266 Configuration Agents SHOULD deliver new configurations to load 267 balancers before doing so to servers, so that load balancers are 268 ready to process CIDs using the new parameters when they arrive. 270 A Configuration Agent SHOULD NOT use a codepoint to represent a new 271 configuration until it takes precautions to make sure that all 272 connections using CIDs with an old configuration at that codepoint 273 have closed or transitioned. 275 Servers MUST NOT generate new connection IDs using an old 276 configuration after receiving a new one from the configuration agent. 277 Servers MUST send NEW_CONNECTION_ID frames that provide CIDs using 278 the new configuration, and retire CIDs using the old configuration 279 using the "Retire Prior To" field of that frame. 281 It also possible to use these bits for more long-lived distinction of 282 different configurations, but this has privacy implications (see 283 Section 8.3). 285 2.2. Configuration Failover 287 If a server has not received a valid QUIC-LB configuration, and 288 believes that low-state, Connection-ID aware load balancers are in 289 the path, it SHOULD generate connection IDs with the config rotation 290 bits set to '11' and SHOULD use the "disable_active_migration" 291 transport parameter in all new QUIC connections. It SHOULD NOT send 292 NEW_CONNECTION_ID frames with new values. 294 A load balancer that sees a connection ID with config rotation bits 295 set to '11' MUST revert to 5-tuple routing. These connection IDs may 296 be of any length; however, see Section 8.6 for limits on this length. 298 2.3. Length Self-Description 300 Local hardware cryptographic offload devices may accelerate QUIC 301 servers by receiving keys from the QUIC implementation indexed to the 302 connection ID. However, on physical devices operating multiple QUIC 303 servers, it is impractical to efficiently lookup these keys if the 304 connection ID does not self-encode its own length. 306 Note that this is a function of particular server devices and is 307 irrelevant to load balancers. As such, load balancers MAY omit this 308 from their configuration. However, the remaining 6 bits in the first 309 octet of the Connection ID are reserved to express the length of the 310 following connection ID, not including the first octet. 312 A server not using this functionality SHOULD make the six bits appear 313 to be random. 315 2.4. Format 317 First Octet { 318 Config Rotation (2), 319 CID Len or Random Bits (6), 320 } 322 Figure 2: First Octet Format 324 The first octet has the following fields: 326 Config Rotation: Indicates the configuration used to interpret the 327 CID. 329 CID Len or Random Bits: Length Self-Description (if applicable), or 330 random bits otherwise. Encodes the length of the Connection ID 331 following the First Octet. 333 3. Load Balancing Preliminaries 335 In QUIC-LB, load balancers do not generate individual connection IDs 336 for servers. Instead, they communicate the parameters of an 337 algorithm to generate routable connection IDs. 339 The algorithms differ in the complexity of configuration at both load 340 balancer and server. Increasing complexity improves obfuscation of 341 the server mapping. 343 This section describes three participants: the configuration agent, 344 the load balancer, and the server. For any given QUIC-LB 345 configuration that enables connection-ID-aware load balancing, there 346 must be a choice of (1) routing algorithm, (2) server ID allocation 347 strategy, and (3) algorithm parameters. 349 Fundamentally, servers generate connection IDs that encode their 350 server ID. Load balancers decode the server ID from the CID in 351 incoming packets to route to the correct server. 353 There are situations where a server pool might be operating two or 354 more routing algorithms or parameter sets simultaneously. The load 355 balancer uses the first two bits of the connection ID to multiplex 356 incoming DCIDs over these schemes (see Section 2.1). 358 3.1. Unroutable Connection IDs 360 QUIC-LB servers will generate Connection IDs that are decodable to 361 extract a server ID in accordance with a specified algorithm and 362 parameters. However, QUIC often uses client-generated Connection IDs 363 prior to receiving a packet from the server. 365 These client-generated CIDs might not conform to the expectations of 366 the routing algorithm and therefore not be routable by the load 367 balancer. Those that are not routable are "unroutable DCIDs" and 368 receive similar treatment regardless of why they're unroutable: 370 * The config rotation bits (Section 2.1) may not correspond to an 371 active configuration. Note: a packet with a DCID that indicates 372 5-tuple routing (see Section 2.2) is always routable. 374 * The DCID might not be long enough for the decoder to process. 376 * The extracted server mapping might not correspond to an active 377 server. 379 All other DCIDs are routable. 381 Load balancers MUST forward packets with routable DCIDs to a server 382 in accordance with the chosen routing algorithm. Exception: if the 383 load balancer can parse the QUIC packet and makes a routing decision 384 depending on the contents (e.g., the SNI in a TLS client hello), it 385 MAY route in accordance with this instead. However, load balancers 386 MUST always route long header packets it cannot parse in accordance 387 with the DCID (see Section 7). 389 Load balancers SHOULD drop short header packets with unroutable 390 DCIDs. 392 When forwarding a packet with a long header and unroutable DCID, load 393 balancers MUST use a fallback algorithm as specified in Section 3.2. 395 Load balancers MAY drop packets with long headers and unroutable 396 DCIDs if and only if it knows that the encoded QUIC version does not 397 allow an unroutable DCID in a packet with that signature. For 398 example, a load balancer can safely drop a QUIC version 1 Handshake 399 packet with an unroutable DCID, as a version 1 Handshake packet sent 400 to a QUIC-LB routable server will always have a server-generated 401 routable CID. The prohibition against dropping packets with long 402 headers remains for unknown QUIC versions. 404 Furthermore, while the load balancer function MUST NOT drop packets, 405 the device might implement other security policies, outside the scope 406 of this specification, that might force a drop. 408 Servers that receive packets with unroutable CIDs MUST use the 409 available mechanisms to induce the client to use a routable CID in 410 future packets. In QUIC version 1, this requires using a routable 411 CID in the Source CID field of server-generated long headers. 413 3.2. Fallback Algorithms 415 There are conditions described below where a load balancer routes a 416 packet using a "fallback algorithm." It can choose any algorithm, 417 without coordination with the servers, but the algorithm SHOULD be 418 deterministic over short time scales so that related packets go to 419 the same server. The design of this algorithm SHOULD consider the 420 version-invariant properties of QUIC described in [RFC8999] to 421 maximize its robustness to future versions of QUIC. 423 A fallback algorithm MUST NOT make the routing behavior dependent on 424 any bits in the first octet of the QUIC packet header, except the 425 first bit, which indicates a long header. All other bits are QUIC 426 version-dependent and intermediaries SHOULD NOT base their design on 427 version-specific templates. 429 For example, one fallback algorithm might convert a unroutable DCID 430 to an integer and divided by the number of servers, with the modulus 431 used to forward the packet. The number of servers is usually 432 consistent on the time scale of a QUIC connection handshake. Another 433 might simply hash the address/port 4-tuple. See also Section 7. 435 3.3. Server ID Allocation 437 Load Balancer configurations include a mapping of server IDs to 438 forwarding addresses. The corresponding server configurations 439 contain one or more unique server IDs. 441 The configuration agent chooses a server ID length for each 442 configuration that MUST be at least one octet. 444 A QUIC-LB configuration MAY significantly over-provision the server 445 ID space (i.e., provide far more codepoints than there are servers) 446 to increase the probability that a randomly generated Destination 447 Connection ID is unroutable. 449 The configuration agent SHOULD provide a means for servers to express 450 the number of server IDs it can usefully employ, because a single 451 routing address actually corresponds to multiple server entities (see 452 Section 6.1). 454 Conceptually, each configuration has its own set of server ID 455 allocations, though two static configurations with identical server 456 ID lengths MAY use a common allocation between them. 458 A server encodes one of its assigned server IDs in any CID it 459 generates using the relevant configuration. 461 4. Server ID Encoding in Connection IDs 463 4.1. CID format 465 All connection IDs use the following format: 467 QUIC-LB Connection ID { 468 First Octet (8), 469 Server ID (8..152-len(Nonce)), 470 Nonce (32..152-len(Server ID)), 471 } 473 Figure 3: CID Format 475 4.2. Configuration Agent Actions 477 The configuration agent assigns a server ID to every server in its 478 pool in accordance with Section 3.3, and determines a server ID 479 length (in octets) sufficiently large to encode all server IDs, 480 including potential future servers. 482 Each configuration specifies the length of the Server ID and Nonce 483 fields, with limits defined for each algorithm. 485 Optionally, it also defines a 16-octet key. Note that failure to 486 define a key means that observers can determine the assigned server 487 of any connection, significantly increasing the linkability of QUIC 488 address migration. 490 The nonce length MUST be at least 4 octets. The server ID length 491 MUST be at least 1 octet. 493 As QUIC version 1 limits connection IDs to 20 octets, the server ID 494 and nonce lengths MUST sum to 19 octets or less. 496 4.3. Server Actions 498 The server writes the first octet and its server ID into their 499 respective fields. 501 If there is no key in the configuration, the server MUST fill the 502 Nonce field with bytes that appear to be random. If there is a key, 503 the server fills the nonce field with a nonce of its choosing. See 504 Section 8.6 for details. 506 The server MAY append additional bytes to the connection ID, up to 507 the limit specified in that version of QUIC, for its own use. These 508 bytes MUST NOT provide observers with any information that could link 509 two connection IDs to the same connection, client, or server. In 510 particular, all servers using a configuration MUST consistently add 511 the same length to each connection ID, to preserve the linkability 512 objectives of QUIC-LB. Any additional bytes SHOULD appear random 513 unless individual servers are not distinguishable (e.g. any server 514 using that configuration appends identical bytes to every connection 515 ID). 517 If there is no key in the configuration, the Connection ID is 518 complete. Otherwise, there are further steps, as described in the 519 two following subsections. 521 Encryption below uses the AES-128-ECB cipher. Future standards could 522 add new algorithms that use other ciphers to provide cryptographic 523 agility in accordance with [RFC7696]. QUIC-LB implementations SHOULD 524 be extensible to support new algorithms. 526 4.3.1. Special Case: Single Pass Encryption 528 When the nonce length and server ID length sum to exactly 16 octets, 529 the server MUST use a single-pass encryption algorithm. All 530 connection ID octets except the first form an AES-ECB block. This 531 block is encrypted once, and the result forms the second through 532 seventeenth most significant bytes of the connection ID. 534 4.3.2. General Case: Four-Pass Encryption 536 Any other field length requires four passes for encryption and at 537 least three for decryption. To understand this algorithm, it is 538 useful to define four functions that minimize the amount of bit- 539 shifting necessary in the event that there are an odd number of 540 octets. 542 The expand_left() function outputs 16 octets, with its first argument 543 in the most significant bits, its second argument in the least 544 significant byte, and zeros in all other positions. Thus, 546 expand_left(0xaaba3c, 0x13) = 0xaaba3c00000000000000000000000013 548 expand_right() is similar, except that the second argument is in the 549 most significant byte, and the first argument is in the least 550 significant bits. Therefore, 552 expand_right(0xaaba3c, 0x13) = 0x13000000000000000000000000aaba3c 554 Similarly, truncate_left() and truncate_right() take the most 555 significant and least significant bits, respectively, from a 556 ciphertext. For example, to take 28 bits of a ciphertext: 558 truncate_left(0x2094842ca49256198c2deaa0ba53caa0, 28) = 0x2094842 559 truncate_right(0x2094842ca49256198c2deaa0ba53caa0, 28) = 0xa53caa0 561 The example at the end of this section helps to clarify the steps 562 described below. 564 1. The server concatenates the server ID and nonce to create 565 plaintext_CID. 567 2. The server splits plaintext_CID into components left_0 and 568 right_0 of equal length, splitting an odd octet in half if 569 necessary. For example, 0x7040b81b55ccf3 would split into a 570 left_0 of 0x7040b81 and right_0 of 0xb55ccf3. 572 3. Encrypt the result of expand_left(left_0) to obtain a ciphertext. 574 4. XOR the least significant bits of the ciphertext with right_0 to 575 form right_1. 577 Thus steps 3 and 4 can be expressed as right_1 = right_0 ^ 578 truncate_right( AES_ECB(key, expand_left(left_0, 0x01)), 579 len(right_0)) 581 5. Repeat steps 3 and 4, but use them to compute left_1 by expanding 582 and encrypting right_1 with the most significant octet as 0x02 583 and XOR the results with left_0. 585 left_1 = left_0 ^ truncate_left( AES_ECB(key, 586 expand_right(right_1, 0x02)), len(left_0)) 588 6. Repeat steps 3 and 4, but use them to compute right_2 by 589 expanding and encrypting left_1 with the least significant octet 590 as 0x03 and XOR the results with right_1. 592 right_2 = right_1 ^ truncate_right( AES_ECB(key, 593 expand_left(left_1, 0x03)), len(right_1)) 595 7. Repeat steps 3 and 4, but use them to compute left_2 by expanding 596 and encrypting right_2 with the most significant octet as 0x04 597 and XOR the results with left_1. 599 left_2 = left_1 ^ truncate_left( AES_ECB(key, 600 expand_right(right_2, 0x04)), len(left_1)) 602 8. The server concatenates left_2 with right_2 to form the 603 ciphertext CID, which it appends to the first octet. 605 The following example executes the steps for the provided inputs. 606 Note that the plaintext is of odd octet length, so the middle octet 607 will be split evenly left_0 and right_0. 609 server_id = 0x31441a 610 nonce = 0x9c69c275 611 key = 0xfdf726a9893ec05c0632d3956680baf0 613 // step 1 614 plaintext_CID = 0x31441a9c69c275 616 // step 2 617 left_0 = 0x31441a9 618 right_0 = 0xc69c275 620 // step 3 621 aes_input = 0x31441a90000000000000000000000001 622 ciphertext = 0x4d140de42d0b85bdf554ba35c1d5c653 624 // step 4 625 right_1 = 0xc69c275 ^ 0x1d5c653 = 0xdbc0426 627 // step 5 628 aes_input = 0x0200000000000000000000000dbc0426 629 aes_output = 0x7e99160f3cf5b89c70584ccd2c2cd24b 630 left_1 = 0x31441a9 ^ 0x7e99160 = 0x4fdd0c9 632 // step 6 633 AES input = 0x4fdd0c90000000000000000000000003 634 AES output = 0x26c1d5a3a5e31ff8e3ca505da6061ac6 635 right_2 = 0xdbc0426 ^ 0x6061ac6 = 0xbba1ee0 637 // step 7 638 AES input = 0x0400000000000000000000000bba1ee0 639 AES output = 0xade1b8b25b436a94007d80cf3704377b 640 left_2 = 0x4fdd0c9 ^ 0xade1b8b = 0xe23cb42 642 // step 8 643 cid = first_octet || left_2 || right_2 = 0x07e23cb42bba1ee0 645 4.4. Load Balancer Actions 647 On each incoming packet, the load balancer extracts consecutive 648 octets, beginning with the second octet. If there is no key, the 649 first octets correspond to the server ID. 651 If there is a key, the load balancer takes one of two actions: 653 4.4.1. Special Case: Single Pass Encryption 655 If server ID length and nonce length sum to exactly 16 octets, they 656 form a ciphertext block. The load balancer decrypts the block using 657 the AES-ECB key and extracts the server ID from the most significant 658 bytes of the resulting plaintext. 660 4.4.2. General Case: Four-Pass Encryption 662 First, split the ciphertext CID (excluding the first octet) into its 663 equal- length components left_2 and right_2. Then follow the process 664 below: 666 left_1 = left_2 ^ truncate_left(AES_ECB(key, expand_right(right_2), 0x04)) 667 right_1 = right_2 ^ truncate_right(AES_ECB(key, expand_left(left_1, 0x03)) 668 left_0 = left_1 ^ truncate_left(AES_ECB(key, expand_right(right_1), 0x02)) 670 As the load balancer has no need for the nonce, it can conclude after 671 3 passes as long as the server ID is entirely contained in left_0 672 (i.e., the nonce is at least as large as the server ID). If the 673 server ID is longer, a fourth pass is necessary: 675 right_0 = right_1 ^ truncate_right(AES_ECB(key, expand_left(left_0, 676 0x01))) 678 and the load balancer has to concatenate left_0 and right_0 to obtain 679 the complete server ID. 681 5. Per-connection state 683 QUIC-LB requires no per-connection state at the load balancer. The 684 load balancer can extract the server ID from the connection ID of 685 each incoming packet and route that packet accordingly. 687 However, once the routing decision has been made, the load balancer 688 MAY associate the 4-tuple with the decision. This has two 689 advantages: 691 * The load balancer only extracts the server ID once per incoming 692 4-tuple. When the CID is encrypted, this substantially reduces 693 computational load. 695 * Incoming Stateless Reset packets and ICMP messages are easily 696 routed to the correct origin server. 698 In addition to the increased state requirements, however, load 699 balancers cannot detect the CONNECTION_CLOSE frame to indicate the 700 end of the connection, so they rely on a timeout to delete connection 701 state. There are numerous considerations around setting such a 702 timeout. 704 In the event a connection ends, freeing an IP and port, and a 705 different connection migrates to that IP and port before the timeout, 706 the load balancer will misroute the different connection's packets to 707 the original server. A short timeout limits the likelihood of such a 708 misrouting. 710 Furthermore, if a short timeout causes premature deletion of state, 711 the routing is easily recoverable by decoding an incoming Connection 712 ID. However, a short timeout also reduces the chance that an 713 incoming Stateless Reset is correctly routed. 715 Servers MAY implement the technique described in Section 14.4.1 of 716 [RFC9000] in case the load balancer is stateless, to increase the 717 likelihood a Source Connection ID is included in ICMP responses to 718 Path Maximum Transmission Unit (PMTU) probes. Load balancers MAY 719 parse the echoed packet to extract the Source Connection ID, if it 720 contains a QUIC long header, and extract the Server ID as if it were 721 in a Destination CID. 723 6. Additional Use Cases 725 This section discusses considerations for some deployment scenarios 726 not implied by the specification above. 728 6.1. Load balancer chains 730 Some network architectures may have multiple tiers of low-state load 731 balancers, where a first tier of devices makes a routing decision to 732 the next tier, and so on, until packets reach the server. Although 733 QUIC-LB is not explicitly designed for this use case, it is possible 734 to support it. 736 If each load balancer is assigned a range of server IDs that is a 737 subset of the range of IDs assigned to devices that are closer to the 738 client, then the first devices to process an incoming packet can 739 extract the server ID and then map it to the correct forwarding 740 address. Note that this solution is extensible to arbitrarily large 741 numbers of load-balancing tiers, as the maximum server ID space is 742 quite large. 744 If the number of necessary server IDs per next hop is uniform, a 745 simple implementation would use successively longer server IDs at 746 each tier of load balancing, and the server configuration would match 747 the last tier. The forward load balancers would simply treat the 748 least significant bits of the server ID as part of the nonce. 750 6.2. Moving connections between servers 752 Some deployments may transparently move a connection from one server 753 to another. The means of transferring connection state between 754 servers is out of scope of this document. 756 To support a handover, a server involved in the transition could 757 issue CIDs that map to the new server via a NEW_CONNECTION_ID frame, 758 and retire CIDs associated with the new server using the "Retire 759 Prior To" field in that frame. 761 Alternately, if the old server is going offline, the load balancer 762 could simply map its server ID to the new server's address. 764 7. Version Invariance of QUIC-LB 766 The server ID encodings, and requirements for their handling, are 767 designed to be QUIC version independent (see [RFC8999]). A QUIC-LB 768 load balancer will generally not require changes as servers deploy 769 new versions of QUIC. However, there are several unlikely future 770 design decisions that could impact the operation of QUIC-LB. 772 The maximum Connection ID length could be below the minimum necessary 773 for one or more encoding algorithms. 775 Section 3.1 provides guidance about how load balancers should handle 776 unroutable DCIDs. This guidance, and the implementation of an 777 algorithm to handle these DCIDs, rests on some assumptions: 779 * Incoming short headers do not contain DCIDs that are client- 780 generated. 782 * The use of client-generated incoming DCIDs does not persist beyond 783 a few round trips in the connection. 785 * While the client is using DCIDs it generated, some exposed fields 786 (IP address, UDP port, client-generated destination Connection ID) 787 remain constant for all packets sent on the same connection. 789 While this document does not update the commitments in [RFC8999], the 790 additional assumptions are minimal and narrowly scoped, and provide a 791 likely set of constants that load balancers can use with minimal risk 792 of version- dependence. 794 If these assumptions are invalid, this specification is likely to 795 lead to loss of packets that contain unroutable DCIDs, and in extreme 796 cases connection failure. 798 Some load balancers might inspect elements of the Server Name 799 Indication (SNI) extension in the TLS Client Hello to make a routing 800 decision. Note that the format and cryptographic protection of this 801 information may change in future versions or extensions of TLS or 802 QUIC, and therefore this functionality is inherently not version- 803 invariant. See also Section 3.1 for other considerations about this 804 case. Note that an SNI-aware load balancer, faced with an unknown 805 QUIC version, might misdirect initial packets to the wrong tenant. 806 While inefficient, this preserves the ability for tenants to deploy 807 new versions provided they have an out-of-band means of providing a 808 connection ID for the client to use. 810 8. Security Considerations 812 QUIC-LB is intended to prevent linkability. Attacks would therefore 813 attempt to subvert this purpose. 815 Note that without a key for the encoding, QUIC-LB makes no attempt to 816 obscure the server mapping, and therefore does not address these 817 concerns. Without a key, QUIC-LB merely allows consistent CID 818 encoding for compatibility across a network infrastructure, which 819 makes QUIC robust to NAT rebinding. Servers that are encoding their 820 server ID without a key algorithm SHOULD only use it to generate new 821 CIDs for the Server Initial Packet and SHOULD NOT send CIDs in QUIC 822 NEW_CONNECTION_ID frames, except that it sends one new Connection ID 823 in the event of config rotation Section 2.1. Doing so might falsely 824 suggest to the client that said CIDs were generated in a secure 825 fashion. 827 A linkability attack would find some means of determining that two 828 connection IDs route to the same server. As described above, there 829 is no scheme that strictly prevents linkability for all traffic 830 patterns, and therefore efforts to frustrate any analysis of server 831 ID encoding have diminishing returns. 833 8.1. Attackers not between the load balancer and server 835 Any attacker might open a connection to the server infrastructure and 836 aggressively simulate migration to obtain a large sample of IDs that 837 map to the same server. It could then apply analytical techniques to 838 try to obtain the server encoding. 840 An encrypted encoding provides robust protection against this. An 841 unencrypted one provides none. 843 Were this analysis to obtain the server encoding, then on-path 844 observers might apply this analysis to correlating different client 845 IP addresses. 847 8.2. Attackers between the load balancer and server 849 Attackers in this privileged position are intrinsically able to map 850 two connection IDs to the same server. The QUIC-LB algorithms do 851 prevent the linkage of two connection IDs to the same individual 852 connection if servers make reasonable selections when generating new 853 IDs for that connection. 855 8.3. Multiple Configuration IDs 857 During the period in which there are multiple deployed configuration 858 IDs (see Section 2.1), there is a slight increase in linkability. 859 The server space is effectively divided into segments with CIDs that 860 have different config rotation bits. Entities that manage servers 861 SHOULD strive to minimize these periods by quickly deploying new 862 configurations across the server pool. 864 8.4. Limited configuration scope 866 A simple deployment of QUIC-LB in a cloud provider might use the same 867 global QUIC-LB configuration across all its load balancers that route 868 to customer servers. An attacker could then simply become a 869 customer, obtain the configuration, and then extract server IDs of 870 other customers' connections at will. 872 To avoid this, the configuration agent SHOULD issue QUIC-LB 873 configurations to mutually distrustful servers that have different 874 keys for encryption algorithms. In many cases, the load balancers 875 can distinguish these configurations by external IP address. 877 However, assigning multiple entities to an IP address is 878 complimentary with concealing DNS requests (e.g., DoH [RFC8484]) and 879 the TLS Server Name Indicator (SNI) ([I-D.ietf-tls-esni]) to obscure 880 the ultimate destination of traffic. While the load balancer's 881 fallback algorithm (Section 3.2) can use the SNI to make a routing 882 decision on the first packet, there are three ways to route 883 subsequent packets: 885 * all co-tenants can use the same QUIC-LB configuration, leaking the 886 server mapping to each other as described above; 888 * co-tenants can be issued one of up to three configurations 889 distinguished by the config rotation bits (Section 2.1), exposing 890 information about the target domain to the entire network; or 892 * tenants can use 4-tuple routing in their CIDs (in which case they 893 SHOULD disable migration in their connections), which neutralizes 894 the value of QUIC-LB but preserves privacy. 896 When configuring QUIC-LB, administrators must evaluate the privacy 897 tradeoff considering the relative value of each of these properties, 898 given the trust model between tenants, the presence of methods to 899 obscure the domain name, and value of address migration in the tenant 900 use cases. 902 As the plaintext algorithm makes no attempt to conceal the server 903 mapping, these deployments SHOULD simply use a common configuration. 905 8.5. Stateless Reset Oracle 907 Section 21.9 of [RFC9000] discusses the Stateless Reset Oracle 908 attack. For a server deployment to be vulnerable, an attacking 909 client must be able to cause two packets with the same Destination 910 CID to arrive at two different servers that share the same 911 cryptographic context for Stateless Reset tokens. As QUIC-LB 912 requires deterministic routing of DCIDs over the life of a 913 connection, it is a sufficient means of avoiding an Oracle without 914 additional measures. 916 Note also that when a server starts using a new QUIC-LB config 917 rotation codepoint, new CIDs might not be unique with respect to 918 previous configurations that occupied that codepoint, and therefore 919 different clients may have observed the same CID and stateless reset 920 token. A straightforward method of managing stateless reset keys is 921 to maintain a separate key for each config rotation codepoint, and 922 replace each key when the configuration for that codepoint changes. 923 Thus, a server transitions from one config to another, it will be 924 able to generate correct tokens for connections using either type of 925 CID. 927 8.6. Connection ID Entropy 929 If a server ever reuses a nonce in generating a CID for a given 930 configuration, it risks exposing sensitive information. Given the 931 same server ID, the CID will be identical (aside from a possible 932 difference in the first octet). This can risk exposure of the QUIC- 933 LB key. If two clients receive the same connection ID, they also 934 have each other's stateless reset token unless that key has changed 935 in the interim. 937 The encrypte mode needs to generate different cipher text for each 938 generated Connection ID instance to protect the Server ID. To do so, 939 at least four octets of the CID are reserved for a nonce that, if 940 used only once, will result in unique cipher text for each Connection 941 ID. 943 If servers simply increment the nonce by one with each generated 944 connection ID, then it is safe to use the existing keys until any 945 server's nonce counter exhausts the allocated space and rolls over. 946 To maximize entropy, servers SHOULD start with a random nonce value, 947 in which case the configuration is usable until the nonce value wraps 948 around to zero and then reaches the initial value again. 950 Whether or not it implements the counter method, the server MUST NOT 951 reuse a nonce until it switches to a configuration with new keys. 953 If the nonce is sent in plaintext, servers MUST generate nonces so 954 that they appear to be random. Observable correlations between 955 plaintext nonces would provide trivial linkability between individual 956 connections, rather than just to a common server. 958 For any algorithm, configuration agents SHOULD implement an out-of- 959 band method to discover when servers are in danger of exhausting 960 their nonce space, and SHOULD respond by issuing a new configuration. 961 A server that has exhausted its nonces MUST either switch to a 962 different configuration, or if none exists, use the 4-tuple routing 963 config rotation codepoint. 965 When sizing a nonce that is to be randomly generated, the 966 configuration agent SHOULD consider that a server generating a N-bit 967 nonce will create a duplicate about every 2^(N/2) attempts, and 968 therefore compare the expected rate at which servers will generate 969 CIDs with the lifetime of a configuration. 971 9. IANA Considerations 973 There are no IANA requirements. 975 10. References 977 10.1. Normative References 979 [RFC8999] Thomson, M., "Version-Independent Properties of QUIC", 980 RFC 8999, DOI 10.17487/RFC8999, May 2021, 981 . 983 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 984 Multiplexed and Secure Transport", RFC 9000, 985 DOI 10.17487/RFC9000, May 2021, 986 . 988 10.2. Informative References 990 [I-D.draft-ietf-tls-dtls13] 991 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 992 Datagram Transport Layer Security (DTLS) Protocol Version 993 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 994 dtls13-43, 30 April 2021, 995 . 998 [I-D.ietf-tls-dtls-connection-id] 999 Rescorla, E., Tschofenig, H., Fossati, T., and A. Kraus, 1000 "Connection Identifier for DTLS 1.2", Work in Progress, 1001 Internet-Draft, draft-ietf-tls-dtls-connection-id-13, 22 1002 June 2021, . 1005 [I-D.ietf-tls-esni] 1006 Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 1007 Encrypted Client Hello", Work in Progress, Internet-Draft, 1008 draft-ietf-tls-esni-14, 13 February 2022, 1009 . 1012 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1013 Requirement Levels", BCP 14, RFC 2119, 1014 DOI 10.17487/RFC2119, March 1997, 1015 . 1017 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1018 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 1019 . 1021 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1022 the Network Configuration Protocol (NETCONF)", RFC 6020, 1023 DOI 10.17487/RFC6020, October 2010, 1024 . 1026 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1027 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1028 January 2012, . 1030 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 1031 Agility and Selecting Mandatory-to-Implement Algorithms", 1032 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1033 . 1035 [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 1036 Updates for Secure Real-time Transport Protocol (SRTP) 1037 Extension for Datagram Transport Layer Security (DTLS)", 1038 RFC 7983, DOI 10.17487/RFC7983, September 2016, 1039 . 1041 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1042 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1043 . 1045 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1046 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1047 . 1049 Appendix A. QUIC-LB YANG Model 1051 These YANG models conform to [RFC6020] and express a complete QUIC-LB 1052 configuration. There is one model for the server and one for the 1053 middlebox (i.e the load balancer and/or Retry Service). 1055 module ietf-quic-lb-server { 1056 yang-version "1.1"; 1057 namespace "urn:ietf:params:xml:ns:yang:ietf-quic-lb"; 1058 prefix "quic-lb"; 1060 import ietf-yang-types { 1061 prefix yang; 1062 reference 1063 "RFC 6991: Common YANG Data Types."; 1064 } 1066 import ietf-inet-types { 1067 prefix inet; 1068 reference 1069 "RFC 6991: Common YANG Data Types."; 1070 } 1072 organization 1073 "IETF QUIC Working Group"; 1075 contact 1076 "WG Web: 1077 WG List: 1079 Authors: Martin Duke (martin.h.duke at gmail dot com) 1080 Nick Banks (nibanks at microsoft dot com) 1081 Christian Huitema (huitema at huitema.net)"; 1083 description 1084 "This module enables the explicit cooperation of QUIC servers with 1085 trusted intermediaries without breaking important protocol 1086 features. 1088 Copyright (c) 2022 IETF Trust and the persons identified as 1089 authors of the code. All rights reserved. 1091 Redistribution and use in source and binary forms, with or 1092 without modification, is permitted pursuant to, and subject to 1093 the license terms contained in, the Simplified BSD License set 1094 forth in Section 4.c of the IETF Trust's Legal Provisions 1095 Relating to IETF Documents 1096 (https://trustee.ietf.org/license-info). 1098 This version of this YANG module is part of RFC XXXX 1099 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 1100 for full legal notices. 1102 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1103 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1104 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1105 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1106 they appear in all capitals, as shown here."; 1108 revision "2022-02-11" { 1109 description 1110 "Updated to design in version 13 of the draft"; 1111 reference 1112 "RFC XXXX, QUIC-LB: Generating Routable QUIC Connection IDs"; 1113 } 1115 container quic-lb { 1116 presence "The container for QUIC-LB configuration."; 1117 description 1118 "QUIC-LB container."; 1120 typedef quic-lb-key { 1121 type yang:hex-string { 1122 length 47; 1123 } 1124 description 1125 "This is a 16-byte key, represented with 47 bytes"; 1126 } 1128 leaf config-id { 1129 type uint8 { 1130 range "0..2"; 1131 } 1132 mandatory true; 1133 description 1134 "Identifier for this CID configuration."; 1135 } 1137 leaf first-octet-encodes-cid-length { 1138 type boolean; 1139 default false; 1140 description 1141 "If true, the six least significant bits of the first CID 1142 octet encode the CID length minus one."; 1143 } 1145 leaf server-id-length { 1146 type uint8 { 1147 range "1..15"; 1148 } 1149 must '. <= (19 - ../nonce-length)' { 1150 error-message 1151 "Server ID and nonce lengths must sum to no more than 19."; 1152 } 1153 mandatory true; 1154 description 1155 "Length (in octets) of a server ID. Further range-limited 1156 by nonce-length."; 1157 } 1159 leaf nonce-length { 1160 type uint8 { 1161 range "4..18"; 1162 } 1163 mandatory true; 1164 description 1165 "Length, in octets, of the nonce. Short nonces mean there will 1166 be frequent configuration updates."; 1167 } 1169 leaf cid-key { 1170 type quic-lb-key; 1171 description 1172 "Key for encrypting the connection ID."; 1173 } 1175 leaf server-id { 1176 type yang:hex-string; 1177 must "string-length(.) = 3 * ../../server-id-length - 1"; 1178 mandatory true; 1179 description 1180 "An allocated server ID"; 1181 } 1182 } 1183 } 1185 module ietf-quic-lb-middlebox { 1186 yang-version "1.1"; 1187 namespace "urn:ietf:params:xml:ns:yang:ietf-quic-lb"; 1188 prefix "quic-lb"; 1190 import ietf-yang-types { 1191 prefix yang; 1192 reference 1193 "RFC 6991: Common YANG Data Types."; 1194 } 1196 import ietf-inet-types { 1197 prefix inet; 1198 reference 1199 "RFC 6991: Common YANG Data Types."; 1200 } 1202 organization 1203 "IETF QUIC Working Group"; 1205 contact 1206 "WG Web: 1207 WG List: 1209 Authors: Martin Duke (martin.h.duke at gmail dot com) 1210 Nick Banks (nibanks at microsoft dot com) 1211 Christian Huitema (huitema at huitema.net)"; 1213 description 1214 "This module enables the explicit cooperation of QUIC servers with 1215 trusted intermediaries without breaking important protocol 1216 features. 1218 Copyright (c) 2021 IETF Trust and the persons identified as 1219 authors of the code. All rights reserved. 1221 Redistribution and use in source and binary forms, with or 1222 without modification, is permitted pursuant to, and subject to 1223 the license terms contained in, the Simplified BSD License set 1224 forth in Section 4.c of the IETF Trust's Legal Provisions 1225 Relating to IETF Documents 1226 (https://trustee.ietf.org/license-info). 1228 This version of this YANG module is part of RFC XXXX 1229 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 1230 for full legal notices. 1232 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1233 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1234 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1235 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1236 they appear in all capitals, as shown here."; 1238 revision "2021-02-11" { 1239 description 1240 "Updated to design in version 13 of the draft"; 1241 reference 1242 "RFC XXXX, QUIC-LB: Generating Routable QUIC Connection IDs"; 1243 } 1245 container quic-lb { 1246 presence "The container for QUIC-LB configuration."; 1248 description 1249 "QUIC-LB container."; 1251 typedef quic-lb-key { 1252 type yang:hex-string { 1253 length 47; 1254 } 1255 description 1256 "This is a 16-byte key, represented with 47 bytes"; 1257 } 1259 list cid-configs { 1260 key "config-rotation-bits"; 1261 description 1262 "List up to three load balancer configurations"; 1264 leaf config-rotation-bits { 1265 type uint8 { 1266 range "0..2"; 1267 } 1268 mandatory true; 1269 description 1270 "Identifier for this CID configuration."; 1271 } 1273 leaf server-id-length { 1274 type uint8 { 1275 range "1..15"; 1276 } 1277 must '. <= (19 - ../nonce-length)' { 1278 error-message 1279 "Server ID and nonce lengths must sum to no more than 19."; 1280 } 1281 mandatory true; 1282 description 1283 "Length (in octets) of a server ID. Further range-limited 1284 by nonce-length."; 1285 } 1287 leaf cid-key { 1288 type quic-lb-key; 1289 description 1290 "Key for encrypting the connection ID."; 1291 } 1293 leaf nonce-length { 1294 type uint8 { 1295 range "4..18"; 1296 } 1297 mandatory true; 1298 description 1299 "Length, in octets, of the nonce. Short nonces mean there 1300 will be frequent configuration updates."; 1301 } 1303 list server-id-mappings { 1304 key "server-id"; 1305 description "Statically allocated Server IDs"; 1307 leaf server-id { 1308 type yang:hex-string; 1309 must "string-length(.) = 3 * ../../server-id-length - 1"; 1310 mandatory true; 1311 description 1312 "An allocated server ID"; 1314 } 1316 leaf server-address { 1317 type inet:ip-address; 1318 mandatory true; 1319 description 1320 "Destination address corresponding to the server ID"; 1321 } 1322 } 1323 } 1324 } 1325 } 1327 A.1. Tree Diagram 1329 This summary of the YANG models uses the notation in [RFC8340]. 1331 module: ietf-quic-lb-server 1332 +--rw quic-lb! 1333 +--rw config-id uint8 1334 +--rw first-octet-encodes-cid-length? boolean 1335 +--rw server-id-length uint8 1336 +--rw nonce-length uint8 1337 +--rw cid-key? quic-lb-key 1338 +--rw server-id yang:hex-string 1340 module: ietf-quic-lb-middlebox 1341 +--rw quic-lb! 1342 +--rw cid-configs* [config-rotation-bits] 1343 | +--rw config-rotation-bits uint8 1344 | +--rw server-id-length uint8 1345 | +--rw cid-key? quic-lb-key 1346 | +--rw nonce-length uint8 1347 | +--rw server-id-mappings* [server-id] 1348 | +--rw server-id yang:hex-string 1349 | +--rw server-address inet:ip-address 1351 Appendix B. Load Balancer Test Vectors 1353 This section uses the following abbreviations: 1355 cid Connection ID 1356 cr_bits Config Rotation Bits 1357 LB Load Balancer 1358 sid Server ID 1360 In all cases, the server is configured to encode the CID length. 1362 B.1. Unencrypted CIDs 1364 cr_bits sid nonce cid 1365 0 c4605e 4504cc4f 07c4605e4504cc4f 1366 1 350d28b420 3487d970b 40a350d28b4203487d970b 1368 B.2. Encrypted CIDs 1370 The key for all of these examples is 1371 8f95f09245765f80256934e50c66207f. The test vectors include an 1372 example that uses the 16-octet single-pass special case, as well as 1373 an instance where the server ID length exceeds the nonce length, 1374 requiring a fourth decryption pass. 1376 cr_bits sid nonce cid 1377 0 ed793a ee080dbf 07fbfe05f731b425 1378 1 ed793a51d49b8f5fab65 ee080dbf48 4f010956fb5c1d4d86e010183e0b7d1e 1379 2 ed793a51d49b8f5f ee080dbf48c0d1e5 904dd2d05a7b0de9b2b9907afb5ecf8cc3 1380 0 ed793a51d49b8f5fab ee080dbf48c0d1e55d 127a285a09f85280f4fd6abb434a7159e4d3eb 1382 Appendix C. Interoperability with DTLS over UDP 1384 Some environments may contain DTLS traffic as well as QUIC operating 1385 over UDP, which may be hard to distinguish. 1387 In most cases, the packet parsing rules above will cause a QUIC-LB 1388 load balancer to route DTLS traffic in an appropriate way. DTLS 1.3 1389 implementations that use the connection_id extension 1390 [I-D.ietf-tls-dtls-connection-id] might use the techniques in this 1391 document to generate connection IDs and achieve robust routability 1392 for DTLS associations if they meet a few additional requirements. 1393 This non-normative appendix describes this interaction. 1395 C.1. DTLS 1.0 and 1.2 1397 DTLS 1.0 [RFC4347] and 1.2 [RFC6347] use packet formats that a QUIC- 1398 LB router will interpret as short header packets with CIDs that 1399 request 4-tuple routing. As such, they will route such packets 1400 consistently as long as the 4-tuple does not change. Note that DTLS 1401 1.0 has been deprecated by the IETF. 1403 The first octet of every DTLS 1.0 or 1.2 datagram contains the 1404 content type. A QUIC-LB load balancer will interpret any content 1405 type less than 128 as a short header packet, meaning that the 1406 subsequent octets should contain a connection ID. 1408 Existing TLS content types comfortably fit in the range below 128. 1409 Assignment of codepoints greater than 64 would require coordination 1410 in accordance with [RFC7983], and anyway would likely create problems 1411 demultiplexing DTLS and version 1 of QUIC. Therefore, this document 1412 believes it is extremely unlikely that TLS content types of 128 or 1413 greater will be assigned. Nevertheless, such an assignment would 1414 cause a QUIC-LB load balancer to interpret the packet as a QUIC long 1415 header with an essentially random connection ID, which is likely to 1416 be routed irregularly. 1418 The second octet of every DTLS 1.0 or 1.2 datagram is the bitwise 1419 complement of the DTLS Major version (i.e. version 1.x = 0xfe). A 1420 QUIC-LB load balancer will interpret this as a connection ID that 1421 requires 4-tuple based load balancing, meaning that the routing will 1422 be consistent as long as the 4-tuple remains the same. 1424 [I-D.ietf-tls-dtls-connection-id] defines an extension to add 1425 connection IDs to DTLS 1.2. Unfortunately, a QUIC-LB load balancer 1426 will not correctly parse the connection ID and will continue 4-tuple 1427 routing. An modified QUIC-LB load balancer that correctly identifies 1428 DTLS and parses a DTLS 1.2 datagram for the connection ID is outside 1429 the scope of this document. 1431 C.2. DTLS 1.3 1433 DTLS 1.3 [I-D.draft-ietf-tls-dtls13] changes the structure of 1434 datagram headers in relevant ways. 1436 Handshake packets continue to have a TLS content type in the first 1437 octet and 0xfe in the second octet, so they will be 4-tuple routed, 1438 which should not present problems for likely NAT rebinding or address 1439 change events. 1441 Non-handshake packets always have zero in their most significant bit 1442 and will therefore always be treated as QUIC short headers. If the 1443 connection ID is present, it follows in the succeeding octets. 1444 Therefore, a DTLS 1.3 association where the server utilizes 1445 Connection IDs and the encodings in this document will be routed 1446 correctly in the presence of client address and port changes. 1448 However, if the client does not include the connection_id extension 1449 in its ClientHello, the server is unable to use connection IDs. In 1450 this case, non- handshake packets will appear to contain random 1451 connection IDs and be routed randomly. Thus, unmodified QUIC-LB load 1452 balancers will not work with DTLS 1.3 if the client does not 1453 advertise support for connection IDs, or the server does not request 1454 the use of a compliant connection ID. 1456 A QUIC-LB load balancer might be modified to identify DTLS 1.3 1457 packets and correctly parse the fields to identify when there is no 1458 connection ID and revert to 4-tuple routing, removing the server 1459 requirement above. However, such a modification is outside the scope 1460 of this document, and classifying some packets as DTLS might be 1461 incompatible with future versions of QUIC. 1463 C.3. Future Versions of DTLS 1465 As DTLS does not have an IETF consensus document that defines what 1466 parts of DTLS will be invariant in future versions, it is difficult 1467 to speculate about the applicability of this section to future 1468 versions of DTLS. 1470 Appendix D. Acknowledgments 1472 Manasi Deval, Erik Fuller, Toma Gavrichenkov, Jana Iyengar, Subodh 1473 Iyengar, Ladislav Lhotka, Jan Lindblad, Ling Tao Nju, Ilari 1474 Liusvaara, Kazuho Oku, Udip Pant, Ian Swett, Martin Thomson, Dmitri 1475 Tikhonov, Victor Vasiliev, and William Zeng Ke all provided useful 1476 input to this document. 1478 Appendix E. Change Log 1480 *RFC Editor's Note:* Please remove this section prior to 1481 publication of a final version of this document. 1483 E.1. since draft-ietf-quic-load-balancers-12 1485 * Separated Retry Service design into a separate draft. 1487 E.2. since draft-ietf-quic-load-balancers-11 1489 * Fixed mistakes in test vectors 1491 E.3. since draft-ietf-quic-load-balancers-10 1493 * Refactored algorithm descriptions; made the 4-pass algorithm 1494 easier to implement 1496 * Revised test vectors 1498 * Split YANG model into a server and middlebox version 1500 E.4. since draft-ietf-quic-load-balancers-09 1502 * Renamed "Stream Cipher" and "Block Cipher" to "Encrypted Short" 1503 and "Encrypted Long" 1505 * Added section on per-connection state 1507 * Changed "Encrypted Short" to a 4-pass algorithm. 1509 * Recommended a random initial nonce when incrementing. 1511 * Clarified what SNI LBs should do with unknown QUIC versions. 1513 E.5. since draft-ietf-quic-load-balancers-08 1515 * Eliminate Dynamic SID allocation 1517 * Eliminated server use bytes 1519 E.6. since draft-ietf-quic-load-balancers-07 1521 * Shortened SSCID nonce minimum length to 4 bytes 1523 * Removed RSCID from Retry token body 1525 * Simplified CID formats 1527 * Shrunk size of SID table 1529 E.7. since draft-ietf-quic-load-balancers-06 1531 * Added interoperability with DTLS 1533 * Changed "non-compliant" to "unroutable" 1535 * Changed "arbitrary" algorithm to "fallback" 1537 * Revised security considerations for mistrustful tenants 1539 * Added retry service considerations for non-Initial packets 1541 E.8. since draft-ietf-quic-load-balancers-05 1543 * Added low-config CID for further discussion 1545 * Complete revision of shared-state Retry Token 1547 * Added YANG model 1548 * Updated configuration limits to ensure CID entropy 1550 * Switched to notation from quic-transport 1552 E.9. since draft-ietf-quic-load-balancers-04 1554 * Rearranged the shared-state retry token to simplify token 1555 processing 1557 * More compact timestamp in shared-state retry token 1559 * Revised server requirements for shared-state retries 1561 * Eliminated zero padding from the test vectors 1563 * Added server use bytes to the test vectors 1565 * Additional compliant DCID criteria 1567 E.10. since-draft-ietf-quic-load-balancers-03 1569 * Improved Config Rotation text 1571 * Added stream cipher test vectors 1573 * Deleted the Obfuscated CID algorithm 1575 E.11. since-draft-ietf-quic-load-balancers-02 1577 * Replaced stream cipher algorithm with three-pass version 1579 * Updated Retry format to encode info for required TPs 1581 * Added discussion of version invariance 1583 * Cleaned up text about config rotation 1585 * Added Reset Oracle and limited configuration considerations 1587 * Allow dropped long-header packets for known QUIC versions 1589 E.12. since-draft-ietf-quic-load-balancers-01 1591 * Test vectors for load balancer decoding 1593 * Deleted remnants of in-band protocol 1595 * Light edit of Retry Services section 1596 * Discussed load balancer chains 1598 E.13. since-draft-ietf-quic-load-balancers-00 1600 * Removed in-band protocol from the document 1602 E.14. Since draft-duke-quic-load-balancers-06 1604 * Switch to IETF WG draft. 1606 E.15. Since draft-duke-quic-load-balancers-05 1608 * Editorial changes 1610 * Made load balancer behavior independent of QUIC version 1612 * Got rid of token in stream cipher encoding, because server might 1613 not have it 1615 * Defined "non-compliant DCID" and specified rules for handling 1616 them. 1618 * Added psuedocode for config schema 1620 E.16. Since draft-duke-quic-load-balancers-04 1622 * Added standard for retry services 1624 E.17. Since draft-duke-quic-load-balancers-03 1626 * Renamed Plaintext CID algorithm as Obfuscated CID 1628 * Added new Plaintext CID algorithm 1630 * Updated to allow 20B CIDs 1632 * Added self-encoding of CID length 1634 E.18. Since draft-duke-quic-load-balancers-02 1636 * Added Config Rotation 1638 * Added failover mode 1640 * Tweaks to existing CID algorithms 1642 * Added Block Cipher CID algorithm 1643 * Reformatted QUIC-LB packets 1645 E.19. Since draft-duke-quic-load-balancers-01 1647 * Complete rewrite 1649 * Supports multiple security levels 1651 * Lightweight messages 1653 E.20. Since draft-duke-quic-load-balancers-00 1655 * Converted to markdown 1657 * Added variable length connection IDs 1659 Authors' Addresses 1661 Martin Duke 1662 Google 1663 Email: martin.h.duke@gmail.com 1665 Nick Banks 1666 Microsoft 1667 Email: nibanks@microsoft.com 1669 Christian Huitema 1670 Private Octopus Inc. 1671 Email: huitema@huitema.net