<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.2 (Ruby 2.7.0) -->
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-banks-quic-cibir-01" category="exp" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.12.3 -->
  <front>
    <title abbrev="QUIC-CIBIR">QUIC Connection ID Based Initial Routing</title>
    <seriesInfo name="Internet-Draft" value="draft-banks-quic-cibir-01"/>
    <author initials="N." surname="Banks" fullname="Nick Banks">
      <organization>Microsoft Corporation</organization>
      <address>
        <email>nibanks@microsoft.com</email>
      </address>
    </author>
    <date/>
    <area>Transport</area>
    <workgroup>QUIC</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>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.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>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.</t>
      <t>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.</t>
      <section anchor="terms-and-definitions">
        <name>Terms and Definitions</name>
        <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="specification">
      <name>Specification</name>
      <section anchor="transport-parameter">
        <name>Transport Parameter</name>
        <t>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.</t>
        <t>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.</t>
        <t>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.</t>
      </section>
      <section anchor="packet-encoding-and-routing">
        <name>Packet Encoding and Routing</name>
        <t>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).</t>
        <t>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.</t>
        <t>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.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The client encodes well-known IDs in the QUIC connection ID that may expose
information to an observer.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="quic-transport-parameter">
        <name>QUIC Transport Parameter</name>
        <t>This document registers a new value in the QUIC Transport Parameter Registry
maintained at
<eref target="https://www.iana.org/assignments/quic/quic.xhtml#quic-transport"/>.</t>
        <dl>
          <dt>Value:</dt>
          <dd>
            <t>0x1000</t>
          </dd>
          <dt>Parameter Name:</dt>
          <dd>
            <t>cibir_encoding</t>
          </dd>
          <dt>Status:</dt>
          <dd>
            <t>permanent</t>
          </dd>
          <dt>Specification:</dt>
          <dd>
            <t>This document</t>
          </dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner">
            <organization/>
          </author>
          <date month="March" year="1997"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba">
            <organization/>
          </author>
          <date month="May" year="2017"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAGxHHmIAA51YYW/bOBL9bsD/Ya790BaI06RY4G4NLHBu4mINNE7OcW+x
WCwCWqJsIhLpJSm7QtH/fm9ISrYSZ2+xXxLJEocz7828GWo0Gg0HXvlSjuk/
X2ZXdGW0lplXRtPsmj4KJ3OaaeWVKGlhaq/0ejgQq5WVu7hidDX7OFsMB7nJ
tKhgJrei8KOV0I9u9EetslGmVsqOLi6Hg0x4uTa2GZP8usUS3I7p2/VkOf0+
HKitHZO3tfMfLi5+vPiAbawUY1paod3WWD8c7Ndxz+HgcT+GW15aLf3omncc
DpwXOn8QpdGw2kiH/UwOf8dUu5FwmVLDwVaN6TdvsjNysGhl4XDVVPEiM1Ul
tXe/DwfYvPYbY8fDAdGI/xAp7cY0PwcoCC3+FCOeq+zx+FdjseeNyqxxpvCA
1MJ9wZjG57ISqhyTVgGkf1ftm+dwgLcejUYkVs5bkXm+X26UI+Bbs3eUy0Jp
6UhooOildsyVN+Q3MlLoW8Boaw1iNSUeMxh41WGBLxuyoFKSKEvaiuxRekeF
NRUJykrFmyR7YgsTW6tAFDlpd9ISNhPAegNycvpyfUe803nrdqXyvJR895r5
sSavsxj4cHAvsR5p5DKphVXGwX84RPuNtJKquvRqW0rAnMutxB+4YSwpZ0ps
n6f9HWmJGw7I1hovBz8deCCpd8oazSCd0ar2lAmtjQf7faOlyeBF67o7J/pk
LPJPcwJl8oyNpmCxqDRNSArsIzxtxE7SptY5onfsHpKkdsg73BRUiWzD3JwN
BxKXtFd+Q0wRv3lYVVCuigJBw5nAWBsaItJIWMYYUVVn/BdYR1+ULqxAUgDQ
mvESDXF0K7C0AmxgzNXbQDsjoutqxWwVT8NFoIDc1GVOVqI+bVi6Vogr+Jx2
E1Rr9Uct4YsEQpM8V8wjMqYBuDITjKopGLaeW8lmhEx0q2h2x3dWOofUPeE7
LmExR91hGYqzrIMGSSAobUivWQAFu3b5cxa5PwkPZwlb2mMrmOd9NYsYcn8+
WQ4HAfc29zmnKaV0Hy745fdS6lAqLU21Y5JCPqTkf6FCqZLZRmjlKiqQAXFd
2Dk7llkXPNRQKxkZxyM4LGzDURlbBe0IJtiNQ4mm0HuxRCwzYy3slw3KhEs9
f7mimV28b7aSNQoOJvuoHl6hQ/14DpCLzm1lpgqVBSS9sGvpGbuDNrQ4drLw
+jUtpa1YsHK6ZmhCTriobJIeZbM3FmS9uvlyv3x1Fv/T/DZcL6aIbjG95uv7
nyefP3cX7Rv3P99++Yznw0G6PCy9ur25mc6v42r8Sk9+upn8in/s16vbu+Xs
dj75/CpKinKho0U+hW1TVHHL2VrJgCJRc+kyq1a4waKPV3d0+QN9+/aPxaer
D5eXP37/nm7+dfnPH76jw0HodNzOaKAXbwFxw6xIwTkcCRZb5UWJ/MYebmP2
mlgiI5p03zLQ6ioD3En+nbDQQngZFDcJAmdOyC+mN/TrXmIpFtW18Sro7KpB
2goddEqkdnvCPr3l5vdTaO4PrfEz2omylj9dfL28uLh4h9RihvvvYN44NKjO
WupOYVe/NwHpNX4P9hy9tRKwcw0H5IeDHRSAtWNUSr2Gyqb33btYl93rIenT
OwH5onCy7W+gRJbl6FEzxIqbA4CVCavAaqqaWBJvwIapbSb75Xsem1vUhrB7
KAGA90RLWt2QiYND+66xoT4obCpaRJFJCHPeFbfIUNiBxeTYE0PwsO35EXu0
/R74dAp75YL2prbTFrMDIITBStrwq22Hvw0rdInRLG/QDpG4OqoLmFI80YW3
mQ7u38URfPCoRYkrnDk8WpFUp+PsL/gd2ysHiUTmzrtu6WWmE+mpbTuUL7QM
MBdqXXdCXzbwaha99IdBs4dNpVwgzoQs9QKDAuJLCtsm6BFwQb6wtlI6BReG
rzZhgtc8vFlrQoP2zRZE3s7n0yvWoIfF9NOX+2lMqzlEnusdaZQIoNBptGzZ
anEDW2nqiT8ELyAiB2JQeEfs/g2c6QnMaNYHnLGRCN0H1lXR9Fqz6/WXNLPh
CABEQESXWS7D0CNPEEJ/iw+gfgRFjxD6f3xA8haT+f3d7WL5cDdZTG6my+ni
YbpY3C7apnYXapKmLXKMRXdCiq1thePTizM5LnYgDdpr2inlxIiO0wzXHKoN
wR/1+BhEDLmbgA7dlzXnaB5OQsxtB8ltgN+KGxB2bXv3G/d0gtpEOpMscrtS
h/HwkHmYAPGebZIoJWDDylgVk893c+bqfj6LCRqnOFZIngHBXFlHseXmNxxw
xNQP+NkAynYBnWdCmcOeHrOltJCH58NpJvmejgVp4uyGWR+OISrwgZOAlyVm
sIBRLmPy4GkRi+iKd3FtqRnbmd4Yx02d7WNThl61dWoqnG6+IgieDEGuzrvR
Pi5jqy6yWBoBx0TJ55H8mEh6G2k4qvzchBzyh7FRgVvuaUjJxod6FSsk07uQ
uUvUKYoYZ7GjdOvEpQhHGubnBA1nx9vGHgmEMWOfbKKheSr/Qs+MCfm8MZuE
8JFNYF3VLhCGpj4Sa8snwHoLQ+10fuQX24qwxlFLuUOjyWmnxF9Vvd58BwB3
rEy/YGbr6eiz40/o2C5NTidQ7LpsV6hckdhZhZNqrJnTiALPKAr8SrLWl4I2
o/6kdxzOFsw1pkts/azaliEFuqmjRBUARq6Sfsa+WIMugh+GL7NWGU+VXea6
UED8sYRFoK2ZDCNFmO503puz4fMW0CKn6+2TSj5w/fQc2k6ehxLRb3z76SBO
8jtT7qLshMNNclM2JvqNcuIBuaR40P2TUNu5XGa1Vb7hT2jcjeMXn+6Y0y+b
fn67tic+PxvG+YUPzOiXACoE2k3uiAWdy6yOWH9Ns8l8csIJtKxg/oWzQv8I
a+WalcFyImu5j1215+WpI8EirLIND2QqdGbmE1n52+9vN95v3fj9+/1+f66E
FufGrt8LdKJ1EDb3nr8Vhj/nXze+Kl+Hb4ddYUbx+i+7MearMcUzBl8fHJjz
97j4+OmhAyM6RL126TGmkUro0L/w5PhIlV7o4dF+3lqhIoaD/wEVfiGzNRUA
AA==

-->

</rfc>
