draft-ietf-quic-load-balancers-07.txt   draft-ietf-quic-load-balancers-08.txt 
QUIC M. Duke QUIC M. Duke
Internet-Draft F5 Networks, Inc. Internet-Draft F5 Networks, Inc.
Intended status: Standards Track N. Banks Intended status: Standards Track N. Banks
Expires: 10 January 2022 Microsoft Expires: 7 April 2022 Microsoft
9 July 2021 4 October 2021
QUIC-LB: Generating Routable QUIC Connection IDs QUIC-LB: Generating Routable QUIC Connection IDs
draft-ietf-quic-load-balancers-07 draft-ietf-quic-load-balancers-08
Abstract Abstract
The QUIC protocol design is resistant to transparent packet The QUIC protocol design is resistant to transparent packet
inspection, injection, and modification by intermediaries. However, inspection, injection, and modification by intermediaries. However,
the server can explicitly cooperate with network services by agreeing the server can explicitly cooperate with network services by agreeing
to certain conventions and/or sharing state with those services. to certain conventions and/or sharing state with those services.
This specification provides a standardized means of solving three This specification provides a standardized means of solving three
problems: (1) maintaining routability to servers via a low-state load problems: (1) maintaining routability to servers via a low-state load
balancer even when the connection IDs in use change; (2) explicit balancer even when the connection IDs in use change; (2) explicit
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 10 January 2022. This Internet-Draft will expire on 7 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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
skipping to change at page 2, line 39 skipping to change at page 2, line 39
3.1. Config Rotation . . . . . . . . . . . . . . . . . . . . . 7 3.1. Config Rotation . . . . . . . . . . . . . . . . . . . . . 7
3.2. Configuration Failover . . . . . . . . . . . . . . . . . 8 3.2. Configuration Failover . . . . . . . . . . . . . . . . . 8
3.3. Length Self-Description . . . . . . . . . . . . . . . . . 8 3.3. Length Self-Description . . . . . . . . . . . . . . . . . 8
3.4. Format . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Format . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Load Balancing Preliminaries . . . . . . . . . . . . . . . . 9 4. Load Balancing Preliminaries . . . . . . . . . . . . . . . . 9
4.1. Unroutable Connection IDs . . . . . . . . . . . . . . . . 9 4.1. Unroutable Connection IDs . . . . . . . . . . . . . . . . 9
4.2. Fallback Algorithms . . . . . . . . . . . . . . . . . . . 10 4.2. Fallback Algorithms . . . . . . . . . . . . . . . . . . . 10
4.3. Server ID Allocation . . . . . . . . . . . . . . . . . . 11 4.3. Server ID Allocation . . . . . . . . . . . . . . . . . . 11
4.3.1. Static Allocation . . . . . . . . . . . . . . . . . . 11 4.3.1. Static Allocation . . . . . . . . . . . . . . . . . . 11
4.3.2. Dynamic Allocation . . . . . . . . . . . . . . . . . 12 4.3.2. Dynamic Allocation . . . . . . . . . . . . . . . . . 12
5. Routing Algorithms . . . . . . . . . . . . . . . . . . . . . 14 4.4. CID format . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Plaintext CID Algorithm . . . . . . . . . . . . . . . . . 14 5. Routing Algorithms . . . . . . . . . . . . . . . . . . . . . 15
5.1.1. Configuration Agent Actions . . . . . . . . . . . . . 14 5.1. Plaintext CID Algorithm . . . . . . . . . . . . . . . . . 15
5.1.2. Load Balancer Actions . . . . . . . . . . . . . . . . 14 5.1.1. Configuration Agent Actions . . . . . . . . . . . . . 15
5.1.3. Server Actions . . . . . . . . . . . . . . . . . . . 14 5.1.2. Load Balancer Actions . . . . . . . . . . . . . . . . 15
5.1.3. Server Actions . . . . . . . . . . . . . . . . . . . 15
5.2. Stream Cipher CID Algorithm . . . . . . . . . . . . . . . 15 5.2. Stream Cipher CID Algorithm . . . . . . . . . . . . . . . 15
5.2.1. Configuration Agent Actions . . . . . . . . . . . . . 15 5.2.1. Configuration Agent Actions . . . . . . . . . . . . . 16
5.2.2. Load Balancer Actions . . . . . . . . . . . . . . . . 15 5.2.2. Load Balancer Actions . . . . . . . . . . . . . . . . 16
5.2.3. Server Actions . . . . . . . . . . . . . . . . . . . 17 5.2.3. Server Actions . . . . . . . . . . . . . . . . . . . 17
5.3. Block Cipher CID Algorithm . . . . . . . . . . . . . . . 17 5.3. Block Cipher CID Algorithm . . . . . . . . . . . . . . . 17
5.3.1. Configuration Agent Actions . . . . . . . . . . . . . 17 5.3.1. Configuration Agent Actions . . . . . . . . . . . . . 18
5.3.2. Load Balancer Actions . . . . . . . . . . . . . . . . 17 5.3.2. Load Balancer Actions . . . . . . . . . . . . . . . . 18
5.3.3. Server Actions . . . . . . . . . . . . . . . . . . . 18 5.3.3. Server Actions . . . . . . . . . . . . . . . . . . . 18
6. ICMP Processing . . . . . . . . . . . . . . . . . . . . . . . 18 6. ICMP Processing . . . . . . . . . . . . . . . . . . . . . . . 18
7. Retry Service . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Retry Service . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Common Requirements . . . . . . . . . . . . . . . . . . . 19 7.1. Common Requirements . . . . . . . . . . . . . . . . . . . 19
7.1.1. Considerations for Non-Initial Packets . . . . . . . 20 7.1.1. Considerations for Non-Initial Packets . . . . . . . 20
7.2. No-Shared-State Retry Service . . . . . . . . . . . . . . 21 7.2. No-Shared-State Retry Service . . . . . . . . . . . . . . 21
7.2.1. Configuration Agent Actions . . . . . . . . . . . . . 21 7.2.1. Configuration Agent Actions . . . . . . . . . . . . . 21
7.2.2. Service Requirements . . . . . . . . . . . . . . . . 21 7.2.2. Service Requirements . . . . . . . . . . . . . . . . 21
7.2.3. Server Requirements . . . . . . . . . . . . . . . . . 23 7.2.3. Server Requirements . . . . . . . . . . . . . . . . . 23
7.3. Shared-State Retry Service . . . . . . . . . . . . . . . 23 7.3. Shared-State Retry Service . . . . . . . . . . . . . . . 24
7.3.1. Token Protection with AEAD . . . . . . . . . . . . . 25 7.3.1. Token Protection with AEAD . . . . . . . . . . . . . 26
7.3.2. Configuration Agent Actions . . . . . . . . . . . . . 26 7.3.2. Configuration Agent Actions . . . . . . . . . . . . . 27
7.3.3. Service Requirements . . . . . . . . . . . . . . . . 26 7.3.3. Service Requirements . . . . . . . . . . . . . . . . 27
7.3.4. Server Requirements . . . . . . . . . . . . . . . . . 27 7.3.4. Server Requirements . . . . . . . . . . . . . . . . . 28
8. Configuration Requirements . . . . . . . . . . . . . . . . . 28 8. Configuration Requirements . . . . . . . . . . . . . . . . . 28
9. Additional Use Cases . . . . . . . . . . . . . . . . . . . . 29 9. Additional Use Cases . . . . . . . . . . . . . . . . . . . . 29
9.1. Load balancer chains . . . . . . . . . . . . . . . . . . 29 9.1. Load balancer chains . . . . . . . . . . . . . . . . . . 29
9.2. Moving connections between servers . . . . . . . . . . . 29 9.2. Moving connections between servers . . . . . . . . . . . 30
10. Version Invariance of QUIC-LB . . . . . . . . . . . . . . . . 29 10. Version Invariance of QUIC-LB . . . . . . . . . . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11.1. Attackers not between the load balancer and server . . . 31 11.1. Attackers not between the load balancer and server . . . 32
11.2. Attackers between the load balancer and server . . . . . 31 11.2. Attackers between the load balancer and server . . . . . 32
11.3. Multiple Configuration IDs . . . . . . . . . . . . . . . 32 11.3. Multiple Configuration IDs . . . . . . . . . . . . . . . 32
11.4. Limited configuration scope . . . . . . . . . . . . . . 32 11.4. Limited configuration scope . . . . . . . . . . . . . . 32
11.5. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 33 11.5. Stateless Reset Oracle . . . . . . . . . . . . . . . . . 33
11.6. Connection ID Entropy . . . . . . . . . . . . . . . . . 33 11.6. Connection ID Entropy . . . . . . . . . . . . . . . . . 34
11.7. Shared-State Retry Keys . . . . . . . . . . . . . . . . 33 11.7. Shared-State Retry Keys . . . . . . . . . . . . . . . . 34
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11.8. Resource Consumption of the SID table . . . . . . . . . 35
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
13.1. Normative References . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
13.2. Informative References . . . . . . . . . . . . . . . . . 35 13.1. Normative References . . . . . . . . . . . . . . . . . . 35
Appendix A. QUIC-LB YANG Model . . . . . . . . . . . . . . . . . 36 13.2. Informative References . . . . . . . . . . . . . . . . . 36
A.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 41 Appendix A. QUIC-LB YANG Model . . . . . . . . . . . . . . . . . 37
Appendix B. Load Balancer Test Vectors . . . . . . . . . . . . . 42 A.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 42
Appendix B. Load Balancer Test Vectors . . . . . . . . . . . . . 43
B.1. Plaintext Connection ID Algorithm . . . . . . . . . . . . 43 B.1. Plaintext Connection ID Algorithm . . . . . . . . . . . . 43
B.2. Stream Cipher Connection ID Algorithm . . . . . . . . . . 44 B.2. Stream Cipher Connection ID Algorithm . . . . . . . . . . 44
B.3. Block Cipher Connection ID Algorithm . . . . . . . . . . 45 B.3. Block Cipher Connection ID Algorithm . . . . . . . . . . 46
B.4. Shared State Retry Tokens . . . . . . . . . . . . . . . . 47 B.4. Shared State Retry Tokens . . . . . . . . . . . . . . . . 46
Appendix C. Interoperability with DTLS over UDP . . . . . . . . 47 Appendix C. Interoperability with DTLS over UDP . . . . . . . . 46
C.1. DTLS 1.0 and 1.2 . . . . . . . . . . . . . . . . . . . . 48 C.1. DTLS 1.0 and 1.2 . . . . . . . . . . . . . . . . . . . . 47
C.2. DTLS 1.3 . . . . . . . . . . . . . . . . . . . . . . . . 48 C.2. DTLS 1.3 . . . . . . . . . . . . . . . . . . . . . . . . 47
C.3. Future Versions of DTLS . . . . . . . . . . . . . . . . . 49 C.3. Future Versions of DTLS . . . . . . . . . . . . . . . . . 48
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 49 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 48
Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 49 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 48
E.1. since draft-ietf-quic-load-balancers-06 . . . . . . . . . 49 E.1. since draft-ietf-quic-load-balancers-07 . . . . . . . . . 49
E.2. since draft-ietf-quic-load-balancers-05 . . . . . . . . . 50 E.2. since draft-ietf-quic-load-balancers-06 . . . . . . . . . 49
E.3. since draft-ietf-quic-load-balancers-04 . . . . . . . . . 50 E.3. since draft-ietf-quic-load-balancers-05 . . . . . . . . . 49
E.4. since-draft-ietf-quic-load-balancers-03 . . . . . . . . . 50 E.4. since draft-ietf-quic-load-balancers-04 . . . . . . . . . 49
E.5. since-draft-ietf-quic-load-balancers-02 . . . . . . . . . 50 E.5. since-draft-ietf-quic-load-balancers-03 . . . . . . . . . 50
E.6. since-draft-ietf-quic-load-balancers-01 . . . . . . . . . 51 E.6. since-draft-ietf-quic-load-balancers-02 . . . . . . . . . 50
E.7. since-draft-ietf-quic-load-balancers-00 . . . . . . . . . 51 E.7. since-draft-ietf-quic-load-balancers-01 . . . . . . . . . 50
E.8. Since draft-duke-quic-load-balancers-06 . . . . . . . . . 51 E.8. since-draft-ietf-quic-load-balancers-00 . . . . . . . . . 50
E.9. Since draft-duke-quic-load-balancers-05 . . . . . . . . . 51 E.9. Since draft-duke-quic-load-balancers-06 . . . . . . . . . 50
E.10. Since draft-duke-quic-load-balancers-04 . . . . . . . . . 51 E.10. Since draft-duke-quic-load-balancers-05 . . . . . . . . . 50
E.11. Since draft-duke-quic-load-balancers-03 . . . . . . . . . 51 E.11. Since draft-duke-quic-load-balancers-04 . . . . . . . . . 51
E.12. Since draft-duke-quic-load-balancers-02 . . . . . . . . . 52 E.12. Since draft-duke-quic-load-balancers-03 . . . . . . . . . 51
E.13. Since draft-duke-quic-load-balancers-01 . . . . . . . . . 52 E.13. Since draft-duke-quic-load-balancers-02 . . . . . . . . . 51
E.14. Since draft-duke-quic-load-balancers-00 . . . . . . . . . 52 E.14. Since draft-duke-quic-load-balancers-01 . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 E.15. Since draft-duke-quic-load-balancers-00 . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
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 12, line 9 skipping to change at page 12, line 9
least one server ID to each server. least one server ID to each server.
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 forward packets with long headers and unroutable DCIDs balancers MUST forward packets with long headers and unroutable DCIDs
using an fallback algorithm as specified in Section 4.2. using an fallback algorithm as specified in Section 4.2.
4.3.2. Dynamic Allocation 4.3.2. Dynamic Allocation
In the dynamic allocation method, the load balancer assigns server In the dynamic allocation method, the load balancer assigns server
IDs dynamically so that configuration does not require fixed server IDs dynamically so that configuration does not require fixed server
ID assignment. This reduces linkability. However, it requires state ID assignment. This reduces linkability and simplifies
at the load balancer that roughly scales with the number of configuration. However, it also limits the length of the server ID
connections, until the server ID codespace is exhausted. and requires the load balancer to lie on the path of outbound
packets. As the server mapping is no longer part of the
configuration, standby load balancers need an out-of-band mechanism
to synchronize server ID allocations in the event of failures of the
primary device.
To summarize, the load balancer forwards incoming Initial packets
arbitrarily and both load balancer and server are sometimes able to
infer a potential server ID allocation from the CID in the packet.
The server can signal acceptance of that allocation by using it
immediately, in which case both entities add it to their permanent
table. Usually, however, the server will reject the allocation by
not using it, in which case it is not added to the permanent
assignment list.
4.3.2.1. Configuration Agent Actions 4.3.2.1. Configuration Agent Actions
The configuration agent does not assign server IDs, but does The configuration agent does not assign server IDs, but does
configure a server ID length and an "LB timeout". The server ID MUST configure a server ID length. The server ID MUST be at least one and
be at least one and no more than seven octets. no more than seven octets. See Section 11.8 for other considerations
if also using the Plaintext CID algorithm.
4.3.2.2. Load Balancer Actions 4.3.2.2. Load Balancer Actions
The load balancer maintains a table of all assigned server IDs and The load balancer maintains a mapping of assigned server IDs to
corresponding routing information, which is initialized empty. These routing information for servers, initialized as empty. This mapping
tables are independent for each operating configuration. is independent for each operating configuration.
The load balancer MUST keep track of the most recent observation of
each server ID, in any sort of packet it forwards, in the table and
delete the entries when the time since that observation exceeds the
LB Timeout.
Note that when the load balancer's table for a configuration is Note that when the load balancer's tables for a configuration are
empty, all incoming DCIDs corresponding to that configuration are empty, all incoming DCIDs corresponding to that configuration are
unroutable by definition. unroutable by definition.
The handling of an unroutable long-header packet depends on the The load balancer processes a long header packet as follows:
reason for unroutability. The load balancer MUST applyt this logic:
* If the config rotation bits do not match a known configuration, * If the config rotation bits do not match a known configuration,
the load balancer routes the packet using a fallback algorithm the load balancer routes the packet using a fallback algorithm
(see Section 4.2). (see Section 4.2). It does not extract a server ID.
* If there is a matching configuration, but the CID is not long * If there is a matching configuration, but the CID is not long
enough to apply the algorithm, the load balancer skips the first enough to apply the algorithm, the load balancer pads the
octet of the CID and then reads a server ID from the following connection ID with zeros to the required length.
octets, up to the server ID length. If this server ID matches a
known server ID for that configuration, it forwards the packet
accordingly and takes no further action. If it does not match, it
routes using a fallback algorithm and adds the new server ID to
that server's table entry.
* If the sole reason for unroutability is that the server ID is not * Otherwise, the load balancer extracts the server ID in accordance
in the load balancer's table, the load balancer routes the packet with the configured algorithm and parameters.
with a fallback algorithm. It adds the decoded server ID to table
entry for the server the algorithm chooses and forwards the packet If the load balancer extracted a server ID already in its mapping, it
accordingly. routes the packet accordingly. If the server ID is not in the
mapping, it routes the packet according to a fallback algorithm and
awaits the first long header the server sends in response.
If the load balancer extracted an unassigned server ID and observes
that the first long header packet the server sends has a Source
Connection ID that encodes the same server ID, it adds that server ID
to the mapping. Otherwise, it takes no action.
4.3.2.3. Server actions 4.3.2.3. Server actions
Each server maintains a list of server IDs assigned to it, Each server maintains a list of server IDs assigned to it,
initialized empty. For each SID, it records the last time it initialized empty.
received any packet with an CID that encoded that SID.
Upon receipt of a packet with a client-generated DCID, the server Upon receipt of a packet with a client-generated DCID, the server
MUST follow these steps in order: MUST follow these steps in order:
* If the config rotation bits do not correspond to a known * If the config rotation bits do not correspond to a known
configuration, do not attempt to extract a server ID. configuration, do not attempt to extract a server ID.
* If the DCID is not long enough to decode using the configured * If the DCID is not long enough to decode using the configured
algorithm, extract a number of octets equal to the server ID algorithm, pad it with zeros to the required length and extract a
length, beginning with the second octet. If the extracted value server ID.
does not match a server ID in the server's list, add it to the
list.
* If the DCID is long enough to decode but the server ID is not in * If the DCID is long enough to decode, extract the server ID.
the server's list, add it to the list.
After any possible SID is extracted, the server processes the packet If the server ID is not already in its list, the server MUST decide
normally. whether or not to immediately use it to encode a CID on the new
connection. If it chooses to use it, it adds the server ID to its
list. If it does not, it MUST NOT use the server ID in future CIDs.
The server SHOULD NOT use more than one CID, unless it is close to
exhausting the nonces for an existing assignment. Note also that the
load balancer may observe a single entity claiming multiple server
IDs because that entity actually represents multiple servers devices
or processors.
The server MUST generate a new connection ID if the client-generated
CID is of insufficient length for the configuration.
The server then processes the packet normally.
When a server needs a new connection ID, it uses one of the server When a server needs a new connection ID, it uses one of the server
IDs in its list to populate the server ID field of that CID. It IDs in its list to populate the server ID field of that CID. It MAY
SHOULD vary this selection to reduce linkability within a connection. vary this selection to reduce linkability within a connection.
After loading a new configuration or long periods of idleness, a After loading a new configuration, a server may not have any
server may not have any available SIDs. This is because an incoming available SIDs. This is because an incoming packet may not contain
packet may not the config rotation bits necessary to extract a server the config rotation bits necessary to extract a server ID in
ID in accordance with the algorithm above. When required to generate accordance with the algorithm above. When required to generate a CID
a CID under these conditions, the server MUST generate CIDs using the under these conditions, the server MUST generate CIDs using the
5-tuple routing codepoint (see Section 3.2. Note that these 5-tuple routing codepoint (see Section 3.2. Note that these
connections will not be robust to client address changes while they connections will not be robust to client address changes while they
use this connection ID. For this reason, a server SHOULD retire use this connection ID. For this reason, a server SHOULD retire
these connection IDs and replace them with routable ones once it these connection IDs and replace them with routable ones once it
receives a client-generated CID that allows it to acquire a server receives a client-generated CID that allows it to acquire a server
ID. As, statistically, one in every four such CIDs can provide a ID. As, statistically, one in every four such CIDs can provide a
server ID, this is typically a short interval. server ID, this is typically a short interval.
If a server has not received a connection ID encoding a particular 4.4. CID format
server ID within the LB timeout, it MUST retire any outstanding CIDs
that use that server ID and cease generating any new ones.
A server SHOULD have a mechanism to stop using some server IDs if the All connection IDs use the following format:
list gets large relative to its share of the codepoint space, so that
these allocations time out and are freed for reuse by servers that QUIC-LB Connection ID {
have recently joined the pool. First Octet (8),
Server ID (..),
Nonce (..),
For Server Use (..),
}
Figure 3: CID Format
Each configuration specifies the length of the Server ID and Nonce
fields, with limits defined for each algorithm.
The Server ID is assigned to each server in accordance with
Section 4.3. Dynamically allocated SIDs are limited to seven octets
or fewer. Statically allocated ones have different limits for each
algorithm.
The Nonce is selected by the server when it generates a CID. As the
name implies, a server MUST use a nonce no more than once when
generating a CID for a given server ID and unique set of
configuration parameters. Limits on the length of the nonce are
different for each algorithm.
The First Octet, Server ID, and Nonce comprise the minimum length
Connection ID for any given algorithm. The load balancer need not
know the full connection ID length to successfully process a packet,
given that it is of minimum size.
The For Server Use field has any value and length chosen by the
server, within the connection ID length limits in the operative QUIC
version. It SHOULD appear random and SHOULD NOT link two connection
IDs to the same connection, or indicate they originate from the same
server.
5. Routing Algorithms 5. Routing Algorithms
Encryption in the algorithms below uses the AES-128-ECB cipher. Encryption in the algorithms below uses the AES-128-ECB cipher.
Future standards could add new algorithms that use other ciphers to Future standards could add new algorithms that use other ciphers to
provide cryptographic agility in accordance with [RFC7696]. QUIC-LB provide cryptographic agility in accordance with [RFC7696]. QUIC-LB
implementations SHOULD be extensible to support new algorithms. implementations SHOULD be extensible to support new algorithms.
5.1. Plaintext CID Algorithm 5.1. Plaintext CID Algorithm
The Plaintext CID Algorithm makes no attempt to obscure the mapping The Plaintext CID Algorithm makes no attempt to obscure the mapping
of connections to servers, significantly increasing linkability. The of connections to servers, significantly increasing linkability.
format is depicted in the figure below.
Plaintext CID {
First Octet (8),
Server ID (8..128),
For Server Use (8..152-len(Server ID)),
}
Figure 3: Plaintext CID Format
5.1.1. Configuration Agent Actions 5.1.1. Configuration Agent Actions
For static SID allocation, the server ID length is limited to 16 For static SID allocation, the server ID length is limited to 16
octets. There are no parameters specific to this algorithm. octets. The nonce length MUST be zero.
5.1.2. Load Balancer Actions 5.1.2. 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. These bytes represent the octets, beginning with the second octet. These bytes represent the
server ID. server ID.
5.1.3. Server Actions 5.1.3. Server Actions
The server chooses how many octets to reserve for its own use, which The server chooses how many octets to reserve for its own use, which
MUST be at least one octet. MUST be at least one octet.
When a server needs a new connection ID, it encodes one of its When a server needs a new connection ID, it encodes one of its
assigned server IDs in consecutive octets beginning with the second. assigned server IDs in consecutive octets beginning with the second.
All other bits in the connection ID, except for the first octet, MAY
be set to any other value. These other bits SHOULD appear random to
observers.
5.2. Stream Cipher CID Algorithm 5.2. Stream Cipher CID Algorithm
The Stream Cipher CID algorithm provides cryptographic protection at The Stream Cipher CID algorithm provides cryptographic protection at
the cost of additional per-packet processing at the load balancer to the cost of additional per-packet processing at the load balancer to
decrypt every incoming connection ID. The CID format is depicted decrypt every incoming connection ID. The CID format is depicted
below. below.
Stream Cipher CID {
First Octet (8),
Nonce (64..120),
Encrypted Server ID (8..128-len(Nonce)),
For Server Use (0..152-len(Nonce)-len(Encrypted Server ID)),
}
Figure 4: Stream Cipher CID Format
5.2.1. Configuration Agent Actions 5.2.1. 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, and determines a server ID length (in octets) sufficiently pool, and determines a server ID length (in octets) sufficiently
large to encode all server IDs, including potential future servers. large to encode all server IDs, including potential future servers.
The configuration agent also selects a nonce length and an 16-octet The nonce length MUST be no fewer than 4 and no more than 16 octets.
AES-ECB key to use for connection ID decryption. The nonce length
MUST be at least 8 octets and no more than 16 octets. The nonce The server ID length and nonce length MUST sum to 19 or fewer octets,
length and server ID length MUST sum to 19 or fewer octets, but and SHOULD sum to 15 or fewer octets to allow space for server use.
SHOULD sum to 15 or fewer to allow space for server use.
5.2.2. Load Balancer Actions 5.2.2. Load Balancer Actions
Upon receipt of a QUIC packet, the load balancer extracts as many of Upon receipt of a QUIC packet, the load balancer extracts as many of
the earliest octets from the destination connection ID as necessary the earliest octets from the destination connection ID as necessary
to match the nonce length. The server ID immediately follows. to match the server ID. The nonce immediately follows.
The load balancer decrypts the nonce and the server ID using the The load balancer decrypts the nonce and the server ID using the
following three pass algorithm: following three pass algorithm:
* Pass 1: The load balancer decrypts the server ID using 128-bit AES * Pass 1: The load balancer decrypts the server ID using 128-bit AES
Electronic Codebook (ECB) mode, much like QUIC header protection. Electronic Codebook (ECB) mode, much like QUIC header protection.
The encrypted nonce octets are zero-padded to 16 octets. AES-ECB The encrypted nonce octets are zero-padded to 16 octets. AES-ECB
encrypts this encrypted nonce using its key to generate a mask encrypts this encrypted nonce using its key to generate a mask
which it applies to the encrypted server id. This provides an which it applies to the encrypted server id. This provides an
intermediate value of the server ID, referred to as server-id intermediate value of the server ID, referred to as server-id
skipping to change at page 17, line 30 skipping to change at page 18, line 5
order. order.
5.3. Block Cipher CID Algorithm 5.3. Block Cipher CID Algorithm
The Block Cipher CID Algorithm, by using a full 16 octets of The Block Cipher CID Algorithm, by using a full 16 octets of
plaintext and a 128-bit cipher, provides higher cryptographic plaintext and a 128-bit cipher, provides higher cryptographic
protection and detection of unroutable connection IDs. However, it protection and detection of unroutable connection IDs. However, it
also requires connection IDs of at least 17 octets, increasing also requires connection IDs of at least 17 octets, increasing
overhead of client-to-server packets. overhead of client-to-server packets.
Block Cipher CID {
First Octet (8),
Encrypted Server ID (8..128),
Encrypted Bits for Server Use (128-len(Encrypted Server ID)),
Unencrypted Bits for Server Use (0..24),
}
Figure 5: Block Cipher CID Format
5.3.1. Configuration Agent Actions 5.3.1. Configuration Agent Actions
If server IDs are statically allocated, the server ID length MUST be The server ID length MUST be no more than 12 octets. The server ID
no more than 12 octets, to provide servers adequate entropy to length and nonce length MUST sum to exactly 16 octets.
generate unique CIDs.
The configuration agent also selects an 16-octet AES-ECB key to use The configuration agent also selects an 16-octet AES-ECB key to use
for connection ID decryption. for connection ID decryption.
5.3.2. Load Balancer Actions 5.3.2. Load Balancer Actions
Upon receipt of a QUIC packet, the load balancer reads the first Upon receipt of a QUIC packet, the load balancer reads the first
octet to obtain the config rotation bits. It then decrypts the octet to obtain the config rotation bits. It then decrypts the
subsequent 16 octets using AES-ECB decryption and the chosen key. subsequent 16 octets using AES-ECB decryption and the chosen key.
The decrypted plaintext contains the server id and opaque server data The decrypted plaintext contains the server id and opaque server data
in that order. The load balancer uses the server ID octets for in that order. The load balancer uses the server ID octets for
routing. routing.
5.3.3. Server Actions 5.3.3. Server Actions
When generating a routable connection ID, the server MUST choose a The server encrypts both its server ID and a nonce in 16-octet block
connection ID length between 17 and 20 octets. The server writes its with the configured AES-ECB key.
server ID into the server ID octets and arbitrary bits into the
remaining bits. These arbitrary bits MAY encode additional
information, and MUST differ between connection IDs. Bits in the
eighteenth, nineteenth, and twentieth octets SHOULD appear
essentially random to observers. The first octet is reserved as
described in Section 3.
The server then encrypts the second through seventeenth octets using
the 128-bit AES-ECB cipher.
6. ICMP Processing 6. ICMP Processing
For protocols where 4-tuple load balancing is sufficient, it is For protocols where 4-tuple load balancing is sufficient, it is
straightforward to deliver ICMP packets from the network to the straightforward to deliver ICMP packets from the network to the
correct server, by reading the echoed IP and transport-layer headers correct server, by reading the echoed IP and transport-layer headers
to obtain the 4-tuple. When routing is based on connection ID, to obtain the 4-tuple. When routing is based on connection ID,
further measures are required, as most QUIC packets that trigger ICMP further measures are required, as most QUIC packets that trigger ICMP
responses will only contain a client-generated connection ID that responses will only contain a client-generated connection ID that
contains no routing information. contains no routing information.
skipping to change at page 22, line 8 skipping to change at page 22, line 15
The path between service and server MUST be free of any potential The path between service and server MUST be free of any potential
attackers. Note that this and other requirements above severely attackers. Note that this and other requirements above severely
restrict the operational conditions in which a no-shared-state retry restrict the operational conditions in which a no-shared-state retry
service can safely operate. service can safely operate.
Retry tokens generated by the service MUST have the format below. Retry tokens generated by the service MUST have the format below.
Non-Shared-State Retry Service Token { Non-Shared-State Retry Service Token {
Token Type (1) = 0, Token Type (1) = 0,
ODCIL (7) = 8..20, ODCIL (7) = 8..20,
RSCIL (8) = 0..20,
Original Destination Connection ID (64..160), Original Destination Connection ID (64..160),
Retry Source Connection ID (0..160),
Opaque Data (..), Opaque Data (..),
} }
Figure 6: Format of non-shared-state retry service tokens Figure 4: Format of non-shared-state retry service tokens
The first bit of retry tokens generated by the service MUST be zero. The first bit of retry tokens generated by the service MUST be zero.
The token has the following additional fields: The token has the following additional fields:
ODCIL: The length of the original destination connection ID from the ODCIL: The length of the original destination connection ID from the
triggering Initial packet. This is in cleartext to be readable for triggering Initial packet. This is in cleartext to be readable for
the server, but authenticated later in the token. The Retry Service the server, but authenticated later in the token. The Retry Service
SHOULD reject any token in which the value is less than 8. SHOULD reject any token in which the value is less than 8.
RSCIL: The retry source connection ID length.
Original Destination Connection ID: This also in cleartext and Original Destination Connection ID: This also in cleartext and
authenticated later. authenticated later.
Retry Source Connection ID: This also in cleartext and authenticated Opaque Data: This data contains the information necessary to
later. authenticate the Retry token in accordance with the QUIC
specification. A straightforward implementation would encode the
Opaque Data: This data MUST contain encrypted information that allows Retry Source Connection ID, client IP address, and a timestamp in the
the retry service to validate the client's IP address, in accordance Opaque Data. A more space-efficient implementation would use the
with the QUIC specification. It MUST also provide a Retry Source Connection ID and Client IP as associated data in an
cryptographically secure means to validate the integrity of the encryption operation, and encode only the timestamp and the
entire token. 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', 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 the retry service MUST validate the token in accordance with the QUIC
specification. specification.
In active mode, the service MUST issue Retry packets for all Client 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 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 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 service MUST validate all tokens with the first bit set to '0'. If
successful, the service MUST forward the packet with the token successful, the service MUST forward the packet with the token
skipping to change at page 23, line 35 skipping to change at page 23, line 44
packets for a QUIC version the retry service understands. It MAY packets for a QUIC version the retry service understands. It MAY
send Retry for QUIC versions the Retry Service does not understand. 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'. 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', 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 it could be from a server-generated NEW_TOKEN frame and should be
processed in accordance with the QUIC specification. If a server processed in accordance with the QUIC specification. If a server
receives an Initial Packet with the first bit to '0', it is a Retry 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 token and the server MUST NOT attempt to validate it. Instead, it
MUST assume the address is validated and MUST extract the Original MUST assume the address is validated, MUST include the packet's
Destination Connection ID and Retry Source Connection ID, assuming Destination Connection ID in a Retry Source Connection ID transport
the format described in Section 7.2.2. 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 7.3. Shared-State Retry Service
A shared-state retry service uses a shared key, so that the server 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 can decode the service's retry tokens. It does not require that all
traffic pass through the Retry service, so servers MAY send Retry traffic pass through the Retry service, so servers MAY send Retry
packets in response to Initial packets that don't include a valid packets in response to Initial packets that don't include a valid
token. token.
Both server and service must have time synchronized with respect to Both server and service must have time synchronized with respect to
one another to prevent tokens being incorrectly marked as expired, one another to prevent tokens being incorrectly marked as expired,
though tight synchronization is unnecessary. though tight synchronization is unnecessary.
The tokens are protected using AES128-GCM AEAD, as explained in The tokens are protected using AES128-GCM AEAD, as explained in
Section 7.3.1. All tokens, generated by either the server or retry Section 7.3.1. All tokens, generated by either the server or retry
service, MUST use the following format, which includes: 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 * A 96 bit unique token number transmitted in clear text, but
protected as part of the AEAD associated data. protected as part of the AEAD associated data.
* An 8 bit token key identifier. * A token body, encoding the Original Destination Connection ID and
the Timestamp, optionally followed by server specific Opaque Data.
* A token body, encoding the Original Destination Connection ID, the
Retry Source Connection ID, and the Timestamp, optionally followed
by server specific Opaque Data.
The token protection uses an 128 bit representation of the source IP The token protection uses an 128 bit representation of the source IP
address from the triggering Initial packet. The client IP address is address from the triggering Initial packet. The client IP address is
16 octets. If an IPv4 address, the last 12 octets are zeroes. 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 If there is a Network Address Translator (NAT) in the server
infrastructure that changes the client IP, the Retry Service MUST infrastructure that changes the client IP, the Retry Service MUST
either be positioned behind the NAT, or the NAT must have the token 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 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 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 a path that does not have an identically configured NAT will fail
address validation. address validation.
The 96 bit unique token number is set to a random value using a The 96 bit unique token number is set to a random value using a
cryptography-grade random number generator. cryptography-grade random number generator.
The token key identifier and the corresponding AEAD key and AEAD IV The token key identifier and the corresponding AEAD key and AEAD IV
are provisioned by the configuration agent. are provisioned by the configuration agent.
The token body is encoded as follows: The token body is encoded as follows:
Shared-State Retry Service Token Body { Shared-State Retry Service Token Body {
ODCIL (8) = 0..20,
RSCIL (8) = 0..20,
[Port (16)],
Original Destination Connection ID (0..160),
Retry Source Connection ID (0..160),
Timestamp (64), Timestamp (64),
[ODCIL (8) = 8..20],
[Original Destination Connection ID (64..160)],
[Port (16)],
Opaque Data (..), Opaque Data (..),
} }
Figure 7: Body of shared-state retry service tokens Figure 5: Body of shared-state retry service tokens
The token body has the following fields: 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 ODCIL: The original destination connection ID length. Tokens in
NEW_TOKEN frames MUST set this field to zero. NEW_TOKEN frames do not have this field.
RSCIL: The retry source connection ID length. Tokens in NEW_TOKEN Original Destination Connection ID: The server or Retry Service
frames MUST set this field to zero. 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 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 packet. This field MUST be present if and only if the ODCIL is
greater than zero. This field is therefore always absent in tokens greater than zero. This field is therefore always absent in tokens
in NEW_TOKEN frames. in NEW_TOKEN frames.
Original Destination Connection ID: The server or Retry Service
copies this from the field in the client Initial packet.
Retry Source Connection ID: The server or Retry service copies this
from the Source Connection ID of the Retry packet.
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]).
Opaque Data: The server may use this field to encode additional Opaque Data: The server may use this field to encode additional
information, such as congestion window, RTT, or MTU. The Retry information, such as congestion window, RTT, or MTU. The Retry
Service MUST have zero-length opaque data. Service MUST have zero-length opaque data.
Some implementations of QUIC encode in the token the Initial Packet Some implementations of QUIC encode in the token the Initial Packet
Number used by the client, in order to verify that the client sends Number used by the client, in order to verify that the client sends
the retried Initial with a PN larger that the triggering Initial. the retried Initial with a PN larger that the triggering Initial.
Such implementations will encode the Initial Packet Number as part of Such implementations will encode the Initial Packet Number as part of
the opaque data. As tokens may be generated by the Service, servers the opaque data. As tokens may be generated by the Service, servers
MUST NOT reject tokens because they lack opaque data and therefore MUST NOT reject tokens because they lack opaque data and therefore
the packet number. 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 7.3.1. Token Protection with AEAD
On the wire, the token is presented as: On the wire, the token is presented as:
Shared-State Retry Service Token { Shared-State Retry Service Token {
Token Type (1),
Key Sequence (7),
Unique Token Number (96), Unique Token Number (96),
Key Sequence (8), Encrypted Shared-State Retry Service Token Body (64..),
Encrypted Shared-State Retry Service Token Body (80..),
AEAD Integrity Check Value (128), AEAD Integrity Check Value (128),
} }
Figure 8: Wire image of shared-state retry service tokens Figure 6: Wire image of shared-state retry service tokens
The tokens are protected using AES128-GCM as follows: The tokens are protected using AES128-GCM as follows:
* The Key Sequence is the 8 bit identifier to retrieve the token key * The Key Sequence is the 7 bit identifier to retrieve the token key
and IV. and IV.
* The AEAD IV, is a 96 bit data which produced by implementer's * The AEAD IV, is a 96 bit data which produced by implementer's
custom AEAD IV derivation function. custom AEAD IV derivation function.
* The AEAD nonce, N, is formed by combining the AEAD IV with the 96 * 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 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 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 OR of the padded unique token number and the AEAD IV forms the
AEAD nonce. AEAD nonce.
* The associated data is a formatted as a pseudo header by combining * 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 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 { Shared-State Retry Service Token Pseudoheader {
IP Address (128), IP Address (128),
Token Type (1),
Key Sequence (7),
Unique Token Number (96), Unique Token Number (96),
Key Sequence (8), [RSCIL (8)],
[Retry Source Connection ID (0..20)],
} }
Figure 9: Psuedoheader for shared-state retry service tokens 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 * The input plaintext for the AEAD is the token body. The output
ciphertext of the AEAD is transmitted in place of the token body. ciphertext of the AEAD is transmitted in place of the token body.
* The AEAD Integrity Check Value(ICV), defined in Section 6 of * The AEAD Integrity Check Value(ICV), defined in Section 6 of
[RFC4106], is computed as part of the AEAD encryption process, and [RFC4106], is computed as part of the AEAD encryption process, and
is verified during decryption. is verified during decryption.
7.3.2. Configuration Agent Actions 7.3.2. Configuration Agent Actions
The configuration agent generates and distributes a "token key", a The configuration agent generates and distributes a "token key", a
"token IV", a key sequence, and the information described in "token IV", a key sequence, and the information described in
Section 7.1. Section 7.1.
7.3.3. Service Requirements 7.3.3. Service Requirements
In inactive mode, the Retry service forwards all packets without In inactive mode, the Retry service forwards all packets without
further inspection or processing. 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 Retry services MUST NOT issue Retry packets except where explicitly
allowed below, to avoid sending a Retry packet in response to a Retry allowed below, to avoid sending a Retry packet in response to a Retry
token. token.
When in active mode, the service MUST generate Retry tokens with the The service MUST generate Retry tokens with the format described
format described above when it receives a client Initial packet with above when it receives a client Initial packet with no token.
no token.
The service SHOULD decrypt incoming tokens. The service SHOULD drop If there is a token of either type, the service MUST attempt to
packets with unknown key sequence, or an AEAD ICV that does not match decrypt it.
the expected value. (By construction, the AEAD ICV will only match
if the client IP Address also matches.)
If the token verification passes, and the ODCIL and RSCIL fields are To decrypt a packet, the service checks the Token Type and constructs
both zero, then this is a NEW_TOKEN token generated by the server. a pseudoheader with the appropriate format for that type, using the
Processing of NEW_TOKEN tokens is subtly different from Retry tokens, bearing packet's Destination Connection ID to populate the Retry
as described below. Source Connection ID field, if any.
The service SHOULD drop a packet containing a token where the ODCIL A token is invalid if:
is greater than zero and less than the minimum number of octets for a
client-generated CID (8 in QUIC version 1). The service also SHOULD
drop a packet containing a token where the ODCIL is zero and RSCIL is
nonzero.
If the Timestamp of a token points to time in the past, the token has * it uses unknown key sequence,
expired; 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. An active Retry service SHOULD drop packets with
expired tokens. If a NEW_TOKEN token, the service MUST generate a
Retry packet in response. It MUST NOT generate a Retry packet in
response to an expired Retry token.
If a Retry token, the service SHOULD drop packets where the port * the AEAD ICV does not match the expected value (By construction,
number encoded in the token does not match the source port in the it will only match if the client IP Address, and any Retry Source
encapsulating UDP header. Connection ID, also matches),
All other packets SHOULD be forwarded to the server. * 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 7.3.4. Server Requirements
When issuing Retry or NEW_TOKEN tokens, the server MUST include the The server MAY issue Retry or NEW_TOKEN tokens in accordance with
client IP address in the authenticated data as specified in [RFC9000]. When doing so, it MUST follow the format above.
Section 7.3.1. The ODCIL and RSCIL fields are zero for NEW_TOKEN
tokens, making them easily distinguishable from Retry tokens.
The server MUST validate all tokens that arrive in Initial packets, The server MUST validate all tokens that arrive in Initial packets,
as they may have bypassed the Retry service. as they may have bypassed the Retry service. It determines validity
using the procedure in Section 7.3.3.
For Retry tokens that follow the format above, servers SHOULD use the If a valid Retry token, the server populates the
timestamp field to apply its expiration limits for tokens. This need original_destination_connection_id transport parameter using the
not be precisely synchronized with the retry service. However, corresponding token field. It populates the
servers MAY allow retry tokens marked as being a few seconds in the retry_source_connection_id transport parameter with the Destination
past, due to possible clock synchronization issues. Connection ID of the packet bearing the token.
After decrypting the token, the server uses the corresponding fields In all other respects, the server processes both valid and invalid
to populate the original_destination_connection_id transport tokens in accordance with [RFC9000].
parameter, with a length equal to ODCIL, and the
retry_source_connection_id transport parameter, with length equal to
RSCIL.
For QUIC versions the service does not support, the server MAY use For QUIC versions the service does not support, the server MAY use
any token format. any token format.
As discussed in [RFC9000], a server MUST NOT send a Retry packet in
response to an Initial packet that contains a retry token.
8. Configuration Requirements 8. Configuration Requirements
QUIC-LB requires common configuration to synchronize understanding of QUIC-LB requires common configuration to synchronize understanding of
encodings and guarantee explicit consent of the server. encodings and guarantee explicit consent of the server.
The load balancer and server MUST agree on a routing algorithm, The load balancer and server MUST agree on a routing algorithm,
server ID allocation method, and the relevant parameters for that server ID allocation method, and the relevant parameters for that
algorithm. algorithm.
All algorithms require a server ID length. If server IDs are All algorithm configurations can have a server ID length, nonce
statically allocated, the load balancer MUST receive the full table length, and key. However, for Plaintext CID, the key is not used and
of mappings, and each server must receive its assigned SID(s), from the nonce length is always zero. For Block Cipher CID, the nonce
the configuration agent. length is directly computed from the server ID length.
For Stream Cipher CID Routing, the servers and load balancer also
MUST have a common understanding of the key and nonce length.
For Block Cipher CID Routing, the servers and load balancer also MUST If server IDs are statically allocated, the load balancer MUST
have a common understanding of the key. 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 Note that server IDs are opaque bytes, not integers, so there is no
notion of network order or host order. notion of network order or host order.
A server configuration MUST specify if the first octet encodes the A server configuration MUST specify if the first octet encodes the
CID length. Note that a load balancer does not need the CID length, CID length. Note that a load balancer does not need the CID length,
as the required bytes are present in the QUIC packet. as the required bytes are present in the QUIC packet.
A full QUIC-LB server configuration MUST also specify the supported A full QUIC-LB server configuration MUST also specify the supported
QUIC versions of any Retry Service. If a shared-state service, the QUIC versions of any Retry Service. If a shared-state service, the
skipping to change at page 33, line 19 skipping to change at page 33, line 40
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.
Note also that when a server starts using a new QUIC-LB config
rotation codepoint, new CIDs might not be unique with respect to
previous configurations that occupied that codepoint, and therefore
different clients may have observed the same CID and stateless reset
token. A straightforward method of managing stateless reset keys is
to maintain a separate key for each config rotation codepoint, and
replace each key when the configuration for that codepoint changes.
Thus, a server transitions from one config to another, it will be
able to generate correct tokens for connections using either type of
CID.
11.6. Connection ID Entropy 11.6. Connection ID Entropy
The Stream Cipher and Block Cipher algorithms need to generate The Stream Cipher and Block Cipher algorithms need to generate
different cipher text for each generated Connection ID instance to different cipher text for each generated Connection ID instance to
protect the Server ID. To do so, at least four octets of the Block protect the Server ID. To do so, at least four octets of the CID are
Cipher CID and at least eight octets of the Stream Cipher CID are
reserved for a nonce that, if used only once, will result in unique reserved for a nonce that, if used only once, will result in unique
cipher text for each Connection ID. cipher text for each Connection ID.
If servers simply increment the nonce by one with each generated If servers simply increment the nonce by one with each generated
connection ID, then it is safe to use the existing keys until any connection ID, then it is safe to use the existing keys until any
server's nonce counter exhausts the allocated space and rolls over to server's nonce counter exhausts the allocated space and rolls over to
zero. Whether or not it implements this method, the server MUST NOT zero. Whether or not it implements this method, the server MUST NOT
reuse a nonce until it switches to a configuration with new keys. reuse a nonce until it switches to a configuration with new keys.
Configuration agents SHOULD implement an out-of-band method to Configuration agents SHOULD implement an out-of-band method to
skipping to change at page 34, line 34 skipping to change at page 35, line 18
here, and configure the service in such a way that no more than 2^23 here, and configure the service in such a way that no more than 2^23
tokens are generated with the same key. tokens are generated with the same key.
In order to protect against collisions, the 96 bit unique token In order to protect against collisions, the 96 bit unique token
numbers should be generated using a cryptographically secure numbers should be generated using a cryptographically secure
pseudorandom number generator (CSPRNG), as specified in Appendix C.1 pseudorandom number generator (CSPRNG), as specified in Appendix C.1
of the TLS 1.3 specification [RFC8446]. With proper random numbers, 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 if fewer than 2^40 tokens are generated with a single key, the risk
of collisions is lower than 0.001%. of collisions is lower than 0.001%.
11.8. Resource Consumption of the SID table
When using Dynamic SID allocation, the load balancer's SID table can
be as large as 2^56 entries, which is prohibitively large. To
constrain the size of this table, servers are encouraged to accept as
few SIDs as possible, so that the remainder do not enter the load
balancer's table.
12. IANA Considerations 12. IANA Considerations
There are no IANA requirements. There are no IANA requirements.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
skipping to change at page 35, line 35 skipping to change at page 36, line 25
[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 Identifiers 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-12, 7 July 2021, draft-ietf-tls-esni-13, 12 August 2021,
<https://www.ietf.org/archive/id/draft-ietf-tls-esni- <https://www.ietf.org/archive/id/draft-ietf-tls-esni-
12.txt>. 13.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 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)", (GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, DOI 10.17487/RFC4106, June 2005, RFC 4106, DOI 10.17487/RFC4106, June 2005,
<https://www.rfc-editor.org/info/rfc4106>. <https://www.rfc-editor.org/info/rfc4106>.
skipping to change at page 38, line 48 skipping to change at page 39, line 39
leaf cid-key { leaf cid-key {
type quic-lb-key; type quic-lb-key;
description description
"Key for encrypting the connection ID. If absent, the "Key for encrypting the connection ID. If absent, the
configuration uses the Plaintext algorithm."; configuration uses the Plaintext algorithm.";
} }
leaf nonce-length { leaf nonce-length {
type uint8 { type uint8 {
range "8..16"; range "4..16";
} }
must '(../cid-key)' { must '(../cid-key)' {
error-message "nonce-length only valid if cid-key is set"; error-message "nonce-length only valid if cid-key is set";
} }
description description
"Length, in octets, of the nonce. If absent when cid-key is "Length, in octets, of the nonce. If absent when cid-key is
present, the configuration uses the Block Cipher Algorithm. present, the configuration uses the Block Cipher Algorithm.
If present along with cid-key, the configurationuses the If present along with cid-key, the configuration uses the
Stream Cipher Algorithm."; Stream Cipher Algorithm.";
} }
leaf lb-timeout { leaf dynamic-sid {
type uint32; type boolean;
description description
"Existence means the configuration uses dynamic Server ID allocation. "If true, server IDs are allocated dynamically.";
Time (in seconds) to keep a server ID allocation if no packets with
that server ID arrive.";
} }
leaf server-id-length { leaf server-id-length {
type uint8 { type uint8 {
range "1..18"; range "1..18";
} }
must '(../lb-timeout and . <= 7) or must '(dynamic-sid and . <= 7) or
(not(../lb-timeout) and (not(../dynamic-sid)) and
(not(../cid-key) and . <= 16) or (not(../cid-key) and . <= 16) or
((../nonce-length) and . <= (19 - ../nonce-length)) or ((../nonce-length) and . <= (19 - ../nonce-length)) or
((../cid-key) and not(../nonce-length) and . <= 12))' { ((../cid-key) and not(../nonce-length) and . <= 12))' {
error-message error-message
"Server ID length too long for routing algorithm and server ID "Server ID length too long for routing algorithm and server ID
allocation method"; allocation method";
} }
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 sid-allocation, cid-key, and nonce-length."; by sid-allocation, cid-key, and nonce-length.";
} }
list server-id-mappings { list server-id-mappings {
when "not(../lb-timeout)"; when "not(../dynamic-sid)";
key "server-id"; key "server-id";
description "Statically allocated Server IDs"; description "Statically allocated Server IDs";
leaf server-id { leaf server-id {
type yang:hex-string; type yang:hex-string;
must "string-length(.) = 3 * ../../server-id-length - 1"; must "string-length(.) = 3 * ../../server-id-length - 1";
mandatory true; mandatory true;
description description
"An allocated server ID"; "An allocated server ID";
} }
skipping to change at page 41, line 6 skipping to change at page 41, line 43
"Exceptions to the default-deny or default-allow rule."; "Exceptions to the default-deny or default-allow rule.";
} }
list token-keys { list token-keys {
key "key-sequence-number"; key "key-sequence-number";
description description
"list of active keys, for key rotation purposes. Existence implies "list of active keys, for key rotation purposes. Existence implies
shared-state format"; shared-state format";
leaf key-sequence-number { leaf key-sequence-number {
type uint8; type uint8 {
range "0..127";
}
mandatory true; mandatory true;
description description
"Identifies the key used to encrypt the token"; "Identifies the key used to encrypt the token";
} }
leaf token-key { leaf token-key {
type quic-lb-key; type quic-lb-key;
mandatory true; mandatory true;
description description
"16-byte key to encrypt the token"; "16-byte key to encrypt the token";
skipping to change at page 42, line 13 skipping to change at page 42, line 35
This summary of the YANG model uses the notation in [RFC8340]. This summary of the YANG model uses the notation in [RFC8340].
module: ietf-quic-lb module: ietf-quic-lb
+--rw quic-lb +--rw quic-lb
+--rw cid-configs* +--rw cid-configs*
| [config-rotation-bits] | [config-rotation-bits]
| +--rw config-rotation-bits uint8 | +--rw config-rotation-bits uint8
| +--rw first-octet-encodes-cid-length? boolean | +--rw first-octet-encodes-cid-length? boolean
| +--rw cid-key? yang:hex-string | +--rw cid-key? yang:hex-string
| +--rw nonce-length? uint8 | +--rw nonce-length? uint8
| +--rw lb-timeout? uint32 | +--rw dynamic-sid boolean
| +--rw server-id-length uint8 | +--rw server-id-length uint8
| +--rw server-id-mappings*? | +--rw server-id-mappings*?
| | [server-id] | | [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
+--ro retry-service-config +--ro retry-service-config
| +--rw supported-versions* | +--rw supported-versions*
| | +--rw version uint32 | | +--rw version uint32
| +--rw unsupported-version-default enumeration {allow deny} | +--rw unsupported-version-default enumeration {allow deny}
| +--rw version-exceptions* | +--rw version-exceptions*
skipping to change at page 45, line 49 skipping to change at page 46, line 4
cid 3df1d90ad5ccd5f8f475f040e90aeca09ec9839d sid b98b1fff su c9839d cid 3df1d90ad5ccd5f8f475f040e90aeca09ec9839d sid b98b1fff su c9839d
LB configuration: cr_bits 0x0 length_self_encoding: y nonce_len 8 sid_len 5 LB configuration: cr_bits 0x0 length_self_encoding: y nonce_len 8 sid_len 5
key 484b2ed942d9f4765e45035da3340423 key 484b2ed942d9f4765e45035da3340423
cid 0da995b7537db605bfd3a38881ae sid 391a7840dc su cid 0da995b7537db605bfd3a38881ae sid 391a7840dc su
cid 0ed8d02d55b91d06443540d1bf6e98 sid 10f7f7b284 su 98 cid 0ed8d02d55b91d06443540d1bf6e98 sid 10f7f7b284 su 98
cid 0f3f74be6d46a84ccb1fd1ee92cdeaf2 sid 0606918fc0 su eaf2 cid 0f3f74be6d46a84ccb1fd1ee92cdeaf2 sid 0606918fc0 su eaf2
cid 1045626dbf20e03050837633cc5650f97c sid e505eea637 su 50f97c cid 1045626dbf20e03050837633cc5650f97c sid e505eea637 su 50f97c
cid 11bb9a17f691ab446a938427febbeb593eaa sid 99343a2a96 su eb593eaa cid 11bb9a17f691ab446a938427febbeb593eaa sid 99343a2a96 su eb593eaa
B.3. Block Cipher Connection ID Algorithm B.3. Block Cipher Connection ID Algorithm
LB configuration: cr_bits 0x0 length_self_encoding: y sid_len 1
key 411592e4160268398386af84ea7505d4
cid 10564f7c0df399f6d93bdddb1a03886f25 sid 23 su 05231748a80884ed58007847eb9fd0
cid 10d5c03f9dd765d73b3d8610b244f74d02 sid 15 su 76cd6b6f0d3f0b20fc8e633e3a05f3
cid 108ca55228ab23b92845341344a2f956f2 sid 64 su 65c0ce170a9548717498b537cb8790
cid 10e73f3d034aef2f6f501e3a7693d6270a sid 07 su f9ad10c84cc1e89a2492221d74e707
cid 101a6ce13d48b14a77ecfd365595ad2582 sid 6c su 76ce4689b0745b956ef71c2608045d
LB configuration: cr_bits 0x0 length_self_encoding: n sid_len 2
key 92ce44aecd636aeeff78da691ef48f77
cid 20aa09bc65ed52b1ccd29feb7ef995d318 sid a52f su 99278b92a86694ff0ecd64bc2f73 In each case below, the server is using a plain text nonce value of
cid 30b8dbef657bd78a2f870e93f9485d5211 sid 6c49 su 7381c8657a388b4e9594297afe96 zero.
cid 043a8137331eacd2e78383279b202b9a6d sid 4188 su 5ac4b0e0b95f4e7473b49ee2d0dd
cid 3ba71ea2bcf0ab95719ab59d3d7fde770d sid 8ccc su 08728807605db25f2ca88be08e0f
cid 37ef1956b4ec354f40dc68336a23d42b31 sid c89d su 5a3ccd1471caa0de221ad6c185c0
LB configuration: cr_bits 0x0 length_self_encoding: y sid_len 3
key 5c49cb9265efe8ae7b1d3886948b0a34
cid 10efcffc161d232d113998a49b1dbc4aa0 sid 0690b3 su 958fc9f38fe61b83881b2c5780
cid 10fc13bdbcb414ba90e391833400c19505 sid 031ac3 su 9a55e1e1904e780346fcc32c3c
cid 10d3cc1efaf5dc52c7a0f6da2746a8c714 sid 572d3a su ff2ec9712664e7174dc03ca3f8
cid 107edf37f6788e33c0ec7758a485215f2b sid 562c25 su 02c5a5dcbea629c3840da5f567
cid 10bc28da122582b7312e65aa096e9724fc sid 2fa4f0 su 8ae8c666bfc0fc364ebfd06b9a
LB configuration: cr_bits 0x0 length_self_encoding: n sid_len 4
key e787a3a491551fb2b4901a3fa15974f3
cid 26125351da12435615e3be6b16fad35560 sid 0cb227d3 su 65b40b1ab54e05bff55db046
cid 14de05fc84e41b611dfbe99ed5b1c9d563 sid 6a0f23ad su d73bee2f3a7e72b3ffea52d9
cid 1306052c3f973db87de6d7904914840ff1 sid ca21402d su 5829465f7418b56ee6ada431
cid 1d202b5811af3e1dba9ea2950d27879a92 sid b14e1307 su 4902aba8b23a5f24616df3cf
cid 26538b78efc2d418539ad1de13ab73e477 sid a75e0148 su 0040323f1854e75aeb449b9f
LB configuration: cr_bits 0x0 length_self_encoding: y sid_len 5 TBD
key d5a6d7824336fbe0f25d28487cdda57c
cid 10a2794871aadb20ddf274a95249e57fde sid 82d3b0b1a1 su 0935471478c2edb8120e60
cid 108122fe80a6e546a285c475a3b8613ec9 sid fbcc902c9d su 59c47946882a9a93981c15
cid 104d227ad9dd0fef4c8cb6eb75887b6ccc sid 2808e22642 su 2a7ef40e2c7e17ae40b3fb
cid 10b3f367d8627b36990a28d67f50b97846 sid 5e018f0197 su 2289cae06a566e5cb6cfa4
cid 1024412bfe25f4547510204bdda6143814 sid 8a8dd3d036 su 4b12933a135e5eaaebc6fd
B.4. Shared State Retry Tokens B.4. Shared State Retry Tokens
In this case, the shared-state retry token is issued by retry 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 service, so the opaque data of shared-state retry token body would be
null (Section 7.3). null (Section 7.3).
LB configuration: LB configuration:
key_seq 0x00 key_seq 0x00
encrypt_key 0x30313233343536373839303132333435 encrypt_key 0x30313233343536373839303132333435
AEAD_IV 0x313233343536373839303132 AEAD_IV 0x313233343536373839303132
skipping to change at page 49, line 49 skipping to change at page 49, line 5
Manasi Deval, Erik Fuller, Toma Gavrichenkov, Jana Iyengar, Subodh Manasi Deval, Erik Fuller, Toma Gavrichenkov, Jana Iyengar, Subodh
Iyengar, Ladislav Lhotka, Jan Lindblad, Ling Tao Nju, Kazuho Oku, Iyengar, Ladislav Lhotka, Jan Lindblad, Ling Tao Nju, Kazuho Oku,
Udip Pant, Martin Thomson, Dmitri Tikhonov, Victor Vasiliev, and Udip Pant, Martin Thomson, Dmitri Tikhonov, Victor Vasiliev, and
William Zeng Ke all provided useful input to this document. William Zeng Ke all provided useful 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-06 E.1. since draft-ietf-quic-load-balancers-07
* Shortened SSCID nonce minimum length to 4 bytes
* Removed RSCID from Retry token body
* Simplified CID formats
* Shrunk size of SID table
E.2. 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.2. since draft-ietf-quic-load-balancers-05 E.3. 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.3. since draft-ietf-quic-load-balancers-04 E.4. 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.4. since-draft-ietf-quic-load-balancers-03 E.5. 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.5. since-draft-ietf-quic-load-balancers-02 E.6. 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.6. since-draft-ietf-quic-load-balancers-01 E.7. 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.7. since-draft-ietf-quic-load-balancers-00 E.8. since-draft-ietf-quic-load-balancers-00
* Removed in-band protocol from the document * Removed in-band protocol from the document
E.8. Since draft-duke-quic-load-balancers-06 E.9. Since draft-duke-quic-load-balancers-06
* Switch to IETF WG draft. * Switch to IETF WG draft.
E.9. Since draft-duke-quic-load-balancers-05 E.10. 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.10. Since draft-duke-quic-load-balancers-04 E.11. Since draft-duke-quic-load-balancers-04
* Added standard for retry services * Added standard for retry services
E.11. Since draft-duke-quic-load-balancers-03 E.12. 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.12. Since draft-duke-quic-load-balancers-02 E.13. 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.13. Since draft-duke-quic-load-balancers-01 E.14. Since draft-duke-quic-load-balancers-01
* Complete rewrite * Complete rewrite
* Supports multiple security levels * Supports multiple security levels
* Lightweight messages * Lightweight messages
E.14. Since draft-duke-quic-load-balancers-00 E.15. 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
F5 Networks, Inc. F5 Networks, Inc.
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
 End of changes. 115 change blocks. 
337 lines changed or deleted 347 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/