idnits 2.17.1 draft-ietf-quic-load-balancers-07.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 42 instances of too long lines in the document, the longest one being 22 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (9 July 2021) is 1014 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-12 -- 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 (~~), 4 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: 10 January 2022 Microsoft 6 9 July 2021 8 QUIC-LB: Generating Routable QUIC Connection IDs 9 draft-ietf-quic-load-balancers-07 11 Abstract 13 The QUIC protocol design is resistant to transparent packet 14 inspection, injection, and modification by intermediaries. However, 15 the server can explicitly cooperate with network services by agreeing 16 to certain conventions and/or sharing state with those services. 17 This specification provides a standardized means of solving three 18 problems: (1) maintaining routability to servers via a low-state load 19 balancer even when the connection IDs in use change; (2) explicit 20 encoding of the connection ID length in all packets to assist 21 hardware accelerators; and (3) injection of QUIC Retry packets by an 22 anti-Denial-of-Service agent on behalf of the server. 24 Note to Readers 26 Discussion of this document takes place on the QUIC Working Group 27 mailing list (quic@ietf.org), which is archived at 28 https://mailarchive.ietf.org/arch/browse/quic/ 29 (https://mailarchive.ietf.org/arch/browse/quic/). 31 Source for this draft and an issue tracker can be found at 32 https://github.com/quicwg/load-balancers (https://github.com/quicwg/ 33 load-balancers). 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 10 January 2022. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Simplified BSD License text 62 as described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Protocol Objectives . . . . . . . . . . . . . . . . . . . . . 6 71 2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3. First CID octet . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.1. Config Rotation . . . . . . . . . . . . . . . . . . . . . 7 75 3.2. Configuration Failover . . . . . . . . . . . . . . . . . 8 76 3.3. Length Self-Description . . . . . . . . . . . . . . . . . 8 77 3.4. Format . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 4. Load Balancing Preliminaries . . . . . . . . . . . . . . . . 9 79 4.1. Unroutable Connection IDs . . . . . . . . . . . . . . . . 9 80 4.2. Fallback Algorithms . . . . . . . . . . . . . . . . . . . 10 81 4.3. Server ID Allocation . . . . . . . . . . . . . . . . . . 11 82 4.3.1. Static Allocation . . . . . . . . . . . . . . . . . . 11 83 4.3.2. Dynamic Allocation . . . . . . . . . . . . . . . . . 12 84 5. Routing Algorithms . . . . . . . . . . . . . . . . . . . . . 14 85 5.1. Plaintext CID Algorithm . . . . . . . . . . . . . . . . . 14 86 5.1.1. Configuration Agent Actions . . . . . . . . . . . . . 14 87 5.1.2. Load Balancer Actions . . . . . . . . . . . . . . . . 14 88 5.1.3. Server Actions . . . . . . . . . . . . . . . . . . . 14 89 5.2. Stream Cipher CID Algorithm . . . . . . . . . . . . . . . 15 90 5.2.1. Configuration Agent Actions . . . . . . . . . . . . . 15 91 5.2.2. Load Balancer Actions . . . . . . . . . . . . . . . . 15 92 5.2.3. Server Actions . . . . . . . . . . . . . . . . . . . 17 93 5.3. Block Cipher CID Algorithm . . . . . . . . . . . . . . . 17 94 5.3.1. Configuration Agent Actions . . . . . . . . . . . . . 17 95 5.3.2. Load Balancer Actions . . . . . . . . . . . . . . . . 17 96 5.3.3. Server Actions . . . . . . . . . . . . . . . . . . . 18 98 6. ICMP Processing . . . . . . . . . . . . . . . . . . . . . . . 18 99 7. Retry Service . . . . . . . . . . . . . . . . . . . . . . . . 18 100 7.1. Common Requirements . . . . . . . . . . . . . . . . . . . 19 101 7.1.1. Considerations for Non-Initial Packets . . . . . . . 20 102 7.2. No-Shared-State Retry Service . . . . . . . . . . . . . . 21 103 7.2.1. Configuration Agent Actions . . . . . . . . . . . . . 21 104 7.2.2. Service Requirements . . . . . . . . . . . . . . . . 21 105 7.2.3. Server Requirements . . . . . . . . . . . . . . . . . 23 106 7.3. Shared-State Retry Service . . . . . . . . . . . . . . . 23 107 7.3.1. Token Protection with AEAD . . . . . . . . . . . . . 25 108 7.3.2. Configuration Agent Actions . . . . . . . . . . . . . 26 109 7.3.3. Service Requirements . . . . . . . . . . . . . . . . 26 110 7.3.4. Server Requirements . . . . . . . . . . . . . . . . . 27 111 8. Configuration Requirements . . . . . . . . . . . . . . . . . 28 112 9. Additional Use Cases . . . . . . . . . . . . . . . . . . . . 29 113 9.1. Load balancer chains . . . . . . . . . . . . . . . . . . 29 114 9.2. Moving connections between servers . . . . . . . . . . . 29 115 10. Version Invariance of QUIC-LB . . . . . . . . . . . . . . . . 29 116 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 117 11.1. Attackers not between the load balancer and server . . . 31 118 11.2. Attackers between the load balancer and server . . . . . 31 119 11.3. Multiple Configuration IDs . . . . . . . . . . . . . . . 32 120 11.4. Limited configuration scope . . . . . . . . . . . . . . 32 121 11.5. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 33 122 11.6. Connection ID Entropy . . . . . . . . . . . . . . . . . 33 123 11.7. Shared-State Retry Keys . . . . . . . . . . . . . . . . 33 124 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 125 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 126 13.1. Normative References . . . . . . . . . . . . . . . . . . 34 127 13.2. Informative References . . . . . . . . . . . . . . . . . 35 128 Appendix A. QUIC-LB YANG Model . . . . . . . . . . . . . . . . . 36 129 A.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 41 130 Appendix B. Load Balancer Test Vectors . . . . . . . . . . . . . 42 131 B.1. Plaintext Connection ID Algorithm . . . . . . . . . . . . 43 132 B.2. Stream Cipher Connection ID Algorithm . . . . . . . . . . 44 133 B.3. Block Cipher Connection ID Algorithm . . . . . . . . . . 45 134 B.4. Shared State Retry Tokens . . . . . . . . . . . . . . . . 47 135 Appendix C. Interoperability with DTLS over UDP . . . . . . . . 47 136 C.1. DTLS 1.0 and 1.2 . . . . . . . . . . . . . . . . . . . . 48 137 C.2. DTLS 1.3 . . . . . . . . . . . . . . . . . . . . . . . . 48 138 C.3. Future Versions of DTLS . . . . . . . . . . . . . . . . . 49 139 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 49 140 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 49 141 E.1. since draft-ietf-quic-load-balancers-06 . . . . . . . . . 49 142 E.2. since draft-ietf-quic-load-balancers-05 . . . . . . . . . 50 143 E.3. since draft-ietf-quic-load-balancers-04 . . . . . . . . . 50 144 E.4. since-draft-ietf-quic-load-balancers-03 . . . . . . . . . 50 145 E.5. since-draft-ietf-quic-load-balancers-02 . . . . . . . . . 50 146 E.6. since-draft-ietf-quic-load-balancers-01 . . . . . . . . . 51 147 E.7. since-draft-ietf-quic-load-balancers-00 . . . . . . . . . 51 148 E.8. Since draft-duke-quic-load-balancers-06 . . . . . . . . . 51 149 E.9. Since draft-duke-quic-load-balancers-05 . . . . . . . . . 51 150 E.10. Since draft-duke-quic-load-balancers-04 . . . . . . . . . 51 151 E.11. Since draft-duke-quic-load-balancers-03 . . . . . . . . . 51 152 E.12. Since draft-duke-quic-load-balancers-02 . . . . . . . . . 52 153 E.13. Since draft-duke-quic-load-balancers-01 . . . . . . . . . 52 154 E.14. Since draft-duke-quic-load-balancers-00 . . . . . . . . . 52 155 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 157 1. Introduction 159 QUIC packets [RFC9000] usually contain a connection ID to allow 160 endpoints to associate packets with different address/port 4-tuples 161 to the same connection context. This feature makes connections 162 robust in the event of NAT rebinding. QUIC endpoints usually 163 designate the connection ID which peers use to address packets. 164 Server-generated connection IDs create a potential need for out-of- 165 band communication to support QUIC. 167 QUIC allows servers (or load balancers) to designate an initial 168 connection ID to encode useful routing information for load 169 balancers. It also encourages servers, in packets protected by 170 cryptography, to provide additional connection IDs to the client. 171 This allows clients that know they are going to change IP address or 172 port to use a separate connection ID on the new path, thus reducing 173 linkability as clients move through the world. 175 There is a tension between the requirements to provide routing 176 information and mitigate linkability. Ultimately, because new 177 connection IDs are in protected packets, they must be generated at 178 the server if the load balancer does not have access to the 179 connection keys. However, it is the load balancer that has the 180 context necessary to generate a connection ID that encodes useful 181 routing information. In the absence of any shared state between load 182 balancer and server, the load balancer must maintain a relatively 183 expensive table of server-generated connection IDs, and will not 184 route packets correctly if they use a connection ID that was 185 originally communicated in a protected NEW_CONNECTION_ID frame. 187 This specification provides common algorithms for encoding the server 188 mapping in a connection ID given some shared parameters. The mapping 189 is generally only discoverable by observers that have the parameters, 190 preserving unlinkability as much as possible. 192 Aside from load balancing, a QUIC server may also desire to offload 193 other protocol functions to trusted intermediaries. These 194 intermediaries might include hardware assist on the server host 195 itself, without access to fully decrypted QUIC packets. For example, 196 this document specifies a means of offloading stateless retry to 197 counter Denial of Service attacks. It also proposes a system for 198 self-encoding connection ID length in all packets, so that crypto 199 offload can consistently look up key information. 201 While this document describes a small set of configuration parameters 202 to make the server mapping intelligible, the means of distributing 203 these parameters between load balancers, servers, and other trusted 204 intermediaries is out of its scope. There are numerous well-known 205 infrastructures for distribution of configuration. 207 1.1. Terminology 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in RFC 2119 [RFC2119]. 213 In this document, these words will appear with that interpretation 214 only when in ALL CAPS. Lower case uses of these words are not to be 215 interpreted as carrying significance described in RFC 2119. 217 In this document, "client" and "server" refer to the endpoints of a 218 QUIC connection unless otherwise indicated. A "load balancer" is an 219 intermediary for that connection that does not possess QUIC 220 connection keys, but it may rewrite IP addresses or conduct other IP 221 or UDP processing. A "configuration agent" is the entity that 222 determines the QUIC-LB configuration parameters for the network and 223 leverages some system to distribute that configuration. 225 Note that stateful load balancers that act as proxies, by terminating 226 a QUIC connection with the client and then retrieving data from the 227 server using QUIC or another protocol, are treated as a server with 228 respect to this specification. 230 For brevity, "Connection ID" will often be abbreviated as "CID". 232 1.2. Notation 234 All wire formats will be depicted using the notation defined in 235 Section 1.3 of [RFC9000]. There is one addition: the function len() 236 refers to the length of a field which can serve as a limit on a 237 different field, so that the lengths of two fields can be concisely 238 defined as limited to a sum, for example: 240 x(A..B) y(C..B-len(x)) 242 indicates that x can be of any length between A and B, and y can be 243 of any length between C and B provided that (len(x) + len(y)) does 244 not exceed B. 246 The example below illustrates the basic framework: 248 Example Structure { 249 One-bit Field (1), 250 7-bit Field with Fixed Value (7) = 61, 251 Field with Variable-Length Integer (i), 252 Arbitrary-Length Field (..), 253 Variable-Length Field (8..24), 254 Variable-Length Field with Dynamic Limit (8..24-len(Variable-Length Field)), 255 Field With Minimum Length (16..), 256 Field With Maximum Length (..128), 257 [Optional Field (64)], 258 Repeated Field (8) ..., 259 } 261 Figure 1: Example Format 263 2. Protocol Objectives 265 2.1. Simplicity 267 QUIC is intended to provide unlinkability across connection 268 migration, but servers are not required to provide additional 269 connection IDs that effectively prevent linkability. If the 270 coordination scheme is too difficult to implement, servers behind 271 load balancers using connection IDs for routing will use trivially 272 linkable connection IDs. Clients will therefore be forced to choose 273 between terminating the connection during migration or remaining 274 linkable, subverting a design objective of QUIC. 276 The solution should be both simple to implement and require little 277 additional infrastructure for cryptographic keys, etc. 279 2.2. Security 281 In the limit where there are very few connections to a pool of 282 servers, no scheme can prevent the linking of two connection IDs with 283 high probability. In the opposite limit, where all servers have many 284 connections that start and end frequently, it will be difficult to 285 associate two connection IDs even if they are known to map to the 286 same server. 288 QUIC-LB is relevant in the region between these extremes: when the 289 information that two connection IDs map to the same server is helpful 290 to linking two connection IDs. Obviously, any scheme that 291 transparently communicates this mapping to outside observers 292 compromises QUIC's defenses against linkability. 294 Though not an explicit goal of the QUIC-LB design, concealing the 295 server mapping also complicates attempts to focus attacks on a 296 specific server in the pool. 298 3. First CID octet 300 The first octet of a Connection ID is reserved for two special 301 purposes, one mandatory (config rotation) and one optional (length 302 self-description). 304 Subsequent sections of this document refer to the contents of this 305 octet as the "first octet." 307 3.1. Config Rotation 309 The first two bits of any connection ID MUST encode an identifier for 310 the configuration that the connection ID uses. This enables 311 incremental deployment of new QUIC-LB settings (e.g., keys). 313 When new configuration is distributed to servers, there will be a 314 transition period when connection IDs reflecting old and new 315 configuration coexist in the network. The rotation bits allow load 316 balancers to apply the correct routing algorithm and parameters to 317 incoming packets. 319 Configuration Agents SHOULD deliver new configurations to load 320 balancers before doing so to servers, so that load balancers are 321 ready to process CIDs using the new parameters when they arrive. 323 A Configuration Agent SHOULD NOT use a codepoint to represent a new 324 configuration until it takes precautions to make sure that all 325 connections using CIDs with an old configuration at that codepoint 326 have closed or transitioned. 328 Servers MUST NOT generate new connection IDs using an old 329 configuration after receiving a new one from the configuration agent. 330 Servers MUST send NEW_CONNECTION_ID frames that provide CIDs using 331 the new configuration, and retire CIDs using the old configuration 332 using the "Retire Prior To" field of that frame. 334 It also possible to use these bits for more long-lived distinction of 335 different configurations, but this has privacy implications (see 336 Section 11.3). 338 3.2. Configuration Failover 340 If a server has not received a valid QUIC-LB configuration, and 341 believes that low-state, Connection-ID aware load balancers are in 342 the path, it SHOULD generate connection IDs with the config rotation 343 bits set to '11' and SHOULD use the "disable_active_migration" 344 transport parameter in all new QUIC connections. It SHOULD NOT send 345 NEW_CONNECTION_ID frames with new values. 347 A load balancer that sees a connection ID with config rotation bits 348 set to '11' MUST revert to 5-tuple routing. 350 3.3. Length Self-Description 352 Local hardware cryptographic offload devices may accelerate QUIC 353 servers by receiving keys from the QUIC implementation indexed to the 354 connection ID. However, on physical devices operating multiple QUIC 355 servers, it is impractical to efficiently lookup these keys if the 356 connection ID does not self-encode its own length. 358 Note that this is a function of particular server devices and is 359 irrelevant to load balancers. As such, load balancers MAY omit this 360 from their configuration. However, the remaining 6 bits in the first 361 octet of the Connection ID are reserved to express the length of the 362 following connection ID, not including the first octet. 364 A server not using this functionality SHOULD make the six bits appear 365 to be random. 367 3.4. Format 369 First Octet { 370 Config Rotation (2), 371 CID Len or Random Bits (6), 372 } 374 Figure 2: First Octet Format 376 The first octet has the following fields: 378 Config Rotation: Indicates the configuration used to interpret the 379 CID. 381 CID Len or Random Bits: Length Self-Description (if applicable), or 382 random bits otherwise. Encodes the length of the Connection ID 383 following the First Octet. 385 4. Load Balancing Preliminaries 387 In QUIC-LB, load balancers do not generate individual connection IDs 388 for servers. Instead, they communicate the parameters of an 389 algorithm to generate routable connection IDs. 391 The algorithms differ in the complexity of configuration at both load 392 balancer and server. Increasing complexity improves obfuscation of 393 the server mapping. 395 This section describes three participants: the configuration agent, 396 the load balancer, and the server. For any given QUIC-LB 397 configuration that enables connection-ID-aware load balancing, there 398 must be a choice of (1) routing algorithm, (2) server ID allocation 399 strategy, and (3) algorithm parameters. 401 Fundamentally, servers generate connection IDs that encode their 402 server ID. Load balancers decode the server ID from the CID in 403 incoming packets to route to the correct server. 405 There are situations where a server pool might be operating two or 406 more routing algorithms or parameter sets simultaneously. The load 407 balancer uses the first two bits of the connection ID to multiplex 408 incoming DCIDs over these schemes (see Section 3.1). 410 4.1. Unroutable Connection IDs 412 QUIC-LB servers will generate Connection IDs that are decodable to 413 extract a server ID in accordance with a specified algorithm and 414 parameters. However, QUIC often uses client-generated Connection IDs 415 prior to receiving a packet from the server. 417 These client-generated CIDs might not conform to the expectations of 418 the routing algorithm and therefore not be routable by the load 419 balancer. Those that are not routable are "unroutable DCIDs" and 420 receive similar treatment regardless of why they're unroutable: 422 * The config rotation bits (Section 3.1) may not correspond to an 423 active configuration. Note: a packet with a DCID that indicates 424 5-tuple routing (see Section 3.2) is always routable. 426 * The DCID might not be long enough for the decoder to process. 428 * The extracted server mapping might not correspond to an active 429 server. 431 All other DCIDs are routable. 433 Load balancers MUST forward packets with routable DCIDs to a server 434 in accordance with the chosen routing algorithm. 436 Load balancers SHOULD drop short header packets with unroutable 437 DCIDs. 439 The routing of long headers with unroutable DCIDs depends on the 440 server ID allocation strategy, described in Section 4.3. However, 441 the load balancer MUST NOT drop these packets, with one exception. 443 Load balancers MAY drop packets with long headers and unroutable 444 DCIDs if and only if it knows that the encoded QUIC version does not 445 allow an unroutable DCID in a packet with that signature. For 446 example, a load balancer can safely drop a QUIC version 1 Handshake 447 packet with an unroutable DCID, as a version 1 Handshake packet sent 448 to a QUIC-LB routable server will always have a server-generated 449 routable CID. The prohibition against dropping packets with long 450 headers remains for unknown QUIC versions. 452 Furthermore, while the load balancer function MUST NOT drop packets, 453 the device might implement other security policies, outside the scope 454 of this specification, that might force a drop. 456 Servers that receive packets with unroutable CIDs MUST use the 457 available mechanisms to induce the client to use a routable CID in 458 future packets. In QUIC version 1, this requires using a routable 459 CID in the Source CID field of server-generated long headers. 461 4.2. Fallback Algorithms 463 There are conditions described below where a load balancer routes a 464 packet using a "fallback algorithm." It can choose any algorithm, 465 without coordination with the servers, but the algorithm SHOULD be 466 deterministic over short time scales so that related packets go to 467 the same server. The design of this algorithm SHOULD consider the 468 version-invariant properties of QUIC described in [RFC8999] to 469 maximize its robustness to future versions of QUIC. 471 A fallback algorithm MUST NOT make the routing behavior dependent on 472 any bits in the first octet of the QUIC packet header, except the 473 first bit, which indicates a long header. All other bits are QUIC 474 version-dependent and intermediaries SHOULD NOT base their design on 475 version-specific templates. 477 For example, one fallback algorithm might convert a unroutable DCID 478 to an integer and divided by the number of servers, with the modulus 479 used to forward the packet. The number of servers is usually 480 consistent on the time scale of a QUIC connection handshake. Another 481 might simply hash the address/port 4-tuple. See also Section 10. 483 4.3. Server ID Allocation 485 For any given configuration, the configuration agent must specify if 486 server IDs will be statically or dynamically allocated. Load 487 Balancer configurations with statically allocated server IDs 488 explicitly include a mapping of server IDs to forwarding addresses. 489 The corresponding server configurations contain one or more unique 490 server IDs. 492 A dynamically allocated configuration does not have a pre-defined 493 assignment, reducing configuration complexity. However, it places 494 limits on the maximum server ID length and requires more state at the 495 load balancer. In certain edge cases, it can force parts of the 496 system to fail over to 5-tuple routing for a short time. 498 In either case, the configuration agent chooses a server ID length 499 for each configuration that MUST be at least one octet. For Static 500 Allocation, the maximum length depends on the algorithm. For dynamic 501 allocation, the maximum length is 7 octets. 503 A QUIC-LB configuration MAY significantly over-provision the server 504 ID space (i.e., provide far more codepoints than there are servers) 505 to increase the probability that a randomly generated Destination 506 Connection ID is unroutable. 508 Conceptually, each configuration has its own set of server ID 509 allocations, though two static configurations with identical server 510 ID lengths MAY use a common allocation between them. 512 A server encodes one of its assigned server IDs in any CID it 513 generates using the relevant configuration. 515 4.3.1. Static Allocation 517 In the static allocation method, the configuration agent assigns at 518 least one server ID to each server. 520 When forwarding a packet with a long header and unroutable DCID, load 521 balancers MUST forward packets with long headers and unroutable DCIDs 522 using an fallback algorithm as specified in Section 4.2. 524 4.3.2. Dynamic Allocation 526 In the dynamic allocation method, the load balancer assigns server 527 IDs dynamically so that configuration does not require fixed server 528 ID assignment. This reduces linkability. However, it requires state 529 at the load balancer that roughly scales with the number of 530 connections, until the server ID codespace is exhausted. 532 4.3.2.1. Configuration Agent Actions 534 The configuration agent does not assign server IDs, but does 535 configure a server ID length and an "LB timeout". The server ID MUST 536 be at least one and no more than seven octets. 538 4.3.2.2. Load Balancer Actions 540 The load balancer maintains a table of all assigned server IDs and 541 corresponding routing information, which is initialized empty. These 542 tables are independent for each operating configuration. 544 The load balancer MUST keep track of the most recent observation of 545 each server ID, in any sort of packet it forwards, in the table and 546 delete the entries when the time since that observation exceeds the 547 LB Timeout. 549 Note that when the load balancer's table for a configuration is 550 empty, all incoming DCIDs corresponding to that configuration are 551 unroutable by definition. 553 The handling of an unroutable long-header packet depends on the 554 reason for unroutability. The load balancer MUST applyt this logic: 556 * If the config rotation bits do not match a known configuration, 557 the load balancer routes the packet using a fallback algorithm 558 (see Section 4.2). 560 * If there is a matching configuration, but the CID is not long 561 enough to apply the algorithm, the load balancer skips the first 562 octet of the CID and then reads a server ID from the following 563 octets, up to the server ID length. If this server ID matches a 564 known server ID for that configuration, it forwards the packet 565 accordingly and takes no further action. If it does not match, it 566 routes using a fallback algorithm and adds the new server ID to 567 that server's table entry. 569 * If the sole reason for unroutability is that the server ID is not 570 in the load balancer's table, the load balancer routes the packet 571 with a fallback algorithm. It adds the decoded server ID to table 572 entry for the server the algorithm chooses and forwards the packet 573 accordingly. 575 4.3.2.3. Server actions 577 Each server maintains a list of server IDs assigned to it, 578 initialized empty. For each SID, it records the last time it 579 received any packet with an CID that encoded that SID. 581 Upon receipt of a packet with a client-generated DCID, the server 582 MUST follow these steps in order: 584 * If the config rotation bits do not correspond to a known 585 configuration, do not attempt to extract a server ID. 587 * If the DCID is not long enough to decode using the configured 588 algorithm, extract a number of octets equal to the server ID 589 length, beginning with the second octet. If the extracted value 590 does not match a server ID in the server's list, add it to the 591 list. 593 * If the DCID is long enough to decode but the server ID is not in 594 the server's list, add it to the list. 596 After any possible SID is extracted, the server processes the packet 597 normally. 599 When a server needs a new connection ID, it uses one of the server 600 IDs in its list to populate the server ID field of that CID. It 601 SHOULD vary this selection to reduce linkability within a connection. 603 After loading a new configuration or long periods of idleness, a 604 server may not have any available SIDs. This is because an incoming 605 packet may not the config rotation bits necessary to extract a server 606 ID in accordance with the algorithm above. When required to generate 607 a CID under these conditions, the server MUST generate CIDs using the 608 5-tuple routing codepoint (see Section 3.2. Note that these 609 connections will not be robust to client address changes while they 610 use this connection ID. For this reason, a server SHOULD retire 611 these connection IDs and replace them with routable ones once it 612 receives a client-generated CID that allows it to acquire a server 613 ID. As, statistically, one in every four such CIDs can provide a 614 server ID, this is typically a short interval. 616 If a server has not received a connection ID encoding a particular 617 server ID within the LB timeout, it MUST retire any outstanding CIDs 618 that use that server ID and cease generating any new ones. 620 A server SHOULD have a mechanism to stop using some server IDs if the 621 list gets large relative to its share of the codepoint space, so that 622 these allocations time out and are freed for reuse by servers that 623 have recently joined the pool. 625 5. Routing Algorithms 627 Encryption in the algorithms below uses the AES-128-ECB cipher. 628 Future standards could add new algorithms that use other ciphers to 629 provide cryptographic agility in accordance with [RFC7696]. QUIC-LB 630 implementations SHOULD be extensible to support new algorithms. 632 5.1. Plaintext CID Algorithm 634 The Plaintext CID Algorithm makes no attempt to obscure the mapping 635 of connections to servers, significantly increasing linkability. The 636 format is depicted in the figure below. 638 Plaintext CID { 639 First Octet (8), 640 Server ID (8..128), 641 For Server Use (8..152-len(Server ID)), 642 } 644 Figure 3: Plaintext CID Format 646 5.1.1. Configuration Agent Actions 648 For static SID allocation, the server ID length is limited to 16 649 octets. There are no parameters specific to this algorithm. 651 5.1.2. Load Balancer Actions 653 On each incoming packet, the load balancer extracts consecutive 654 octets, beginning with the second octet. These bytes represent the 655 server ID. 657 5.1.3. Server Actions 659 The server chooses how many octets to reserve for its own use, which 660 MUST be at least one octet. 662 When a server needs a new connection ID, it encodes one of its 663 assigned server IDs in consecutive octets beginning with the second. 664 All other bits in the connection ID, except for the first octet, MAY 665 be set to any other value. These other bits SHOULD appear random to 666 observers. 668 5.2. Stream Cipher CID Algorithm 670 The Stream Cipher CID algorithm provides cryptographic protection at 671 the cost of additional per-packet processing at the load balancer to 672 decrypt every incoming connection ID. The CID format is depicted 673 below. 675 Stream Cipher CID { 676 First Octet (8), 677 Nonce (64..120), 678 Encrypted Server ID (8..128-len(Nonce)), 679 For Server Use (0..152-len(Nonce)-len(Encrypted Server ID)), 680 } 682 Figure 4: Stream Cipher CID Format 684 5.2.1. Configuration Agent Actions 686 The configuration agent assigns a server ID to every server in its 687 pool, and determines a server ID length (in octets) sufficiently 688 large to encode all server IDs, including potential future servers. 690 The configuration agent also selects a nonce length and an 16-octet 691 AES-ECB key to use for connection ID decryption. The nonce length 692 MUST be at least 8 octets and no more than 16 octets. The nonce 693 length and server ID length MUST sum to 19 or fewer octets, but 694 SHOULD sum to 15 or fewer to allow space for server use. 696 5.2.2. Load Balancer Actions 698 Upon receipt of a QUIC packet, the load balancer extracts as many of 699 the earliest octets from the destination connection ID as necessary 700 to match the nonce length. The server ID immediately follows. 702 The load balancer decrypts the nonce and the server ID using the 703 following three pass algorithm: 705 * Pass 1: The load balancer decrypts the server ID using 128-bit AES 706 Electronic Codebook (ECB) mode, much like QUIC header protection. 707 The encrypted nonce octets are zero-padded to 16 octets. AES-ECB 708 encrypts this encrypted nonce using its key to generate a mask 709 which it applies to the encrypted server id. This provides an 710 intermediate value of the server ID, referred to as server-id 711 intermediate. 713 server_id_intermediate = encrypted_server_id ^ AES-ECB(key, padded- 714 encrypted-nonce) 716 * Pass 2: The load balancer decrypts the nonce octets using 128-bit 717 AES ECB mode, using the server-id intermediate as "nonce" for this 718 pass. The server-id intermediate octets are zero-padded to 16 719 octets. AES-ECB encrypts this padded server-id intermediate using 720 its key to generate a mask which it applies to the encrypted 721 nonce. This provides the decrypted nonce value. 723 nonce = encrypted_nonce ^ AES-ECB(key, padded-server_id_intermediate) 725 * Pass 3: The load balancer decrypts the server ID using 128-bit AES 726 ECB mode. The nonce octets are zero-padded to 16 octets. AES-ECB 727 encrypts this nonce using its key to generate a mask which it 728 applies to the intermediate server id. This provides the 729 decrypted server ID. 731 server_id = server_id_intermediate ^ AES-ECB(key, padded-nonce) 733 For example, if the nonce length is 10 octets and the server ID 734 length is 2 octets, the connection ID can be as small as 13 octets. 735 The load balancer uses the the second through eleventh octets of the 736 connection ID for the nonce, zero-pads it to 16 octets, uses xors the 737 result with the twelfth and thirteenth octet. The result is padded 738 with 14 octets of zeros and encrypted to obtain a mask that is xored 739 with the nonce octets. Finally, the nonce octets are padded with six 740 octets of zeros, encrypted, and the first two octets xored with the 741 server ID octets to obtain the actual server ID. 743 This three-pass algorithm is a simplified version of the FFX 744 algorithm, with the property that each encrypted nonce value depends 745 on all server ID bits, and each encrypted server ID bit depends on 746 all nonce bits and all server ID bits. This mitigates attacks 747 against stream ciphers in which attackers simply flip encrypted 748 server-ID bits. 750 The output of the decryption is the server ID that the load balancer 751 uses for routing. 753 5.2.3. Server Actions 755 When generating a routable connection ID, the server writes arbitrary 756 bits into its nonce octets, and its provided server ID into the 757 server ID octets. Servers MAY opt to have a longer connection ID 758 beyond the nonce and server ID. The additional bits MAY encode 759 additional information, but SHOULD appear essentially random to 760 observers. 762 If the decrypted nonce bits increase monotonically, that guarantees 763 that nonces are not reused between connection IDs from the same 764 server. 766 The server encrypts the server ID using exactly the algorithm as 767 described in Section 5.2.2, performing the three passes in reverse 768 order. 770 5.3. Block Cipher CID Algorithm 772 The Block Cipher CID Algorithm, by using a full 16 octets of 773 plaintext and a 128-bit cipher, provides higher cryptographic 774 protection and detection of unroutable connection IDs. However, it 775 also requires connection IDs of at least 17 octets, increasing 776 overhead of client-to-server packets. 778 Block Cipher CID { 779 First Octet (8), 780 Encrypted Server ID (8..128), 781 Encrypted Bits for Server Use (128-len(Encrypted Server ID)), 782 Unencrypted Bits for Server Use (0..24), 783 } 785 Figure 5: Block Cipher CID Format 787 5.3.1. Configuration Agent Actions 789 If server IDs are statically allocated, the server ID length MUST be 790 no more than 12 octets, to provide servers adequate entropy to 791 generate unique CIDs. 793 The configuration agent also selects an 16-octet AES-ECB key to use 794 for connection ID decryption. 796 5.3.2. Load Balancer Actions 798 Upon receipt of a QUIC packet, the load balancer reads the first 799 octet to obtain the config rotation bits. It then decrypts the 800 subsequent 16 octets using AES-ECB decryption and the chosen key. 802 The decrypted plaintext contains the server id and opaque server data 803 in that order. The load balancer uses the server ID octets for 804 routing. 806 5.3.3. Server Actions 808 When generating a routable connection ID, the server MUST choose a 809 connection ID length between 17 and 20 octets. The server writes its 810 server ID into the server ID octets and arbitrary bits into the 811 remaining bits. These arbitrary bits MAY encode additional 812 information, and MUST differ between connection IDs. Bits in the 813 eighteenth, nineteenth, and twentieth octets SHOULD appear 814 essentially random to observers. The first octet is reserved as 815 described in Section 3. 817 The server then encrypts the second through seventeenth octets using 818 the 128-bit AES-ECB cipher. 820 6. ICMP Processing 822 For protocols where 4-tuple load balancing is sufficient, it is 823 straightforward to deliver ICMP packets from the network to the 824 correct server, by reading the echoed IP and transport-layer headers 825 to obtain the 4-tuple. When routing is based on connection ID, 826 further measures are required, as most QUIC packets that trigger ICMP 827 responses will only contain a client-generated connection ID that 828 contains no routing information. 830 To solve this problem, load balancers MAY maintain a mapping of 831 Client IP and port to server ID based on recently observed packets. 833 Alternatively, servers MAY implement the technique described in 834 Section 14.4.1 of [RFC9000] to increase the likelihood a Source 835 Connection ID is included in ICMP responses to Path Maximum 836 Transmission Unit (PMTU) probes. Load balancers MAY parse the echoed 837 packet to extract the Source Connection ID, if it contains a QUIC 838 long header, and extract the Server ID as if it were in a Destination 839 CID. 841 7. Retry Service 843 When a server is under load, QUICv1 allows it to defer storage of 844 connection state until the client proves it can receive packets at 845 its advertised IP address. Through the use of a Retry packet, a 846 token in subsequent client Initial packets, and transport parameters, 847 servers verify address ownership and clients verify that there is no 848 on-path attacker generating Retry packets. 850 A "Retry Service" detects potential Denial of Service attacks and 851 handles sending of Retry packets on behalf of the server. As it is, 852 by definition, literally an on-path entity, the service must 853 communicate some of the original connection IDs back to the server so 854 that it can pass client verification. It also must either verify the 855 address itself (with the server trusting this verification) or make 856 sure there is common context for the server to verify the address 857 using a service-generated token. 859 There are two different mechanisms to allow offload of DoS mitigation 860 to a trusted network service. One requires no shared state; the 861 server need only be configured to trust a retry service, though this 862 imposes other operational constraints. The other requires a shared 863 key, but has no such constraints. 865 7.1. Common Requirements 867 Regardless of mechanism, a retry service has an active mode, where it 868 is generating Retry packets, and an inactive mode, where it is not, 869 based on its assessment of server load and the likelihood an attack 870 is underway. The choice of mode MAY be made on a per-packet or per- 871 connection basis, through a stochastic process or based on client 872 address. 874 A configuration agent MUST distribute a list of QUIC versions the 875 Retry Service supports. It MAY also distribute either an "Allow- 876 List" or a "Deny-List" of other QUIC versions. It MUST NOT 877 distribute both an Allow-List and a Deny-List. 879 The Allow-List or Deny-List MUST NOT include any versions included 880 for Retry Service Support. 882 The Configuration Agent MUST provide a means for the entity that 883 controls the Retry Service to report its supported version(s) to the 884 configuration Agent. If the entity has not reported this 885 information, it MUST NOT activate the Retry Service and the 886 configuration agent MUST NOT distribute configuration that activates 887 it. 889 The configuration agent MAY delete versions from the final supported 890 version list if policy does not require the Retry Service to operate 891 on those versions. 893 The configuration Agent MUST provide a means for the entities that 894 control servers behind the Retry Service to report either an Allow- 895 List or a Deny-List. 897 If all entities supply Allow-Lists, the consolidated list MUST be the 898 union of these sets. If all entities supply Deny-Lists, the 899 consolidated list MUST be the intersection of these sets. 901 If entities provide a mixture of Allow-Lists and Deny-Lists, the 902 consolidated list MUST be a Deny-List that is the intersection of all 903 provided Deny-Lists and the inverses of all Allow-Lists. 905 If no entities that control servers have reported Allow-Lists or 906 Deny-Lists, the default is a Deny-List with the null set (i.e., all 907 unsupported versions will be admitted). This preserves the future 908 extensibilty of QUIC. 910 A retry service MUST forward all packets for a QUIC version it does 911 not support that are not on a Deny-List or absent from an Allow-List. 912 Note that if servers support versions the retry service does not, 913 this may increase load on the servers. 915 Note that future versions of QUIC might not have Retry packets, 916 require different information in Retry, or use different packet type 917 indicators. 919 7.1.1. Considerations for Non-Initial Packets 921 Initial Packets are especially effective at consuming server 922 resources because they cause the server to create connection state. 923 Even when mitigating this load with Retry Packets, the act of 924 validating an Initial Token and sending a Retry Packet is more 925 expensive than the response to a non-Initial packet with an unknown 926 Connection ID: simply dropping it and/or sending a Stateless Reset. 928 Nevertheless, a Retry Service in Active Mode might desire to shield 929 servers from non-Initial packets that do not correspond to a 930 previously admitted Initial Packet. This has a number of 931 considerations. 933 * If a Retry Service maintains no per-flow state whatsoever, it 934 cannot distinguish between valid and invalid non-Initial packets 935 and MUST forward all non-Initial Packets to the server. 937 * For QUIC versions the Retry Service does not support and are 938 present on the Allow-List (or absent from the Deny-List), the 939 Retry Service cannot distinguish Initial Packets from other long 940 headers and therefore MUST admit all long headers. 942 * If a Retry Service keeps per-flow state, it can identify 4-tuples 943 that have been previously approved, admit non-Initial packets from 944 those flows, and drop all others. However, dropping short headers 945 will effectively break Address Migration and NAT Rebinding when in 946 Active Mode, as post-migration packets will arrive with a 947 previously unknown 4-tuple. This policy will also break 948 connection attempts using any new QUIC versions that begin 949 connections with a short header. 951 * If a Retry Service is integrated with a QUIC-LB routable load 952 balancer, it can verify that the Destination Connection ID is 953 routable, and only admit non-Initial packets with routable DCIDs. 954 As the Connection ID encoding is invariant across QUIC versions, 955 the Retry Service can do this for all short headers. 957 Nothing in this section prevents Retry Services from making basic 958 syntax correctness checks on packets with QUIC versions that it 959 understands (e.g., enforcing the Initial Packet datagram size minimum 960 in version 1) and dropping packets that are not routable with the 961 QUIC specification. 963 7.2. No-Shared-State Retry Service 965 The no-shared-state retry service requires no coordination, except 966 that the server must be configured to accept this service and know 967 which QUIC versions the retry service supports. The scheme uses the 968 first bit of the token to distinguish between tokens from Retry 969 packets (codepoint '0') and tokens from NEW_TOKEN frames (codepoint 970 '1'). 972 7.2.1. Configuration Agent Actions 974 See Section 7.1. 976 7.2.2. Service Requirements 978 A no-shared-state retry service MUST be present on all paths from 979 potential clients to the server. These paths MUST fail to pass QUIC 980 traffic should the service fail for any reason. That is, if the 981 service is not operational, the server MUST NOT be exposed to client 982 traffic. Otherwise, servers that have already disabled their Retry 983 capability would be vulnerable to attack. 985 The path between service and server MUST be free of any potential 986 attackers. Note that this and other requirements above severely 987 restrict the operational conditions in which a no-shared-state retry 988 service can safely operate. 990 Retry tokens generated by the service MUST have the format below. 992 Non-Shared-State Retry Service Token { 993 Token Type (1) = 0, 994 ODCIL (7) = 8..20, 995 RSCIL (8) = 0..20, 996 Original Destination Connection ID (64..160), 997 Retry Source Connection ID (0..160), 998 Opaque Data (..), 999 } 1001 Figure 6: Format of non-shared-state retry service tokens 1003 The first bit of retry tokens generated by the service MUST be zero. 1004 The token has the following additional fields: 1006 ODCIL: The length of the original destination connection ID from the 1007 triggering Initial packet. This is in cleartext to be readable for 1008 the server, but authenticated later in the token. The Retry Service 1009 SHOULD reject any token in which the value is less than 8. 1011 RSCIL: The retry source connection ID length. 1013 Original Destination Connection ID: This also in cleartext and 1014 authenticated later. 1016 Retry Source Connection ID: This also in cleartext and authenticated 1017 later. 1019 Opaque Data: This data MUST contain encrypted information that allows 1020 the retry service to validate the client's IP address, in accordance 1021 with the QUIC specification. It MUST also provide a 1022 cryptographically secure means to validate the integrity of the 1023 entire token. 1025 Upon receipt of an Initial packet with a token that begins with '0', 1026 the retry service MUST validate the token in accordance with the QUIC 1027 specification. 1029 In active mode, the service MUST issue Retry packets for all Client 1030 initial packets that contain no token, or a token that has the first 1031 bit set to '1'. It MUST NOT forward the packet to the server. The 1032 service MUST validate all tokens with the first bit set to '0'. If 1033 successful, the service MUST forward the packet with the token 1034 intact. If unsuccessful, it MUST drop the packet. The Retry Service 1035 MAY send an Initial Packet containing a CONNECTION_CLOSE frame with 1036 the INVALID_TOKEN error code when dropping the packet. 1038 Note that this scheme has a performance drawback. When the retry 1039 service is in active mode, clients with a token from a NEW_TOKEN 1040 frame will suffer a 1-RTT penalty even though its token provides 1041 proof of address. 1043 In inactive mode, the service MUST forward all packets that have no 1044 token or a token with the first bit set to '1'. It MUST validate all 1045 tokens with the first bit set to '0'. If successful, the service 1046 MUST forward the packet with the token intact. If unsuccessful, it 1047 MUST either drop the packet or forward it with the token removed. 1048 The latter requires decryption and re-encryption of the entire 1049 Initial packet to avoid authentication failure. Forwarding the 1050 packet causes the server to respond without the 1051 original_destination_connection_id transport parameter, which 1052 preserves the normal QUIC signal to the client that there is an on- 1053 path attacker. 1055 7.2.3. Server Requirements 1057 A server behind a non-shared-state retry service MUST NOT send Retry 1058 packets for a QUIC version the retry service understands. It MAY 1059 send Retry for QUIC versions the Retry Service does not understand. 1061 Tokens sent in NEW_TOKEN frames MUST have the first bit set to '1'. 1063 If a server receives an Initial Packet with the first bit set to '1', 1064 it could be from a server-generated NEW_TOKEN frame and should be 1065 processed in accordance with the QUIC specification. If a server 1066 receives an Initial Packet with the first bit to '0', it is a Retry 1067 token and the server MUST NOT attempt to validate it. Instead, it 1068 MUST assume the address is validated and MUST extract the Original 1069 Destination Connection ID and Retry Source Connection ID, assuming 1070 the format described in Section 7.2.2. 1072 7.3. Shared-State Retry Service 1074 A shared-state retry service uses a shared key, so that the server 1075 can decode the service's retry tokens. It does not require that all 1076 traffic pass through the Retry service, so servers MAY send Retry 1077 packets in response to Initial packets that don't include a valid 1078 token. 1080 Both server and service must have time synchronized with respect to 1081 one another to prevent tokens being incorrectly marked as expired, 1082 though tight synchronization is unnecessary. 1084 The tokens are protected using AES128-GCM AEAD, as explained in 1085 Section 7.3.1. All tokens, generated by either the server or retry 1086 service, MUST use the following format, which includes: 1088 * A 96 bit unique token number transmitted in clear text, but 1089 protected as part of the AEAD associated data. 1091 * An 8 bit token key identifier. 1093 * A token body, encoding the Original Destination Connection ID, the 1094 Retry Source Connection ID, and the Timestamp, optionally followed 1095 by server specific Opaque Data. 1097 The token protection uses an 128 bit representation of the source IP 1098 address from the triggering Initial packet. The client IP address is 1099 16 octets. If an IPv4 address, the last 12 octets are zeroes. 1101 If there is a Network Address Translator (NAT) in the server 1102 infrastructure that changes the client IP, the Retry Service MUST 1103 either be positioned behind the NAT, or the NAT must have the token 1104 key to rewrite the Retry token accordingly. Note also that a host 1105 that obtains a token through a NAT and then attempts to connect over 1106 a path that does not have an identically configured NAT will fail 1107 address validation. 1109 The 96 bit unique token number is set to a random value using a 1110 cryptography-grade random number generator. 1112 The token key identifier and the corresponding AEAD key and AEAD IV 1113 are provisioned by the configuration agent. 1115 The token body is encoded as follows: 1117 Shared-State Retry Service Token Body { 1118 ODCIL (8) = 0..20, 1119 RSCIL (8) = 0..20, 1120 [Port (16)], 1121 Original Destination Connection ID (0..160), 1122 Retry Source Connection ID (0..160), 1123 Timestamp (64), 1124 Opaque Data (..), 1125 } 1127 Figure 7: Body of shared-state retry service tokens 1129 The token body has the following fields: 1131 ODCIL: The original destination connection ID length. Tokens in 1132 NEW_TOKEN frames MUST set this field to zero. 1134 RSCIL: The retry source connection ID length. Tokens in NEW_TOKEN 1135 frames MUST set this field to zero. 1137 Port: The Source Port of the UDP datagram that triggered the Retry 1138 packet. This field MUST be present if and only if the ODCIL is 1139 greater than zero. This field is therefore always absent in tokens 1140 in NEW_TOKEN frames. 1142 Original Destination Connection ID: The server or Retry Service 1143 copies this from the field in the client Initial packet. 1145 Retry Source Connection ID: The server or Retry service copies this 1146 from the Source Connection ID of the Retry packet. 1148 Timestamp: The Timestamp is a 64-bit integer, in network order, that 1149 expresses the expiration time of the token as a number of seconds in 1150 POSIX time (see Sec. 4.16 of [TIME_T]). 1152 Opaque Data: The server may use this field to encode additional 1153 information, such as congestion window, RTT, or MTU. The Retry 1154 Service MUST have zero-length opaque data. 1156 Some implementations of QUIC encode in the token the Initial Packet 1157 Number used by the client, in order to verify that the client sends 1158 the retried Initial with a PN larger that the triggering Initial. 1159 Such implementations will encode the Initial Packet Number as part of 1160 the opaque data. As tokens may be generated by the Service, servers 1161 MUST NOT reject tokens because they lack opaque data and therefore 1162 the packet number. 1164 7.3.1. Token Protection with AEAD 1166 On the wire, the token is presented as: 1168 Shared-State Retry Service Token { 1169 Unique Token Number (96), 1170 Key Sequence (8), 1171 Encrypted Shared-State Retry Service Token Body (80..), 1172 AEAD Integrity Check Value (128), 1173 } 1175 Figure 8: Wire image of shared-state retry service tokens 1177 The tokens are protected using AES128-GCM as follows: 1179 * The Key Sequence is the 8 bit identifier to retrieve the token key 1180 and IV. 1182 * The AEAD IV, is a 96 bit data which produced by implementer's 1183 custom AEAD IV derivation function. 1185 * The AEAD nonce, N, is formed by combining the AEAD IV with the 96 1186 bit unique token number. The 96 bits of the unique token number 1187 are left-padded with zeros to the size of the IV. The exclusive 1188 OR of the padded unique token number and the AEAD IV forms the 1189 AEAD nonce. 1191 * The associated data is a formatted as a pseudo header by combining 1192 the cleartext part of the token with the IP address of the client. 1194 Shared-State Retry Service Token Pseudoheader { 1195 IP Address (128), 1196 Unique Token Number (96), 1197 Key Sequence (8), 1198 } 1200 Figure 9: Psuedoheader for shared-state retry service tokens 1202 * The input plaintext for the AEAD is the token body. The output 1203 ciphertext of the AEAD is transmitted in place of the token body. 1205 * The AEAD Integrity Check Value(ICV), defined in Section 6 of 1206 [RFC4106], is computed as part of the AEAD encryption process, and 1207 is verified during decryption. 1209 7.3.2. Configuration Agent Actions 1211 The configuration agent generates and distributes a "token key", a 1212 "token IV", a key sequence, and the information described in 1213 Section 7.1. 1215 7.3.3. Service Requirements 1217 In inactive mode, the Retry service forwards all packets without 1218 further inspection or processing. 1220 Retry services MUST NOT issue Retry packets except where explicitly 1221 allowed below, to avoid sending a Retry packet in response to a Retry 1222 token. 1224 When in active mode, the service MUST generate Retry tokens with the 1225 format described above when it receives a client Initial packet with 1226 no token. 1228 The service SHOULD decrypt incoming tokens. The service SHOULD drop 1229 packets with unknown key sequence, or an AEAD ICV that does not match 1230 the expected value. (By construction, the AEAD ICV will only match 1231 if the client IP Address also matches.) 1233 If the token verification passes, and the ODCIL and RSCIL fields are 1234 both zero, then this is a NEW_TOKEN token generated by the server. 1235 Processing of NEW_TOKEN tokens is subtly different from Retry tokens, 1236 as described below. 1238 The service SHOULD drop a packet containing a token where the ODCIL 1239 is greater than zero and less than the minimum number of octets for a 1240 client-generated CID (8 in QUIC version 1). The service also SHOULD 1241 drop a packet containing a token where the ODCIL is zero and RSCIL is 1242 nonzero. 1244 If the Timestamp of a token points to time in the past, the token has 1245 expired; however, in order to allow for clock skew, it SHOULD NOT 1246 consider tokens to be expired if the Timestamp encodes a few seconds 1247 in the past. An active Retry service SHOULD drop packets with 1248 expired tokens. If a NEW_TOKEN token, the service MUST generate a 1249 Retry packet in response. It MUST NOT generate a Retry packet in 1250 response to an expired Retry token. 1252 If a Retry token, the service SHOULD drop packets where the port 1253 number encoded in the token does not match the source port in the 1254 encapsulating UDP header. 1256 All other packets SHOULD be forwarded to the server. 1258 7.3.4. Server Requirements 1260 When issuing Retry or NEW_TOKEN tokens, the server MUST include the 1261 client IP address in the authenticated data as specified in 1262 Section 7.3.1. The ODCIL and RSCIL fields are zero for NEW_TOKEN 1263 tokens, making them easily distinguishable from Retry tokens. 1265 The server MUST validate all tokens that arrive in Initial packets, 1266 as they may have bypassed the Retry service. 1268 For Retry tokens that follow the format above, servers SHOULD use the 1269 timestamp field to apply its expiration limits for tokens. This need 1270 not be precisely synchronized with the retry service. However, 1271 servers MAY allow retry tokens marked as being a few seconds in the 1272 past, due to possible clock synchronization issues. 1274 After decrypting the token, the server uses the corresponding fields 1275 to populate the original_destination_connection_id transport 1276 parameter, with a length equal to ODCIL, and the 1277 retry_source_connection_id transport parameter, with length equal to 1278 RSCIL. 1280 For QUIC versions the service does not support, the server MAY use 1281 any token format. 1283 As discussed in [RFC9000], a server MUST NOT send a Retry packet in 1284 response to an Initial packet that contains a retry token. 1286 8. Configuration Requirements 1288 QUIC-LB requires common configuration to synchronize understanding of 1289 encodings and guarantee explicit consent of the server. 1291 The load balancer and server MUST agree on a routing algorithm, 1292 server ID allocation method, and the relevant parameters for that 1293 algorithm. 1295 All algorithms require a server ID length. If server IDs are 1296 statically allocated, the load balancer MUST receive the full table 1297 of mappings, and each server must receive its assigned SID(s), from 1298 the configuration agent. 1300 For Stream Cipher CID Routing, the servers and load balancer also 1301 MUST have a common understanding of the key and nonce length. 1303 For Block Cipher CID Routing, the servers and load balancer also MUST 1304 have a common understanding of the key. 1306 Note that server IDs are opaque bytes, not integers, so there is no 1307 notion of network order or host order. 1309 A server configuration MUST specify if the first octet encodes the 1310 CID length. Note that a load balancer does not need the CID length, 1311 as the required bytes are present in the QUIC packet. 1313 A full QUIC-LB server configuration MUST also specify the supported 1314 QUIC versions of any Retry Service. If a shared-state service, the 1315 server also must have the token key. 1317 A non-shared-state Retry Service need only be configured with the 1318 QUIC versions it supports, and an Allow- or Deny-List. A shared- 1319 state Retry Service also needs the token key, and to be aware if a 1320 NAT sits between it and the servers. 1322 Appendix A provides a YANG Model of the a full QUIC-LB configuration. 1324 9. Additional Use Cases 1326 This section discusses considerations for some deployment scenarios 1327 not implied by the specification above. 1329 9.1. Load balancer chains 1331 Some network architectures may have multiple tiers of low-state load 1332 balancers, where a first tier of devices makes a routing decision to 1333 the next tier, and so on, until packets reach the server. Although 1334 QUIC-LB is not explicitly designed for this use case, it is possible 1335 to support it. 1337 If each load balancer is assigned a range of server IDs that is a 1338 subset of the range of IDs assigned to devices that are closer to the 1339 client, then the first devices to process an incoming packet can 1340 extract the server ID and then map it to the correct forwarding 1341 address. Note that this solution is extensible to arbitrarily large 1342 numbers of load-balancing tiers, as the maximum server ID space is 1343 quite large. 1345 9.2. Moving connections between servers 1347 Some deployments may transparently move a connection from one server 1348 to another. The means of transferring connection state between 1349 servers is out of scope of this document. 1351 To support a handover, a server involved in the transition could 1352 issue CIDs that map to the new server via a NEW_CONNECTION_ID frame, 1353 and retire CIDs associated with the new server using the "Retire 1354 Prior To" field in that frame. 1356 Alternately, if the old server is going offline, the load balancer 1357 could simply map its server ID to the new server's address. 1359 10. Version Invariance of QUIC-LB 1361 Non-shared-state Retry Services are inherently dependent on the 1362 format (and existence) of Retry Packets in each version of QUIC, and 1363 so Retry Service configuration explicitly includes the supported QUIC 1364 versions. 1366 The server ID encodings, and requirements for their handling, are 1367 designed to be QUIC version independent (see [RFC8999]). A QUIC-LB 1368 load balancer will generally not require changes as servers deploy 1369 new versions of QUIC. However, there are several unlikely future 1370 design decisions that could impact the operation of QUIC-LB. 1372 The maximum Connection ID length could be below the minimum necessary 1373 for one or more encoding algorithms. 1375 Section 4.1 provides guidance about how load balancers should handle 1376 unroutable DCIDs. This guidance, and the implementation of an 1377 algorithm to handle these DCIDs, rests on some assumptions: 1379 * Incoming short headers do not contain DCIDs that are client- 1380 generated. 1382 * The use of client-generated incoming DCIDs does not persist beyond 1383 a few round trips in the connection. 1385 * While the client is using DCIDs it generated, some exposed fields 1386 (IP address, UDP port, client-generated destination Connection ID) 1387 remain constant for all packets sent on the same connection. 1389 * Dynamic server ID allocation is dependent on client-generated 1390 Destination CIDs in Initial Packets being at least 8 octets in 1391 length. If they are not, the load balancer may not be able to 1392 extract a valid server ID to add to its table. Configuring a 1393 shorter server ID length can increase robustness to a change. 1395 While this document does not update the commitments in [RFC8999], the 1396 additional assumptions are minimal and narrowly scoped, and provide a 1397 likely set of constants that load balancers can use with minimal risk 1398 of version- dependence. 1400 If these assumptions are invalid, this specification is likely to 1401 lead to loss of packets that contain unroutable DCIDs, and in extreme 1402 cases connection failure. 1404 Some load balancers might inspect elements of the Server Name 1405 Indication (SNI) extension in the TLS Client Hello to make a routing 1406 decision. Note that the format and cryptographic protection of this 1407 information may change in future versions or extensions of TLS or 1408 QUIC, and therefore this functionality is inherently not version- 1409 invariant. 1411 11. Security Considerations 1413 QUIC-LB is intended to prevent linkability. Attacks would therefore 1414 attempt to subvert this purpose. 1416 Note that the Plaintext CID algorithm makes no attempt to obscure the 1417 server mapping, and therefore does not address these concerns. It 1418 exists to allow consistent CID encoding for compatibility across a 1419 network infrastructure, which makes QUIC robust to NAT rebinding. 1420 Servers that are running the Plaintext CID algorithm SHOULD only use 1421 it to generate new CIDs for the Server Initial Packet and SHOULD NOT 1422 send CIDs in QUIC NEW_CONNECTION_ID frames, except that it sends one 1423 new Connection ID in the event of config rotation Section 3.1. Doing 1424 so might falsely suggest to the client that said CIDs were generated 1425 in a secure fashion. 1427 A linkability attack would find some means of determining that two 1428 connection IDs route to the same server. As described above, there 1429 is no scheme that strictly prevents linkability for all traffic 1430 patterns, and therefore efforts to frustrate any analysis of server 1431 ID encoding have diminishing returns. 1433 11.1. Attackers not between the load balancer and server 1435 Any attacker might open a connection to the server infrastructure and 1436 aggressively simulate migration to obtain a large sample of IDs that 1437 map to the same server. It could then apply analytical techniques to 1438 try to obtain the server encoding. 1440 The Stream and Block Cipher CID algorithms provide robust protection 1441 against any sort of linkage. The Plaintext CID algorithm makes no 1442 attempt to protect this encoding. 1444 Were this analysis to obtain the server encoding, then on-path 1445 observers might apply this analysis to correlating different client 1446 IP addresses. 1448 11.2. Attackers between the load balancer and server 1450 Attackers in this privileged position are intrinsically able to map 1451 two connection IDs to the same server. The QUIC-LB algorithms do 1452 prevent the linkage of two connection IDs to the same individual 1453 connection if servers make reasonable selections when generating new 1454 IDs for that connection. 1456 11.3. Multiple Configuration IDs 1458 During the period in which there are multiple deployed configuration 1459 IDs (see Section 3.1), there is a slight increase in linkability. 1460 The server space is effectively divided into segments with CIDs that 1461 have different config rotation bits. Entities that manage servers 1462 SHOULD strive to minimize these periods by quickly deploying new 1463 configurations across the server pool. 1465 11.4. Limited configuration scope 1467 A simple deployment of QUIC-LB in a cloud provider might use the same 1468 global QUIC-LB configuration across all its load balancers that route 1469 to customer servers. An attacker could then simply become a 1470 customer, obtain the configuration, and then extract server IDs of 1471 other customers' connections at will. 1473 To avoid this, the configuration agent SHOULD issue QUIC-LB 1474 configurations to mutually distrustful servers that have different 1475 keys for encryption algorithms. In many cases, the load balancers 1476 can distinguish these configurations by external IP address. 1478 However, assigning multiple entities to an IP address is 1479 complimentary with concealing DNS requests (e.g., DoH [RFC8484]) and 1480 the TLS Server Name Indicator (SNI) ([I-D.ietf-tls-esni]) to obscure 1481 the ultimate destination of traffic. While the load balancer's 1482 fallback algorithm (Section 4.2) can use the SNI to make a routing 1483 decision on the first packet, there are three ways to route 1484 subsequent packets: 1486 * all co-tenants can use the same QUIC-LB configuration, leaking the 1487 server mapping to each other as described above; 1489 * co-tenants can be issued one of up to three configurations 1490 distinguished by the config rotation bits (Section 3.1), exposing 1491 information about the target domain to the entire network; or 1493 * tenants can use 4-tuple routing in their CIDs (in which case they 1494 SHOULD disable migration in their connections), which neutralizes 1495 the value of QUIC-LB but preserves privacy. 1497 When configuring QUIC-LB, administrators must evaluate the privacy 1498 tradeoff considering the relative value of each of these properties, 1499 given the trust model between tenants, the presence of methods to 1500 obscure the domain name, and value of address migration in the tenant 1501 use cases. 1503 As the plaintext algorithm makes no attempt to conceal the server 1504 mapping, these deployments SHOULD simply use a common configuration. 1506 11.5. Stateless Reset Oracle 1508 Section 21.9 of [RFC9000] discusses the Stateless Reset Oracle 1509 attack. For a server deployment to be vulnerable, an attacking 1510 client must be able to cause two packets with the same Destination 1511 CID to arrive at two different servers that share the same 1512 cryptographic context for Stateless Reset tokens. As QUIC-LB 1513 requires deterministic routing of DCIDs over the life of a 1514 connection, it is a sufficient means of avoiding an Oracle without 1515 additional measures. 1517 11.6. Connection ID Entropy 1519 The Stream Cipher and Block Cipher algorithms need to generate 1520 different cipher text for each generated Connection ID instance to 1521 protect the Server ID. To do so, at least four octets of the Block 1522 Cipher CID and at least eight octets of the Stream Cipher CID are 1523 reserved for a nonce that, if used only once, will result in unique 1524 cipher text for each Connection ID. 1526 If servers simply increment the nonce by one with each generated 1527 connection ID, then it is safe to use the existing keys until any 1528 server's nonce counter exhausts the allocated space and rolls over to 1529 zero. Whether or not it implements this method, the server MUST NOT 1530 reuse a nonce until it switches to a configuration with new keys. 1532 Configuration agents SHOULD implement an out-of-band method to 1533 discover when servers are in danger of exhausting their nonce space, 1534 and SHOULD respond by issuing a new configuration. A server that has 1535 exhausted its nonces MUST either switch to a different configuration, 1536 or if none exists, use the 4-tuple routing config rotation codepoint. 1538 11.7. Shared-State Retry Keys 1540 The Shared-State Retry Service defined in Section 7.3 describes the 1541 format of retry tokens or new tokens protected and encrypted using 1542 AES128-GCM. Each token includes a 96 bit randomly generated unique 1543 token number, and an 8 bit identifier used to get the AES-GCM 1544 encryption context. The AES-GCM encryption context contains a 128 1545 bit key and an AEAD IV. There are three important security 1546 considerations for these tokens: 1548 * An attacker that obtains a copy of the encryption key will be able 1549 to decrypt and forge tokens. 1551 * Attackers may be able to retrieve the key if they capture a 1552 sufficently large number of retry tokens encrypted with a given 1553 key. 1555 * Confidentiality of the token data will fail if separate tokens 1556 reuse the same 96 bit unique token number and the same key. 1558 To protect against disclosure of keys to attackers, service and 1559 servers MUST ensure that the keys are stored securely. To limit the 1560 consequences of potential exposures, the time to live of any given 1561 key should be limited. 1563 Section 6.6 of [RFC9001] states that "Endpoints MUST count the number 1564 of encrypted packets for each set of keys. If the total number of 1565 encrypted packets with the same key exceeds the confidentiality limit 1566 for the selected AEAD, the endpoint MUST stop using those keys." It 1567 goes on with the specific limit: "For AEAD_AES_128_GCM and 1568 AEAD_AES_256_GCM, the confidentiality limit is 2^23 encrypted 1569 packets; see Appendix B.1." It is prudent to adopt the same limit 1570 here, and configure the service in such a way that no more than 2^23 1571 tokens are generated with the same key. 1573 In order to protect against collisions, the 96 bit unique token 1574 numbers should be generated using a cryptographically secure 1575 pseudorandom number generator (CSPRNG), as specified in Appendix C.1 1576 of the TLS 1.3 specification [RFC8446]. With proper random numbers, 1577 if fewer than 2^40 tokens are generated with a single key, the risk 1578 of collisions is lower than 0.001%. 1580 12. IANA Considerations 1582 There are no IANA requirements. 1584 13. References 1586 13.1. Normative References 1588 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1589 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1590 . 1592 [RFC8999] Thomson, M., "Version-Independent Properties of QUIC", 1593 RFC 8999, DOI 10.17487/RFC8999, May 2021, 1594 . 1596 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1597 Multiplexed and Secure Transport", RFC 9000, 1598 DOI 10.17487/RFC9000, May 2021, 1599 . 1601 [TIME_T] "Open Group Standard: Vol. 1: Base Definitions, Issue 7", 1602 IEEE Std 1003.1 , 2018, 1603 . 1606 13.2. Informative References 1608 [I-D.draft-ietf-tls-dtls13] 1609 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1610 Datagram Transport Layer Security (DTLS) Protocol Version 1611 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1612 dtls13-43, 30 April 2021, 1613 . 1616 [I-D.ietf-tls-dtls-connection-id] 1617 Rescorla, E., Tschofenig, H., Fossati, T., and A. Kraus, 1618 "Connection Identifiers for DTLS 1.2", Work in Progress, 1619 Internet-Draft, draft-ietf-tls-dtls-connection-id-13, 22 1620 June 2021, . 1623 [I-D.ietf-tls-esni] 1624 Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 1625 Encrypted Client Hello", Work in Progress, Internet-Draft, 1626 draft-ietf-tls-esni-12, 7 July 2021, 1627 . 1630 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1631 Requirement Levels", BCP 14, RFC 2119, 1632 DOI 10.17487/RFC2119, March 1997, 1633 . 1635 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 1636 (GCM) in IPsec Encapsulating Security Payload (ESP)", 1637 RFC 4106, DOI 10.17487/RFC4106, June 2005, 1638 . 1640 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1641 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 1642 . 1644 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1645 the Network Configuration Protocol (NETCONF)", RFC 6020, 1646 DOI 10.17487/RFC6020, October 2010, 1647 . 1649 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1650 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1651 January 2012, . 1653 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 1654 Agility and Selecting Mandatory-to-Implement Algorithms", 1655 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1656 . 1658 [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme 1659 Updates for Secure Real-time Transport Protocol (SRTP) 1660 Extension for Datagram Transport Layer Security (DTLS)", 1661 RFC 7983, DOI 10.17487/RFC7983, September 2016, 1662 . 1664 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1665 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1666 . 1668 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1669 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1670 . 1672 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 1673 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 1674 . 1676 Appendix A. QUIC-LB YANG Model 1678 This YANG model conforms to [RFC6020] and expresses a complete QUIC- 1679 LB configuration. 1681 module ietf-quic-lb { 1682 yang-version "1.1"; 1683 namespace "urn:ietf:params:xml:ns:yang:ietf-quic-lb"; 1684 prefix "quic-lb"; 1686 import ietf-yang-types { 1687 prefix yang; 1688 reference 1689 "RFC 6991: Common YANG Data Types."; 1690 } 1691 import ietf-inet-types { 1692 prefix inet; 1693 reference 1694 "RFC 6991: Common YANG Data Types."; 1695 } 1697 organization 1698 "IETF QUIC Working Group"; 1700 contact 1701 "WG Web: 1702 WG List: 1704 Authors: Martin Duke (martin.h.duke at gmail dot com) 1705 Nick Banks (nibanks at microsoft dot com)"; 1707 description 1708 "This module enables the explicit cooperation of QUIC servers with 1709 trusted intermediaries without breaking important protocol features. 1711 Copyright (c) 2021 IETF Trust and the persons identified as 1712 authors of the code. All rights reserved. 1714 Redistribution and use in source and binary forms, with or 1715 without modification, is permitted pursuant to, and subject to 1716 the license terms contained in, the Simplified BSD License set 1717 forth in Section 4.c of the IETF Trust's Legal Provisions 1718 Relating to IETF Documents 1719 (https://trustee.ietf.org/license-info). 1721 This version of this YANG module is part of RFC XXXX 1722 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 1723 for full legal notices. 1725 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 1726 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1727 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1728 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 1729 they appear in all capitals, as shown here."; 1731 revision "2021-01-29" { 1732 description 1733 "Initial Version"; 1734 reference 1735 "RFC XXXX, QUIC-LB: Generating Routable QUIC Connection IDs"; 1736 } 1738 container quic-lb { 1739 presence "The container for QUIC-LB configuration."; 1741 description 1742 "QUIC-LB container."; 1744 typedef quic-lb-key { 1745 type yang:hex-string { 1746 length 47; 1747 } 1748 description 1749 "This is a 16-byte key, represented with 47 bytes"; 1750 } 1752 list cid-configs { 1753 key "config-rotation-bits"; 1754 description 1755 "List up to three load balancer configurations"; 1757 leaf config-rotation-bits { 1758 type uint8 { 1759 range "0..2"; 1760 } 1761 mandatory true; 1762 description 1763 "Identifier for this CID configuration."; 1764 } 1766 leaf first-octet-encodes-cid-length { 1767 type boolean; 1768 default false; 1769 description 1770 "If true, the six least significant bits of the first CID 1771 octet encode the CID length minus one."; 1772 } 1774 leaf cid-key { 1775 type quic-lb-key; 1776 description 1777 "Key for encrypting the connection ID. If absent, the 1778 configuration uses the Plaintext algorithm."; 1779 } 1781 leaf nonce-length { 1782 type uint8 { 1783 range "8..16"; 1784 } 1785 must '(../cid-key)' { 1786 error-message "nonce-length only valid if cid-key is set"; 1788 } 1789 description 1790 "Length, in octets, of the nonce. If absent when cid-key is 1791 present, the configuration uses the Block Cipher Algorithm. 1792 If present along with cid-key, the configurationuses the 1793 Stream Cipher Algorithm."; 1794 } 1796 leaf lb-timeout { 1797 type uint32; 1798 description 1799 "Existence means the configuration uses dynamic Server ID allocation. 1800 Time (in seconds) to keep a server ID allocation if no packets with 1801 that server ID arrive."; 1802 } 1804 leaf server-id-length { 1805 type uint8 { 1806 range "1..18"; 1807 } 1808 must '(../lb-timeout and . <= 7) or 1809 (not(../lb-timeout) and 1810 (not(../cid-key) and . <= 16) or 1811 ((../nonce-length) and . <= (19 - ../nonce-length)) or 1812 ((../cid-key) and not(../nonce-length) and . <= 12))' { 1813 error-message 1814 "Server ID length too long for routing algorithm and server ID 1815 allocation method"; 1816 } 1817 mandatory true; 1818 description 1819 "Length (in octets) of a server ID. Further range-limited 1820 by sid-allocation, cid-key, and nonce-length."; 1821 } 1823 list server-id-mappings { 1824 when "not(../lb-timeout)"; 1825 key "server-id"; 1826 description "Statically allocated Server IDs"; 1828 leaf server-id { 1829 type yang:hex-string; 1830 must "string-length(.) = 3 * ../../server-id-length - 1"; 1831 mandatory true; 1832 description 1833 "An allocated server ID"; 1834 } 1835 leaf server-address { 1836 type inet:ip-address; 1837 mandatory true; 1838 description 1839 "Destination address corresponding to the server ID"; 1840 } 1841 } 1842 } 1844 container retry-service-config { 1845 description 1846 "Configuration of Retry Service. If supported-versions is empty, there 1847 is no retry service. If token-keys is empty, it uses the non-shared- 1848 state service. If present, it uses shared-state tokens."; 1850 leaf-list supported-versions { 1851 type uint32; 1852 description 1853 "QUIC versions that the retry service supports. If empty, there 1854 is no retry service."; 1855 } 1857 leaf unsupported-version-default { 1858 type enumeration { 1859 enum allow { 1860 description "Unsupported versions admitted by default"; 1861 } 1862 enum deny { 1863 description "Unsupported versions denied by default"; 1864 } 1865 } 1866 default allow; 1867 description 1868 "Are unsupported versions not in version-exceptions allowed 1869 or denied?"; 1870 } 1872 leaf-list version-exceptions { 1873 type uint32; 1874 description 1875 "Exceptions to the default-deny or default-allow rule."; 1876 } 1878 list token-keys { 1879 key "key-sequence-number"; 1880 description 1881 "list of active keys, for key rotation purposes. Existence implies 1882 shared-state format"; 1884 leaf key-sequence-number { 1885 type uint8; 1886 mandatory true; 1887 description 1888 "Identifies the key used to encrypt the token"; 1889 } 1891 leaf token-key { 1892 type quic-lb-key; 1893 mandatory true; 1894 description 1895 "16-byte key to encrypt the token"; 1896 } 1898 leaf token-iv { 1899 type yang:hex-string { 1900 length 23; 1901 } 1902 mandatory true; 1903 description 1904 "8-byte IV to encrypt the token, encoded in 23 bytes"; 1905 } 1906 } 1907 } 1908 } 1909 } 1911 A.1. Tree Diagram 1913 This summary of the YANG model uses the notation in [RFC8340]. 1915 module: ietf-quic-lb 1916 +--rw quic-lb 1917 +--rw cid-configs* 1918 | [config-rotation-bits] 1919 | +--rw config-rotation-bits uint8 1920 | +--rw first-octet-encodes-cid-length? boolean 1921 | +--rw cid-key? yang:hex-string 1922 | +--rw nonce-length? uint8 1923 | +--rw lb-timeout? uint32 1924 | +--rw server-id-length uint8 1925 | +--rw server-id-mappings*? 1926 | | [server-id] 1927 | | +--rw server-id yang:hex-string 1928 | | +--rw server-address inet:ip-address 1929 +--ro retry-service-config 1930 | +--rw supported-versions* 1931 | | +--rw version uint32 1932 | +--rw unsupported-version-default enumeration {allow deny} 1933 | +--rw version-exceptions* 1934 | | +--rw version uint32 1935 | +--rw token-keys*? 1936 | | [key-sequence-number] 1937 | | +--rw key-sequence-number uint8 1938 | | +--rw token-key yang:hex-string 1939 | | +--rw token-iv yang:hex-string 1941 Appendix B. Load Balancer Test Vectors 1943 Each section of this draft includes multiple sets of load balancer 1944 configuration, each of which has five examples of server ID and 1945 server use bytes and how they are encoded in a CID. 1947 In some cases, there are no server use bytes. Note that, for 1948 simplicity, the first octet bits used for neither config rotation nor 1949 length self-encoding are random, rather than listed in the server use 1950 field. Therefore, a server implementation using these parameters may 1951 generate CIDs with a slightly different first octet. 1953 This section uses the following abbreviations: 1955 cid Connection ID 1956 cr_bits Config Rotation Bits 1957 LB Load Balancer 1958 sid Server ID 1959 sid_len Server ID length 1960 su Server Use Bytes 1961 All values except length_self_encoding and sid_len are expressed in 1962 hexidecimal format. 1964 B.1. Plaintext Connection ID Algorithm 1966 LB configuration: cr_bits 0x0 length_self_encoding: y sid_len 1 1968 cid 01be sid be su 1969 cid 0221b7 sid 21 su b7 1970 cid 03cadfd8 sid ca su dfd8 1971 cid 041e0c9328 sid 1e su 0c9328 1972 cid 050c8f6d9129 sid 0c su 8f6d9129 1974 LB configuration: cr_bits 0x0 length_self_encoding: n sid_len 2 1976 cid 02aab0 sid aab0 su 1977 cid 3ac4b106 sid c4b1 su 06 1978 cid 08bd3cf4a0 sid bd3c su f4a0 1979 cid 3771d59502d6 sid 71d5 su 9502d6 1980 cid 1d57dee8b888f3 sid 57de su e8b888f3 1982 LB configuration: cr_bits 0x0 length_self_encoding: y sid_len 3 1984 cid 0336c976 sid 36c976 su 1985 cid 04aa291806 sid aa2918 su 06 1986 cid 0586897bd8b6 sid 86897b su d8b6 1987 cid 063625bcae4de0 sid 3625bc su ae4de0 1988 cid 07966fb1f3cb535f sid 966fb1 su f3cb535f 1990 LB configuration: cr_bits 0x0 length_self_encoding: n sid_len 4 1992 cid 185172fab8 sid 5172fab8 su 1993 cid 2eb7ff2c9297 sid b7ff2c92 su 97 1994 cid 14f3eb3dd3edbe sid f3eb3dd3 su edbe 1995 cid 3feb31cece744b74 sid eb31cece su 744b74 1996 cid 06b9f34c353ce23bb5 sid b9f34c35 su 3ce23bb5 1998 LB configuration: cr_bits 0x0 length_self_encoding: y sid_len 5 2000 cid 05bdcd8d0b1d sid bdcd8d0b1d su 2001 cid 06aee673725a63 sid aee673725a su 63 2002 cid 07bbf338ddbf37f4 sid bbf338ddbf su 37f4 2003 cid 08fbbca64c26756840 sid fbbca64c26 su 756840 2004 cid 09e7737c495b93894e34 sid e7737c495b su 93894e34 2006 B.2. Stream Cipher Connection ID Algorithm 2008 In each case below, the server is using a plain text nonce value of 2009 zero. 2011 LB configuration: cr_bits 0x0 length_self_encoding: y nonce_len 12 sid_len 1 2012 key 4d9d0fd25a25e7f321ef464e13f9fa3d 2014 cid 0d69fe8ab8293680395ae256e89c sid c5 su 2015 cid 0e420d74ed99b985e10f5073f43027 sid d5 su 27 2016 cid 0f380f440c6eefd3142ee776f6c16027 sid 10 su 6027 2017 cid 1020607efbe82049ddbf3a7c3d9d32604d sid 3c su 32604d 2018 cid 11e132d12606a1bb0fa17e1caef00ec54c10 sid e3 su 0ec54c10 2020 LB configuration: cr_bits 0x0 length_self_encoding: n nonce_len 12 sid_len 2 2021 key 49e1cec7fd264b1f4af37413baf8ada9 2023 cid 3d3a5e1126414271cc8dc2ec7c8c15 sid f7fe su 2024 cid 007042539e7c5f139ac2adfbf54ba748 sid eaf4 su 48 2025 cid 2bc125dd2aed2aafacf59855d99e029217 sid e880 su 9217 2026 cid 3be6728dc082802d9862c6c8e4dda3d984d8 sid 62c6 su d984d8 2027 cid 1afe9c6259ad350fc7bad28e0aeb2e8d4d4742 sid 8502 su 8d4d4742 2029 LB configuration: cr_bits 0x0 length_self_encoding: y nonce_len 14 sid_len 3 2030 key 2c70df0b399bd33a7335523dcdb884ad 2032 cid 11d62e8670565cd30b552edff6782ff5a740 sid d794bb su 2033 cid 12c70e481f49363cabd9370d1fd5012c12bca5 sid 2cbd5d su a5 2034 cid 133b95dfd8ad93566782f8424df82458069fc9e9 sid d126cd su c9e9 2035 cid 13ac6ffcd635532ab60370306c7ee572d6b6e795 sid 539e42 su e795 2036 cid 1383ed07a9700777ff450bb39bb9c1981266805c sid 9094dd su 805c 2038 LB configuration: cr_bits 0x0 length_self_encoding: n nonce_len 12 sid_len 4 2039 key 2297b8a95c776cf9c048b76d9dc27019 2041 cid 32873890c3059ca62628089439c44c1f84 sid 7398d8ca su 2042 cid 1ff7c7d7b9823954b178636c99a7dc93ac83 sid 9655f091 su 83 2043 cid 31044000a5ebb3bf2fa7629a17f2c78b077c17 sid 8b035fc6 su 7c17 2044 cid 1791bd28c66721e8fea0c6f34fd2d8e663a6ef70 sid 6672e0e2 su a6ef70 2045 cid 3df1d90ad5ccd5f8f475f040e90aeca09ec9839d sid b98b1fff su c9839d 2047 LB configuration: cr_bits 0x0 length_self_encoding: y nonce_len 8 sid_len 5 2048 key 484b2ed942d9f4765e45035da3340423 2050 cid 0da995b7537db605bfd3a38881ae sid 391a7840dc su 2051 cid 0ed8d02d55b91d06443540d1bf6e98 sid 10f7f7b284 su 98 2052 cid 0f3f74be6d46a84ccb1fd1ee92cdeaf2 sid 0606918fc0 su eaf2 2053 cid 1045626dbf20e03050837633cc5650f97c sid e505eea637 su 50f97c 2054 cid 11bb9a17f691ab446a938427febbeb593eaa sid 99343a2a96 su eb593eaa 2056 B.3. Block Cipher Connection ID Algorithm 2057 LB configuration: cr_bits 0x0 length_self_encoding: y sid_len 1 2058 key 411592e4160268398386af84ea7505d4 2060 cid 10564f7c0df399f6d93bdddb1a03886f25 sid 23 su 05231748a80884ed58007847eb9fd0 2061 cid 10d5c03f9dd765d73b3d8610b244f74d02 sid 15 su 76cd6b6f0d3f0b20fc8e633e3a05f3 2062 cid 108ca55228ab23b92845341344a2f956f2 sid 64 su 65c0ce170a9548717498b537cb8790 2063 cid 10e73f3d034aef2f6f501e3a7693d6270a sid 07 su f9ad10c84cc1e89a2492221d74e707 2064 cid 101a6ce13d48b14a77ecfd365595ad2582 sid 6c su 76ce4689b0745b956ef71c2608045d 2066 LB configuration: cr_bits 0x0 length_self_encoding: n sid_len 2 2067 key 92ce44aecd636aeeff78da691ef48f77 2069 cid 20aa09bc65ed52b1ccd29feb7ef995d318 sid a52f su 99278b92a86694ff0ecd64bc2f73 2070 cid 30b8dbef657bd78a2f870e93f9485d5211 sid 6c49 su 7381c8657a388b4e9594297afe96 2071 cid 043a8137331eacd2e78383279b202b9a6d sid 4188 su 5ac4b0e0b95f4e7473b49ee2d0dd 2072 cid 3ba71ea2bcf0ab95719ab59d3d7fde770d sid 8ccc su 08728807605db25f2ca88be08e0f 2073 cid 37ef1956b4ec354f40dc68336a23d42b31 sid c89d su 5a3ccd1471caa0de221ad6c185c0 2075 LB configuration: cr_bits 0x0 length_self_encoding: y sid_len 3 2076 key 5c49cb9265efe8ae7b1d3886948b0a34 2078 cid 10efcffc161d232d113998a49b1dbc4aa0 sid 0690b3 su 958fc9f38fe61b83881b2c5780 2079 cid 10fc13bdbcb414ba90e391833400c19505 sid 031ac3 su 9a55e1e1904e780346fcc32c3c 2080 cid 10d3cc1efaf5dc52c7a0f6da2746a8c714 sid 572d3a su ff2ec9712664e7174dc03ca3f8 2081 cid 107edf37f6788e33c0ec7758a485215f2b sid 562c25 su 02c5a5dcbea629c3840da5f567 2082 cid 10bc28da122582b7312e65aa096e9724fc sid 2fa4f0 su 8ae8c666bfc0fc364ebfd06b9a 2084 LB configuration: cr_bits 0x0 length_self_encoding: n sid_len 4 2085 key e787a3a491551fb2b4901a3fa15974f3 2087 cid 26125351da12435615e3be6b16fad35560 sid 0cb227d3 su 65b40b1ab54e05bff55db046 2088 cid 14de05fc84e41b611dfbe99ed5b1c9d563 sid 6a0f23ad su d73bee2f3a7e72b3ffea52d9 2089 cid 1306052c3f973db87de6d7904914840ff1 sid ca21402d su 5829465f7418b56ee6ada431 2090 cid 1d202b5811af3e1dba9ea2950d27879a92 sid b14e1307 su 4902aba8b23a5f24616df3cf 2091 cid 26538b78efc2d418539ad1de13ab73e477 sid a75e0148 su 0040323f1854e75aeb449b9f 2093 LB configuration: cr_bits 0x0 length_self_encoding: y sid_len 5 2094 key d5a6d7824336fbe0f25d28487cdda57c 2096 cid 10a2794871aadb20ddf274a95249e57fde sid 82d3b0b1a1 su 0935471478c2edb8120e60 2097 cid 108122fe80a6e546a285c475a3b8613ec9 sid fbcc902c9d su 59c47946882a9a93981c15 2098 cid 104d227ad9dd0fef4c8cb6eb75887b6ccc sid 2808e22642 su 2a7ef40e2c7e17ae40b3fb 2099 cid 10b3f367d8627b36990a28d67f50b97846 sid 5e018f0197 su 2289cae06a566e5cb6cfa4 2100 cid 1024412bfe25f4547510204bdda6143814 sid 8a8dd3d036 su 4b12933a135e5eaaebc6fd 2101 B.4. Shared State Retry Tokens 2103 In this case, the shared-state retry token is issued by retry 2104 service, so the opaque data of shared-state retry token body would be 2105 null (Section 7.3). 2107 LB configuration: 2108 key_seq 0x00 2109 encrypt_key 0x30313233343536373839303132333435 2110 AEAD_IV 0x313233343536373839303132 2112 Shared-State Retry Service Token Body: 2113 ODCIL 0x12 2114 RSCIL 0x10 2115 port 0x1a0a 2116 original_destination_connection_id 0x0c3817b544ca1c94313bba41757547eec937 2117 retry_source_connection_id 0x0301e770d24b3b13070dd5c2a9264307 2118 timestamp 0x0000000060c7bf4d 2120 Shared-State Retry Service Token: 2121 unique_token_number 0x59ef316b70575e793e1a8782 2122 key_sequence 0x00 2123 encrypted_shared_state_retry_service_token_body 2124 0x7d38b274aa4427c7a1557c3fa666945931defc65da387a83855196a7cb73caac1e28e5346fd76868de94f8b62294 2125 AEAD_ICV 0xf91174fdd711543a32d5e959867f9c22 2127 AEAD related parameters: 2128 client_ip_addr 127.0.0.1 2129 client_port 6666 2130 AEAD_nonce 0x68dd025f45616941072ab6b0 2131 AEAD_associated_data 0x7f00000100000000000000000000000059ef316b70575e793e1a878200 2133 Appendix C. Interoperability with DTLS over UDP 2135 Some environments may contain DTLS traffic as well as QUIC operating 2136 over UDP, which may be hard to distinguish. 2138 In most cases, the packet parsing rules above will cause a QUIC-LB 2139 load balancer to route DTLS traffic in an appropriate way. DTLS 1.3 2140 implementations that use the connection_id extension 2141 [I-D.ietf-tls-dtls-connection-id] might use the techniques in this 2142 document to generate connection IDs and achieve robust routability 2143 for DTLS associations if they meet a few additional requirements. 2144 This non-normative appendix describes this interaction. 2146 C.1. DTLS 1.0 and 1.2 2148 DTLS 1.0 [RFC4347] and 1.2 [RFC6347] use packet formats that a QUIC- 2149 LB router will interpret as short header packets with CIDs that 2150 request 4-tuple routing. As such, they will route such packets 2151 consistently as long as the 4-tuple does not change. Note that DTLS 2152 1.0 has been deprecated by the IETF. 2154 The first octet of every DTLS 1.0 or 1.2 datagram contains the 2155 content type. A QUIC-LB load balancer will interpret any content 2156 type less than 128 as a short header packet, meaning that the 2157 subsequent octets should contain a connection ID. 2159 Existing TLS content types comfortably fit in the range below 128. 2160 Assignment of codepoints greater than 64 would require coordination 2161 in accordance with [RFC7983], and anyway would likely create problems 2162 demultiplexing DTLS and version 1 of QUIC. Therefore, this document 2163 believes it is extremely unlikely that TLS content types of 128 or 2164 greater will be assigned. Nevertheless, such an assignment would 2165 cause a QUIC-LB load balancer to interpret the packet as a QUIC long 2166 header with an essentially random connection ID, which is likely to 2167 be routed irregularly. 2169 The second octet of every DTLS 1.0 or 1.2 datagram is the bitwise 2170 complement of the DTLS Major version (i.e. version 1.x = 0xfe). A 2171 QUIC-LB load balancer will interpret this as a connection ID that 2172 requires 4-tuple based load balancing, meaning that the routing will 2173 be consistent as long as the 4-tuple remains the same. 2175 [I-D.ietf-tls-dtls-connection-id] defines an extension to add 2176 connection IDs to DTLS 1.2. Unfortunately, a QUIC-LB load balancer 2177 will not correctly parse the connection ID and will continue 4-tuple 2178 routing. An modified QUIC-LB load balancer that correctly identifies 2179 DTLS and parses a DTLS 1.2 datagram for the connection ID is outside 2180 the scope of this document. 2182 C.2. DTLS 1.3 2184 DTLS 1.3 [I-D.draft-ietf-tls-dtls13] changes the structure of 2185 datagram headers in relevant ways. 2187 Handshake packets continue to have a TLS content type in the first 2188 octet and 0xfe in the second octet, so they will be 4-tuple routed, 2189 which should not present problems for likely NAT rebinding or address 2190 change events. 2192 Non-handshake packets always have zero in their most significant bit 2193 and will therefore always be treated as QUIC short headers. If the 2194 connection ID is present, it follows in the succeeding octets. 2195 Therefore, a DTLS 1.3 association where the server utilizes 2196 Connection IDs and the encodings in this document will be routed 2197 correctly in the presence of client address and port changes. 2199 However, if the client does not include the connection_id extension 2200 in its ClientHello, the server is unable to use connection IDs. In 2201 this case, non- handshake packets will appear to contain random 2202 connection IDs and be routed randomly. Thus, unmodified QUIC-LB load 2203 balancers will not work with DTLS 1.3 if the client does not 2204 advertise support for connection IDs, or the server does not request 2205 the use of a compliant connection ID. 2207 A QUIC-LB load balancer might be modified to identify DTLS 1.3 2208 packets and correctly parse the fields to identify when there is no 2209 connection ID and revert to 4-tuple routing, removing the server 2210 requirement above. However, such a modification is outside the scope 2211 of this document, and classifying some packets as DTLS might be 2212 incompatible with future versions of QUIC. 2214 C.3. Future Versions of DTLS 2216 As DTLS does not have an IETF consensus document that defines what 2217 parts of DTLS will be invariant in future versions, it is difficult 2218 to speculate about the applicability of this section to future 2219 versions of DTLS. 2221 Appendix D. Acknowledgments 2223 The authors would like to thank Christian Huitema and Ian Swett for 2224 their major design contributions. 2226 Manasi Deval, Erik Fuller, Toma Gavrichenkov, Jana Iyengar, Subodh 2227 Iyengar, Ladislav Lhotka, Jan Lindblad, Ling Tao Nju, Kazuho Oku, 2228 Udip Pant, Martin Thomson, Dmitri Tikhonov, Victor Vasiliev, and 2229 William Zeng Ke all provided useful input to this document. 2231 Appendix E. Change Log 2233 *RFC Editor's Note:* Please remove this section prior to 2234 publication of a final version of this document. 2236 E.1. since draft-ietf-quic-load-balancers-06 2238 * Added interoperability with DTLS 2239 * Changed "non-compliant" to "unroutable" 2241 * Changed "arbitrary" algorithm to "fallback" 2243 * Revised security considerations for mistrustful tenants 2245 * Added retry service considerations for non-Initial packets 2247 E.2. since draft-ietf-quic-load-balancers-05 2249 * Added low-config CID for further discussion 2251 * Complete revision of shared-state Retry Token 2253 * Added YANG model 2255 * Updated configuration limits to ensure CID entropy 2257 * Switched to notation from quic-transport 2259 E.3. since draft-ietf-quic-load-balancers-04 2261 * Rearranged the shared-state retry token to simplify token 2262 processing 2264 * More compact timestamp in shared-state retry token 2266 * Revised server requirements for shared-state retries 2268 * Eliminated zero padding from the test vectors 2270 * Added server use bytes to the test vectors 2272 * Additional compliant DCID criteria 2274 E.4. since-draft-ietf-quic-load-balancers-03 2276 * Improved Config Rotation text 2278 * Added stream cipher test vectors 2280 * Deleted the Obfuscated CID algorithm 2282 E.5. since-draft-ietf-quic-load-balancers-02 2284 * Replaced stream cipher algorithm with three-pass version 2286 * Updated Retry format to encode info for required TPs 2287 * Added discussion of version invariance 2289 * Cleaned up text about config rotation 2291 * Added Reset Oracle and limited configuration considerations 2293 * Allow dropped long-header packets for known QUIC versions 2295 E.6. since-draft-ietf-quic-load-balancers-01 2297 * Test vectors for load balancer decoding 2299 * Deleted remnants of in-band protocol 2301 * Light edit of Retry Services section 2303 * Discussed load balancer chains 2305 E.7. since-draft-ietf-quic-load-balancers-00 2307 * Removed in-band protocol from the document 2309 E.8. Since draft-duke-quic-load-balancers-06 2311 * Switch to IETF WG draft. 2313 E.9. Since draft-duke-quic-load-balancers-05 2315 * Editorial changes 2317 * Made load balancer behavior independent of QUIC version 2319 * Got rid of token in stream cipher encoding, because server might 2320 not have it 2322 * Defined "non-compliant DCID" and specified rules for handling 2323 them. 2325 * Added psuedocode for config schema 2327 E.10. Since draft-duke-quic-load-balancers-04 2329 * Added standard for retry services 2331 E.11. Since draft-duke-quic-load-balancers-03 2333 * Renamed Plaintext CID algorithm as Obfuscated CID 2334 * Added new Plaintext CID algorithm 2336 * Updated to allow 20B CIDs 2338 * Added self-encoding of CID length 2340 E.12. Since draft-duke-quic-load-balancers-02 2342 * Added Config Rotation 2344 * Added failover mode 2346 * Tweaks to existing CID algorithms 2348 * Added Block Cipher CID algorithm 2350 * Reformatted QUIC-LB packets 2352 E.13. Since draft-duke-quic-load-balancers-01 2354 * Complete rewrite 2356 * Supports multiple security levels 2358 * Lightweight messages 2360 E.14. Since draft-duke-quic-load-balancers-00 2362 * Converted to markdown 2364 * Added variable length connection IDs 2366 Authors' Addresses 2368 Martin Duke 2369 F5 Networks, Inc. 2371 Email: martin.h.duke@gmail.com 2373 Nick Banks 2374 Microsoft 2376 Email: nibanks@microsoft.com