Skip to main content

QUIC-LB: Using Load Balancers to Generate QUIC Connection IDs
draft-duke-quic-load-balancers-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Author Martin Duke
Last updated 2018-02-12
Replaced by draft-ietf-quic-load-balancers
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-duke-quic-load-balancers-00
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]