Internet DRAFT - draft-banks-quic-cibir
draft-banks-quic-cibir
QUIC N. Banks
Internet-Draft Microsoft Corporation
Intended status: Experimental 1 March 2022
Expires: 2 September 2022
QUIC Connection ID Based Initial Routing
draft-banks-quic-cibir-01
Abstract
This document defines an extension to the QUIC transport protocol to
consistently route all packets from a client to the appropriate
server on a shared UDP port.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on 2 September 2022.
Copyright Notice
Copyright (c) 2022 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 (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Banks Expires 2 September 2022 [Page 1]
Internet-Draft QUIC-CIBIR March 2022
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 2
2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Transport Parameter . . . . . . . . . . . . . . . . . . . 3
2.2. Packet Encoding and Routing . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4.1. QUIC Transport Parameter . . . . . . . . . . . . . . . . 4
5. Normative References . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction
Several scenarios exist where multiple independent or isolated
servers need to run in the same environment, but cannot use
independent local UDP ports. For instance, in server deployments
that have hundreds or thousands of machines, each with tens or
hundreds of different QUIC servers running on them, the server
infrastructure may not be able to support the number of local UDP
ports it would require to give each server a unique one.
Additionally, because of infrastructure requirements additional IP
addresses may not be able to be used as a solution either.
In these scenarios, the server infrastructure needs a way to
essentially NAT QUIC packets on a shared local UDP port between all
servers using that port. This document defines a mechanism for using
QUIC connection IDs to encode the necessary information for all
client to server QUIC packets to be correctly routed to the
appropriate server. A cooperating client can then use this to
specifically target a server on a shared port.
1.1. Terms and Definitions
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Specification
Banks Expires 2 September 2022 [Page 2]
Internet-Draft QUIC-CIBIR March 2022
2.1. Transport Parameter
Support for encoding CIBIR information is negotiated by means of a
QUIC Transport Parameter (name=cibir_encoding, value=0x1000). The
cibir_encoding transport parameter consists of two integer values
(represented as variable-length integers) that represent the length
and offset to the well-known identifier encoded into the client's
source connection ID.
Servers that share a local UDP port using the CIBIR extension
unconditionally route received packets according to the CIBIR
extension's protocol. The cibir_encoding transport parameter is used
on the server side after the routing has already happened to validate
the intent of the client. Servers MUST validate the client sent the
cibir_encoding transport parameter with the matching offset and
length that has been configured locally. If the transport parameter
is missing or contains incorrect values the server MUST terminate the
connection with an error of type CONNECTION_REFUSED.
No special routing is done on the client side, but client MUST also
validate the server sent the cibir_encoding transport parameter with
the matching offset and length so as to verify the server is
cooperating in the expected routing scheme. If the transport
parameter is missing or contains incorrect values the client MUST
terminate the connection with an error of type
TRANSPORT_PARAMETER_ERROR.
2.2. Packet Encoding and Routing
The base QUIC transport protocol provides no way to consistently
route long header packets to the correct server in a shared UDP
environment. The only possibly way a server's infrastructure has to
identify which server the client is trying to connect to is the ALPN
or SNI, but these are not included in all long header packets.
Additionally, the destination connection ID in packets sent to the
server cannot be used because there is no stateless way determine if
the CID is client or server chosen, not to mention the complexities
around server chosen CIDs in a load balanced environment (which the
client does not necessarily know anything about).
To achieve consistent routing for these long header packets, the
client encodes a well-known identifier into its source connection ID.
The length and offset of the well-known ID must be pre-agreed upon
between the client and server, and is validated via the
cibir_encoding transport parameter as described above. When the
server infrastructure receives a QUIC long header packet on the
shared UDP port it uses the well-known identifier to route the packet
to the correct server.
Banks Expires 2 September 2022 [Page 3]
Internet-Draft QUIC-CIBIR March 2022
No special routing is necessary for short header packets. These
packets always use server chosen destination connection IDs, and the
logic by which these CIDs are chosen, created and interpreted is
purely up to the server and server infrastructure. The client
doesn't need to be involved in this logic beyond the normal use of
destination connection IDs.
3. Security Considerations
The client encodes well-known IDs in the QUIC connection ID that may
expose information to an observer.
4. IANA Considerations
4.1. QUIC Transport Parameter
This document registers a new value in the QUIC Transport Parameter
Registry maintained at https://www.iana.org/assignments/quic/
quic.xhtml#quic-transport.
Value: 0x1000
Parameter Name: cibir_encoding
Status: permanent
Specification: This document
5. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Author's Address
Nick Banks
Microsoft Corporation
Email: nibanks@microsoft.com
Banks Expires 2 September 2022 [Page 4]
