< draft-ietf-quic-load-balancers-12.txt   draft-ietf-quic-load-balancers-13.txt >
QUIC M. Duke QUIC M. Duke
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track N. Banks Intended status: Standards Track N. Banks
Expires: 15 August 2022 Microsoft Expires: 29 September 2022 Microsoft
C. Huitema C. Huitema
Private Octopus Inc. Private Octopus Inc.
11 February 2022 28 March 2022
QUIC-LB: Generating Routable QUIC Connection IDs QUIC-LB: Generating Routable QUIC Connection IDs
draft-ietf-quic-load-balancers-12 draft-ietf-quic-load-balancers-13
Abstract Abstract
The QUIC protocol design is resistant to transparent packet QUIC address migration allows clients to change their IP address
inspection, injection, and modification by intermediaries. However, while maintaining connection state. To reduce the ability of an
the server can explicitly cooperate with network services by agreeing observer to link two IP addresses, clients and servers use new
to certain conventions and/or sharing state with those services. connection IDs when they communicate via different client addresses.
This specification provides a standardized means of solving three This poses a problem for traditional "layer-4" load balancers that
problems: (1) maintaining routability to servers via a low-state load route packets via the IP address and port 4-tuple. This
balancer even when the connection IDs in use change; (2) explicit specification provides a standardized means of securely encoding
encoding of the connection ID length in all packets to assist routing information in the server's connection IDs so that a properly
hardware accelerators; and (3) injection of QUIC Retry packets by an configured load balancer can route packets with migrated addresses
anti-Denial-of-Service agent on behalf of the server. correctly. As it proposes a structured connection ID format, it also
provides a means of connection IDs self-encoding their length to aid
some hardware offloads.
Note to Readers Note to Readers
Discussion of this document takes place on the QUIC Working Group Discussion of this document takes place on the QUIC Working Group
mailing list (quic@ietf.org), which is archived at mailing list (quic@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/quic/ https://mailarchive.ietf.org/arch/browse/quic/
(https://mailarchive.ietf.org/arch/browse/quic/). (https://mailarchive.ietf.org/arch/browse/quic/).
Source for this draft and an issue tracker can be found at Source for this draft and an issue tracker can be found at
https://github.com/quicwg/load-balancers (https://github.com/quicwg/ https://github.com/quicwg/load-balancers (https://github.com/quicwg/
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 15 August 2022. This Internet-Draft will expire on 29 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Objectives . . . . . . . . . . . . . . . . . . . . . 6 2. First CID octet . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Config Rotation . . . . . . . . . . . . . . . . . . . . . 6
2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Configuration Failover . . . . . . . . . . . . . . . . . 7
3. First CID octet . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Length Self-Description . . . . . . . . . . . . . . . . . 7
3.1. Config Rotation . . . . . . . . . . . . . . . . . . . . . 7 2.4. Format . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Configuration Failover . . . . . . . . . . . . . . . . . 8 3. Load Balancing Preliminaries . . . . . . . . . . . . . . . . 8
3.3. Length Self-Description . . . . . . . . . . . . . . . . . 8 3.1. Unroutable Connection IDs . . . . . . . . . . . . . . . . 8
3.4. Format . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Fallback Algorithms . . . . . . . . . . . . . . . . . . . 10
4. Load Balancing Preliminaries . . . . . . . . . . . . . . . . 9 3.3. Server ID Allocation . . . . . . . . . . . . . . . . . . 10
4.1. Unroutable Connection IDs . . . . . . . . . . . . . . . . 9 4. Server ID Encoding in Connection IDs . . . . . . . . . . . . 11
4.2. Fallback Algorithms . . . . . . . . . . . . . . . . . . . 10 4.1. CID format . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Server ID Allocation . . . . . . . . . . . . . . . . . . 11 4.2. Configuration Agent Actions . . . . . . . . . . . . . . . 11
5. Server ID Encoding in Connection IDs . . . . . . . . . . . . 11 4.3. Server Actions . . . . . . . . . . . . . . . . . . . . . 11
5.1. CID format . . . . . . . . . . . . . . . . . . . . . . . 11 4.3.1. Special Case: Single Pass Encryption . . . . . . . . 12
5.2. Configuration Agent Actions . . . . . . . . . . . . . . . 12 4.3.2. General Case: Four-Pass Encryption . . . . . . . . . 12
5.3. Server Actions . . . . . . . . . . . . . . . . . . . . . 12 4.4. Load Balancer Actions . . . . . . . . . . . . . . . . . . 14
5.3.1. Special Case: Single Pass Encryption . . . . . . . . 13 4.4.1. Special Case: Single Pass Encryption . . . . . . . . 15
5.3.2. General Case: Four-Pass Encryption . . . . . . . . . 13 4.4.2. General Case: Four-Pass Encryption . . . . . . . . . 15
5.4. Load Balancer Actions . . . . . . . . . . . . . . . . . . 15 5. Per-connection state . . . . . . . . . . . . . . . . . . . . 15
5.4.1. Special Case: Single Pass Encryption . . . . . . . . 16 6. Additional Use Cases . . . . . . . . . . . . . . . . . . . . 16
5.4.2. General Case: Four-Pass Encryption . . . . . . . . . 16 6.1. Load balancer chains . . . . . . . . . . . . . . . . . . 16
6. Per-connection state . . . . . . . . . . . . . . . . . . . . 16 6.2. Moving connections between servers . . . . . . . . . . . 17
7. Retry Service . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Common Requirements . . . . . . . . . . . . . . . . . . . 18 7. Version Invariance of QUIC-LB . . . . . . . . . . . . . . . . 17
7.1.1. Considerations for Non-Initial Packets . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7.2. No-Shared-State Retry Service . . . . . . . . . . . . . . 20 8.1. Attackers not between the load balancer and server . . . 19
7.2.1. Configuration Agent Actions . . . . . . . . . . . . . 20 8.2. Attackers between the load balancer and server . . . . . 19
7.2.2. Service Requirements . . . . . . . . . . . . . . . . 20 8.3. Multiple Configuration IDs . . . . . . . . . . . . . . . 19
7.2.3. Server Requirements . . . . . . . . . . . . . . . . . 22 8.4. Limited configuration scope . . . . . . . . . . . . . . . 19
7.3. Shared-State Retry Service . . . . . . . . . . . . . . . 22 8.5. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 20
7.3.1. Token Protection with AEAD . . . . . . . . . . . . . 24 8.6. Connection ID Entropy . . . . . . . . . . . . . . . . . . 21
7.3.2. Configuration Agent Actions . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7.3.3. Service Requirements . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.3.4. Server Requirements . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . 22
8. Configuration Requirements . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . 22
9. Additional Use Cases . . . . . . . . . . . . . . . . . . . . 27 Appendix A. QUIC-LB YANG Model . . . . . . . . . . . . . . . . . 23
9.1. Load balancer chains . . . . . . . . . . . . . . . . . . 28 A.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 29
9.2. Moving connections between servers . . . . . . . . . . . 28 Appendix B. Load Balancer Test Vectors . . . . . . . . . . . . . 29
10. Version Invariance of QUIC-LB . . . . . . . . . . . . . . . . 28 B.1. Unencrypted CIDs . . . . . . . . . . . . . . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 B.2. Encrypted CIDs . . . . . . . . . . . . . . . . . . . . . 30
11.1. Attackers not between the load balancer and server . . . 30 Appendix C. Interoperability with DTLS over UDP . . . . . . . . 30
11.2. Attackers between the load balancer and server . . . . . 30 C.1. DTLS 1.0 and 1.2 . . . . . . . . . . . . . . . . . . . . 30
11.3. Multiple Configuration IDs . . . . . . . . . . . . . . . 30 C.2. DTLS 1.3 . . . . . . . . . . . . . . . . . . . . . . . . 31
11.4. Limited configuration scope . . . . . . . . . . . . . . 30 C.3. Future Versions of DTLS . . . . . . . . . . . . . . . . . 32
11.5. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 31 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 32
11.6. Connection ID Entropy . . . . . . . . . . . . . . . . . 32 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 32
11.7. Shared-State Retry Keys . . . . . . . . . . . . . . . . 33 E.1. since draft-ietf-quic-load-balancers-12 . . . . . . . . . 32
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 E.2. since draft-ietf-quic-load-balancers-11 . . . . . . . . . 32
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 E.3. since draft-ietf-quic-load-balancers-10 . . . . . . . . . 32
13.1. Normative References . . . . . . . . . . . . . . . . . . 34 E.4. since draft-ietf-quic-load-balancers-09 . . . . . . . . . 33
13.2. Informative References . . . . . . . . . . . . . . . . . 34 E.5. since draft-ietf-quic-load-balancers-08 . . . . . . . . . 33
Appendix A. QUIC-LB YANG Model . . . . . . . . . . . . . . . . . 36 E.6. since draft-ietf-quic-load-balancers-07 . . . . . . . . . 33
A.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 44 E.7. since draft-ietf-quic-load-balancers-06 . . . . . . . . . 33
Appendix B. Load Balancer Test Vectors . . . . . . . . . . . . . 45 E.8. since draft-ietf-quic-load-balancers-05 . . . . . . . . . 33
B.1. Unencrypted CIDs . . . . . . . . . . . . . . . . . . . . 46 E.9. since draft-ietf-quic-load-balancers-04 . . . . . . . . . 34
B.2. Encrypted CIDs . . . . . . . . . . . . . . . . . . . . . 46 E.10. since-draft-ietf-quic-load-balancers-03 . . . . . . . . . 34
B.3. Shared State Retry Tokens . . . . . . . . . . . . . . . . 46 E.11. since-draft-ietf-quic-load-balancers-02 . . . . . . . . . 34
Appendix C. Interoperability with DTLS over UDP . . . . . . . . 47 E.12. since-draft-ietf-quic-load-balancers-01 . . . . . . . . . 34
C.1. DTLS 1.0 and 1.2 . . . . . . . . . . . . . . . . . . . . 47 E.13. since-draft-ietf-quic-load-balancers-00 . . . . . . . . . 35
C.2. DTLS 1.3 . . . . . . . . . . . . . . . . . . . . . . . . 48 E.14. Since draft-duke-quic-load-balancers-06 . . . . . . . . . 35
C.3. Future Versions of DTLS . . . . . . . . . . . . . . . . . 49 E.15. Since draft-duke-quic-load-balancers-05 . . . . . . . . . 35
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 49 E.16. Since draft-duke-quic-load-balancers-04 . . . . . . . . . 35
Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 49 E.17. Since draft-duke-quic-load-balancers-03 . . . . . . . . . 35
E.1. since draft-ietf-quic-load-balancers-11 . . . . . . . . . 49 E.18. Since draft-duke-quic-load-balancers-02 . . . . . . . . . 35
E.2. since draft-ietf-quic-load-balancers-10 . . . . . . . . . 49 E.19. Since draft-duke-quic-load-balancers-01 . . . . . . . . . 36
E.3. since draft-ietf-quic-load-balancers-09 . . . . . . . . . 49 E.20. Since draft-duke-quic-load-balancers-00 . . . . . . . . . 36
E.4. since draft-ietf-quic-load-balancers-08 . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
E.5. since draft-ietf-quic-load-balancers-07 . . . . . . . . . 50
E.6. since draft-ietf-quic-load-balancers-06 . . . . . . . . . 50
E.7. since draft-ietf-quic-load-balancers-05 . . . . . . . . . 50
E.8. since draft-ietf-quic-load-balancers-04 . . . . . . . . . 51
E.9. since-draft-ietf-quic-load-balancers-03 . . . . . . . . . 51
E.10. since-draft-ietf-quic-load-balancers-02 . . . . . . . . . 51
E.11. since-draft-ietf-quic-load-balancers-01 . . . . . . . . . 51
E.12. since-draft-ietf-quic-load-balancers-00 . . . . . . . . . 52
E.13. Since draft-duke-quic-load-balancers-06 . . . . . . . . . 52
E.14. Since draft-duke-quic-load-balancers-05 . . . . . . . . . 52
E.15. Since draft-duke-quic-load-balancers-04 . . . . . . . . . 52
E.16. Since draft-duke-quic-load-balancers-03 . . . . . . . . . 52
E.17. Since draft-duke-quic-load-balancers-02 . . . . . . . . . 52
E.18. Since draft-duke-quic-load-balancers-01 . . . . . . . . . 53
E.19. Since draft-duke-quic-load-balancers-00 . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
QUIC packets [RFC9000] usually contain a connection ID to allow QUIC packets [RFC9000] usually contain a connection ID to allow
endpoints to associate packets with different address/port 4-tuples endpoints to associate packets with different address/port 4-tuples
to the same connection context. This feature makes connections to the same connection context. This feature makes connections
robust in the event of NAT rebinding. QUIC endpoints usually robust in the event of NAT rebinding. QUIC endpoints usually
designate the connection ID which peers use to address packets. designate the connection ID which peers use to address packets.
Server-generated connection IDs create a potential need for out-of- Server-generated connection IDs create a potential need for out-of-
band communication to support QUIC. band communication to support QUIC.
skipping to change at page 5, line 5 skipping to change at page 4, line 40
balancer and server, the load balancer must maintain a relatively balancer and server, the load balancer must maintain a relatively
expensive table of server-generated connection IDs, and will not expensive table of server-generated connection IDs, and will not
route packets correctly if they use a connection ID that was route packets correctly if they use a connection ID that was
originally communicated in a protected NEW_CONNECTION_ID frame. originally communicated in a protected NEW_CONNECTION_ID frame.
This specification provides common algorithms for encoding the server This specification provides common algorithms for encoding the server
mapping in a connection ID given some shared parameters. The mapping mapping in a connection ID given some shared parameters. The mapping
is generally only discoverable by observers that have the parameters, is generally only discoverable by observers that have the parameters,
preserving unlinkability as much as possible. preserving unlinkability as much as possible.
Aside from load balancing, a QUIC server may also desire to offload As this document proposes a structured QUIC Connection ID, it also
other protocol functions to trusted intermediaries. These proposes a system for self-encoding connection ID length in all
intermediaries might include hardware assist on the server host packets, so that crypto offload can efficiently obtain key
itself, without access to fully decrypted QUIC packets. For example, information.
this document specifies a means of offloading stateless retry to
counter Denial of Service attacks. It also proposes a system for
self-encoding connection ID length in all packets, so that crypto
offload can consistently look up key information.
While this document describes a small set of configuration parameters While this document describes a small set of configuration parameters
to make the server mapping intelligible, the means of distributing to make the server mapping intelligible, the means of distributing
these parameters between load balancers, servers, and other trusted these parameters between load balancers, servers, and other trusted
intermediaries is out of its scope. There are numerous well-known intermediaries is out of its scope. There are numerous well-known
infrastructures for distribution of configuration. infrastructures for distribution of configuration.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 6, line 28 skipping to change at page 6, line 20
Variable-Length Field (8..24), Variable-Length Field (8..24),
Variable-Length Field with Dynamic Limit (8..24-len(Variable-Length Field)), Variable-Length Field with Dynamic Limit (8..24-len(Variable-Length Field)),
Field With Minimum Length (16..), Field With Minimum Length (16..),
Field With Maximum Length (..128), Field With Maximum Length (..128),
[Optional Field (64)], [Optional Field (64)],
Repeated Field (8) ..., Repeated Field (8) ...,
} }
Figure 1: Example Format Figure 1: Example Format
2. Protocol Objectives 2. First CID octet
2.1. Simplicity
QUIC is intended to provide unlinkability across connection
migration, but servers are not required to provide additional
connection IDs that effectively prevent linkability. If the
coordination scheme is too difficult to implement, servers behind
load balancers using connection IDs for routing will use trivially
linkable connection IDs. Clients will therefore be forced to choose
between terminating the connection during migration or remaining
linkable, subverting a design objective of QUIC.
The solution should be both simple to implement and require little
additional infrastructure for cryptographic keys, etc.
2.2. Security
In the limit where there are very few connections to a pool of
servers, no scheme can prevent the linking of two connection IDs with
high probability. In the opposite limit, where all servers have many
connections that start and end frequently, it will be difficult to
associate two connection IDs even if they are known to map to the
same server.
QUIC-LB is relevant in the region between these extremes: when the
information that two connection IDs map to the same server is helpful
to linking two connection IDs. Obviously, any scheme that
transparently communicates this mapping to outside observers
compromises QUIC's defenses against linkability.
Though not an explicit goal of the QUIC-LB design, concealing the
server mapping also complicates attempts to focus attacks on a
specific server in the pool.
3. First CID octet
The first octet of a Connection ID is reserved for two special The first octet of a Connection ID is reserved for two special
purposes, one mandatory (config rotation) and one optional (length purposes, one mandatory (config rotation) and one optional (length
self-description). self-description).
Subsequent sections of this document refer to the contents of this Subsequent sections of this document refer to the contents of this
octet as the "first octet." octet as the "first octet."
3.1. Config Rotation 2.1. Config Rotation
The first two bits of any connection ID MUST encode an identifier for The first two bits of any connection ID MUST encode an identifier for
the configuration that the connection ID uses. This enables the configuration that the connection ID uses. This enables
incremental deployment of new QUIC-LB settings (e.g., keys). incremental deployment of new QUIC-LB settings (e.g., keys).
When new configuration is distributed to servers, there will be a When new configuration is distributed to servers, there will be a
transition period when connection IDs reflecting old and new transition period when connection IDs reflecting old and new
configuration coexist in the network. The rotation bits allow load configuration coexist in the network. The rotation bits allow load
balancers to apply the correct routing algorithm and parameters to balancers to apply the correct routing algorithm and parameters to
incoming packets. incoming packets.
skipping to change at page 8, line 7 skipping to change at page 7, line 13
have closed or transitioned. have closed or transitioned.
Servers MUST NOT generate new connection IDs using an old Servers MUST NOT generate new connection IDs using an old
configuration after receiving a new one from the configuration agent. configuration after receiving a new one from the configuration agent.
Servers MUST send NEW_CONNECTION_ID frames that provide CIDs using Servers MUST send NEW_CONNECTION_ID frames that provide CIDs using
the new configuration, and retire CIDs using the old configuration the new configuration, and retire CIDs using the old configuration
using the "Retire Prior To" field of that frame. using the "Retire Prior To" field of that frame.
It also possible to use these bits for more long-lived distinction of It also possible to use these bits for more long-lived distinction of
different configurations, but this has privacy implications (see different configurations, but this has privacy implications (see
Section 11.3). Section 8.3).
3.2. Configuration Failover 2.2. Configuration Failover
If a server has not received a valid QUIC-LB configuration, and If a server has not received a valid QUIC-LB configuration, and
believes that low-state, Connection-ID aware load balancers are in believes that low-state, Connection-ID aware load balancers are in
the path, it SHOULD generate connection IDs with the config rotation the path, it SHOULD generate connection IDs with the config rotation
bits set to '11' and SHOULD use the "disable_active_migration" bits set to '11' and SHOULD use the "disable_active_migration"
transport parameter in all new QUIC connections. It SHOULD NOT send transport parameter in all new QUIC connections. It SHOULD NOT send
NEW_CONNECTION_ID frames with new values. NEW_CONNECTION_ID frames with new values.
A load balancer that sees a connection ID with config rotation bits A load balancer that sees a connection ID with config rotation bits
set to '11' MUST revert to 5-tuple routing. These connection IDs may set to '11' MUST revert to 5-tuple routing. These connection IDs may
be of any length; however, see Section 11.6 for limits on this be of any length; however, see Section 8.6 for limits on this length.
length.
3.3. Length Self-Description 2.3. Length Self-Description
Local hardware cryptographic offload devices may accelerate QUIC Local hardware cryptographic offload devices may accelerate QUIC
servers by receiving keys from the QUIC implementation indexed to the servers by receiving keys from the QUIC implementation indexed to the
connection ID. However, on physical devices operating multiple QUIC connection ID. However, on physical devices operating multiple QUIC
servers, it is impractical to efficiently lookup these keys if the servers, it is impractical to efficiently lookup these keys if the
connection ID does not self-encode its own length. connection ID does not self-encode its own length.
Note that this is a function of particular server devices and is Note that this is a function of particular server devices and is
irrelevant to load balancers. As such, load balancers MAY omit this irrelevant to load balancers. As such, load balancers MAY omit this
from their configuration. However, the remaining 6 bits in the first from their configuration. However, the remaining 6 bits in the first
octet of the Connection ID are reserved to express the length of the octet of the Connection ID are reserved to express the length of the
following connection ID, not including the first octet. following connection ID, not including the first octet.
A server not using this functionality SHOULD make the six bits appear A server not using this functionality SHOULD make the six bits appear
to be random. to be random.
3.4. Format 2.4. Format
First Octet { First Octet {
Config Rotation (2), Config Rotation (2),
CID Len or Random Bits (6), CID Len or Random Bits (6),
} }
Figure 2: First Octet Format Figure 2: First Octet Format
The first octet has the following fields: The first octet has the following fields:
Config Rotation: Indicates the configuration used to interpret the Config Rotation: Indicates the configuration used to interpret the
CID. CID.
CID Len or Random Bits: Length Self-Description (if applicable), or CID Len or Random Bits: Length Self-Description (if applicable), or
random bits otherwise. Encodes the length of the Connection ID random bits otherwise. Encodes the length of the Connection ID
following the First Octet. following the First Octet.
4. Load Balancing Preliminaries 3. Load Balancing Preliminaries
In QUIC-LB, load balancers do not generate individual connection IDs In QUIC-LB, load balancers do not generate individual connection IDs
for servers. Instead, they communicate the parameters of an for servers. Instead, they communicate the parameters of an
algorithm to generate routable connection IDs. algorithm to generate routable connection IDs.
The algorithms differ in the complexity of configuration at both load The algorithms differ in the complexity of configuration at both load
balancer and server. Increasing complexity improves obfuscation of balancer and server. Increasing complexity improves obfuscation of
the server mapping. the server mapping.
This section describes three participants: the configuration agent, This section describes three participants: the configuration agent,
skipping to change at page 9, line 32 skipping to change at page 8, line 37
must be a choice of (1) routing algorithm, (2) server ID allocation must be a choice of (1) routing algorithm, (2) server ID allocation
strategy, and (3) algorithm parameters. strategy, and (3) algorithm parameters.
Fundamentally, servers generate connection IDs that encode their Fundamentally, servers generate connection IDs that encode their
server ID. Load balancers decode the server ID from the CID in server ID. Load balancers decode the server ID from the CID in
incoming packets to route to the correct server. incoming packets to route to the correct server.
There are situations where a server pool might be operating two or There are situations where a server pool might be operating two or
more routing algorithms or parameter sets simultaneously. The load more routing algorithms or parameter sets simultaneously. The load
balancer uses the first two bits of the connection ID to multiplex balancer uses the first two bits of the connection ID to multiplex
incoming DCIDs over these schemes (see Section 3.1). incoming DCIDs over these schemes (see Section 2.1).
4.1. Unroutable Connection IDs 3.1. Unroutable Connection IDs
QUIC-LB servers will generate Connection IDs that are decodable to QUIC-LB servers will generate Connection IDs that are decodable to
extract a server ID in accordance with a specified algorithm and extract a server ID in accordance with a specified algorithm and
parameters. However, QUIC often uses client-generated Connection IDs parameters. However, QUIC often uses client-generated Connection IDs
prior to receiving a packet from the server. prior to receiving a packet from the server.
These client-generated CIDs might not conform to the expectations of These client-generated CIDs might not conform to the expectations of
the routing algorithm and therefore not be routable by the load the routing algorithm and therefore not be routable by the load
balancer. Those that are not routable are "unroutable DCIDs" and balancer. Those that are not routable are "unroutable DCIDs" and
receive similar treatment regardless of why they're unroutable: receive similar treatment regardless of why they're unroutable:
* The config rotation bits (Section 3.1) may not correspond to an * The config rotation bits (Section 2.1) may not correspond to an
active configuration. Note: a packet with a DCID that indicates active configuration. Note: a packet with a DCID that indicates
5-tuple routing (see Section 3.2) is always routable. 5-tuple routing (see Section 2.2) is always routable.
* The DCID might not be long enough for the decoder to process. * The DCID might not be long enough for the decoder to process.
* The extracted server mapping might not correspond to an active * The extracted server mapping might not correspond to an active
server. server.
All other DCIDs are routable. All other DCIDs are routable.
Load balancers MUST forward packets with routable DCIDs to a server Load balancers MUST forward packets with routable DCIDs to a server
in accordance with the chosen routing algorithm. Exception: if the in accordance with the chosen routing algorithm. Exception: if the
load balancer can parse the QUIC packet and makes a routing decision load balancer can parse the QUIC packet and makes a routing decision
depending on the contents (e.g., the SNI in a TLS client hello), it depending on the contents (e.g., the SNI in a TLS client hello), it
MAY route in accordance with this instead. However, load balancers MAY route in accordance with this instead. However, load balancers
MUST always route long header packets it cannot parse in accordance MUST always route long header packets it cannot parse in accordance
with the DCID (see Section 10). with the DCID (see Section 7).
Load balancers SHOULD drop short header packets with unroutable Load balancers SHOULD drop short header packets with unroutable
DCIDs. DCIDs.
When forwarding a packet with a long header and unroutable DCID, load When forwarding a packet with a long header and unroutable DCID, load
balancers MUST use a fallback algorithm as specified in Section 4.2. balancers MUST use a fallback algorithm as specified in Section 3.2.
Load balancers MAY drop packets with long headers and unroutable Load balancers MAY drop packets with long headers and unroutable
DCIDs if and only if it knows that the encoded QUIC version does not DCIDs if and only if it knows that the encoded QUIC version does not
allow an unroutable DCID in a packet with that signature. For allow an unroutable DCID in a packet with that signature. For
example, a load balancer can safely drop a QUIC version 1 Handshake example, a load balancer can safely drop a QUIC version 1 Handshake
packet with an unroutable DCID, as a version 1 Handshake packet sent packet with an unroutable DCID, as a version 1 Handshake packet sent
to a QUIC-LB routable server will always have a server-generated to a QUIC-LB routable server will always have a server-generated
routable CID. The prohibition against dropping packets with long routable CID. The prohibition against dropping packets with long
headers remains for unknown QUIC versions. headers remains for unknown QUIC versions.
Furthermore, while the load balancer function MUST NOT drop packets, Furthermore, while the load balancer function MUST NOT drop packets,
the device might implement other security policies, outside the scope the device might implement other security policies, outside the scope
of this specification, that might force a drop. of this specification, that might force a drop.
Servers that receive packets with unroutable CIDs MUST use the Servers that receive packets with unroutable CIDs MUST use the
available mechanisms to induce the client to use a routable CID in available mechanisms to induce the client to use a routable CID in
future packets. In QUIC version 1, this requires using a routable future packets. In QUIC version 1, this requires using a routable
CID in the Source CID field of server-generated long headers. CID in the Source CID field of server-generated long headers.
4.2. Fallback Algorithms 3.2. Fallback Algorithms
There are conditions described below where a load balancer routes a There are conditions described below where a load balancer routes a
packet using a "fallback algorithm." It can choose any algorithm, packet using a "fallback algorithm." It can choose any algorithm,
without coordination with the servers, but the algorithm SHOULD be without coordination with the servers, but the algorithm SHOULD be
deterministic over short time scales so that related packets go to deterministic over short time scales so that related packets go to
the same server. The design of this algorithm SHOULD consider the the same server. The design of this algorithm SHOULD consider the
version-invariant properties of QUIC described in [RFC8999] to version-invariant properties of QUIC described in [RFC8999] to
maximize its robustness to future versions of QUIC. maximize its robustness to future versions of QUIC.
A fallback algorithm MUST NOT make the routing behavior dependent on A fallback algorithm MUST NOT make the routing behavior dependent on
any bits in the first octet of the QUIC packet header, except the any bits in the first octet of the QUIC packet header, except the
first bit, which indicates a long header. All other bits are QUIC first bit, which indicates a long header. All other bits are QUIC
version-dependent and intermediaries SHOULD NOT base their design on version-dependent and intermediaries SHOULD NOT base their design on
version-specific templates. version-specific templates.
For example, one fallback algorithm might convert a unroutable DCID For example, one fallback algorithm might convert a unroutable DCID
to an integer and divided by the number of servers, with the modulus to an integer and divided by the number of servers, with the modulus
used to forward the packet. The number of servers is usually used to forward the packet. The number of servers is usually
consistent on the time scale of a QUIC connection handshake. Another consistent on the time scale of a QUIC connection handshake. Another
might simply hash the address/port 4-tuple. See also Section 10. might simply hash the address/port 4-tuple. See also Section 7.
4.3. Server ID Allocation 3.3. Server ID Allocation
Load Balancer configurations include a mapping of server IDs to Load Balancer configurations include a mapping of server IDs to
forwarding addresses. The corresponding server configurations forwarding addresses. The corresponding server configurations
contain one or more unique server IDs. contain one or more unique server IDs.
The configuration agent chooses a server ID length for each The configuration agent chooses a server ID length for each
configuration that MUST be at least one octet. configuration that MUST be at least one octet.
A QUIC-LB configuration MAY significantly over-provision the server A QUIC-LB configuration MAY significantly over-provision the server
ID space (i.e., provide far more codepoints than there are servers) ID space (i.e., provide far more codepoints than there are servers)
to increase the probability that a randomly generated Destination to increase the probability that a randomly generated Destination
Connection ID is unroutable. Connection ID is unroutable.
The configuration agent SHOULD provide a means for servers to express The configuration agent SHOULD provide a means for servers to express
the number of server IDs it can usefully employ, because a single the number of server IDs it can usefully employ, because a single
routing address actually corresponds to multiple server entities (see routing address actually corresponds to multiple server entities (see
Section 9.1). Section 6.1).
Conceptually, each configuration has its own set of server ID Conceptually, each configuration has its own set of server ID
allocations, though two static configurations with identical server allocations, though two static configurations with identical server
ID lengths MAY use a common allocation between them. ID lengths MAY use a common allocation between them.
A server encodes one of its assigned server IDs in any CID it A server encodes one of its assigned server IDs in any CID it
generates using the relevant configuration. generates using the relevant configuration.
5. Server ID Encoding in Connection IDs 4. Server ID Encoding in Connection IDs
5.1. CID format 4.1. CID format
All connection IDs use the following format: All connection IDs use the following format:
QUIC-LB Connection ID { QUIC-LB Connection ID {
First Octet (8), First Octet (8),
Server ID (8..152-len(Nonce)), Server ID (8..152-len(Nonce)),
Nonce (32..152-len(Server ID)), Nonce (32..152-len(Server ID)),
} }
Figure 3: CID Format Figure 3: CID Format
5.2. Configuration Agent Actions 4.2. Configuration Agent Actions
The configuration agent assigns a server ID to every server in its The configuration agent assigns a server ID to every server in its
pool in accordance with Section 4.3, and determines a server ID pool in accordance with Section 3.3, and determines a server ID
length (in octets) sufficiently large to encode all server IDs, length (in octets) sufficiently large to encode all server IDs,
including potential future servers. including potential future servers.
Each configuration specifies the length of the Server ID and Nonce Each configuration specifies the length of the Server ID and Nonce
fields, with limits defined for each algorithm. fields, with limits defined for each algorithm.
Optionally, it also defines a 16-octet key. Note that failure to Optionally, it also defines a 16-octet key. Note that failure to
define a key means that observers can determine the assigned server define a key means that observers can determine the assigned server
of any connection, significantly increasing the linkability of QUIC of any connection, significantly increasing the linkability of QUIC
address migration. address migration.
The nonce length MUST be at least 4 octets. The server ID length The nonce length MUST be at least 4 octets. The server ID length
MUST be at least 1 octet. MUST be at least 1 octet.
As QUIC version 1 limits connection IDs to 20 octets, the server ID As QUIC version 1 limits connection IDs to 20 octets, the server ID
and nonce lengths MUST sum to 19 octets or less. and nonce lengths MUST sum to 19 octets or less.
5.3. Server Actions 4.3. Server Actions
The server writes the first octet and its server ID into their The server writes the first octet and its server ID into their
respective fields. respective fields.
If there is no key in the configuration, the server MUST fill the If there is no key in the configuration, the server MUST fill the
Nonce field with bytes that appear to be random. If there is a key, Nonce field with bytes that appear to be random. If there is a key,
the server fills the nonce field with a nonce of its choosing. See the server fills the nonce field with a nonce of its choosing. See
Section 11.6 for details. Section 8.6 for details.
The server MAY append additional bytes to the connection ID, up to The server MAY append additional bytes to the connection ID, up to
the limit specified in that version of QUIC, for its own use. These the limit specified in that version of QUIC, for its own use. These
bytes MUST NOT provide observers with any information that could link bytes MUST NOT provide observers with any information that could link
two connection IDs to the same connection, client, or server. In two connection IDs to the same connection, client, or server. In
particular, all servers using a configuration MUST consistently add particular, all servers using a configuration MUST consistently add
the same length to each connection ID, to preserve the linkability the same length to each connection ID, to preserve the linkability
objectives of QUIC-LB. Any additional bytes SHOULD appear random objectives of QUIC-LB. Any additional bytes SHOULD appear random
unless individual servers are not distinguishable (e.g. any server unless individual servers are not distinguishable (e.g. any server
using that configuration appends identical bytes to every connection using that configuration appends identical bytes to every connection
skipping to change at page 13, line 25 skipping to change at page 12, line 21
If there is no key in the configuration, the Connection ID is If there is no key in the configuration, the Connection ID is
complete. Otherwise, there are further steps, as described in the complete. Otherwise, there are further steps, as described in the
two following subsections. two following subsections.
Encryption below uses the AES-128-ECB cipher. Future standards could Encryption below uses the AES-128-ECB cipher. Future standards could
add new algorithms that use other ciphers to provide cryptographic add new algorithms that use other ciphers to provide cryptographic
agility in accordance with [RFC7696]. QUIC-LB implementations SHOULD agility in accordance with [RFC7696]. QUIC-LB implementations SHOULD
be extensible to support new algorithms. be extensible to support new algorithms.
5.3.1. Special Case: Single Pass Encryption 4.3.1. Special Case: Single Pass Encryption
When the nonce length and server ID length sum to exactly 16 octets, When the nonce length and server ID length sum to exactly 16 octets,
the server MUST use a single-pass encryption algorithm. All the server MUST use a single-pass encryption algorithm. All
connection ID octets except the first form an AES-ECB block. This connection ID octets except the first form an AES-ECB block. This
block is encrypted once, and the result forms the second through block is encrypted once, and the result forms the second through
seventeenth most significant bytes of the connection ID. seventeenth most significant bytes of the connection ID.
5.3.2. General Case: Four-Pass Encryption 4.3.2. General Case: Four-Pass Encryption
Any other field length requires four passes for encryption and at Any other field length requires four passes for encryption and at
least three for decryption. To understand this algorithm, it is least three for decryption. To understand this algorithm, it is
useful to define four functions that minimize the amount of bit- useful to define four functions that minimize the amount of bit-
shifting necessary in the event that there are an odd number of shifting necessary in the event that there are an odd number of
octets. octets.
The expand_left() function outputs 16 octets, with its first argument The expand_left() function outputs 16 octets, with its first argument
in the most significant bits, its second argument in the least in the most significant bits, its second argument in the least
significant byte, and zeros in all other positions. Thus, significant byte, and zeros in all other positions. Thus,
skipping to change at page 15, line 48 skipping to change at page 14, line 45
right_2 = 0xdbc0426 ^ 0x6061ac6 = 0xbba1ee0 right_2 = 0xdbc0426 ^ 0x6061ac6 = 0xbba1ee0
// step 7 // step 7
AES input = 0x0400000000000000000000000bba1ee0 AES input = 0x0400000000000000000000000bba1ee0
AES output = 0xade1b8b25b436a94007d80cf3704377b AES output = 0xade1b8b25b436a94007d80cf3704377b
left_2 = 0x4fdd0c9 ^ 0xade1b8b = 0xe23cb42 left_2 = 0x4fdd0c9 ^ 0xade1b8b = 0xe23cb42
// step 8 // step 8
cid = first_octet || left_2 || right_2 = 0x07e23cb42bba1ee0 cid = first_octet || left_2 || right_2 = 0x07e23cb42bba1ee0
5.4. Load Balancer Actions 4.4. Load Balancer Actions
On each incoming packet, the load balancer extracts consecutive On each incoming packet, the load balancer extracts consecutive
octets, beginning with the second octet. If there is no key, the octets, beginning with the second octet. If there is no key, the
first octets correspond to the server ID. first octets correspond to the server ID.
If there is a key, the load balancer takes one of two actions: If there is a key, the load balancer takes one of two actions:
5.4.1. Special Case: Single Pass Encryption 4.4.1. Special Case: Single Pass Encryption
If server ID length and nonce length sum to exactly 16 octets, they If server ID length and nonce length sum to exactly 16 octets, they
form a ciphertext block. The load balancer decrypts the block using form a ciphertext block. The load balancer decrypts the block using
the AES-ECB key and extracts the server ID from the most significant the AES-ECB key and extracts the server ID from the most significant
bytes of the resulting plaintext. bytes of the resulting plaintext.
5.4.2. General Case: Four-Pass Encryption 4.4.2. General Case: Four-Pass Encryption
First, split the ciphertext CID (excluding the first octet) into its First, split the ciphertext CID (excluding the first octet) into its
equal- length components left_2 and right_2. Then follow the process equal- length components left_2 and right_2. Then follow the process
below: below:
left_1 = left_2 ^ truncate_left(AES_ECB(key, expand_right(right_2), 0x04)) left_1 = left_2 ^ truncate_left(AES_ECB(key, expand_right(right_2), 0x04))
right_1 = right_2 ^ truncate_right(AES_ECB(key, expand_left(left_1, 0x03)) right_1 = right_2 ^ truncate_right(AES_ECB(key, expand_left(left_1, 0x03))
left_0 = left_1 ^ truncate_left(AES_ECB(key, expand_right(right_1), 0x02)) left_0 = left_1 ^ truncate_left(AES_ECB(key, expand_right(right_1), 0x02))
As the load balancer has no need for the nonce, it can conclude after As the load balancer has no need for the nonce, it can conclude after
3 passes as long as the server ID is entirely contained in left_0 3 passes as long as the server ID is entirely contained in left_0
(i.e., the nonce is at least as large as the server ID). If the (i.e., the nonce is at least as large as the server ID). If the
server ID is longer, a fourth pass is necessary: server ID is longer, a fourth pass is necessary:
right_0 = right_1 ^ truncate_right(AES_ECB(key, expand_left(left_0, right_0 = right_1 ^ truncate_right(AES_ECB(key, expand_left(left_0,
0x01))) 0x01)))
and the load balancer has to concatenate left_0 and right_0 to obtain and the load balancer has to concatenate left_0 and right_0 to obtain
the complete server ID. the complete server ID.
6. Per-connection state 5. Per-connection state
QUIC-LB requires no per-connection state at the load balancer. The QUIC-LB requires no per-connection state at the load balancer. The
load balancer can extract the server ID from the connection ID of load balancer can extract the server ID from the connection ID of
each incoming packet and route that packet accordingly. each incoming packet and route that packet accordingly.
However, once the routing decision has been made, the load balancer However, once the routing decision has been made, the load balancer
MAY associate the 4-tuple with the decision. This has two MAY associate the 4-tuple with the decision. This has two
advantages: advantages:
* The load balancer only extracts the server ID once per incoming * The load balancer only extracts the server ID once per incoming
skipping to change at page 17, line 30 skipping to change at page 16, line 30
incoming Stateless Reset is correctly routed. incoming Stateless Reset is correctly routed.
Servers MAY implement the technique described in Section 14.4.1 of Servers MAY implement the technique described in Section 14.4.1 of
[RFC9000] in case the load balancer is stateless, to increase the [RFC9000] in case the load balancer is stateless, to increase the
likelihood a Source Connection ID is included in ICMP responses to likelihood a Source Connection ID is included in ICMP responses to
Path Maximum Transmission Unit (PMTU) probes. Load balancers MAY Path Maximum Transmission Unit (PMTU) probes. Load balancers MAY
parse the echoed packet to extract the Source Connection ID, if it parse the echoed packet to extract the Source Connection ID, if it
contains a QUIC long header, and extract the Server ID as if it were contains a QUIC long header, and extract the Server ID as if it were
in a Destination CID. in a Destination CID.
7. Retry Service 6. Additional Use Cases
When a server is under load, QUICv1 allows it to defer storage of
connection state until the client proves it can receive packets at
its advertised IP address. Through the use of a Retry packet, a
token in subsequent client Initial packets, and transport parameters,
servers verify address ownership and clients verify that there is no
on-path attacker generating Retry packets.
A "Retry Service" detects potential Denial of Service attacks and
handles sending of Retry packets on behalf of the server. As it is,
by definition, literally an on-path entity, the service must
communicate some of the original connection IDs back to the server so
that it can pass client verification. It also must either verify the
address itself (with the server trusting this verification) or make
sure there is common context for the server to verify the address
using a service-generated token.
There are two different mechanisms to allow offload of DoS mitigation
to a trusted network service. One requires no shared state; the
server need only be configured to trust a retry service, though this
imposes other operational constraints. The other requires a shared
key, but has no such constraints.
7.1. Common Requirements
Regardless of mechanism, a retry service has an active mode, where it
is generating Retry packets, and an inactive mode, where it is not,
based on its assessment of server load and the likelihood an attack
is underway. The choice of mode MAY be made on a per-packet or per-
connection basis, through a stochastic process or based on client
address.
A configuration agent MUST distribute a list of QUIC versions the
Retry Service supports. It MAY also distribute either an "Allow-
List" or a "Deny-List" of other QUIC versions. It MUST NOT
distribute both an Allow-List and a Deny-List.
The Allow-List or Deny-List MUST NOT include any versions included
for Retry Service Support.
The Configuration Agent MUST provide a means for the entity that
controls the Retry Service to report its supported version(s) to the
configuration Agent. If the entity has not reported this
information, it MUST NOT activate the Retry Service and the
configuration agent MUST NOT distribute configuration that activates
it.
The configuration agent MAY delete versions from the final supported
version list if policy does not require the Retry Service to operate
on those versions.
The configuration Agent MUST provide a means for the entities that
control servers behind the Retry Service to report either an Allow-
List or a Deny-List.
If all entities supply Allow-Lists, the consolidated list MUST be the
union of these sets. If all entities supply Deny-Lists, the
consolidated list MUST be the intersection of these sets.
If entities provide a mixture of Allow-Lists and Deny-Lists, the
consolidated list MUST be a Deny-List that is the intersection of all
provided Deny-Lists and the inverses of all Allow-Lists.
If no entities that control servers have reported Allow-Lists or
Deny-Lists, the default is a Deny-List with the null set (i.e., all
unsupported versions will be admitted). This preserves the future
extensibilty of QUIC.
A retry service MUST forward all packets for a QUIC version it does
not support that are not on a Deny-List or absent from an Allow-List.
Note that if servers support versions the retry service does not,
this may increase load on the servers.
Note that future versions of QUIC might not have Retry packets,
require different information in Retry, or use different packet type
indicators.
7.1.1. Considerations for Non-Initial Packets
Initial Packets are especially effective at consuming server
resources because they cause the server to create connection state.
Even when mitigating this load with Retry Packets, the act of
validating an Initial Token and sending a Retry Packet is more
expensive than the response to a non-Initial packet with an unknown
Connection ID: simply dropping it and/or sending a Stateless Reset.
Nevertheless, a Retry Service in Active Mode might desire to shield
servers from non-Initial packets that do not correspond to a
previously admitted Initial Packet. This has a number of
considerations.
* If a Retry Service maintains no per-flow state whatsoever, it
cannot distinguish between valid and invalid non-Initial packets
and MUST forward all non-Initial Packets to the server.
* For QUIC versions the Retry Service does not support and are
present on the Allow-List (or absent from the Deny-List), the
Retry Service cannot distinguish Initial Packets from other long
headers and therefore MUST admit all long headers.
* If a Retry Service keeps per-flow state, it can identify 4-tuples
that have been previously approved, admit non-Initial packets from
those flows, and drop all others. However, dropping short headers
will effectively break Address Migration and NAT Rebinding when in
Active Mode, as post-migration packets will arrive with a
previously unknown 4-tuple. This policy will also break
connection attempts using any new QUIC versions that begin
connections with a short header.
* If a Retry Service is integrated with a QUIC-LB routable load
balancer, it can verify that the Destination Connection ID is
routable, and only admit non-Initial packets with routable DCIDs.
As the Connection ID encoding is invariant across QUIC versions,
the Retry Service can do this for all short headers.
Nothing in this section prevents Retry Services from making basic
syntax correctness checks on packets with QUIC versions that it
understands (e.g., enforcing the Initial Packet datagram size minimum
in version 1) and dropping packets that are not routable with the
QUIC specification.
7.2. No-Shared-State Retry Service
The no-shared-state retry service requires no coordination, except
that the server must be configured to accept this service and know
which QUIC versions the retry service supports. The scheme uses the
first bit of the token to distinguish between tokens from Retry
packets (codepoint '0') and tokens from NEW_TOKEN frames (codepoint
'1').
7.2.1. Configuration Agent Actions
See Section 7.1.
7.2.2. Service Requirements
A no-shared-state retry service MUST be present on all paths from
potential clients to the server. These paths MUST fail to pass QUIC
traffic should the service fail for any reason. That is, if the
service is not operational, the server MUST NOT be exposed to client
traffic. Otherwise, servers that have already disabled their Retry
capability would be vulnerable to attack.
The path between service and server MUST be free of any potential
attackers. Note that this and other requirements above severely
restrict the operational conditions in which a no-shared-state retry
service can safely operate.
Retry tokens generated by the service MUST have the format below.
Non-Shared-State Retry Service Token {
Token Type (1) = 0,
ODCIL (7) = 8..20,
Original Destination Connection ID (64..160),
Opaque Data (..),
}
Figure 4: Format of non-shared-state retry service tokens
The first bit of retry tokens generated by the service MUST be zero.
The token has the following additional fields:
ODCIL: The length of the original destination connection ID from the
triggering Initial packet. This is in cleartext to be readable for
the server, but authenticated later in the token. The Retry Service
SHOULD reject any token in which the value is less than 8.
Original Destination Connection ID: This also in cleartext and
authenticated later.
Opaque Data: This data contains the information necessary to
authenticate the Retry token in accordance with the QUIC
specification. A straightforward implementation would encode the
Retry Source Connection ID, client IP address, and a timestamp in the
Opaque Data. A more space-efficient implementation would use the
Retry Source Connection ID and Client IP as associated data in an
encryption operation, and encode only the timestamp and the
authentication tag in the Opaque Data. If the Initial Packet has
altered the Connection ID or source IP address, authentication of the
token will fail.
Upon receipt of an Initial packet with a token that begins with '0',
the retry service MUST validate the token in accordance with the QUIC
specification.
In active mode, the service MUST issue Retry packets for all Client
initial packets that contain no token, or a token that has the first
bit set to '1'. It MUST NOT forward the packet to the server. The
service MUST validate all tokens with the first bit set to '0'. If
successful, the service MUST forward the packet with the token
intact. If unsuccessful, it MUST drop the packet. The Retry Service
MAY send an Initial Packet containing a CONNECTION_CLOSE frame with
the INVALID_TOKEN error code when dropping the packet.
Note that this scheme has a performance drawback. When the retry
service is in active mode, clients with a token from a NEW_TOKEN
frame will suffer a 1-RTT penalty even though its token provides
proof of address.
In inactive mode, the service MUST forward all packets that have no
token or a token with the first bit set to '1'. It MUST validate all
tokens with the first bit set to '0'. If successful, the service
MUST forward the packet with the token intact. If unsuccessful, it
MUST either drop the packet or forward it with the token removed.
The latter requires decryption and re-encryption of the entire
Initial packet to avoid authentication failure. Forwarding the
packet causes the server to respond without the
original_destination_connection_id transport parameter, which
preserves the normal QUIC signal to the client that there is an on-
path attacker.
7.2.3. Server Requirements
A server behind a non-shared-state retry service MUST NOT send Retry
packets for a QUIC version the retry service understands. It MAY
send Retry for QUIC versions the Retry Service does not understand.
Tokens sent in NEW_TOKEN frames MUST have the first bit set to '1'.
If a server receives an Initial Packet with the first bit set to '1',
it could be from a server-generated NEW_TOKEN frame and should be
processed in accordance with the QUIC specification. If a server
receives an Initial Packet with the first bit to '0', it is a Retry
token and the server MUST NOT attempt to validate it. Instead, it
MUST assume the address is validated, MUST include the packet's
Destination Connection ID in a Retry Source Connection ID transport
parameter, and MUST extract the Original Destination Connection ID
from the token cleartext for use in the transport parameter of the
same name.
7.3. Shared-State Retry Service
A shared-state retry service uses a shared key, so that the server
can decode the service's retry tokens. It does not require that all
traffic pass through the Retry service, so servers MAY send Retry
packets in response to Initial packets that don't include a valid
token.
Both server and service must have time synchronized with respect to
one another to prevent tokens being incorrectly marked as expired,
though tight synchronization is unnecessary.
The tokens are protected using AES128-GCM AEAD, as explained in
Section 7.3.1. All tokens, generated by either the server or retry
service, MUST use the following format, which includes:
* A 1 bit token type identifier.
* A 7 bit token key identifier.
* A 96 bit unique token number transmitted in clear text, but
protected as part of the AEAD associated data.
* A token body, encoding the Original Destination Connection ID and
the Timestamp, optionally followed by server specific Opaque Data.
The token protection uses an 128 bit representation of the source IP
address from the triggering Initial packet. The client IP address is
16 octets. If an IPv4 address, the last 12 octets are zeroes. It
also uses the Source Connection ID of the Retry packet, which will
cause an authentication failure if it differs from the Destination
Connection ID of the packet bearing the token.
If there is a Network Address Translator (NAT) in the server
infrastructure that changes the client IP, the Retry Service MUST
either be positioned behind the NAT, or the NAT must have the token
key to rewrite the Retry token accordingly. Note also that a host
that obtains a token through a NAT and then attempts to connect over
a path that does not have an identically configured NAT will fail
address validation.
The 96 bit unique token number is set to a random value using a
cryptography-grade random number generator.
The token key identifier and the corresponding AEAD key and AEAD IV
are provisioned by the configuration agent.
The token body is encoded as follows:
Shared-State Retry Service Token Body {
Timestamp (64),
[ODCIL (8) = 8..20],
[Original Destination Connection ID (64..160)],
[Port (16)],
Opaque Data (..),
}
Figure 5: Body of shared-state retry service tokens
The token body has the following fields:
Timestamp: The Timestamp is a 64-bit integer, in network order, that
expresses the expiration time of the token as a number of seconds in
POSIX time (see Sec. 4.16 of [TIME_T]).
ODCIL: The original destination connection ID length. Tokens in
NEW_TOKEN frames do not have this field.
Original Destination Connection ID: The server or Retry Service
copies this from the field in the client Initial packet. Tokens in
NEW_TOKEN frames do not have this field.
Port: The Source Port of the UDP datagram that triggered the Retry
packet. This field MUST be present if and only if the ODCIL is
greater than zero. This field is therefore always absent in tokens
in NEW_TOKEN frames.
Opaque Data: The server may use this field to encode additional
information, such as congestion window, RTT, or MTU. The Retry
Service MUST have zero-length opaque data.
Some implementations of QUIC encode in the token the Initial Packet
Number used by the client, in order to verify that the client sends
the retried Initial with a PN larger that the triggering Initial.
Such implementations will encode the Initial Packet Number as part of
the opaque data. As tokens may be generated by the Service, servers
MUST NOT reject tokens because they lack opaque data and therefore
the packet number.
Shared-state Retry Services use the AES-128-ECB cipher. Future
standards could add new algorithms that use other ciphers to provide
cryptographic agility in accordance with [RFC7696]. Retry Service
and server implementations SHOULD be extensible to support new
algorithms.
7.3.1. Token Protection with AEAD
On the wire, the token is presented as:
Shared-State Retry Service Token {
Token Type (1),
Key Sequence (7),
Unique Token Number (96),
Encrypted Shared-State Retry Service Token Body (64..),
AEAD Integrity Check Value (128),
}
Figure 6: Wire image of shared-state retry service tokens
The tokens are protected using AES128-GCM as follows:
* The Key Sequence is the 7 bit identifier to retrieve the token key
and IV.
* The AEAD IV, is a 96 bit data which produced by implementer's
custom AEAD IV derivation function.
* The AEAD nonce, N, is formed by combining the AEAD IV with the 96
bit unique token number. The 96 bits of the unique token number
are left-padded with zeros to the size of the IV. The exclusive
OR of the padded unique token number and the AEAD IV forms the
AEAD nonce.
* The associated data is a formatted as a pseudo header by combining
the cleartext part of the token with the IP address of the client.
The format of the pseudoheader depends on whether the Token Type
bit is '1' (a NEW_TOKEN token) or '0' (a Retry token).
Shared-State Retry Service Token Pseudoheader {
IP Address (128),
Token Type (1),
Key Sequence (7),
Unique Token Number (96),
[RSCIL (8)],
[Retry Source Connection ID (0..20)],
}
Figure 7: Psuedoheader for shared-state retry service tokens
RSCIL: The Retry Source Connection ID Length in octets. This field
is only present when the Token Type is '0'.
Retry Source Connection ID: To create a Retry Token, populate this
field with the Source Connection ID the Retry packet will use. To
validate a Retry token, populate it with the Destination Connection
ID of the Initial packet that carries the token. This field is only
present when the Token Type is '0'.
* The input plaintext for the AEAD is the token body. The output
ciphertext of the AEAD is transmitted in place of the token body.
* The AEAD Integrity Check Value(ICV), defined in Section 6 of
[RFC4106], is computed as part of the AEAD encryption process, and
is verified during decryption.
7.3.2. Configuration Agent Actions
The configuration agent generates and distributes a "token key", a
"token IV", a key sequence, and the information described in
Section 7.1.
7.3.3. Service Requirements
In inactive mode, the Retry service forwards all packets without
further inspection or processing. The rest of this section only
applies to a service in active mode.
Retry services MUST NOT issue Retry packets except where explicitly
allowed below, to avoid sending a Retry packet in response to a Retry
token.
The service MUST generate Retry tokens with the format described
above when it receives a client Initial packet with no token.
If there is a token of either type, the service MUST attempt to
decrypt it.
To decrypt a packet, the service checks the Token Type and constructs
a pseudoheader with the appropriate format for that type, using the
bearing packet's Destination Connection ID to populate the Retry
Source Connection ID field, if any.
A token is invalid if:
* it uses unknown key sequence,
* the AEAD ICV does not match the expected value (By construction,
it will only match if the client IP Address, and any Retry Source
Connection ID, also matches),
* the ODCIL, if present, is invalid for a client-generated CID (less
than 8 or more than 20 in QUIC version 1),
* the Timestamp of a token points to time in the past (however, in
order to allow for clock skew, it SHOULD NOT consider tokens to be
expired if the Timestamp encodes a few seconds in the past), or
* the port number, if present, does not match the source port in the
encapsulating UDP header.
Packets with valid tokens MUST be forwarded to the server.
The service MUST drop packets with invalid tokens. If the token is
of type '1' (NEW_TOKEN), it MUST respond with a Retry packet. If of
type '0', it MUST NOT respond with a Retry packet.
7.3.4. Server Requirements
The server MAY issue Retry or NEW_TOKEN tokens in accordance with
[RFC9000]. When doing so, it MUST follow the format above.
The server MUST validate all tokens that arrive in Initial packets,
as they may have bypassed the Retry service. It determines validity
using the procedure in Section 7.3.3.
If a valid Retry token, the server populates the
original_destination_connection_id transport parameter using the
corresponding token field. It populates the
retry_source_connection_id transport parameter with the Destination
Connection ID of the packet bearing the token.
In all other respects, the server processes both valid and invalid
tokens in accordance with [RFC9000].
For QUIC versions the service does not support, the server MAY use
any token format.
8. Configuration Requirements
QUIC-LB requires common configuration to synchronize understanding of
encodings and guarantee explicit consent of the server.
The load balancer and server MUST agree on the connection ID encoding
parameters, which include the server ID length and nonce length. A
key is optional.
The load balancer MUST receive the full table of mappings, and each
server must receive its assigned SID(s), from the configuration
agent.
Note that server IDs are opaque bytes, not integers, so there is no
notion of network order or host order.
A server configuration MUST specify if the first octet encodes the
CID length. Note that a load balancer does not need the CID length,
as the required bytes are present in the QUIC packet.
A full QUIC-LB server configuration MUST also specify the supported
QUIC versions of any Retry Service. If a shared-state service, the
server also must have the token key.
A non-shared-state Retry Service need only be configured with the
QUIC versions it supports, and an Allow- or Deny-List. A shared-
state Retry Service also needs the token key, and to be aware if a
NAT sits between it and the servers.
Appendix A provides a YANG Model of the a full QUIC-LB configuration.
9. Additional Use Cases
This section discusses considerations for some deployment scenarios This section discusses considerations for some deployment scenarios
not implied by the specification above. not implied by the specification above.
9.1. Load balancer chains 6.1. Load balancer chains
Some network architectures may have multiple tiers of low-state load Some network architectures may have multiple tiers of low-state load
balancers, where a first tier of devices makes a routing decision to balancers, where a first tier of devices makes a routing decision to
the next tier, and so on, until packets reach the server. Although the next tier, and so on, until packets reach the server. Although
QUIC-LB is not explicitly designed for this use case, it is possible QUIC-LB is not explicitly designed for this use case, it is possible
to support it. to support it.
If each load balancer is assigned a range of server IDs that is a If each load balancer is assigned a range of server IDs that is a
subset of the range of IDs assigned to devices that are closer to the subset of the range of IDs assigned to devices that are closer to the
client, then the first devices to process an incoming packet can client, then the first devices to process an incoming packet can
extract the server ID and then map it to the correct forwarding extract the server ID and then map it to the correct forwarding
address. Note that this solution is extensible to arbitrarily large address. Note that this solution is extensible to arbitrarily large
numbers of load-balancing tiers, as the maximum server ID space is numbers of load-balancing tiers, as the maximum server ID space is
quite large. quite large.
9.2. Moving connections between servers If the number of necessary server IDs per next hop is uniform, a
simple implementation would use successively longer server IDs at
each tier of load balancing, and the server configuration would match
the last tier. The forward load balancers would simply treat the
least significant bits of the server ID as part of the nonce.
6.2. Moving connections between servers
Some deployments may transparently move a connection from one server Some deployments may transparently move a connection from one server
to another. The means of transferring connection state between to another. The means of transferring connection state between
servers is out of scope of this document. servers is out of scope of this document.
To support a handover, a server involved in the transition could To support a handover, a server involved in the transition could
issue CIDs that map to the new server via a NEW_CONNECTION_ID frame, issue CIDs that map to the new server via a NEW_CONNECTION_ID frame,
and retire CIDs associated with the new server using the "Retire and retire CIDs associated with the new server using the "Retire
Prior To" field in that frame. Prior To" field in that frame.
Alternately, if the old server is going offline, the load balancer Alternately, if the old server is going offline, the load balancer
could simply map its server ID to the new server's address. could simply map its server ID to the new server's address.
10. Version Invariance of QUIC-LB 7. Version Invariance of QUIC-LB
Non-shared-state Retry Services are inherently dependent on the
format (and existence) of Retry Packets in each version of QUIC, and
so Retry Service configuration explicitly includes the supported QUIC
versions.
The server ID encodings, and requirements for their handling, are The server ID encodings, and requirements for their handling, are
designed to be QUIC version independent (see [RFC8999]). A QUIC-LB designed to be QUIC version independent (see [RFC8999]). A QUIC-LB
load balancer will generally not require changes as servers deploy load balancer will generally not require changes as servers deploy
new versions of QUIC. However, there are several unlikely future new versions of QUIC. However, there are several unlikely future
design decisions that could impact the operation of QUIC-LB. design decisions that could impact the operation of QUIC-LB.
The maximum Connection ID length could be below the minimum necessary The maximum Connection ID length could be below the minimum necessary
for one or more encoding algorithms. for one or more encoding algorithms.
Section 4.1 provides guidance about how load balancers should handle Section 3.1 provides guidance about how load balancers should handle
unroutable DCIDs. This guidance, and the implementation of an unroutable DCIDs. This guidance, and the implementation of an
algorithm to handle these DCIDs, rests on some assumptions: algorithm to handle these DCIDs, rests on some assumptions:
* Incoming short headers do not contain DCIDs that are client- * Incoming short headers do not contain DCIDs that are client-
generated. generated.
* The use of client-generated incoming DCIDs does not persist beyond * The use of client-generated incoming DCIDs does not persist beyond
a few round trips in the connection. a few round trips in the connection.
* While the client is using DCIDs it generated, some exposed fields * While the client is using DCIDs it generated, some exposed fields
skipping to change at page 29, line 33 skipping to change at page 18, line 19
If these assumptions are invalid, this specification is likely to If these assumptions are invalid, this specification is likely to
lead to loss of packets that contain unroutable DCIDs, and in extreme lead to loss of packets that contain unroutable DCIDs, and in extreme
cases connection failure. cases connection failure.
Some load balancers might inspect elements of the Server Name Some load balancers might inspect elements of the Server Name
Indication (SNI) extension in the TLS Client Hello to make a routing Indication (SNI) extension in the TLS Client Hello to make a routing
decision. Note that the format and cryptographic protection of this decision. Note that the format and cryptographic protection of this
information may change in future versions or extensions of TLS or information may change in future versions or extensions of TLS or
QUIC, and therefore this functionality is inherently not version- QUIC, and therefore this functionality is inherently not version-
invariant. See also Section 4.1 for other considerations about this invariant. See also Section 3.1 for other considerations about this
case. Note that an SNI-aware load balancer, faced with an unknown case. Note that an SNI-aware load balancer, faced with an unknown
QUIC version, might misdirect initial packets to the wrong tenant. QUIC version, might misdirect initial packets to the wrong tenant.
While inefficient, this preserves the ability for tenants to deploy While inefficient, this preserves the ability for tenants to deploy
new versions provided they have an out-of-band means of providing a new versions provided they have an out-of-band means of providing a
connection ID for the client to use. connection ID for the client to use.
11. Security Considerations 8. Security Considerations
QUIC-LB is intended to prevent linkability. Attacks would therefore QUIC-LB is intended to prevent linkability. Attacks would therefore
attempt to subvert this purpose. attempt to subvert this purpose.
Note that without a key for the encoding, QUIC-LB makes no attempt to Note that without a key for the encoding, QUIC-LB makes no attempt to
obscure the server mapping, and therefore does not address these obscure the server mapping, and therefore does not address these
concerns. Without a key, QUIC-LB merely allows consistent CID concerns. Without a key, QUIC-LB merely allows consistent CID
encoding for compatibility across a' network infrastructure, which encoding for compatibility across a network infrastructure, which
makes QUIC robust to NAT rebinding. Servers that are encoding their makes QUIC robust to NAT rebinding. Servers that are encoding their
server ID without a key algorithm SHOULD only use it to generate new server ID without a key algorithm SHOULD only use it to generate new
CIDs for the Server Initial Packet and SHOULD NOT send CIDs in QUIC CIDs for the Server Initial Packet and SHOULD NOT send CIDs in QUIC
NEW_CONNECTION_ID frames, except that it sends one new Connection ID NEW_CONNECTION_ID frames, except that it sends one new Connection ID
in the event of config rotation Section 3.1. Doing so might falsely in the event of config rotation Section 2.1. Doing so might falsely
suggest to the client that said CIDs were generated in a secure suggest to the client that said CIDs were generated in a secure
fashion. fashion.
A linkability attack would find some means of determining that two A linkability attack would find some means of determining that two
connection IDs route to the same server. As described above, there connection IDs route to the same server. As described above, there
is no scheme that strictly prevents linkability for all traffic is no scheme that strictly prevents linkability for all traffic
patterns, and therefore efforts to frustrate any analysis of server patterns, and therefore efforts to frustrate any analysis of server
ID encoding have diminishing returns. ID encoding have diminishing returns.
11.1. Attackers not between the load balancer and server 8.1. Attackers not between the load balancer and server
Any attacker might open a connection to the server infrastructure and Any attacker might open a connection to the server infrastructure and
aggressively simulate migration to obtain a large sample of IDs that aggressively simulate migration to obtain a large sample of IDs that
map to the same server. It could then apply analytical techniques to map to the same server. It could then apply analytical techniques to
try to obtain the server encoding. try to obtain the server encoding.
An encrypted encoding provides robust protection against this. An An encrypted encoding provides robust protection against this. An
unencrypted one provides none. unencrypted one provides none.
Were this analysis to obtain the server encoding, then on-path Were this analysis to obtain the server encoding, then on-path
observers might apply this analysis to correlating different client observers might apply this analysis to correlating different client
IP addresses. IP addresses.
11.2. Attackers between the load balancer and server 8.2. Attackers between the load balancer and server
Attackers in this privileged position are intrinsically able to map Attackers in this privileged position are intrinsically able to map
two connection IDs to the same server. The QUIC-LB algorithms do two connection IDs to the same server. The QUIC-LB algorithms do
prevent the linkage of two connection IDs to the same individual prevent the linkage of two connection IDs to the same individual
connection if servers make reasonable selections when generating new connection if servers make reasonable selections when generating new
IDs for that connection. IDs for that connection.
11.3. Multiple Configuration IDs 8.3. Multiple Configuration IDs
During the period in which there are multiple deployed configuration During the period in which there are multiple deployed configuration
IDs (see Section 3.1), there is a slight increase in linkability. IDs (see Section 2.1), there is a slight increase in linkability.
The server space is effectively divided into segments with CIDs that The server space is effectively divided into segments with CIDs that
have different config rotation bits. Entities that manage servers have different config rotation bits. Entities that manage servers
SHOULD strive to minimize these periods by quickly deploying new SHOULD strive to minimize these periods by quickly deploying new
configurations across the server pool. configurations across the server pool.
11.4. Limited configuration scope 8.4. Limited configuration scope
A simple deployment of QUIC-LB in a cloud provider might use the same A simple deployment of QUIC-LB in a cloud provider might use the same
global QUIC-LB configuration across all its load balancers that route global QUIC-LB configuration across all its load balancers that route
to customer servers. An attacker could then simply become a to customer servers. An attacker could then simply become a
customer, obtain the configuration, and then extract server IDs of customer, obtain the configuration, and then extract server IDs of
other customers' connections at will. other customers' connections at will.
To avoid this, the configuration agent SHOULD issue QUIC-LB To avoid this, the configuration agent SHOULD issue QUIC-LB
configurations to mutually distrustful servers that have different configurations to mutually distrustful servers that have different
keys for encryption algorithms. In many cases, the load balancers keys for encryption algorithms. In many cases, the load balancers
can distinguish these configurations by external IP address. can distinguish these configurations by external IP address.
However, assigning multiple entities to an IP address is However, assigning multiple entities to an IP address is
complimentary with concealing DNS requests (e.g., DoH [RFC8484]) and complimentary with concealing DNS requests (e.g., DoH [RFC8484]) and
the TLS Server Name Indicator (SNI) ([I-D.ietf-tls-esni]) to obscure the TLS Server Name Indicator (SNI) ([I-D.ietf-tls-esni]) to obscure
the ultimate destination of traffic. While the load balancer's the ultimate destination of traffic. While the load balancer's
fallback algorithm (Section 4.2) can use the SNI to make a routing fallback algorithm (Section 3.2) can use the SNI to make a routing
decision on the first packet, there are three ways to route decision on the first packet, there are three ways to route
subsequent packets: subsequent packets:
* all co-tenants can use the same QUIC-LB configuration, leaking the * all co-tenants can use the same QUIC-LB configuration, leaking the
server mapping to each other as described above; server mapping to each other as described above;
* co-tenants can be issued one of up to three configurations * co-tenants can be issued one of up to three configurations
distinguished by the config rotation bits (Section 3.1), exposing distinguished by the config rotation bits (Section 2.1), exposing
information about the target domain to the entire network; or information about the target domain to the entire network; or
* tenants can use 4-tuple routing in their CIDs (in which case they * tenants can use 4-tuple routing in their CIDs (in which case they
SHOULD disable migration in their connections), which neutralizes SHOULD disable migration in their connections), which neutralizes
the value of QUIC-LB but preserves privacy. the value of QUIC-LB but preserves privacy.
When configuring QUIC-LB, administrators must evaluate the privacy When configuring QUIC-LB, administrators must evaluate the privacy
tradeoff considering the relative value of each of these properties, tradeoff considering the relative value of each of these properties,
given the trust model between tenants, the presence of methods to given the trust model between tenants, the presence of methods to
obscure the domain name, and value of address migration in the tenant obscure the domain name, and value of address migration in the tenant
use cases. use cases.
As the plaintext algorithm makes no attempt to conceal the server As the plaintext algorithm makes no attempt to conceal the server
mapping, these deployments SHOULD simply use a common configuration. mapping, these deployments SHOULD simply use a common configuration.
11.5. Stateless Reset Oracle 8.5. Stateless Reset Oracle
Section 21.9 of [RFC9000] discusses the Stateless Reset Oracle Section 21.9 of [RFC9000] discusses the Stateless Reset Oracle
attack. For a server deployment to be vulnerable, an attacking attack. For a server deployment to be vulnerable, an attacking
client must be able to cause two packets with the same Destination client must be able to cause two packets with the same Destination
CID to arrive at two different servers that share the same CID to arrive at two different servers that share the same
cryptographic context for Stateless Reset tokens. As QUIC-LB cryptographic context for Stateless Reset tokens. As QUIC-LB
requires deterministic routing of DCIDs over the life of a requires deterministic routing of DCIDs over the life of a
connection, it is a sufficient means of avoiding an Oracle without connection, it is a sufficient means of avoiding an Oracle without
additional measures. additional measures.
skipping to change at page 32, line 11 skipping to change at page 21, line 5
rotation codepoint, new CIDs might not be unique with respect to rotation codepoint, new CIDs might not be unique with respect to
previous configurations that occupied that codepoint, and therefore previous configurations that occupied that codepoint, and therefore
different clients may have observed the same CID and stateless reset different clients may have observed the same CID and stateless reset
token. A straightforward method of managing stateless reset keys is token. A straightforward method of managing stateless reset keys is
to maintain a separate key for each config rotation codepoint, and to maintain a separate key for each config rotation codepoint, and
replace each key when the configuration for that codepoint changes. replace each key when the configuration for that codepoint changes.
Thus, a server transitions from one config to another, it will be Thus, a server transitions from one config to another, it will be
able to generate correct tokens for connections using either type of able to generate correct tokens for connections using either type of
CID. CID.
11.6. Connection ID Entropy 8.6. Connection ID Entropy
If a server ever reuses a nonce in generating a CID for a given If a server ever reuses a nonce in generating a CID for a given
configuration, it risks exposing sensitive information. Given the configuration, it risks exposing sensitive information. Given the
same server ID, the CID will be identical (aside from a possible same server ID, the CID will be identical (aside from a possible
difference in the first octet). This can risk exposure of the QUIC- difference in the first octet). This can risk exposure of the QUIC-
LB key. If two clients receive the same connection ID, they also LB key. If two clients receive the same connection ID, they also
have each other's stateless reset token unless that key has changed have each other's stateless reset token unless that key has changed
in the interim. in the interim.
The encrypte mode needs to generate different cipher text for each The encrypte mode needs to generate different cipher text for each
skipping to change at page 33, line 11 skipping to change at page 21, line 49
A server that has exhausted its nonces MUST either switch to a A server that has exhausted its nonces MUST either switch to a
different configuration, or if none exists, use the 4-tuple routing different configuration, or if none exists, use the 4-tuple routing
config rotation codepoint. config rotation codepoint.
When sizing a nonce that is to be randomly generated, the When sizing a nonce that is to be randomly generated, the
configuration agent SHOULD consider that a server generating a N-bit configuration agent SHOULD consider that a server generating a N-bit
nonce will create a duplicate about every 2^(N/2) attempts, and nonce will create a duplicate about every 2^(N/2) attempts, and
therefore compare the expected rate at which servers will generate therefore compare the expected rate at which servers will generate
CIDs with the lifetime of a configuration. CIDs with the lifetime of a configuration.
11.7. Shared-State Retry Keys 9. IANA Considerations
The Shared-State Retry Service defined in Section 7.3 describes the
format of retry tokens or new tokens protected and encrypted using
AES128-GCM. Each token includes a 96 bit randomly generated unique
token number, and an 8 bit identifier used to get the AES-GCM
encryption context. The AES-GCM encryption context contains a 128
bit key and an AEAD IV. There are three important security
considerations for these tokens:
* An attacker that obtains a copy of the encryption key will be able
to decrypt and forge tokens.
* Attackers may be able to retrieve the key if they capture a
sufficently large number of retry tokens encrypted with a given
key.
* Confidentiality of the token data will fail if separate tokens
reuse the same 96 bit unique token number and the same key.
To protect against disclosure of keys to attackers, service and
servers MUST ensure that the keys are stored securely. To limit the
consequences of potential exposures, the time to live of any given
key should be limited.
Section 6.6 of [RFC9001] states that "Endpoints MUST count the number
of encrypted packets for each set of keys. If the total number of
encrypted packets with the same key exceeds the confidentiality limit
for the selected AEAD, the endpoint MUST stop using those keys." It
goes on with the specific limit: "For AEAD_AES_128_GCM and
AEAD_AES_256_GCM, the confidentiality limit is 2^23 encrypted
packets; see Appendix B.1." It is prudent to adopt the same limit
here, and configure the service in such a way that no more than 2^23
tokens are generated with the same key.
In order to protect against collisions, the 96 bit unique token
numbers should be generated using a cryptographically secure
pseudorandom number generator (CSPRNG), as specified in Appendix C.1
of the TLS 1.3 specification [RFC8446]. With proper random numbers,
if fewer than 2^40 tokens are generated with a single key, the risk
of collisions is lower than 0.001%.
12. IANA Considerations
There are no IANA requirements. There are no IANA requirements.
13. References 10. References
13.1. Normative References
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 10.1. Normative References
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8999] Thomson, M., "Version-Independent Properties of QUIC", [RFC8999] Thomson, M., "Version-Independent Properties of QUIC",
RFC 8999, DOI 10.17487/RFC8999, May 2021, RFC 8999, DOI 10.17487/RFC8999, May 2021,
<https://www.rfc-editor.org/info/rfc8999>. <https://www.rfc-editor.org/info/rfc8999>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
[TIME_T] "Open Group Standard: Vol. 1: Base Definitions, Issue 7", 10.2. Informative References
IEEE Std 1003.1 , 2018,
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
V1_chap04.html#tag_04_16>.
13.2. Informative References
[I-D.draft-ietf-tls-dtls13] [I-D.draft-ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-43, 30 April 2021, dtls13-43, 30 April 2021,
<https://www.ietf.org/archive/id/draft-ietf-tls- <https://www.ietf.org/archive/id/draft-ietf-tls-
dtls13-43.txt>. dtls13-43.txt>.
[I-D.ietf-tls-dtls-connection-id] [I-D.ietf-tls-dtls-connection-id]
Rescorla, E., Tschofenig, H., Fossati, T., and A. Kraus, Rescorla, E., Tschofenig, H., Fossati, T., and A. Kraus,
"Connection Identifiers for DTLS 1.2", Work in Progress, "Connection Identifier for DTLS 1.2", Work in Progress,
Internet-Draft, draft-ietf-tls-dtls-connection-id-13, 22 Internet-Draft, draft-ietf-tls-dtls-connection-id-13, 22
June 2021, <https://www.ietf.org/archive/id/draft-ietf- June 2021, <https://www.ietf.org/archive/id/draft-ietf-
tls-dtls-connection-id-13.txt>. tls-dtls-connection-id-13.txt>.
[I-D.ietf-tls-esni] [I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft, Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-13, 12 August 2021, draft-ietf-tls-esni-14, 13 February 2022,
<https://www.ietf.org/archive/id/draft-ietf-tls-esni- <https://www.ietf.org/archive/id/draft-ietf-tls-esni-
13.txt>. 14.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, DOI 10.17487/RFC4106, June 2005,
<https://www.rfc-editor.org/info/rfc4106>.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, Security", RFC 4347, DOI 10.17487/RFC4347, April 2006,
<https://www.rfc-editor.org/info/rfc4347>. <https://www.rfc-editor.org/info/rfc4347>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
skipping to change at page 36, line 5 skipping to change at page 23, line 33
<https://www.rfc-editor.org/info/rfc7983>. <https://www.rfc-editor.org/info/rfc7983>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>.
Appendix A. QUIC-LB YANG Model Appendix A. QUIC-LB YANG Model
These YANG models conform to [RFC6020] and express a complete QUIC-LB These YANG models conform to [RFC6020] and express a complete QUIC-LB
configuration. There is one model for the server and one for the configuration. There is one model for the server and one for the
middlebox (i.e the load balancer and/or Retry Service). middlebox (i.e the load balancer and/or Retry Service).
module ietf-quic-lb-server { module ietf-quic-lb-server {
yang-version "1.1"; yang-version "1.1";
namespace "urn:ietf:params:xml:ns:yang:ietf-quic-lb"; namespace "urn:ietf:params:xml:ns:yang:ietf-quic-lb";
prefix "quic-lb"; prefix "quic-lb";
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types.";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types.";
}
organization
"IETF QUIC Working Group";
contact
"WG Web: <http://datatracker.ietf.org/wg/quic>
WG List: <quic@ietf.org>
Authors: Martin Duke (martin.h.duke at gmail dot com)
Nick Banks (nibanks at microsoft dot com)
Christian Huitema (huitema at huitema.net)";
description
"This module enables the explicit cooperation of QUIC servers with
trusted intermediaries without breaking important protocol
features.
Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or import ietf-yang-types {
without modification, is permitted pursuant to, and subject to prefix yang;
the license terms contained in, the Simplified BSD License set reference
forth in Section 4.c of the IETF Trust's Legal Provisions "RFC 6991: Common YANG Data Types.";
Relating to IETF Documents }
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX import ietf-inet-types {
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself prefix inet;
for full legal notices. reference
"RFC 6991: Common YANG Data Types.";
}
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL organization
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', "IETF QUIC Working Group";
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
revision "2022-02-10" { contact
description "WG Web: <http://datatracker.ietf.org/wg/quic>
"Updated to design in version 11 of the draft"; WG List: <quic@ietf.org>
reference
"RFC XXXX, QUIC-LB: Generating Routable QUIC Connection IDs";
}
container quic-lb { Authors: Martin Duke (martin.h.duke at gmail dot com)
presence "The container for QUIC-LB configuration."; Nick Banks (nibanks at microsoft dot com)
Christian Huitema (huitema at huitema.net)";
description description
"QUIC-LB container."; "This module enables the explicit cooperation of QUIC servers with
trusted intermediaries without breaking important protocol
typedef quic-lb-key { features.
type yang:hex-string {
length 47;
}
description
"This is a 16-byte key, represented with 47 bytes";
}
leaf config-id {
type uint8 {
range "0..2";
}
mandatory true;
description
"Identifier for this CID configuration.";
}
leaf first-octet-encodes-cid-length { Copyright (c) 2022 IETF Trust and the persons identified as
type boolean; authors of the code. All rights reserved.
default false;
description
"If true, the six least significant bits of the first CID
octet encode the CID length minus one.";
}
leaf server-id-length { Redistribution and use in source and binary forms, with or
type uint8 { without modification, is permitted pursuant to, and subject to
range "1..15"; the license terms contained in, the Simplified BSD License set
} forth in Section 4.c of the IETF Trust's Legal Provisions
must '. <= (19 - ../nonce-length)' { Relating to IETF Documents
error-message (https://trustee.ietf.org/license-info).
"Server ID and nonce lengths must sum to no more than 19.";
}
mandatory true;
description
"Length (in octets) of a server ID. Further range-limited
by nonce-length.";
}
leaf nonce-length { This version of this YANG module is part of RFC XXXX
type uint8 { (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
range "4..18"; for full legal notices.
}
mandatory true;
description
"Length, in octets, of the nonce. Short nonces mean there will
be frequent configuration updates.";
}
leaf cid-key { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
type quic-lb-key; NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
description 'MAY', and 'OPTIONAL' in this document are to be interpreted as
"Key for encrypting the connection ID."; described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
} they appear in all capitals, as shown here.";
leaf server-id { revision "2022-02-11" {
type yang:hex-string;
must "string-length(.) = 3 * ../../server-id-length - 1";
mandatory true;
description description
"An allocated server ID"; "Updated to design in version 13 of the draft";
reference
"RFC XXXX, QUIC-LB: Generating Routable QUIC Connection IDs";
} }
container retry-service-config { container quic-lb {
presence "The container for QUIC-LB configuration.";
description description
"Configuration of Retry Service. If supported-versions is empty, "QUIC-LB container.";
there is no retry service. If token-keys is empty, it uses the
non-shared-state service. If present, it uses shared-state
tokens.";
leaf-list supported-versions {
type uint32;
description
"QUIC versions that the retry service supports. If empty,
there is no retry service.";
}
leaf unsupported-version-default { typedef quic-lb-key {
type enumeration { type yang:hex-string {
enum allow { length 47;
description "Unsupported versions admitted by default";
}
enum deny {
description "Unsupported versions denied by default";
}
} }
default allow;
description
"Are unsupported versions not in version-exceptions allowed
or denied?";
}
leaf-list version-exceptions {
type uint32;
description
"Exceptions to the default-deny or default-allow rule.";
}
list token-keys {
key "key-sequence-number";
description description
"list of active keys, for key rotation purposes. Existence "This is a 16-byte key, represented with 47 bytes";
implies shared-state format";
leaf key-sequence-number {
type uint8 {
range "0..127";
}
mandatory true;
description
"Identifies the key used to encrypt the token";
}
leaf token-key {
type quic-lb-key;
mandatory true;
description
"16-byte key to encrypt the token";
}
leaf token-iv {
type yang:hex-string {
length 23;
}
mandatory true;
description
"8-byte IV to encrypt the token, encoded in 23 bytes";
}
}
}
}
}
module ietf-quic-lb-middlebox {
yang-version "1.1";
namespace "urn:ietf:params:xml:ns:yang:ietf-quic-lb";
prefix "quic-lb";
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types.";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types.";
}
organization
"IETF QUIC Working Group";
contact
"WG Web: <http://datatracker.ietf.org/wg/quic>
WG List: <quic@ietf.org>
Authors: Martin Duke (martin.h.duke at gmail dot com)
Nick Banks (nibanks at microsoft dot com)
Christian Huitema (huitema at huitema.net)";
description
"This module enables the explicit cooperation of QUIC servers with
trusted intermediaries without breaking important protocol
features.
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
revision "2021-02-10" {
description
"Updated to design in version 11 of the draft";
reference
"RFC XXXX, QUIC-LB: Generating Routable QUIC Connection IDs";
}
container quic-lb {
presence "The container for QUIC-LB configuration.";
description
"QUIC-LB container.";
typedef quic-lb-key {
type yang:hex-string {
length 47;
} }
description
"This is a 16-byte key, represented with 47 bytes";
}
list cid-configs {
key "config-rotation-bits";
description
"List up to three load balancer configurations";
leaf config-rotation-bits { leaf config-id {
type uint8 { type uint8 {
range "0..2"; range "0..2";
} }
mandatory true; mandatory true;
description description
"Identifier for this CID configuration."; "Identifier for this CID configuration.";
} }
leaf first-octet-encodes-cid-length {
type boolean;
default false;
description
"If true, the six least significant bits of the first CID
octet encode the CID length minus one.";
}
leaf server-id-length { leaf server-id-length {
type uint8 { type uint8 {
range "1..15"; range "1..15";
} }
must '. <= (19 - ../nonce-length)' { must '. <= (19 - ../nonce-length)' {
error-message error-message
"Server ID and nonce lengths must sum to no more than 19."; "Server ID and nonce lengths must sum to no more than 19.";
} }
mandatory true; mandatory true;
description description
"Length (in octets) of a server ID. Further range-limited "Length (in octets) of a server ID. Further range-limited
by nonce-length."; by nonce-length.";
} }
leaf nonce-length {
type uint8 {
range "4..18";
}
mandatory true;
description
"Length, in octets, of the nonce. Short nonces mean there will
be frequent configuration updates.";
}
leaf cid-key { leaf cid-key {
type quic-lb-key; type quic-lb-key;
description description
"Key for encrypting the connection ID."; "Key for encrypting the connection ID.";
} }
leaf nonce-length { leaf server-id {
type uint8 { type yang:hex-string;
range "4..18"; must "string-length(.) = 3 * ../../server-id-length - 1";
}
mandatory true; mandatory true;
description description
"Length, in octets, of the nonce. Short nonces mean there "An allocated server ID";
will be frequent configuration updates.";
} }
}
}
list server-id-mappings { module ietf-quic-lb-middlebox {
key "server-id"; yang-version "1.1";
description "Statically allocated Server IDs"; namespace "urn:ietf:params:xml:ns:yang:ietf-quic-lb";
prefix "quic-lb";
leaf server-id { import ietf-yang-types {
type yang:hex-string; prefix yang;
must "string-length(.) = 3 * ../../server-id-length - 1"; reference
mandatory true; "RFC 6991: Common YANG Data Types.";
description }
"An allocated server ID";
} import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types.";
}
leaf server-address { organization
type inet:ip-address; "IETF QUIC Working Group";
mandatory true;
description
"Destination address corresponding to the server ID";
}
}
}
container retry-service-config { contact
description "WG Web: <http://datatracker.ietf.org/wg/quic>
"Configuration of Retry Service. If supported-versions is empty, WG List: <quic@ietf.org>
there is no retry service. If token-keys is empty, it uses the
non-shared-state service. If present, it uses shared-state
tokens.";
leaf-list supported-versions { Authors: Martin Duke (martin.h.duke at gmail dot com)
type uint32; Nick Banks (nibanks at microsoft dot com)
description Christian Huitema (huitema at huitema.net)";
"QUIC versions that the retry service supports. If empty,
there is no retry service.";
}
leaf unsupported-version-default { description
type enumeration { "This module enables the explicit cooperation of QUIC servers with
enum allow { trusted intermediaries without breaking important protocol
description "Unsupported versions admitted by default"; features.
}
enum deny {
description "Unsupported versions denied by default";
}
}
default allow;
description
"Are unsupported versions not in version-exceptions allowed
or denied?";
}
leaf-list version-exceptions { Copyright (c) 2021 IETF Trust and the persons identified as
type uint32; authors of the code. All rights reserved.
description
"Exceptions to the default-deny or default-allow rule.";
}
list token-keys {
key "key-sequence-number";
description
"list of active keys, for key rotation purposes. Existence
implies shared-state format";
leaf key-sequence-number { Redistribution and use in source and binary forms, with or
type uint8 { without modification, is permitted pursuant to, and subject to
range "0..127"; the license terms contained in, the Simplified BSD License set
} forth in Section 4.c of the IETF Trust's Legal Provisions
mandatory true; Relating to IETF Documents
description (https://trustee.ietf.org/license-info).
"Identifies the key used to encrypt the token";
}
leaf token-key { This version of this YANG module is part of RFC XXXX
type quic-lb-key; (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
mandatory true; for full legal notices.
description
"16-byte key to encrypt the token";
}
leaf token-iv { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
type yang:hex-string { NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
length 23; 'MAY', and 'OPTIONAL' in this document are to be interpreted as
} described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
mandatory true; they appear in all capitals, as shown here.";
description
"8-byte IV to encrypt the token, encoded in 23 bytes"; revision "2021-02-11" {
} description
} "Updated to design in version 13 of the draft";
} reference
} "RFC XXXX, QUIC-LB: Generating Routable QUIC Connection IDs";
} }
container quic-lb {
presence "The container for QUIC-LB configuration.";
description
"QUIC-LB container.";
typedef quic-lb-key {
type yang:hex-string {
length 47;
}
description
"This is a 16-byte key, represented with 47 bytes";
}
list cid-configs {
key "config-rotation-bits";
description
"List up to three load balancer configurations";
leaf config-rotation-bits {
type uint8 {
range "0..2";
}
mandatory true;
description
"Identifier for this CID configuration.";
}
leaf server-id-length {
type uint8 {
range "1..15";
}
must '. <= (19 - ../nonce-length)' {
error-message
"Server ID and nonce lengths must sum to no more than 19.";
}
mandatory true;
description
"Length (in octets) of a server ID. Further range-limited
by nonce-length.";
}
leaf cid-key {
type quic-lb-key;
description
"Key for encrypting the connection ID.";
}
leaf nonce-length {
type uint8 {
range "4..18";
}
mandatory true;
description
"Length, in octets, of the nonce. Short nonces mean there
will be frequent configuration updates.";
}
list server-id-mappings {
key "server-id";
description "Statically allocated Server IDs";
leaf server-id {
type yang:hex-string;
must "string-length(.) = 3 * ../../server-id-length - 1";
mandatory true;
description
"An allocated server ID";
}
leaf server-address {
type inet:ip-address;
mandatory true;
description
"Destination address corresponding to the server ID";
}
}
}
}
}
A.1. Tree Diagram A.1. Tree Diagram
This summary of the YANG models uses the notation in [RFC8340]. This summary of the YANG models uses the notation in [RFC8340].
module: ietf-quic-lb-server module: ietf-quic-lb-server
+--rw quic-lb! +--rw quic-lb!
+--rw config-id uint8 +--rw config-id uint8
+--rw first-octet-encodes-cid-length? boolean +--rw first-octet-encodes-cid-length? boolean
+--rw server-id-length uint8 +--rw server-id-length uint8
+--rw nonce-length uint8 +--rw nonce-length uint8
+--rw cid-key? quic-lb-key +--rw cid-key? quic-lb-key
+--rw server-id yang:hex-string +--rw server-id yang:hex-string
+--rw retry-service-config
+--rw supported-versions* uint32
+--rw unsupported-version-default? enumeration
+--rw version-exceptions* uint32
+--rw token-keys* [key-sequence-number]
+--rw key-sequence-number uint8
+--rw token-key quic-lb-key
+--rw token-iv yang:hex-string
module: ietf-quic-lb-middlebox module: ietf-quic-lb-middlebox
+--rw quic-lb! +--rw quic-lb!
+--rw cid-configs* [config-rotation-bits] +--rw cid-configs* [config-rotation-bits]
| +--rw config-rotation-bits uint8 | +--rw config-rotation-bits uint8
| +--rw server-id-length uint8 | +--rw server-id-length uint8
| +--rw cid-key? quic-lb-key | +--rw cid-key? quic-lb-key
| +--rw nonce-length uint8 | +--rw nonce-length uint8
| +--rw server-id-mappings* [server-id] | +--rw server-id-mappings* [server-id]
| +--rw server-id yang:hex-string | +--rw server-id yang:hex-string
| +--rw server-address inet:ip-address | +--rw server-address inet:ip-address
+--rw retry-service-config
+--rw supported-versions* uint32
+--rw unsupported-version-default? enumeration
+--rw version-exceptions* uint32
+--rw token-keys* [key-sequence-number]
+--rw key-sequence-number uint8
+--rw token-key quic-lb-key
+--rw token-iv yang:hex-string
Appendix B. Load Balancer Test Vectors Appendix B. Load Balancer Test Vectors
This section uses the following abbreviations: This section uses the following abbreviations:
cid Connection ID cid Connection ID
cr_bits Config Rotation Bits cr_bits Config Rotation Bits
LB Load Balancer LB Load Balancer
sid Server ID sid Server ID
skipping to change at page 46, line 25 skipping to change at page 30, line 32
example that uses the 16-octet single-pass special case, as well as example that uses the 16-octet single-pass special case, as well as
an instance where the server ID length exceeds the nonce length, an instance where the server ID length exceeds the nonce length,
requiring a fourth decryption pass. requiring a fourth decryption pass.
cr_bits sid nonce cid cr_bits sid nonce cid
0 ed793a ee080dbf 07fbfe05f731b425 0 ed793a ee080dbf 07fbfe05f731b425
1 ed793a51d49b8f5fab65 ee080dbf48 4f010956fb5c1d4d86e010183e0b7d1e 1 ed793a51d49b8f5fab65 ee080dbf48 4f010956fb5c1d4d86e010183e0b7d1e
2 ed793a51d49b8f5f ee080dbf48c0d1e5 904dd2d05a7b0de9b2b9907afb5ecf8cc3 2 ed793a51d49b8f5f ee080dbf48c0d1e5 904dd2d05a7b0de9b2b9907afb5ecf8cc3
0 ed793a51d49b8f5fab ee080dbf48c0d1e55d 127a285a09f85280f4fd6abb434a7159e4d3eb 0 ed793a51d49b8f5fab ee080dbf48c0d1e55d 127a285a09f85280f4fd6abb434a7159e4d3eb
B.3. Shared State Retry Tokens
In this case, the shared-state retry token is issued by retry
service, so the opaque data of shared-state retry token body would be
null (Section 7.3).
LB configuration:
key_seq 0x00
encrypt_key 0x30313233343536373839303132333435
AEAD_IV 0x313233343536373839303132
Shared-State Retry Service Token Body:
ODCIL 0x12
RSCIL 0x10
port 0x1a0a
original_destination_connection_id 0x0c3817b544ca1c94313bba41757547eec937
retry_source_connection_id 0x0301e770d24b3b13070dd5c2a9264307
timestamp 0x0000000060c7bf4d
Shared-State Retry Service Token:
unique_token_number 0x59ef316b70575e793e1a8782
key_sequence 0x00
encrypted_shared_state_retry_service_token_body
0x7d38b274aa4427c7a1557c3fa666945931defc65da387a83855196a7cb73caac1e28e5346fd76868de94f8b62294
AEAD_ICV 0xf91174fdd711543a32d5e959867f9c22
AEAD related parameters:
client_ip_addr 127.0.0.1
client_port 6666
AEAD_nonce 0x68dd025f45616941072ab6b0
AEAD_associated_data 0x7f00000100000000000000000000000059ef316b70575e793e1a878200
Appendix C. Interoperability with DTLS over UDP Appendix C. Interoperability with DTLS over UDP
Some environments may contain DTLS traffic as well as QUIC operating Some environments may contain DTLS traffic as well as QUIC operating
over UDP, which may be hard to distinguish. over UDP, which may be hard to distinguish.
In most cases, the packet parsing rules above will cause a QUIC-LB In most cases, the packet parsing rules above will cause a QUIC-LB
load balancer to route DTLS traffic in an appropriate way. DTLS 1.3 load balancer to route DTLS traffic in an appropriate way. DTLS 1.3
implementations that use the connection_id extension implementations that use the connection_id extension
[I-D.ietf-tls-dtls-connection-id] might use the techniques in this [I-D.ietf-tls-dtls-connection-id] might use the techniques in this
document to generate connection IDs and achieve robust routability document to generate connection IDs and achieve robust routability
skipping to change at page 49, line 36 skipping to change at page 32, line 36
Iyengar, Ladislav Lhotka, Jan Lindblad, Ling Tao Nju, Ilari Iyengar, Ladislav Lhotka, Jan Lindblad, Ling Tao Nju, Ilari
Liusvaara, Kazuho Oku, Udip Pant, Ian Swett, Martin Thomson, Dmitri Liusvaara, Kazuho Oku, Udip Pant, Ian Swett, Martin Thomson, Dmitri
Tikhonov, Victor Vasiliev, and William Zeng Ke all provided useful Tikhonov, Victor Vasiliev, and William Zeng Ke all provided useful
input to this document. input to this document.
Appendix E. Change Log Appendix E. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
E.1. since draft-ietf-quic-load-balancers-11 E.1. since draft-ietf-quic-load-balancers-12
* Separated Retry Service design into a separate draft.
E.2. since draft-ietf-quic-load-balancers-11
* Fixed mistakes in test vectors * Fixed mistakes in test vectors
E.2. since draft-ietf-quic-load-balancers-10 E.3. since draft-ietf-quic-load-balancers-10
* Refactored algorithm descriptions; made the 4-pass algorithm * Refactored algorithm descriptions; made the 4-pass algorithm
easier to implement easier to implement
* Revised test vectors * Revised test vectors
* Split YANG model into a server and middlebox version * Split YANG model into a server and middlebox version
E.3. since draft-ietf-quic-load-balancers-09 E.4. since draft-ietf-quic-load-balancers-09
* Renamed "Stream Cipher" and "Block Cipher" to "Encrypted Short" * Renamed "Stream Cipher" and "Block Cipher" to "Encrypted Short"
and "Encrypted Long" and "Encrypted Long"
* Added section on per-connection state * Added section on per-connection state
* Changed "Encrypted Short" to a 4-pass algorithm. * Changed "Encrypted Short" to a 4-pass algorithm.
* Recommended a random initial nonce when incrementing. * Recommended a random initial nonce when incrementing.
* Clarified what SNI LBs should do with unknown QUIC versions. * Clarified what SNI LBs should do with unknown QUIC versions.
E.4. since draft-ietf-quic-load-balancers-08 E.5. since draft-ietf-quic-load-balancers-08
* Eliminate Dynamic SID allocation * Eliminate Dynamic SID allocation
* Eliminated server use bytes * Eliminated server use bytes
E.5. since draft-ietf-quic-load-balancers-07 E.6. since draft-ietf-quic-load-balancers-07
* Shortened SSCID nonce minimum length to 4 bytes * Shortened SSCID nonce minimum length to 4 bytes
* Removed RSCID from Retry token body * Removed RSCID from Retry token body
* Simplified CID formats * Simplified CID formats
* Shrunk size of SID table * Shrunk size of SID table
E.6. since draft-ietf-quic-load-balancers-06 E.7. since draft-ietf-quic-load-balancers-06
* Added interoperability with DTLS * Added interoperability with DTLS
* Changed "non-compliant" to "unroutable" * Changed "non-compliant" to "unroutable"
* Changed "arbitrary" algorithm to "fallback" * Changed "arbitrary" algorithm to "fallback"
* Revised security considerations for mistrustful tenants * Revised security considerations for mistrustful tenants
* Added retry service considerations for non-Initial packets * Added retry service considerations for non-Initial packets
E.7. since draft-ietf-quic-load-balancers-05 E.8. since draft-ietf-quic-load-balancers-05
* Added low-config CID for further discussion * Added low-config CID for further discussion
* Complete revision of shared-state Retry Token * Complete revision of shared-state Retry Token
* Added YANG model * Added YANG model
* Updated configuration limits to ensure CID entropy * Updated configuration limits to ensure CID entropy
* Switched to notation from quic-transport * Switched to notation from quic-transport
E.8. since draft-ietf-quic-load-balancers-04 E.9. since draft-ietf-quic-load-balancers-04
* Rearranged the shared-state retry token to simplify token * Rearranged the shared-state retry token to simplify token
processing processing
* More compact timestamp in shared-state retry token * More compact timestamp in shared-state retry token
* Revised server requirements for shared-state retries * Revised server requirements for shared-state retries
* Eliminated zero padding from the test vectors * Eliminated zero padding from the test vectors
* Added server use bytes to the test vectors * Added server use bytes to the test vectors
* Additional compliant DCID criteria * Additional compliant DCID criteria
E.9. since-draft-ietf-quic-load-balancers-03 E.10. since-draft-ietf-quic-load-balancers-03
* Improved Config Rotation text * Improved Config Rotation text
* Added stream cipher test vectors * Added stream cipher test vectors
* Deleted the Obfuscated CID algorithm * Deleted the Obfuscated CID algorithm
E.10. since-draft-ietf-quic-load-balancers-02 E.11. since-draft-ietf-quic-load-balancers-02
* Replaced stream cipher algorithm with three-pass version * Replaced stream cipher algorithm with three-pass version
* Updated Retry format to encode info for required TPs * Updated Retry format to encode info for required TPs
* Added discussion of version invariance * Added discussion of version invariance
* Cleaned up text about config rotation * Cleaned up text about config rotation
* Added Reset Oracle and limited configuration considerations * Added Reset Oracle and limited configuration considerations
* Allow dropped long-header packets for known QUIC versions * Allow dropped long-header packets for known QUIC versions
E.11. since-draft-ietf-quic-load-balancers-01 E.12. since-draft-ietf-quic-load-balancers-01
* Test vectors for load balancer decoding * Test vectors for load balancer decoding
* Deleted remnants of in-band protocol * Deleted remnants of in-band protocol
* Light edit of Retry Services section * Light edit of Retry Services section
* Discussed load balancer chains * Discussed load balancer chains
E.12. since-draft-ietf-quic-load-balancers-00 E.13. since-draft-ietf-quic-load-balancers-00
* Removed in-band protocol from the document * Removed in-band protocol from the document
E.13. Since draft-duke-quic-load-balancers-06 E.14. Since draft-duke-quic-load-balancers-06
* Switch to IETF WG draft. * Switch to IETF WG draft.
E.14. Since draft-duke-quic-load-balancers-05 E.15. Since draft-duke-quic-load-balancers-05
* Editorial changes * Editorial changes
* Made load balancer behavior independent of QUIC version * Made load balancer behavior independent of QUIC version
* Got rid of token in stream cipher encoding, because server might * Got rid of token in stream cipher encoding, because server might
not have it not have it
* Defined "non-compliant DCID" and specified rules for handling * Defined "non-compliant DCID" and specified rules for handling
them. them.
* Added psuedocode for config schema * Added psuedocode for config schema
E.15. Since draft-duke-quic-load-balancers-04 E.16. Since draft-duke-quic-load-balancers-04
* Added standard for retry services * Added standard for retry services
E.16. Since draft-duke-quic-load-balancers-03 E.17. Since draft-duke-quic-load-balancers-03
* Renamed Plaintext CID algorithm as Obfuscated CID * Renamed Plaintext CID algorithm as Obfuscated CID
* Added new Plaintext CID algorithm * Added new Plaintext CID algorithm
* Updated to allow 20B CIDs * Updated to allow 20B CIDs
* Added self-encoding of CID length * Added self-encoding of CID length
E.17. Since draft-duke-quic-load-balancers-02 E.18. Since draft-duke-quic-load-balancers-02
* Added Config Rotation * Added Config Rotation
* Added failover mode * Added failover mode
* Tweaks to existing CID algorithms * Tweaks to existing CID algorithms
* Added Block Cipher CID algorithm * Added Block Cipher CID algorithm
* Reformatted QUIC-LB packets * Reformatted QUIC-LB packets
E.18. Since draft-duke-quic-load-balancers-01 E.19. Since draft-duke-quic-load-balancers-01
* Complete rewrite * Complete rewrite
* Supports multiple security levels * Supports multiple security levels
* Lightweight messages * Lightweight messages
E.19. Since draft-duke-quic-load-balancers-00 E.20. Since draft-duke-quic-load-balancers-00
* Converted to markdown * Converted to markdown
* Added variable length connection IDs * Added variable length connection IDs
Authors' Addresses Authors' Addresses
Martin Duke Martin Duke
Google Google
Email: martin.h.duke@gmail.com Email: martin.h.duke@gmail.com
Nick Banks Nick Banks
Microsoft Microsoft
Email: nibanks@microsoft.com Email: nibanks@microsoft.com
Christian Huitema Christian Huitema
Private Octopus Inc. Private Octopus Inc.
Email: huitema@huitema.net Email: huitema@huitema.net
 End of changes. 129 change blocks. 
1167 lines changed or deleted 381 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/