QUIC WG M. Duke
Internet Draft F5 Networks
Intended status: Standards Track February 12, 2018
Expires: August 12, 2018
QUIC-LB: Using Load Balancers to Generate QUIC Connection IDs
draft-duke-quic-load-balancers-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 12, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Duke Expires August 12, 2017 [Page 1]
Internet-Draft QUIC-LB February 2018
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
QUIC connection IDs allow continuation of connections across
address/port 5-tuple changes, and can store routing information for
stateless or low-state layer 4 load balancers. They are also meant
to prevent linkability of connections across deliberate address
migration through the use of protected communications between client
and server. This creates issues for load-balancing intermediaries.
This specification standardizes the communication between load
balancers and servers to overcome these issues in a protocol called
QUIC-LB.
Table of Contents
1. Introduction...................................................3
1.1. Terminology...............................................3
2. Protocol Objectives............................................4
2.1. Simplicity................................................4
2.2. Security..................................................4
2.3. Robustness to Middleboxes.................................4
3. Protocol Design................................................4
3.1. Connection ID Generation..................................4
3.2. Message Exchange..........................................5
3.3. Load Balancer Trust.......................................6
3.4. Servers with Zero Stock...................................6
4. Message Format.................................................6
4.1. NEW_IDS message...........................................6
4.2. ID_STOCK message..........................................7
5. Chained Load Balancers.........................................8
6. Security Considerations........................................8
7. IANA Considerations............................................8
8. References.....................................................9
8.1. Normative References......................................9
8.2. Informative References....................................9
9. Acknowledgments................................................9
Appendix A. Alternate Approaches to server/load balancer
coordination problems............................................10
A.1. Terminating proxies......................................10
A.2. Unified control of load balancer and server..............10
A.3. Synchronized Algorithms..................................10
Duke Expires August 12, 2018 [Page 2]
Internet-Draft QUIC-LB February 2018
1. Introduction
Server-generated connection IDs create a potential need for out-of-
band communication. QUIC packets usually contain a connection ID to
allow endpoints to associate packets with different
address/port/protocol 5-tuples to the same connection context. This
feature makes connections robust in the event of NAT rebinding.
QUIC allows servers (or load balancers) to designate an initial
connection ID to encode useful routing information for load
balancers. It also encourages servers, in packets protected by
cryptography, to provide additional connection IDs to the client.
This allows clients that know they are going to change IP address or
port to use a separate connection ID on the new path, thus reducing
linkability as clients move through the world.
There is a tension between the requirements to provide routing
information and mitigate linkability. Ultimately, because new
connection IDs are in protected packets, they must be generated at
the server if the load balancer does not have access to the
connection keys. However, it is the load balancer that has the
context necessary to generate a connection ID that encodes useful
routing information. In the absence of any shared state between load
balancer and server, the load balancer must maintain a relatively
expensive table of server-generated connection IDs, and will not
route packets correctly if they use a connection ID that was
originally communicated in a protected NEW_CONNECTION_ID frame.
This specification provides a method of coordination between QUIC
servers and layer 4 load balancers to support connection IDs that
encode routing information. It describes desirable properties of a
solution, and then specifies a protocol that provides those
properties.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying significance described in RFC 2119.
In this document, "client" and "server" refer to the endpoints of a
QUIC connection unless otherwise indicated. A "load balancer" is an
intermediary for that connection that does not possess QUIC
Duke Expires August 12, 2018 [Page 3]
Internet-Draft QUIC-LB February 2018
connection keys, but it may rewrite IP addresses or conduct other IP
or UDP processing. In most respects, the load balancer behaves as a
client in a QUIC-LB connection, but is always referred to as a "load
balancer" below to avoid confusion.
2. Protocol Objectives
2.1. Simplicity
QUIC is intended to provide unlinkability across connection
migration, but servers are under no obligation to provide connection
IDs to enable this. 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 choose between terminating the connection during
migration or remaining linkable.
The solution should be both simple to implement and require little
additional infrastructure for cryptographic keys, etc.
2.2. Security
The path between load balancer and server may not be free of
observers from which the client wishes to avoid linkability.
Similarly, malicious hosts could spoof a trusted load balancer to
provide connection IDs that are linkable. Therefore, coordination
messages must be encrypted, and there must be some way for servers
to authenticate the load balancer's messages.
2.3. Robustness to Middleboxes
The path between load balancer and server may transit multiple
domains. It is therefore advantageous to make messages resemble QUIC
traffic as much as possible, as any viable path must obviously admit
QUIC traffic.
3. Protocol Design
3.1. Connection ID Generation
Load balancers MAY use connection IDs to encode routing information
to the destination server. This encoding MAY be opaque to the
destination server and SHOULD be opaque to all other hosts.
The encoding scheme MUST be able to generate enough connection IDs
for each server to have at least two for every QUIC connection
concurrently assigned to it.
Duke Expires August 12, 2018 [Page 4]
Internet-Draft QUIC-LB February 2018
The encoding SHOULD maximize the cryptographic distance between
connection IDs intended for the same server.
The encoding SHOULD NOT vary with the number of active servers, as
the connection ID remains routable even if other servers boot up or
suffer an outage.
A representative encoding that meets these requirements might
concatenate the server's IPv4 address and a monotonically increasing
sequence number, and then encrypt the result to obtain the
connection ID. For any incoming QUIC packet, the load balancer would
decrypt the connection ID to extract the server IP address. There
would be different routing rules for (readily identifiable) Initial
packets that contain an (essentially random) client-generated
connection ID.
3.2. Message Exchange
No message in this protocol is sent with reliability assurances. For
all messages the load balancer uses an ephemeral UDP port, and the
server uses UDP port 443. All messages are sent as encrypted records
in an established DTLS connection.
The best practice for servers is to always provide at least one
connection ID to clients beyond the one it is currently using. Load
balancers SHOULD monitor the usage of these connection IDs and the
number of active connections for each server. A "used" connection ID
is one that has been used in the Connection ID field of a QUIC
header, as opposed to the QUIC NEW_CONNECTION_ID frame. When the
stock of unused connection IDs is low, load balancers SHOULD send a
NEW_IDS message to that server.
Servers SHOULD periodically send a ID_STOCK message to the load
balancer to synchronize the load balancer's view of its current
unused connection IDs. This allows the shared state to recover from
lost NEW_CONN_ID messages.
Servers MAY increase the rate at which they send ID_STOCK messages
as their stocks shrink, relative to the usage rate of connection
IDs, to accelerate delivery of new IDs and overcome packet losses.
Note that the Connection IDs provided by the load balancer can be
used by any connection terminated at the server. There is no need
for the load balancer to designate specific QUIC connections for
each ID. As a result, load balancers cannot necessarily associate
packets before and after an IP address migration to the same
connection.
Duke Expires August 12, 2018 [Page 5]
Internet-Draft QUIC-LB February 2018
3.3. Load Balancer Trust
Message authentication and encryption is achieved using DTLS 1.2 or
1.3 ([RFC6347] or [I-D.ietf-tls-dtls13]). Load balancers MUST
initiate the handshake as the client, as some firewalls may block
outbound connections from the server. Servers MUST request a Client
Certificate to verify that the Load Balancer meets the trust
requirements to potentially introduce linkable Connection IDs into
the system.
Servers MUST NOT accept DTLS connections from load balancers for
which they do not have configured trust relationships.
3.4. Servers with Zero Stock
If the server has an active DTLS connection with a lower balancer,
but has zero stock, the server SHOULD use the connection ID provided
in the Initial packet and SHOULD NOT generate QUIC NEW_CONNECTION_ID
frames. Therefore, clients that knowingly change IP address or port
are forced to choose between terminating the connection and
traceably changing IP address.
Servers with no such trust relationship MUST behave in accordance
with the QUIC transport spec [ID-ietf-quic-transport], generating
new connection IDs at will.
4. Message Format
All messages below are encapsulated in DTLS Records.
The type field is not strictly necessary to resolve ambiguity, as
each message type is only sent by one entity in the connection.
However, the type byte allows future extension of the protocol.
4.1. NEW_IDS message
Load Balancers MUST ignore NEW_IDS messages.
Duke Expires August 12, 2018 [Page 6]
Internet-Draft QUIC-LB February 2018
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Connection ID 1 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Connection ID 2 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Connection ID n +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 NEW_IDS Message
Other data MUST NOT be in the DTLS Record, so the number of
Connection IDs present in the packet is determined by the Record
length. Note that connection IDs are strings, not integers that are
expressed in host or network order.
4.2. ID_STOCK message
Servers MUST ignore received ID_STOCK messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x02 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused Connection IDs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 ID_STOCK Message
This message simply reports the number of unused connection IDs in a
32-bit integer in Network order. Load Balancers MUST update their
estimate of server stock based on this message, as some connection
IDs may have been lost in transit.
Duke Expires August 12, 2018 [Page 7]
Internet-Draft QUIC-LB February 2018
5. Chained Load Balancers
In some deployments, there may be multiple tiers of trusted load
balancers in the path between client and server. All load balancers
using connection ID to encode routing information MUST agree on how
to decode connection IDs as routing instructions. Due to QUIC packet
authentication, connection IDs of established QUIC connections
cannot be rewritten in flight without access to the QUIC connection
keys.
A server configured to trust multiple load balancers MAY accept DTLS
connections from all of them and use provided Connection IDs
interchangeably. It SHOULD report its entire stock of connection IDs
to all trusted load balancers, rather than the number of IDs issued
from each source.
6. Security Considerations
QUIC-LB is intended to preserve routability and prevent linkability,
so attacks on the protocol would compromise at least one of these
objectives.
Injection of connection IDs could either break routability (by
diverting flows to a server with no QUIC connection context) or
allow linkability (by allowing observers to determine that two
connection IDs originate from the same server, and that one begins
at roughly the same time that the other disappears). Use of DTLS
authentication mechanisms, at both load balancer and server, are
meant to mitigate this risk.
Cleartext connection IDs would also allow observers to map
connection IDs to a specific server, potentially allowing
linkability. QUIC-LB utilizes DTLS-based encryption to avoid this.
QUIC-LB depends on DTLS, and therefore on Public Key Infrastructure.
Any compromise of the PKI would allow untrusted middleboxes to
successfully execute either of the attacks above.
7. IANA Considerations
There are no IANA requirements.
Duke Expires August 12, 2018 [Page 8]
Internet-Draft QUIC-LB February 2018
8. References
8.1. Normative References
[I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP-
Based Multiplexed and Secure Transport", draft-ietf-quic-
transport-09 (work in progress), January 2018.
[I-D.ietf-tls-dtls13] Rescorla, E., Tschofenig, H., Modadugu, M,
"The Datagram Transport Layer Security (DTLS) Protocol
Version 1.3", draft-ietf-tls-dtls13-01 (work in progress),
July 2017.
[RFC6347] Rescorla, E., " Datagram Transport Layer Security Version
1.2", RFC 6347, January 2012.
8.2. Informative References
None.
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Duke Expires August 12, 2018 [Page 9]
Internet-Draft QUIC-LB February 2018
Appendix A. Alternate Approaches to server/load balancer coordination
problems.
A.1. Terminating proxies
A load balancer that terminates the QUIC connection at the
application layer, with separate connections to client and server,
can generate new connection IDs on its own and has enough state to
not require connection ID to route packets. However, this approach
cannot work if the load balancer is not a trusted intermediary with
the TLS certificates required to terminate a QUIC connection.
Moreover, the load balancer may not have sufficient resources to
keep the state for every connection that traverses it.
A.2. Unified control of load balancer and server
Obviously, a vendor or network operator with access to the source
code of both the load balancer and the server can develop a
proprietary method to share the necessary state. This is difficult
to implement for network operators that purchase their servers and
load balancers from different vendors.
A.3. Synchronized Algorithms
If server understands how the load balancer encodes routing
information via a standard algorithm, it can generate new connection
IDs that preserve routability. However, if the algorithm is not
cryptographically secure this erodes protection against linkability.
Ultimately, this approach requires a key rotation scheme to remain
secure.
Duke Expires August 12, 2018 [Page 10]
Internet-Draft QUIC-LB February 2018
Authors' Addresses
Martin Duke
F5 Networks
401 Elliott Ave W.
Seattle, WA, USA 98119
Email: m.duke@f5.com
Duke Expires August 12, 2018 [Page 11]