idnits 2.17.1 draft-ietf-quic-load-balancers-05.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 == Line 954 has weird spacing: '...boolean first...' -- The document date (30 October 2020) is 1274 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '16' on line 981 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC M. Duke 3 Internet-Draft F5 Networks, Inc. 4 Intended status: Standards Track N. Banks 5 Expires: 3 May 2021 Microsoft 6 30 October 2020 8 QUIC-LB: Generating Routable QUIC Connection IDs 9 draft-ietf-quic-load-balancers-05 11 Abstract 13 QUIC connection IDs allow continuation of connections across address/ 14 port 4-tuple changes, and can store routing information for stateless 15 or low-state load balancers. They also can prevent linkability of 16 connections across deliberate address migration through the use of 17 protected communications between client and server. This creates 18 issues for load-balancing intermediaries. This specification 19 standardizes methods for encoding routing information given a small 20 set of configuration parameters. This framework also enables offload 21 of other QUIC functions to trusted intermediaries, given the explicit 22 cooperation of the QUIC server. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 3 May 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Protocol Objectives . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. First CID octet . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Config Rotation . . . . . . . . . . . . . . . . . . . . . 6 64 3.2. Configuration Failover . . . . . . . . . . . . . . . . . 7 65 3.3. Length Self-Description . . . . . . . . . . . . . . . . . 7 66 3.4. Format . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. Routing Algorithms . . . . . . . . . . . . . . . . . . . . . 8 68 4.1. Plaintext CID Algorithm . . . . . . . . . . . . . . . . . 9 69 4.1.1. Configuration Agent Actions . . . . . . . . . . . . . 9 70 4.1.2. Load Balancer Actions . . . . . . . . . . . . . . . . 10 71 4.1.3. Server Actions . . . . . . . . . . . . . . . . . . . 10 72 4.2. Stream Cipher CID Algorithm . . . . . . . . . . . . . . . 10 73 4.2.1. Configuration Agent Actions . . . . . . . . . . . . . 10 74 4.2.2. Load Balancer Actions . . . . . . . . . . . . . . . . 11 75 4.2.3. Server Actions . . . . . . . . . . . . . . . . . . . 12 76 4.3. Block Cipher CID Algorithm . . . . . . . . . . . . . . . 12 77 4.3.1. Configuration Agent Actions . . . . . . . . . . . . . 13 78 4.3.2. Load Balancer Actions . . . . . . . . . . . . . . . . 13 79 4.3.3. Server Actions . . . . . . . . . . . . . . . . . . . 13 80 5. ICMP Processing . . . . . . . . . . . . . . . . . . . . . . . 13 81 6. Retry Service . . . . . . . . . . . . . . . . . . . . . . . . 14 82 6.1. Common Requirements . . . . . . . . . . . . . . . . . . . 14 83 6.2. No-Shared-State Retry Service . . . . . . . . . . . . . . 15 84 6.2.1. Configuration Agent Actions . . . . . . . . . . . . . 15 85 6.2.2. Service Requirements . . . . . . . . . . . . . . . . 15 86 6.2.3. Server Requirements . . . . . . . . . . . . . . . . . 17 87 6.3. Shared-State Retry Service . . . . . . . . . . . . . . . 17 88 6.3.1. Configuration Agent Actions . . . . . . . . . . . . . 19 89 6.3.2. Service Requirements . . . . . . . . . . . . . . . . 19 90 6.3.3. Server Requirements . . . . . . . . . . . . . . . . . 20 91 7. Configuration Requirements . . . . . . . . . . . . . . . . . 20 92 8. Additional Use Cases . . . . . . . . . . . . . . . . . . . . 22 93 8.1. Load balancer chains . . . . . . . . . . . . . . . . . . 22 94 8.2. Moving connections between servers . . . . . . . . . . . 23 95 9. Version Invariance of QUIC-LB . . . . . . . . . . . . . . . . 23 96 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 97 10.1. Attackers not between the load balancer and server . . . 24 98 10.2. Attackers between the load balancer and server . . . . . 25 99 10.3. Multiple Configuration IDs . . . . . . . . . . . . . . . 25 100 10.4. Limited configuration scope . . . . . . . . . . . . . . 25 101 10.5. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 25 102 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 103 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 104 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 105 12.2. Informative References . . . . . . . . . . . . . . . . . 26 106 Appendix A. Load Balancer Test Vectors . . . . . . . . . . . . . 26 107 A.1. Plaintext Connection ID Algorithm . . . . . . . . . . . . 27 108 A.2. Stream Cipher Connection ID Algorithm . . . . . . . . . . 27 109 A.3. Block Cipher Connection ID Algorithm . . . . . . . . . . 28 110 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 30 111 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 30 112 C.1. since draft-ietf-quic-load-balancers-04 . . . . . . . . . 30 113 C.2. since-draft-ietf-quic-load-balancers-03 . . . . . . . . . 30 114 C.3. since-draft-ietf-quic-load-balancers-02 . . . . . . . . . 30 115 C.4. since-draft-ietf-quic-load-balancers-01 . . . . . . . . . 31 116 C.5. since-draft-ietf-quic-load-balancers-00 . . . . . . . . . 31 117 C.6. Since draft-duke-quic-load-balancers-06 . . . . . . . . . 31 118 C.7. Since draft-duke-quic-load-balancers-05 . . . . . . . . . 31 119 C.8. Since draft-duke-quic-load-balancers-04 . . . . . . . . . 31 120 C.9. Since draft-duke-quic-load-balancers-03 . . . . . . . . . 31 121 C.10. Since draft-duke-quic-load-balancers-02 . . . . . . . . . 32 122 C.11. Since draft-duke-quic-load-balancers-01 . . . . . . . . . 32 123 C.12. Since draft-duke-quic-load-balancers-00 . . . . . . . . . 32 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 126 1. Introduction 128 QUIC packets [QUIC-TRANSPORT] usually contain a connection ID to 129 allow endpoints to associate packets with different address/port 130 4-tuples to the same connection context. This feature makes 131 connections robust in the event of NAT rebinding. QUIC endpoints 132 usually designate the connection ID which peers use to address 133 packets. Server-generated connection IDs create a potential need for 134 out-of-band communication to support QUIC. 136 QUIC allows servers (or load balancers) to designate an initial 137 connection ID to encode useful routing information for load 138 balancers. It also encourages servers, in packets protected by 139 cryptography, to provide additional connection IDs to the client. 140 This allows clients that know they are going to change IP address or 141 port to use a separate connection ID on the new path, thus reducing 142 linkability as clients move through the world. 144 There is a tension between the requirements to provide routing 145 information and mitigate linkability. Ultimately, because new 146 connection IDs are in protected packets, they must be generated at 147 the server if the load balancer does not have access to the 148 connection keys. However, it is the load balancer that has the 149 context necessary to generate a connection ID that encodes useful 150 routing information. In the absence of any shared state between load 151 balancer and server, the load balancer must maintain a relatively 152 expensive table of server-generated connection IDs, and will not 153 route packets correctly if they use a connection ID that was 154 originally communicated in a protected NEW_CONNECTION_ID frame. 156 This specification provides common algorithms for encoding the server 157 mapping in a connection ID given some shared parameters. The mapping 158 is generally only discoverable by observers that have the parameters, 159 preserving unlinkability as much as possible. 161 Aside from load balancing, a QUIC server may also desire to offload 162 other protocol functions to trusted intermediaries. These 163 intermediaries might include hardware assist on the server host 164 itself, without access to fully decrypted QUIC packets. For example, 165 this document specifies a means of offloading stateless retry to 166 counter Denial of Service attacks. It also proposes a system for 167 self-encoding connection ID length in all packets, so that crypto 168 offload can consistently look up key information. 170 While this document describes a small set of configuration parameters 171 to make the server mapping intelligible, the means of distributing 172 these parameters between load balancers, servers, and other trusted 173 intermediaries is out of its scope. There are numerous well-known 174 infrastructures for distribution of configuration. 176 1.1. Terminology 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in RFC 2119 [RFC2119]. 182 In this document, these words will appear with that interpretation 183 only when in ALL CAPS. Lower case uses of these words are not to be 184 interpreted as carrying significance described in RFC 2119. 186 In this document, "client" and "server" refer to the endpoints of a 187 QUIC connection unless otherwise indicated. A "load balancer" is an 188 intermediary for that connection that does not possess QUIC 189 connection keys, but it may rewrite IP addresses or conduct other IP 190 or UDP processing. A "configuration agent" is the entity that 191 determines the QUIC-LB configuration parameters for the network and 192 leverages some system to distribute that configuration. 194 Note that stateful load balancers that act as proxies, by terminating 195 a QUIC connection with the client and then retrieving data from the 196 server using QUIC or another protocol, are treated as a server with 197 respect to this specification. 199 For brevity, "Connection ID" will often be abbreviated as "CID". 201 2. Protocol Objectives 203 2.1. Simplicity 205 QUIC is intended to provide unlinkability across connection 206 migration, but servers are not required to provide additional 207 connection IDs that effectively prevent linkability. If the 208 coordination scheme is too difficult to implement, servers behind 209 load balancers using connection IDs for routing will use trivially 210 linkable connection IDs. Clients will therefore be forced to choose 211 between terminating the connection during migration or remaining 212 linkable, subverting a design objective of QUIC. 214 The solution should be both simple to implement and require little 215 additional infrastructure for cryptographic keys, etc. 217 2.2. Security 219 In the limit where there are very few connections to a pool of 220 servers, no scheme can prevent the linking of two connection IDs with 221 high probability. In the opposite limit, where all servers have many 222 connections that start and end frequently, it will be difficult to 223 associate two connection IDs even if they are known to map to the 224 same server. 226 QUIC-LB is relevant in the region between these extremes: when the 227 information that two connection IDs map to the same server is helpful 228 to linking two connection IDs. Obviously, any scheme that 229 transparently communicates this mapping to outside observers 230 compromises QUIC's defenses against linkability. 232 Though not an explicit goal of the QUIC-LB design, concealing the 233 server mapping also complicates attempts to focus attacks on a 234 specific server in the pool. 236 3. First CID octet 238 The first octet of a Connection ID is reserved for two special 239 purposes, one mandatory (config rotation) and one optional (length 240 self-description). 242 Subsequent sections of this document refer to the contents of this 243 octet as the "first octet." 245 3.1. Config Rotation 247 The first two bits of any connection ID MUST encode an identifier for 248 the configuration that the connection ID uses. This enables 249 incremental deployment of new QUIC-LB settings (e.g., keys). 251 When new configuration is distributed to servers, there will be a 252 transition period when connection IDs reflecting old and new 253 configuration coexist in the network. The rotation bits allow load 254 balancers to apply the correct routing algorithm and parameters to 255 incoming packets. 257 Configuration Agents SHOULD deliver new configurations to load 258 balancers before doing so to servers, so that load balancers are 259 ready to process CIDs using the new parameters when they arrive. 261 A Configuration Agent SHOULD NOT use a codepoint to represent a new 262 configuration until it takes precautions to make sure that all 263 connections using CIDs with an old configuration at that codepoint 264 have closed or transitioned. 266 Servers MUST NOT generate new connection IDs using an old 267 configuration after receiving a new one from the configuration agent. 268 Servers MUST send NEW_CONNECTION_ID frames that provide CIDs using 269 the new configuration, and retire CIDs using the old configuration 270 using the "Retire Prior To" field of that frame. 272 It also possible to use these bits for more long-lived distinction of 273 different configurations, but this has privacy implications (see 274 Section 10.3). 276 3.2. Configuration Failover 278 If a server has not received a valid QUIC-LB configuration, and 279 believes that low-state, Connection-ID aware load balancers are in 280 the path, it SHOULD generate connection IDs with the config rotation 281 bits set to '11' and SHOULD use the "disable_active_migration" 282 transport parameter in all new QUIC connections. It SHOULD NOT send 283 NEW_CONNECTION_ID frames with new values. 285 A load balancer that sees a connection ID with config rotation bits 286 set to '11' MUST revert to 5-tuple routing. 288 3.3. Length Self-Description 290 Local hardware cryptographic offload devices may accelerate QUIC 291 servers by receiving keys from the QUIC implementation indexed to the 292 connection ID. However, on physical devices operating multiple QUIC 293 servers, it is impractical to efficiently lookup these keys if the 294 connection ID does not self-encode its own length. 296 Note that this is a function of particular server devices and is 297 irrelevant to load balancers. As such, load balancers MAY omit this 298 from their configuration. However, the remaining 6 bits in the first 299 octet of the Connection ID are reserved to express the length of the 300 following connection ID, not including the first octet. 302 A server not using this functionality SHOULD make the six bits appear 303 to be random. 305 3.4. Format 307 0 1 2 3 308 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 |C R| CID Len | 311 +-+-+-+-+-+-+-+-+ 313 Figure 1: First Octet Format 315 The first octet has the following fields: 317 CR: Config Rotation bits. 319 CID Len: Length Self-Description (if applicable). Encodes the length 320 of the Connection ID following the First Octet. 322 4. Routing Algorithms 324 In QUIC-LB, load balancers do not generate individual connection IDs 325 to servers. Instead, they communicate the parameters of an algorithm 326 to generate routable connection IDs. 328 The algorithms differ in the complexity of configuration at both load 329 balancer and server. Increasing complexity improves obfuscation of 330 the server mapping. 332 As clients sometimes generate the DCIDs in long headers, these might 333 not conform to the expectations of the routing algorithm. These are 334 called "non-compliant DCIDs": 336 * The DCID might not be long enough for the routing algorithm to 337 process. 339 * The config rotation bits (Section 3.1) may not correspond to an 340 active configuration. 342 * The extracted server mapping might not correspond to an active 343 server. 345 Load balancers MUST forward packets with long headers and non- 346 compliant DCIDs to an active server using an algorithm of its own 347 choosing. It need not coordinate this algorithm with the servers. 348 The algorithm SHOULD be deterministic over short time scales so that 349 related packets go to the same server. The design of this algorithm 350 SHOULD consider the version-invariant properties of QUIC described in 351 [QUIC-INVARIANTS] to maximize its robustness to future versions of 352 QUIC. For example, a non-compliant DCID might be converted to an 353 integer and divided by the number of servers, with the modulus used 354 to forward the packet. The number of servers is usually consistent 355 on the time scale of a QUIC connection handshake. See also 356 Section 9. 358 As a partial exception to the above, load balancers MAY drop packets 359 with long headers and non-compliant DCIDs if and only if it knows 360 that the encoded QUIC version does not allow a non-compliant DCID in 361 a packet with that signature. For example, a load balancer can 362 safely drop a QUIC version 1 Handshake packet with a non-compliant 363 DCID. The prohibition against dropping packets with long headers 364 remains for unknown QUIC versions. 366 Load balancers SHOULD drop packets with non-compliant DCIDs in a 367 short header. 369 Servers that receive packets with noncompliant CIDs MUST use the 370 available mechanisms to induce the client to use a compliant CID in 371 future packets. In QUIC version 1, this requires using a compliant 372 CID in the Source CID field of server-generated long headers. 374 A QUIC-LB configuration MAY significantly over-provision the server 375 ID space (i.e., provide far more codepoints than there are servers) 376 to increase the probability that a randomly generated Destination 377 Connection ID is non- compliant. 379 Load balancers MUST forward packets with compliant DCIDs to a server 380 in accordance with the chosen routing algorithm. 382 The load balancer MUST NOT make the routing behavior dependent on any 383 bits in the first octet of the QUIC packet header, except the first 384 bit, which indicates a long header. All other bits are QUIC version- 385 dependent and intermediaries cannot base their design on version- 386 specific templates. 388 There are situations where a server pool might be operating two or 389 more routing algorithms or parameter sets simultaneously. The load 390 balancer uses the first two bits of the connection ID to multiplex 391 incoming DCIDs over these schemes. 393 This section describes three participants: the configuration agent, 394 the load balancer, and the server. 396 4.1. Plaintext CID Algorithm 398 The Plaintext CID Algorithm makes no attempt to obscure the mapping 399 of connections to servers, significantly increasing linkability. The 400 format is depicted in the figure below. 402 0 1 2 3 403 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | First octet | Server ID (X=8..152) | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Any (0..152-X) | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Figure 2: Plaintext CID Format 412 4.1.1. Configuration Agent Actions 414 The configuration agent selects a length for the server ID encoding. 415 This length MUST have enough entropy to have a different code point 416 for each server. 418 It also assigns a server ID to each server. 420 4.1.2. Load Balancer Actions 422 On each incoming packet, the load balancer extracts consecutive 423 octets, beginning with the second octet. These bytes represent the 424 server ID. 426 4.1.3. Server Actions 428 The server chooses a connection ID length. This MUST be at least one 429 byte longer than the routing bytes. 431 When a server needs a new connection ID, it encodes its assigned 432 server ID in consecutive octets beginning with the second. All other 433 bits in the connection ID, except for the first octet, MAY be set to 434 any other value. These other bits SHOULD appear random to observers. 436 4.2. Stream Cipher CID Algorithm 438 The Stream Cipher CID algorithm provides cryptographic protection at 439 the cost of additional per-packet processing at the load balancer to 440 decrypt every incoming connection ID. The CID format is depicted 441 below. 443 0 1 2 3 444 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | First Octet | Nonce (X=64..128) | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Encrypted Server ID (Y=8..152-X) | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | For server use (0..152-X-Y) | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Figure 3: Stream Cipher CID Format 455 4.2.1. Configuration Agent Actions 457 The configuration agent assigns a server ID to every server in its 458 pool, and determines a server ID length (in octets) sufficiently 459 large to encode all server IDs, including potential future servers. 461 The configuration agent also selects a nonce length and an 16-octet 462 AES-ECB key to use for connection ID decryption. The nonce length 463 MUST be at least 8 octets and no more than 16 octets. The nonce 464 length and server ID length MUST sum to 19 or fewer octets. 466 4.2.2. Load Balancer Actions 468 Upon receipt of a QUIC packet, the load balancer extracts as many of 469 the earliest octets from the destination connection ID as necessary 470 to match the nonce length. The server ID immediately follows. 472 The load balancer decrypts the nonce and the server ID using the 473 following three pass algorithm: 475 * Pass 1: The load balancer decrypts the server ID using 128-bit AES 476 Electronic Codebook (ECB) mode, much like QUIC header protection. 477 The encrypted nonce octets are zero-padded to 16 octets. AES-ECB 478 encrypts this encrypted nonce using its key to generate a mask 479 which it applies to the encrypted server id. This provides an 480 intermediate value of the server ID, referred to as server-id 481 intermediate. 483 server_id_intermediate = encrypted_server_id ^ AES-ECB(key, padded- 484 encrypted-nonce) 486 * Pass 2: The load balancer decrypts the nonce octets using 128-bit 487 AES ECB mode, using the server-id intermediate as "nonce" for this 488 pass. The server-id intermediate octets are zero-padded to 16 489 octets. AES-ECB encrypts this padded server-id intermediate using 490 its key to generate a mask which it applies to the encrypted 491 nonce. This provides the decrypted nonce value. 493 nonce = encrypted_nonce ^ AES-ECB(key, padded-server_id_intermediate) 495 * Pass 3: The load balancer decrypts the server ID using 128-bit AES 496 ECB mode. The nonce octets are zero-padded to 16 octets. AES-ECB 497 encrypts this nonce using its key to generate a mask which it 498 applies to the intermediate server id. This provides the 499 decrypted server ID. 501 server_id = server_id_intermediate ^ AES-ECB(key, padded-nonce) 503 For example, if the nonce length is 10 octets and the server ID 504 length is 2 octets, the connection ID can be as small as 13 octets. 505 The load balancer uses the the second through eleventh octets of the 506 connection ID for the nonce, zero-pads it to 16 octets, uses xors the 507 result with the twelfth and thirteenth octet. The result is padded 508 with 14 octets of zeros and encrypted to obtain a mask that is xored 509 with the nonce octets. Finally, the nonce octets are padded with six 510 octets of zeros, encrypted, and the first two octets xored with the 511 server ID octets to obtain the actual server ID. 513 This three-pass algorithm is a simplified version of the FFX 514 algorithm, with the property that each encrypted nonce value depends 515 on all server ID bits, and each encrypted server ID bit depends on 516 all nonce bits and all server ID bits. This mitigates attacks 517 against stream ciphers in which attackers simply flip encrypted 518 server-ID bits. 520 The output of the decryption is the server ID that the load balancer 521 uses for routing. 523 4.2.3. Server Actions 525 When generating a routable connection ID, the server writes arbitrary 526 bits into its nonce octets, and its provided server ID into the 527 server ID octets. Servers MAY opt to have a longer connection ID 528 beyond the nonce and server ID. The additional bits MAY encode 529 additional information, but SHOULD appear essentially random to 530 observers. 532 If the decrypted nonce bits increase monotonically, that guarantees 533 that nonces are not reused between connection IDs from the same 534 server. 536 The server encrypts the server ID using exactly the algorithm as 537 described in Section 4.2.2, performing the three passes in reverse 538 order. 540 4.3. Block Cipher CID Algorithm 542 The Block Cipher CID Algorithm, by using a full 16 octets of 543 plaintext and a 128-bit cipher, provides higher cryptographic 544 protection and detection of non-compliant connection IDs. However, 545 it also requires connection IDs of at least 17 octets, increasing 546 overhead of client-to-server packets. 548 0 1 2 3 549 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | First octet | Encrypted server ID (X=8..128) | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Encrypted bits for server use (128-X) | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Unencrypted bits for server use (0..24) | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 Figure 4: Block Cipher CID Format 560 4.3.1. Configuration Agent Actions 562 The configuration agent assigns a server ID to every server in its 563 pool, and determines a server ID length (in octets) sufficiently 564 large to encode all server IDs, including potential future servers. 565 The server ID will start in the second octet of the decrypted 566 connection ID and occupy continuous octets beyond that. 568 They server ID length MUST be no more than 16 octets and SHOULD be no 569 more than 12 octets, to provide servers adequate space to encode 570 their own opaque data. 572 The configuration agent also selects an 16-octet AES-ECB key to use 573 for connection ID decryption. 575 4.3.2. Load Balancer Actions 577 Upon receipt of a QUIC packet, the load balancer reads the first 578 octet to obtain the config rotation bits. It then decrypts the 579 subsequent 16 octets using AES-ECB decryption and the chosen key. 581 The decrypted plaintext contains the server id and opaque server data 582 in that order. The load balancer uses the server ID octets for 583 routing. 585 4.3.3. Server Actions 587 When generating a routable connection ID, the server MUST choose a 588 connection ID length between 17 and 20 octets. The server writes its 589 provided server ID into the server ID octets and arbitrary bits into 590 the remaining bits. These arbitrary bits MAY encode additional 591 information. Bits in the eighteenth, nineteenth, and twentieth 592 octets SHOULD appear essentially random to observers. The first 593 octet is reserved as described in Section 3. 595 The server then encrypts the second through seventeenth octets using 596 the 128-bit AES-ECB cipher. 598 5. ICMP Processing 600 For protocols where 4-tuple load balancing is sufficient, it is 601 straightforward to deliver ICMP packets from the network to the 602 correct server, by reading the echoed `IP and transport-layer headers 603 to obtain the 4-tuple. When routing is based on connection ID, 604 further measures are required, as most QUIC packets that trigger ICMP 605 responses will only contain a client-generated connection ID that 606 contains no routing information. 608 To solve this problem, load balancers MAY maintain a mapping of 609 Client IP and port to server ID based on recently observed packets. 611 Alternatively, servers MAY implement the technique described in 612 Section 14.4.1 of [QUIC-TRANSPORT] to increase the likelihood a 613 Source Connection ID is included in ICMP responses to Path Maximum 614 Transmission Unit (PMTU) probes. Load balancers MAY parse the echoed 615 packet to extract the Source Connection ID, if it contains a QUIC 616 long header, and extract the Server ID as if it were in a Destination 617 CID. 619 6. Retry Service 621 When a server is under load, QUICv1 allows it to defer storage of 622 connection state until the client proves it can receive packets at 623 its advertised IP address. Through the use of a Retry packet, a 624 token in subsequent client Initial packets, and transport parameters, 625 servers verify address ownership and clients verify that there is no 626 on-path attacker generating Retry packets. 628 A "Retry Service" detects potential Denial of Service attacks and 629 handles sending of Retry packets on behalf of the server. As it is, 630 by definition, literally an on-path entity, the service must 631 communicate some of the original connection IDs back to the server so 632 that it can pass client verification. It also must either verify the 633 address itself (with the server trusting this verification) or make 634 sure there is common context for the server to verify the address 635 using a service-generated token. 637 There are two different mechanisms to allow offload of DoS mitigation 638 to a trusted network service. One requires no shared state; the 639 server need only be configured to trust a retry service, though this 640 imposes other operational constraints. The other requires a shared 641 key, but has no such constraints. 643 Retry services MUST forward all QUIC packets that are not of type 644 Initial or 0-RTT. Other packet types might involve changed IP 645 addresses or connection IDs, so it is not practical for Retry 646 Services to identify such packets as valid or invalid. 648 6.1. Common Requirements 650 Regardless of mechanism, a retry service has an active mode, where it 651 is generating Retry packets, and an inactive mode, where it is not, 652 based on its assessment of server load and the likelihood an attack 653 is underway. The choice of mode MAY be made on a per-packet or per- 654 connection basis, through a stochastic process or based on client 655 address. 657 A retry service MUST forward all packets for a QUIC version it does 658 not understand. Note that if servers support versions the retry 659 service does not, this may increase load on the servers. However, 660 dropping these packets would introduce chokepoints to block 661 deployment of new QUIC versions. Note that future versions of QUIC 662 might not have Retry packets, require different information in Retry, 663 or use different packet type indicators. 665 6.2. No-Shared-State Retry Service 667 The no-shared-state retry service requires no coordination, except 668 that the server must be configured to accept this service and know 669 which QUIC versions the retry service supports. The scheme uses the 670 first bit of the token to distinguish between tokens from Retry 671 packets (codepoint '0') and tokens from NEW_TOKEN frames (codepoint 672 '1'). 674 6.2.1. Configuration Agent Actions 676 The configuration agent distributes a list of QUIC versions to be 677 served by the Retry Service. 679 6.2.2. Service Requirements 681 A no-shared-state retry service MUST be present on all paths from 682 potential clients to the server. These paths MUST fail to pass QUIC 683 traffic should the service fail for any reason. That is, if the 684 service is not operational, the server MUST NOT be exposed to client 685 traffic. Otherwise, servers that have already disabled their Retry 686 capability would be vulnerable to attack. 688 The path between service and server MUST be free of any potential 689 attackers. Note that this and other requirements above severely 690 restrict the operational conditions in which a no-shared-state retry 691 service can safely operate. 693 Retry tokens generated by the service MUST have the format below. 695 0 1 2 3 696 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 |0| ODCIL (7) | RSCIL (8) | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Original Destination Connection ID (0..160) | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | ... | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Retry Source Connection ID (0..160) | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | ... | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Opaque Data (variable) | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 Figure 5: Format of non-shared-state retry service tokens 713 The first bit of retry tokens generated by the service MUST be zero. 714 The token has the following additional fields: 716 ODCIL: The length of the original destination connection ID from the 717 triggering Initial packet. This is in cleartext to be readable for 718 the server, but authenticated later in the token. 720 RSCIL: The retry source connection ID length. 722 Original Destination Connection ID: This also in cleartext and 723 authenticated later. 725 Retry Source Connection ID: This also in cleartext and authenticated 726 later. 728 Opaque Data: This data MUST contain encrypted information that allows 729 the retry service to validate the client's IP address, in accordance 730 with the QUIC specification. It MUST also provide a 731 cryptographically secure means to validate the integrity of the 732 entire token. 734 Upon receipt of an Initial packet with a token that begins with '0', 735 the retry service MUST validate the token in accordance with the QUIC 736 specification. 738 In active mode, the service MUST issue Retry packets for all Client 739 initial packets that contain no token, or a token that has the first 740 bit set to '1'. It MUST NOT forward the packet to the server. The 741 service MUST validate all tokens with the first bit set to '0'. If 742 successful, the service MUST forward the packet with the token 743 intact. If unsuccessful, it MUST drop the packet. The Retry Service 744 MAY send an Initial Packet containing a CONNECTION_CLOSE frame with 745 the INVALID_TOKEN error code when dropping the packet. 747 Note that this scheme has a performance drawback. When the retry 748 service is in active mode, clients with a token from a NEW_TOKEN 749 frame will suffer a 1-RTT penalty even though its token provides 750 proof of address. 752 In inactive mode, the service MUST forward all packets that have no 753 token or a token with the first bit set to '1'. It MUST validate all 754 tokens with the first bit set to '0'. If successful, the service 755 MUST forward the packet with the token intact. If unsuccessful, it 756 MUST either drop the packet or forward it with the token removed. 757 The latter requires decryption and re-encryption of the entire 758 Initial packet to avoid authentication failure. Forwarding the 759 packet causes the server to respond without the 760 original_destination_connection_id transport parameter, which 761 preserves the normal QUIC signal to the client that there is an on- 762 path attacker. 764 6.2.3. Server Requirements 766 A server behind a non-shared-state retry service MUST NOT send Retry 767 packets for a QUIC version the retry service understands. It MAY 768 send Retry for QUIC versions the Retry Service does not understand. 770 Tokens sent in NEW_TOKEN frames MUST have the first bit set to '1'. 772 If a server receives an Initial Packet with the first bit set to '1', 773 it could be from a server-generated NEW_TOKEN frame and should be 774 processed in accordance with the QUIC specification. If a server 775 receives an Initial Packet with the first bit to '0', it is a Retry 776 token and the server MUST NOT attempt to validate it. Instead, it 777 MUST assume the address is validated and MUST extract the Original 778 Destination Connection ID and Retry Source Connection ID, assuming 779 the format described in Section 6.2.2. 781 6.3. Shared-State Retry Service 783 A shared-state retry service uses a shared key, so that the server 784 can decode the service's retry tokens. It does not require that all 785 traffic pass through the Retry service, so servers MAY send Retry 786 packets in response to Initial packets that don't include a valid 787 token. 789 Both server and service must have access to Universal time, though 790 tight synchronization is unnecessary. 792 All tokens, generated by either the server or retry service, MUST use 793 the following format. This format is the cleartext version. On the 794 wire, these fields are encrypted using an AES-ECB cipher and the 795 token key. If the token is not a multiple of 16 octets, the last 796 block is padded with zeroes. 798 0 1 2 3 799 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | | 802 + + 803 | | 804 + Client IP Address (128) + 805 | | 806 + + 807 | | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | ODCIL | RSCIL | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Original Destination Connection ID (0..160) | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | ... | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Retry Source Connection ID (0..160) | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | ... | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | | 820 + Timestamp (64) + 821 | | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Opaque Data (optional) | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 Figure 6: Cleartext format of shared-state retry tokens 828 The tokens have the following fields: 830 ODCIL: The original destination connection ID length. Tokens in 831 NEW_TOKEN frames MUST set this field to zero. 833 RSCIL: The retry source connection ID length. Tokens in NEW_TOKEN 834 frames MUST set this field to zero. 836 Original Destination Connection ID: The server or Retry Service 837 copies this from the field in the client Initial packet. 839 Retry Source Connection ID: The server or Retry service copies this 840 from the Source Connection ID of the Retry packet. 842 Client IP Address: The source IP address from the triggering Initial 843 packet. The client IP address is 16 octets. If an IPv4 address, the 844 last 12 octets are zeroes. If there is a Network Address Translator 845 (NAT) in the server infrastructure that changes the client IP, the 846 Retry Service MUST either be positioned behind the NAT, or the NAT 847 must have the token key to rewrite the Retry token accordingly. 849 Timestamp: The timestamp is a 64-bit integer, in network order, that 850 expresses the number of seconds in POSIX time (see Sec. 4.16 of 851 [TIME_T]). 853 Opaque Data: The server may use this field to encode additional 854 information, such as congestion window, RTT, or MTU. Opaque data MAY 855 also allow servers to distinguish between retry tokens (which trigger 856 use of certain transport parameters) and NEW_TOKEN frame tokens. 858 6.3.1. Configuration Agent Actions 860 The configuration agent generates and distributes a "token key" and a 861 list of QUIC versions the service supports. It must also inform the 862 service if a NAT lies between the service and the servers. 864 6.3.2. Service Requirements 866 When in active mode, the service MUST generate Retry tokens with the 867 format described above when it receives a client Initial packet with 868 no token. 870 In active mode, the service SHOULD decrypt the first 16 octets of 871 incoming tokens. The service SHOULD drop packets with an IP address 872 that does not match, and SHOULD forward packets that do, regardless 873 of the other fields. 875 However, the service MUST NOT decrypt or validate tokens if there is 876 a NAT between it and the servers. 878 In inactive mode, the service SHOULD forward all packets to the 879 server so that the server can issue an up-to-date token to the 880 client. 882 6.3.3. Server Requirements 884 When issuing Retry or NEW_TOKEN tokens, the server MUST encode the 885 client IP address in the first 16 octets and encrypt that block with 886 the token key. It MAY use any format or encryption for the remainder 887 of the token. However, it MUST include a means of distinguishing 888 service-generated Retry tokens, server-generated Retry tokens (if 889 different), and NEW_TOKEN tokens. 891 The server MUST validate all tokens that arrive in Initial packets, 892 as they may have bypassed the Retry service. 894 For Retry tokens that follow the format above, servers SHOULD use the 895 timestamp field to apply its expiration limits for tokens. This need 896 not be precisely synchronized with the retry service. However, 897 servers MAY allow retry tokens marked as being a few seconds in the 898 future, due to possible clock synchronization issues. 900 After decrypting the token, the server uses the corresponding fields 901 to populate the original_destination_connection_id transport 902 parameter, with a length equal to ODCIL, and the 903 retry_source_connection_id transport parameter, with length equal to 904 RSCIL. 906 For QUIC versions the service does not support, the server MAY use 907 any token format. 909 As discussed in [QUIC-TRANSPORT], a server MUST NOT send a Retry 910 packet in response to an Initial packet that contains a retry token. 912 7. Configuration Requirements 914 QUIC-LB requires common configuration to synchronize understanding of 915 encodings and guarantee explicit consent of the server. 917 The load balancer and server MUST agree on a routing algorithm and 918 the relevant parameters for that algorithm. Each server MUST know 919 its server ID for each configuration, and the load balancer MUST have 920 forwarding instructions for each server ID. 922 For all algorithms, the load balancer and servers MUST have a common 923 understanding of the server ID length. 925 For Stream Cipher CID Routing, the servers and load balancer also 926 MUST have a common understanding of the key and nonce length. 928 For Block Cipher CID Routing, the servers and load balancer also MUST 929 have a common understanding of the key. 931 Note that server IDs are opaque bytes, not integers, so there is no 932 notion of network order or host order. 934 A server configuration MUST specify if the first octet encodes the 935 CID length. Note that a load balancer does not need the CID length, 936 as the required bytes are present in the QUIC packet. 938 A full QUIC-LB server configuration MUST also specify the supported 939 QUIC versions of any Retry Service. If a shared-state service, the 940 server also must have the token key. 942 A non-shared-state Retry Service need only be configured with the 943 QUIC versions it supports. A shared-state Retry Service also needs 944 the token key, and to be aware if a NAT sits between it and the 945 servers. 947 The following pseudocode describes the data items necessary to store 948 a full QUIC-LB configuration at the server. It is meant to describe 949 the conceptual range and not specify the presentation of such 950 configuration in an internet packet. The comments signify the range 951 of acceptable values where applicable. 953 uint2 config_rotation_bits; 954 boolean first_octet_encodes_cid_length; 955 enum { none, non_shared_state, shared_state } retry_service; 956 select (retry_service) { 957 case none: null; 958 case non_shared_state: uint32 list_of_quic_versions[]; 959 case shared_state: { 960 uint32 list_of_quic_versions[]; 961 uint8 token_key[16]; 962 } shared_state_config; 963 } retry_service_config; 964 enum { none, plaintext, stream_cipher, block_cipher } 965 routing_algorithm; 966 select (routing_algorithm) { 967 case none: null; 968 case plaintext: struct { 969 uint8 server_id_length; /* 1..19 */ 970 uint8 server_id[server_id_length]; 971 } plaintext_config; 972 case stream_cipher: struct { 973 uint8 nonce_length; /* 8..16 */ 974 uint8 server_id_length; /* 1..(19 - nonce_length) */ 975 uint8 server_id[server_id_length]; 976 uint8 key[16]; 977 } stream_cipher_config; 978 case block_cipher: struct { 979 uint8 server_id_length; 980 uint8 server_id[server_id_length]; 981 uint8 key[16]; 982 } block_cipher_config; 983 } routing_algorithm_config; 985 8. Additional Use Cases 987 This section discusses considerations for some deployment scenarios 988 not implied by the specification above. 990 8.1. Load balancer chains 992 Some network architectures may have multiple tiers of low-state load 993 balancers, where a first tier of devices makes a routing decision to 994 the next tier, and so on, until packets reach the server. Although 995 QUIC-LB is not explicitly designed for this use case, it is possible 996 to support it. 998 If each load balancer is assigned a range of server IDs that is a 999 subset of the range of IDs assigned to devices that are closer to the 1000 client, then the first devices to process an incoming packet can 1001 extract the server ID and then map it to the correct forwarding 1002 address. Note that this solution is extensible to arbitrarily large 1003 numbers of load-balancing tiers, as the maximum server ID space is 1004 quite large. 1006 8.2. Moving connections between servers 1008 Some deployments may transparently move a connection from one server 1009 to another. The means of transferring connection state between 1010 servers is out of scope of this document. 1012 To support a handover, a server involved in the transition could 1013 issue CIDs that map to the new server via a NEW_CONNECTION_ID frame, 1014 and retire CIDs associated with the new server using the "Retire 1015 Prior To" field in that frame. 1017 Alternately, if the old server is going offline, the load balancer 1018 could simply map its server ID to the new server's address. 1020 9. Version Invariance of QUIC-LB 1022 Non-shared-state Retry Services are inherently dependent on the 1023 format (and existence) of Retry Packets in each version of QUIC, and 1024 so Retry Service configuration explicitly includes the supported QUIC 1025 versions. 1027 The server ID encodings, and requirements for their handling, are 1028 designed to be QUIC version independent (see [QUIC-INVARIANTS]). A 1029 QUIC-LB load balancer will generally not require changes as servers 1030 deploy new versions of QUIC. However, there are several unlikely 1031 future design decisions that could impact the operation of QUIC-LB. 1033 The maximum Connection ID length could be below the minimum necessary 1034 for one or more encoding algorithms. 1036 Section 4 provides guidance about how load balancers should handle 1037 non-compliant DCIDs. This guidance, and the implementation of an 1038 algorithm to handle these DCIDs, rests on some assumptions: 1040 * Incoming short headers do not contain DCIDs that are client- 1041 generated. 1043 * The use of client-generated incoming DCIDs does not persist beyond 1044 a few round trips in the connection. 1046 * While the client is using DCIDs it generated, some exposed fields 1047 (IP address, UDP port, client-generated destination Connection ID) 1048 remain constant for all packets sent on the same connection. 1050 While this document does not update the commitments in 1051 [QUIC-INVARIANTS], the additional assumptions are minimal and 1052 narrowly scoped, and provide a likely set of constants that load 1053 balancers can use with minimal risk of version- dependence. 1055 If these assumptions are invalid, this specification is likely to 1056 lead to loss of packets that contain non-compliant DCIDs, and in 1057 extreme cases connection failure. 1059 10. Security Considerations 1061 QUIC-LB is intended to prevent linkability. Attacks would therefore 1062 attempt to subvert this purpose. 1064 Note that the Plaintext CID algorithm makes no attempt to obscure the 1065 server mapping, and therefore does not address these concerns. It 1066 exists to allow consistent CID encoding for compatibility across a 1067 network infrastructure, which makes QUIC robust to NAT rebinding. 1068 Servers that are running the Plaintext CID algorithm SHOULD only use 1069 it to generate new CIDs for the Server Initial Packet and SHOULD NOT 1070 send CIDs in QUIC NEW_CONNECTION_ID frames, except that it sends one 1071 new Connection ID in the event of config rotation Section 3.1. Doing 1072 so might falsely suggest to the client that said CIDs were generated 1073 in a secure fashion. 1075 A linkability attack would find some means of determining that two 1076 connection IDs route to the same server. As described above, there 1077 is no scheme that strictly prevents linkability for all traffic 1078 patterns, and therefore efforts to frustrate any analysis of server 1079 ID encoding have diminishing returns. 1081 10.1. Attackers not between the load balancer and server 1083 Any attacker might open a connection to the server infrastructure and 1084 aggressively simulate migration to obtain a large sample of IDs that 1085 map to the same server. It could then apply analytical techniques to 1086 try to obtain the server encoding. 1088 The Stream and Block Cipher CID algorithms provide robust protection 1089 against any sort of linkage. The Plaintext CID algorithm makes no 1090 attempt to protect this encoding. 1092 Were this analysis to obtain the server encoding, then on-path 1093 observers might apply this analysis to correlating different client 1094 IP addresses. 1096 10.2. Attackers between the load balancer and server 1098 Attackers in this privileged position are intrinsically able to map 1099 two connection IDs to the same server. The QUIC-LB algorithms do 1100 prevent the linkage of two connection IDs to the same individual 1101 connection if servers make reasonable selections when generating new 1102 IDs for that connection. 1104 10.3. Multiple Configuration IDs 1106 During the period in which there are multiple deployed configuration 1107 IDs (see Section 3.1), there is a slight increase in linkability. 1108 The server space is effectively divided into segments with CIDs that 1109 have different config rotation bits. Entities that manage servers 1110 SHOULD strive to minimize these periods by quickly deploying new 1111 configurations across the server pool. 1113 10.4. Limited configuration scope 1115 A simple deployment of QUIC-LB in a cloud provider might use the same 1116 global QUIC-LB configuration across all its load balancers that route 1117 to customer servers. An attacker could then simply become a 1118 customer, obtain the configuration, and then extract server IDs of 1119 other customers' connections at will. 1121 To avoid this, the configuration agent SHOULD issue QUIC-LB 1122 configurations to mutually distrustful servers that have different 1123 keys for encryption algorithms. The load balancers can distinguish 1124 these configurations by external IP address, or by assigning 1125 different values to the config rotation bits (Section 3.1). Note 1126 that either solution has a privacy impact; see Section 10.3. 1128 These techniques are not necessary for the plaintext algorithm, as it 1129 does not attempt to conceal the server ID. 1131 10.5. Stateless Reset Oracle 1133 Section 21.9 of [QUIC-TRANSPORT] discusses the Stateless Reset Oracle 1134 attack. For a server deployment to be vulnerable, an attacking 1135 client must be able to cause two packets with the same Destination 1136 CID to arrive at two different servers that share the same 1137 cryptographic context for Stateless Reset tokens. As QUIC-LB 1138 requires deterministic routing of DCIDs over the life of a 1139 connection, it is a sufficient means of avoiding an Oracle without 1140 additional measures. 1142 11. IANA Considerations 1144 There are no IANA requirements. 1146 12. References 1148 12.1. Normative References 1150 [QUIC-INVARIANTS] 1151 Thomson, M., Ed., "Version-Independent Properties of 1152 QUIC", Work in Progress, Internet-Draft, draft-ietf-quic- 1153 invariants, 1154 . 1156 [QUIC-TRANSPORT] 1157 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1158 Multiplexed and Secure Transport", Work in Progress, 1159 Internet-Draft, draft-ietf-quic-transport, 1160 . 1162 [TIME_T] "Open Group Standard: Vol. 1: Base Definitions, Issue 7", 1163 IEEE Std 1003.1 , 2018, 1164 . 1167 12.2. Informative References 1169 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1170 Requirement Levels", BCP 14, RFC 2119, 1171 DOI 10.17487/RFC2119, March 1997, 1172 . 1174 Appendix A. Load Balancer Test Vectors 1176 Each section of this draft includes multiple sets of load balancer 1177 configuration, each of which has five examples of server ID and 1178 server use bytes and how they are encoded in a CID. 1180 In some cases, there are no server use bytes. Note that, for 1181 simplicity, the first octet bits used for neither config rotation nor 1182 length self-encoding are random, rather than listed in the server use 1183 field. Therefore, a server implementation using these parameters may 1184 generate CIDs with a slightly different first octet. 1186 This section uses the following abbreviations: 1188 cid Connection ID cr_bits Config Rotation Bits LB Load Balancer sid 1189 Server ID sid_len Server ID length su Server Use Bytes 1190 All values except length_self_encoding and sid_len are expressed in 1191 hexidecimal format. 1193 A.1. Plaintext Connection ID Algorithm 1195 LB configuration: cr_bits 0x0 length_self_encoding: y sid_len 1 1197 cid 01be sid be su cid 0221b7 sid 21 su b7 cid 03cadfd8 sid ca su 1198 dfd8 cid 041e0c9328 sid 1e su 0c9328 cid 050c8f6d9129 sid 0c su 1199 8f6d9129 1201 LB configuration: cr_bits 0x0 length_self_encoding: n sid_len 2 1203 cid 02aab0 sid aab0 su cid 3ac4b106 sid c4b1 su 06 cid 08bd3cf4a0 sid 1204 bd3c su f4a0 cid 3771d59502d6 sid 71d5 su 9502d6 cid 1d57dee8b888f3 1205 sid 57de su e8b888f3 1207 LB configuration: cr_bits 0x0 length_self_encoding: y sid_len 3 1209 cid 0336c976 sid 36c976 su cid 04aa291806 sid aa2918 su 06 cid 1210 0586897bd8b6 sid 86897b su d8b6 cid 063625bcae4de0 sid 3625bc su 1211 ae4de0 cid 07966fb1f3cb535f sid 966fb1 su f3cb535f 1213 LB configuration: cr_bits 0x0 length_self_encoding: n sid_len 4 1215 cid 185172fab8 sid 5172fab8 su cid 2eb7ff2c9297 sid b7ff2c92 su 97 1216 cid 14f3eb3dd3edbe sid f3eb3dd3 su edbe cid 3feb31cece744b74 sid 1217 eb31cece su 744b74 cid 06b9f34c353ce23bb5 sid b9f34c35 su 3ce23bb5 1219 LB configuration: cr_bits 0x0 length_self_encoding: y sid_len 5 1221 cid 05bdcd8d0b1d sid bdcd8d0b1d su cid 06aee673725a63 sid aee673725a 1222 su 63 cid 07bbf338ddbf37f4 sid bbf338ddbf su 37f4 cid 1223 08fbbca64c26756840 sid fbbca64c26 su 756840 cid 09e7737c495b93894e34 1224 sid e7737c495b su 93894e34 1226 A.2. Stream Cipher Connection ID Algorithm 1228 In each case below, the server is using a plain text nonce value of 1229 zero. 1231 LB configuration: cr_bits 0x0 length_self_encoding: y nonce_len 12 1232 sid_len 1 key 4d9d0fd25a25e7f321ef464e13f9fa3d 1233 cid 0d69fe8ab8293680395ae256e89c sid c5 su cid 1234 0e420d74ed99b985e10f5073f43027 sid d5 su 27 cid 1235 0f380f440c6eefd3142ee776f6c16027 sid 10 su 6027 cid 1236 1020607efbe82049ddbf3a7c3d9d32604d sid 3c su 32604d cid 1237 11e132d12606a1bb0fa17e1caef00ec54c10 sid e3 su 0ec54c10 1239 LB configuration: cr_bits 0x0 length_self_encoding: n nonce_len 12 1240 sid_len 2 key 49e1cec7fd264b1f4af37413baf8ada9 1242 cid 3d3a5e1126414271cc8dc2ec7c8c15 sid f7fe su cid 1243 007042539e7c5f139ac2adfbf54ba748 sid eaf4 su 48 cid 1244 2bc125dd2aed2aafacf59855d99e029217 sid e880 su 9217 cid 1245 3be6728dc082802d9862c6c8e4dda3d984d8 sid 62c6 su d984d8 cid 1246 1afe9c6259ad350fc7bad28e0aeb2e8d4d4742 sid 8502 su 8d4d4742 1248 LB configuration: cr_bits 0x0 length_self_encoding: y nonce_len 14 1249 sid_len 3 key 2c70df0b399bd33a7335523dcdb884ad 1251 cid 11d62e8670565cd30b552edff6782ff5a740 sid d794bb su cid 1252 12c70e481f49363cabd9370d1fd5012c12bca5 sid 2cbd5d su a5 cid 1253 133b95dfd8ad93566782f8424df82458069fc9e9 sid d126cd su c9e9 cid 1254 13ac6ffcd635532ab60370306c7ee572d6b6e795 sid 539e42 su e795 cid 1255 1383ed07a9700777ff450bb39bb9c1981266805c sid 9094dd su 805c 1257 LB configuration: cr_bits 0x0 length_self_encoding: n nonce_len 12 1258 sid_len 4 key 2297b8a95c776cf9c048b76d9dc27019 1260 cid 32873890c3059ca62628089439c44c1f84 sid 7398d8ca su cid 1261 1ff7c7d7b9823954b178636c99a7dc93ac83 sid 9655f091 su 83 cid 1262 31044000a5ebb3bf2fa7629a17f2c78b077c17 sid 8b035fc6 su 7c17 cid 1263 1791bd28c66721e8fea0c6f34fd2d8e663a6ef70 sid 6672e0e2 su a6ef70 cid 1264 3df1d90ad5ccd5f8f475f040e90aeca09ec9839d sid b98b1fff su c9839d 1266 LB configuration: cr_bits 0x0 length_self_encoding: y nonce_len 8 1267 sid_len 5 key 484b2ed942d9f4765e45035da3340423 1269 cid 0da995b7537db605bfd3a38881ae sid 391a7840dc su cid 1270 0ed8d02d55b91d06443540d1bf6e98 sid 10f7f7b284 su 98 cid 1271 0f3f74be6d46a84ccb1fd1ee92cdeaf2 sid 0606918fc0 su eaf2 cid 1272 1045626dbf20e03050837633cc5650f97c sid e505eea637 su 50f97c cid 1273 11bb9a17f691ab446a938427febbeb593eaa sid 99343a2a96 su eb593eaa 1275 A.3. Block Cipher Connection ID Algorithm 1277 LB configuration: cr_bits 0x0 length_self_encoding: y sid_len 1 key 1278 411592e4160268398386af84ea7505d4 1279 cid 10564f7c0df399f6d93bdddb1a03886f25 sid 23 su 1280 05231748a80884ed58007847eb9fd0 cid 10d5c03f9dd765d73b3d8610b244f74d02 1281 sid 15 su 76cd6b6f0d3f0b20fc8e633e3a05f3 cid 1282 108ca55228ab23b92845341344a2f956f2 sid 64 su 1283 65c0ce170a9548717498b537cb8790 cid 10e73f3d034aef2f6f501e3a7693d6270a 1284 sid 07 su f9ad10c84cc1e89a2492221d74e707 cid 1285 101a6ce13d48b14a77ecfd365595ad2582 sid 6c su 1286 76ce4689b0745b956ef71c2608045d 1288 LB configuration: cr_bits 0x0 length_self_encoding: n sid_len 2 key 1289 92ce44aecd636aeeff78da691ef48f77 1291 cid 20aa09bc65ed52b1ccd29feb7ef995d318 sid a52f su 1292 99278b92a86694ff0ecd64bc2f73 cid 30b8dbef657bd78a2f870e93f9485d5211 1293 sid 6c49 su 7381c8657a388b4e9594297afe96 cid 1294 043a8137331eacd2e78383279b202b9a6d sid 4188 su 1295 5ac4b0e0b95f4e7473b49ee2d0dd cid 3ba71ea2bcf0ab95719ab59d3d7fde770d 1296 sid 8ccc su 08728807605db25f2ca88be08e0f cid 1297 37ef1956b4ec354f40dc68336a23d42b31 sid c89d su 1298 5a3ccd1471caa0de221ad6c185c0 1300 LB configuration: cr_bits 0x0 length_self_encoding: y sid_len 3 key 1301 5c49cb9265efe8ae7b1d3886948b0a34 1303 cid 10efcffc161d232d113998a49b1dbc4aa0 sid 0690b3 su 1304 958fc9f38fe61b83881b2c5780 cid 10fc13bdbcb414ba90e391833400c19505 sid 1305 031ac3 su 9a55e1e1904e780346fcc32c3c cid 1306 10d3cc1efaf5dc52c7a0f6da2746a8c714 sid 572d3a su 1307 ff2ec9712664e7174dc03ca3f8 cid 107edf37f6788e33c0ec7758a485215f2b sid 1308 562c25 su 02c5a5dcbea629c3840da5f567 cid 1309 10bc28da122582b7312e65aa096e9724fc sid 2fa4f0 su 1310 8ae8c666bfc0fc364ebfd06b9a 1312 LB configuration: cr_bits 0x0 length_self_encoding: n sid_len 4 key 1313 e787a3a491551fb2b4901a3fa15974f3 1315 cid 26125351da12435615e3be6b16fad35560 sid 0cb227d3 su 1316 65b40b1ab54e05bff55db046 cid 14de05fc84e41b611dfbe99ed5b1c9d563 sid 1317 6a0f23ad su d73bee2f3a7e72b3ffea52d9 cid 1318 1306052c3f973db87de6d7904914840ff1 sid ca21402d su 1319 5829465f7418b56ee6ada431 cid 1d202b5811af3e1dba9ea2950d27879a92 sid 1320 b14e1307 su 4902aba8b23a5f24616df3cf cid 1321 26538b78efc2d418539ad1de13ab73e477 sid a75e0148 su 1322 0040323f1854e75aeb449b9f 1324 LB configuration: cr_bits 0x0 length_self_encoding: y sid_len 5 key 1325 d5a6d7824336fbe0f25d28487cdda57c 1326 cid 10a2794871aadb20ddf274a95249e57fde sid 82d3b0b1a1 su 1327 0935471478c2edb8120e60 cid 108122fe80a6e546a285c475a3b8613ec9 sid 1328 fbcc902c9d su 59c47946882a9a93981c15 cid 1329 104d227ad9dd0fef4c8cb6eb75887b6ccc sid 2808e22642 su 1330 2a7ef40e2c7e17ae40b3fb cid 10b3f367d8627b36990a28d67f50b97846 sid 1331 5e018f0197 su 2289cae06a566e5cb6cfa4 cid 1332 1024412bfe25f4547510204bdda6143814 sid 8a8dd3d036 su 1333 4b12933a135e5eaaebc6fd 1335 Appendix B. Acknowledgments 1337 Appendix C. Change Log 1339 *RFC Editor's Note:* Please remove this section prior to 1340 publication of a final version of this document. 1342 C.1. since draft-ietf-quic-load-balancers-04 1344 * Rearranged the shared-state retry token to simplify token 1345 processing 1347 * More compact timestamp in shared-state retry token 1349 * Revised server requirements for shared-state retries 1351 * Eliminated zero padding from the test vectors 1353 * Added server use bytes to the test vectors 1355 * Additional compliant DCID criteria 1357 C.2. since-draft-ietf-quic-load-balancers-03 1359 * Improved Config Rotation text 1361 * Added stream cipher test vectors 1363 * Deleted the Obfuscated CID algorithm 1365 C.3. since-draft-ietf-quic-load-balancers-02 1367 * Replaced stream cipher algorithm with three-pass version 1369 * Updated Retry format to encode info for required TPs 1371 * Added discussion of version invariance 1373 * Cleaned up text about config rotation 1374 * Added Reset Oracle and limited configuration considerations 1376 * Allow dropped long-header packets for known QUIC versions 1378 C.4. since-draft-ietf-quic-load-balancers-01 1380 * Test vectors for load balancer decoding 1382 * Deleted remnants of in-band protocol 1384 * Light edit of Retry Services section 1386 * Discussed load balancer chains 1388 C.5. since-draft-ietf-quic-load-balancers-00 1390 * Removed in-band protocol from the document 1392 C.6. Since draft-duke-quic-load-balancers-06 1394 * Switch to IETF WG draft. 1396 C.7. Since draft-duke-quic-load-balancers-05 1398 * Editorial changes 1400 * Made load balancer behavior independent of QUIC version 1402 * Got rid of token in stream cipher encoding, because server might 1403 not have it 1405 * Defined "non-compliant DCID" and specified rules for handling 1406 them. 1408 * Added psuedocode for config schema 1410 C.8. Since draft-duke-quic-load-balancers-04 1412 * Added standard for retry services 1414 C.9. Since draft-duke-quic-load-balancers-03 1416 * Renamed Plaintext CID algorithm as Obfuscated CID 1418 * Added new Plaintext CID algorithm 1420 * Updated to allow 20B CIDs 1421 * Added self-encoding of CID length 1423 C.10. Since draft-duke-quic-load-balancers-02 1425 * Added Config Rotation 1427 * Added failover mode 1429 * Tweaks to existing CID algorithms 1431 * Added Block Cipher CID algorithm 1433 * Reformatted QUIC-LB packets 1435 C.11. Since draft-duke-quic-load-balancers-01 1437 * Complete rewrite 1439 * Supports multiple security levels 1441 * Lightweight messages 1443 C.12. Since draft-duke-quic-load-balancers-00 1445 * Converted to markdown 1447 * Added variable length connection IDs 1449 Authors' Addresses 1451 Martin Duke 1452 F5 Networks, Inc. 1454 Email: martin.h.duke@gmail.com 1456 Nick Banks 1457 Microsoft 1459 Email: nibanks@microsoft.com