<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.18 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc docmapping="yes"?> version="1.0" encoding="UTF-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-quic-invariants-13" category="std" consensus="true" number="8999" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <link href="https://datatracker.ietf.org/doc/draft-ietf-quic-invariants-13" rel="prev"/>
  <front>
    <title abbrev="QUIC Invariants">Version-Independent Properties of QUIC</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-quic-invariants-13"/> name="RFC" value="8999"/>
    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <email>mt@lowentropy.net</email>
      </address>
    </author>
    <date year="2021" month="January" day="15"/> month="May"/>
    <area>Transport</area>
    <workgroup>QUIC</workgroup>
    <keyword>crypto</keyword>
    <keyword>next generation</keyword>
    <keyword>protocol</keyword>
    <keyword>secure</keyword>
    <keyword>transport</keyword>
    <keyword>UDP</keyword>
    <keyword>invariants</keyword>
    <abstract>
      <t>This document defines the properties of the QUIC transport protocol that are
common to all versions of the protocol.</t>
    </abstract>
    <note>
      <name>Note to Readers</name>
      <t>Discussion of this draft takes place on the QUIC working group mailing list
(<eref target="mailto:quic@ietf.org">quic@ietf.org</eref>), which is archived at
<eref target="https://mailarchive.ietf.org/arch/search/?email_list=quic"/>.</t>
      <t>Working Group information can be found at <eref target="https://github.com/quicwg"/>; source
code and issues list for this draft can be found at
<eref target="https://github.com/quicwg/base-drafts/labels/-invariants"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="an-extremely-abstract-description-of-quic" numbered="true" toc="default">
      <name>An Extremely Abstract Description of QUIC</name>
      <t>QUIC is a connection-oriented protocol between two endpoints.  Those endpoints
exchange UDP datagrams.  These UDP datagrams contain QUIC packets.  QUIC
endpoints use QUIC packets to establish a QUIC connection, which is shared
protocol state between those endpoints.</t>
    </section>
    <section anchor="fixed-properties-of-all-quic-versions" numbered="true" toc="default">
      <name>Fixed Properties of All QUIC Versions</name>
      <t>In addition to providing secure, multiplexed transport, QUIC <xref target="QUIC-TRANSPORT" format="default"/>
allows for the option to negotiate a version.  This allows the protocol to
change over time in response to new requirements.  Many characteristics of the
protocol could change between versions.</t>
      <t>This document describes the subset of QUIC that is intended to remain stable as
new versions are developed and deployed.  All of these invariants are
IP-version-independent.</t>
independent of the IP version.</t>
      <t>The primary goal of this document is to ensure that it is possible to deploy new
versions of QUIC.  By documenting the properties that cannot change, this
document aims to preserve the ability for QUIC endpoints to negotiate changes to
any other aspect of the protocol.  As a consequence, this also guarantees a
minimal amount of information that is made available to entities other than
endpoints.  Unless specifically prohibited in this document, any aspect of the
protocol can change between different versions.</t>
      <t><xref target="bad-assumptions" format="default"/> contains a non-exhaustive list of some incorrect assumptions
that might be made based on knowledge of QUIC version 1; these do not apply to
every version of QUIC.</t>
    </section>
    <section anchor="conventions-and-definitions" numbered="true" toc="default">
      <name>Conventions and Definitions</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this
document are to be interpreted as described in BCP&nbsp;14 BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here.</t>
      <t>This document defines requirements on future QUIC versions, even where normative
language is not used.</t>
      <t>This document uses terms and notational conventions from <xref target="QUIC-TRANSPORT" format="default"/>.</t>
    </section>
    <section anchor="notational-conventions" numbered="true" toc="default">
      <name>Notational Conventions</name>
      <t>The format of packets is described using the notation defined in this section.
This notation is the same as that used in <xref target="QUIC-TRANSPORT" format="default"/>.</t>
      <t>Complex fields are named and then followed by a list of fields surrounded by a
pair of matching braces. Each field in this list is separated by commas.</t>
      <t>Individual fields include length information, plus indications about fixed
value, optionality, or repetitions. Individual fields use the following
notational conventions, with all lengths in bits:</t>
      <dl>
        <dt>
x (A):  </dt>
        <dt>x (A):</dt>
        <dd>
          <t>Indicates that x is A bits long</t>
        </dd>
        <dt>
x (A..B):  </dt>
        <dt>x (A..B):</dt>
        <dd>
          <t>Indicates that x can be any length from A to B; A can be omitted to indicate
a minimum of zero bits bits, and B can be omitted to indicate no set upper limit;
values in this format always end on an a byte boundary</t>
        </dd>
        <dt>
x
        <dt>x (L) = C:  </dt> C:</dt>
        <dd>
          <t>Indicates that x, with x has a fixed value of C; the length of x is described by
L, has a fixed value which can use any of C</t> the length forms above</t>
        </dd>
        <dt>
x
        <dt>x (L) ...:  </dt> ...:</dt>
        <dd>
          <t>Indicates that x is repeated zero or more times (and and that each instance is has a
length L)</t> of L</t>
        </dd>
      </dl>
      <t>This document uses network byte order (that is, big endian) values.  Fields
are placed starting from the high-order bits of each byte.</t>
      <t><xref target="fig-ex-format" format="default"/> shows an example structure:</t>
      <figure anchor="fig-ex-format">
        <name>Example Format</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Example Structure {
  One-bit Field (1),
  7-bit Field with Fixed Value (7) = 61,
  Arbitrary-Length Field (..),
  Variable-Length Field (8..24),
  Repeated Field (8) ...,
}
]]></artwork>
      </figure>
    </section>
    <section anchor="quic-packets" numbered="true" toc="default">
      <name>QUIC Packets</name>
      <t>QUIC endpoints exchange UDP datagrams that contain one or more QUIC packets.
This section describes the invariant characteristics of a QUIC packet.  A
version of QUIC could permit multiple QUIC packets in a single UDP datagram, but
the invariant properties only describe the first packet in a datagram.</t>
      <t>QUIC defines two types of packet header: headers: long and short.  Packets with a long
headers
header are identified by the most significant bit of the first byte being set;
packets with a short header have that bit cleared.</t>
      <t>QUIC packets might be integrity protected, including the header.  However, QUIC
Version Negotiation packets are not integrity protected; see <xref target="vn" format="default"/>.</t>
      <t>Aside from the values described here, the payload of QUIC packets is
version-specific
version specific and of arbitrary length.</t>
      <section anchor="long-header" numbered="true" toc="default">
        <name>Long Header</name>
        <t>Long headers take the form described in <xref target="fig-long" format="default"/>.</t>
        <figure anchor="fig-long">
          <name>QUIC Long Header</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
Long Header Packet {
  Header Form (1) = 1,
  Version-Specific Bits (7),
  Version (32),
  Destination Connection ID Length (8),
  Destination Connection ID (0..2040),
  Source Connection ID Length (8),
  Source Connection ID (0..2040),
  Version-Specific Data (..),
}
]]></artwork>
        </figure>
        <t>A QUIC packet with a long header has the high bit of the first byte set to 1.
All other bits in that byte are version specific.</t>
        <t>The next four bytes include a 32-bit Version field.  Versions are described in
<xref target="version" format="default"/>.</t>
        <t>The next byte contains the length in bytes of the Destination Connection ID
field that follows it.  This length is encoded as an 8-bit unsigned integer.
The Destination Connection ID field follows the Destination Connection ID Length
field and is between 0 and 255 bytes in length.  Connection IDs are described in
<xref target="connection-id" format="default"/>.</t>
        <t>The next byte contains the length in bytes of the Source Connection ID field
that follows it.  This length is encoded as an 8-bit unsigned integer.  The
Source Connection ID field follows the Source Connection ID Length field and is
between 0 and 255 bytes in length.</t>
        <t>The remainder of the packet contains version-specific content.</t>
      </section>
      <section anchor="short-header" numbered="true" toc="default">
        <name>Short Header</name>
        <t>Short headers take the form described in <xref target="fig-short" format="default"/>.</t>
        <figure anchor="fig-short">
          <name>QUIC Short Header</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
Short Header Packet {
  Header Form (1) = 0,
  Version-Specific Bits (7),
  Destination Connection ID (..),
  Version-Specific Data (..),
}
]]></artwork>
        </figure>
        <t>A QUIC packet with a short header has the high bit of the first byte set to 0.</t>
        <t>A QUIC packet with a short header includes a Destination Connection ID
immediately following the first byte.  The short header does not include the
Destination Connection ID Length, Source Connection ID Lengths, Length, Source Connection
ID, or Version fields.  The length of the Destination Connection ID is not
encoded in packets with a short header and is not constrained by this
specification.</t>
        <t>The remainder of the packet has version-specific semantics.</t>
      </section>
      <section anchor="connection-id" numbered="true" toc="default">
        <name>Connection ID</name>
        <t>A connection ID is an opaque field of arbitrary length.</t>
        <t>The primary function of a connection ID is to ensure that changes in addressing
at lower protocol layers (UDP, IP, and below) do not cause packets for a QUIC
connection to be delivered to the wrong QUIC endpoint.  The connection ID
is used by endpoints and the intermediaries that support them to ensure that
each QUIC packet can be delivered to the correct instance of an endpoint.  At
the endpoint, the connection ID is used to identify the QUIC connection for
which the packet is intended.</t>
        <t>The connection ID is chosen by each endpoint using version-specific methods.
Packets for the same QUIC connection might use different connection ID values.</t>
      </section>
      <section anchor="version" numbered="true" toc="default">
        <name>Version</name>
        <t>The Version field contains a 4-byte identifier.  This value can be used by
endpoints to identify a QUIC Version. version.  A Version field with a value of
0x00000000 is reserved for version negotiation; see <xref target="vn" format="default"/>.  All other values
are potentially valid.</t>
        <t>The properties described in this document apply to all versions of QUIC. A
protocol that does not conform to the properties described in this document is
not QUIC.  Future documents might describe additional properties that apply to
a specific QUIC version, version or to a range of QUIC versions.</t>
      </section>
    </section>
    <section anchor="vn" numbered="true" toc="default">
      <name>Version Negotiation</name>
      <t>A QUIC endpoint that receives a packet with a long header and a version it
either does not understand or does not support might send a Version Negotiation
packet in response.  Packets with a short header do not trigger version
negotiation.</t>
      <t>A Version Negotiation packet sets the high bit of the first byte, and thus it
conforms with the format of a packet with a long header as defined in
<xref target="long-header" format="default"/>.  A Version Negotiation packet is identifiable as such by the
Version field, which is set to 0x00000000.</t>
      <figure anchor="version-negotiation-format">
        <name>Version Negotiation Packet</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Version Negotiation Packet {
  Header Form (1) = 1,
  Unused (7),
  Version (32) = 0,
  Destination Connection ID Length (8),
  Destination Connection ID (0..2040),
  Source Connection ID Length (8),
  Source Connection ID (0..2040),
  Supported Version (32) ...,
}
]]></artwork>
      </figure>
      <t>Only the most significant bit of the first byte of a Version Negotiation packet
has any defined value.  The remaining 7 bits, labeled Unused, "Unused", can be set to
any value when sending and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>
      <t>After the Source Connection ID field, the Version Negotiation packet contains a
list of Supported Version fields, each identifying a version that the endpoint
sending the packet supports.  A Version Negotiation packet contains no other
fields.  An endpoint MUST <bcp14>MUST</bcp14> ignore a packet that contains no Supported Version
fields,
fields or contains a truncated Supported Version.</t> Version value.</t>
      <t>Version Negotiation packets do not use integrity or confidentiality protection.
Specific QUIC versions might include protocol elements that allow endpoints to
detect modification or corruption in the set of supported versions.</t>
      <t>An endpoint MUST <bcp14>MUST</bcp14> include the value from the Source Connection ID field of the
packet it receives in the Destination Connection ID field.  The value for the
Source Connection ID MUST field <bcp14>MUST</bcp14> be copied from the Destination Connection ID
field of the received packet, which is initially randomly selected by a client.
Echoing both connection IDs gives clients some assurance that the server
received the packet and that the Version Negotiation packet was not generated by
an attacker that is unable to observe packets.</t>
      <t>An endpoint that receives a Version Negotiation packet might change the version
that it decides to use for subsequent packets.  The conditions under which an
endpoint changes its QUIC version will depend on the version of QUIC that it
chooses.</t>
      <t>See <xref target="QUIC-TRANSPORT" format="default"/> for a more thorough description of how an endpoint that
supports QUIC version 1 generates and consumes a Version Negotiation packet.</t>
    </section>
    <section anchor="security-and-privacy-considerations" numbered="true" toc="default">
      <name>Security and Privacy Considerations</name>
      <t>It is possible that middleboxes could observe traits of a specific version of
QUIC and assume that when other versions of QUIC exhibit similar traits the same
underlying semantic is being expressed.  There are potentially many such traits;
see <xref target="bad-assumptions" format="default"/>.  Some effort has been made to either eliminate or
obscure some observable traits in QUIC version 1, but many of these remain.
Other QUIC versions might make different design decisions and so exhibit
different traits.</t>
      <t>The QUIC version number does not appear in all QUIC packets, which means that
reliably extracting information from a flow based on version-specific traits
requires that middleboxes retain state for every connection ID they see.</t>
      <t>The Version Negotiation packet described in this document is not
integrity-protected;
integrity protected; it only has modest protection against insertion by
attackers.  An endpoint MUST <bcp14>MUST</bcp14> authenticate the semantic content of a Version
Negotiation packet if it attempts a different QUIC version as a result.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document makes no request of IANA.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <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 initials="S." surname="Bradner" fullname="S. Bradner"> Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/> 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 initials="B." surname="Leiba" fullname="B. Leiba"> Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/> 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>
      <references>
        <name>Informative References</name>
        <reference anchor="QUIC-TRANSPORT"> anchor="QUIC-TRANSPORT" target="https://www.rfc-editor.org/info/rfc9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author initials="J." surname="Iyengar" fullname="Jana Iyengar" role="editor">
              <organization>Google</organization>
            </author>
            <author initials="M." surname="Thomson" fullname="Martin Thomson" role="editor">
              <organization>Mozilla</organization>
            </author>
            <date year="2021" month="January" day="15"/> month="May"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-transport-34"/> name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
        <reference anchor="QUIC-TLS"> anchor="QUIC-TLS" target="https://www.rfc-editor.org/info/rfc9001">
          <front>
            <title>Using Transport Layer Security (TLS) TLS to Secure QUIC</title>
            <author initials="M." surname="Thomson" fullname="Martin Thomson" role="editor">
              <organization>Mozilla</organization>
            </author>
            <author initials="S." surname="Turner" fullname="Sean Turner" role="editor">
              <organization>sn3rd</organization>
            </author>
            <date year="2021" month="January" day="15"/> month="May"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-tls-33"/> name="RFC" value="9001"/>
          <seriesInfo name="DOI" value="10.17487/RFC9001"/>
        </reference>
        <reference anchor="RFC5116" target="https://www.rfc-editor.org/info/rfc5116">
          <front>
            <title>An Interface and Algorithms for Authenticated Encryption</title>
            <author initials="D." surname="McGrew" fullname="D. McGrew"> McGrew" initials="D." surname="McGrew">
              <organization/>
            </author>
            <date year="2008" month="January"/> month="January" year="2008"/>
            <abstract>
              <t>This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms.  The interface and registry can be used as an application-independent set of cryptoalgorithm suites.  This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5116"/>
          <seriesInfo name="DOI" value="10.17487/RFC5116"/>
        </reference>
      </references>
    </references>
    <section anchor="bad-assumptions" numbered="true" toc="default">
      <name>Incorrect Assumptions</name>
      <t>There are several traits of QUIC version 1 <xref target="QUIC-TRANSPORT" format="default"/> that are not
protected from observation, observation but are nonetheless considered to be changeable when
a new version is deployed.</t>
      <t>This section lists a sampling of incorrect assumptions that might be made about
QUIC based on knowledge of QUIC version 1.  Some of these statements are not
even true for QUIC version 1.  This is not an exhaustive list; it is intended to
be illustrative only.</t>
      <t><strong>Any
      <t>
        <strong>Any and all of the following statements can be false for a given QUIC
version:</strong></t>
version:</strong>
      </t>
      <ul spacing="normal">
        <li>QUIC uses TLS <xref target="QUIC-TLS" format="default"/> format="default"/>, and some TLS messages are visible on the wire</li> wire.</li>
        <li>QUIC long headers are only exchanged during connection establishment</li> establishment.</li>
        <li>Every flow on a given 5-tuple will include a connection establishment phase</li> phase.</li>
        <li>The first packets exchanged on a flow use the long header</li> header.</li>
        <li>The last packet before a long period of quiescence might be assumed
to contain only an acknowledgment</li> acknowledgment.</li>
        <li>QUIC uses an AEAD (AEAD_AES_128_GCM Authenticated Encryption with Associated Data (AEAD) function
(AEAD_AES_128_GCM; see <xref target="RFC5116" format="default"/>) to protect the packets it exchanges
during connection establishment</li> establishment.</li>
        <li>QUIC packet numbers are encrypted and appear as the first encrypted bytes</li> bytes.</li>
        <li>QUIC packet numbers increase by one for every packet sent</li> sent.</li>
        <li>QUIC has a minimum size for the first handshake packet sent by a client</li> client.</li>
        <li>QUIC stipulates that a client speaks first</li> speak first.</li>
        <li>QUIC packets always have the second bit of the first byte (0x40) set</li> set.</li>
        <li>A QUIC Version Negotiation packet is only sent by a server</li> server.</li>
        <li>A QUIC connection ID changes infrequently</li> infrequently.</li>
        <li>QUIC endpoints change the version they speak if they are sent a Version
Negotiation packet</li> packet.</li>
        <li>The Version field in a QUIC long header is the same in both directions</li> directions.</li>
        <li>A QUIC packet with a particular value in the Version field means that the
corresponding version of QUIC is in use</li> use.</li>
        <li>Only one connection at a time is established between any pair of QUIC
endpoints</li>
endpoints.</li>
      </ul>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIALAHAWAAA81b624bR5b+X09Rq/yRApKWbGeSkRHM0JKdaCBf1rIzGASB
UWQXyYb7wqnqlsQYzrPss+yT7XfOqaruJinJu8iPDRBb6q4+depcvnOp4/F4
rJq8KeypPvjFOp/X1fiiyuza4o+q0W9dvbauya3X9UL/54eLswNlZjNnr0/5
N31RXRuXm6rxKqvnlSlBKXNm0Yxz2yzG/27z+ThPa8YnT1RmGqx5fPz4ZHx8
Mj75Ts3xYFm7zan2TabytTvVjWt98/j4+K/Hj5Vx1pzq985Ufl27Rt3U7tPS
1e1aOFDKN6bKPpqirkB3Y71a56f616aej7THB84uPH7alPIDuCzNep1Xy9+U
Mm2zqt2p0nqM/7XOK3+qX030+1Vd+rriZ3KmVwZSqAYvarfE8/r3vCgMP7Cl
yYtTXTZ/L+obSA+y20wq2yiVV4valabJr+2pwlpifPz+3fT11ds3796f8tdR
DfTuVE/1h/O34+fG20y/aosmXxf2Fj/jqPrKzltnO5Ec8Pc7cqWH3jrojraX
TTQU1lgHpsbnpKVdZTWR6vjJU/6kkxH9Nw5/B1n9Y6IvNrZaGpeei7z+YSqz
84ol9lNdLwubnrmaTm2zvKnd/j229HGvTvbqZWebpIHLq6HsP0BUy06w+tJs
rBN5581GH+KDI93UUQPiD3+m8As/fvLkYbH/+SLZu80VtmnB77Zyr6yptt/w
Fr564rI7ZK7G47E2Mw8Dm8Ml3q9yT87YloQzmV3kFUCmWVm9HmAOPWGkSYZJ
C+DddYF3ptHABzWvy7KuSDOmKPS1AFn6PK6fBCaqurEfX9MfTf3xnTUZ1it1
nvt56+lD+Y7YI/XoxnwCK+vCzK2mTSJDBERkLgxGmnyffity36jDX0mdfyfF
TiCY3w7pbVOfDp4eHY30zSqfrzS2Mm6+AjrAwRv162+Hq6ZZ+9NHj+i78GoS
v3tEDx55y3/9jUHnI+36I1E/wiH/GRj7iRlL2APe59DbzOpF3Va0k+7ttMyb
VTubQJKPiM7N8ugZ4LN1c5JuZhl4cu9biII2Aw3XF9IWZXUf5UczwNqYv/OP
CjOzhX/UCxJHUU9lnmVACvWNnlb6xS2QvLTFRk+DDelz6+cuXzdBZRINWDUk
UD2vq8rO6e24hiPC9bLOdGa2ubEW2rypNWLdus6x80ST53jbPVH2dr4y1dIS
HJOXm6UzpSy0fusp7dgYuB/zsDbzT5ZpMmOJpG69Hawgs7UIYjPIdQW++V3H
fM9I/ArGnql0CHzU2O4oQ9ZJit/olzlFjWEYn8JHeJMQ8WH8F5U2GRw1Fy/C
Dtd5RjbkGelGuuzFoOSJIyHz+fMwnn35ouCG9Y0PRgK3WUfKFUJ9kxPbJvop
C5M0Jt/0PRZfqCD/GquB06WFQWtnsX+F0zLFG/wOyyLzECW+MtVG4zuyEmCw
b/J5BINOePO6LTIdqEcZRuiY7AIU2dosQJRvZ9420egEh7AaYqe8KSO2HDlm
pVmvOKxXxGdCJugRJK9tAb1IUEfOVdQbm4F90o9w6+m00S8Y6S7ejgMReEzK
05hdElteGrfRy9oUHYjFI+RiaZWn0CUs88N1DdQjJvFWuCCZqj6K0inB2PNN
oka2sQXWTBI4AHgNYh0xBypxYPLSi3nhZO7aMgUzA3AiuJKtsDQ7TxnYi5Ck
h4rUW+NbB7mu4SU7QA8ZBgTwsAxbzQMrsDFf62ULy4CqQMyoMq8gtEKbEtDF
lPqAGTVbGoLAa0LjICmSgTgUM4KFleoDyYeqsB4uC/7yRT6HcW+Iv1U+ywmI
8mqonZGmQw2O0zNVgOuWoWb5YmEdCbVnsp8/z0w2NkDpkh3Of/kSMYnEUcFo
7O3KILdGPBEYx1a+Zqea187R5r3PFR+/zJerhsCdhTDjlBSi+VTVN4XNyDWD
GwRO9MmzYLtZTbFWI93G4aE3GDysMy6LdsU4dVZX1yRSdg64wzklBLlwwbb9
yW4o4mZeH7z6cPX+YCR/69dv+Od3L0Dr3Ytz+vnq5+nlZfpBhRVXP7/5cHne
/dR9efbm1asXr8/lYzzVg0fq4NX0Xwcj5urgzdv3F29eTy8PdhTILg27mFmG
AQcbJz3D8SN0sNKfn7397/86eQrM/I93L88en5z8FTqSX344+f4pfrlZ2Up2
qyuITX6FPDcKckTQJyqU5czNOm9gz1hLkaG+qTQM0ZI49+dWfZAkBS7aJiax
yYhGGjqqaFO8qWLNogrYXmugatAljSKEZTsQiYfwTutK0SDWsQ8ZgtpOuQtX
l3sihljB6+6bnkGIAYhTktXEuEmbJ9m2PkJS3DgcvPM1LwF1InynZXnAdKS2
JEq2eTogfbeX0bO6pEioF7ktMsFyyosFx0EKoq0pluHJDD6dHC2sB/46SpPC
a7U2uaPXOB0SPRxihrhlgSEvDMI+f5SOwKT4KGtgWCMkKPs15P+o3HPE7Rbi
C3vBrYsWXlugEGtWfWgbIaNtaUEGcAp+N6tbJHaUMahrU7QATQnchgAavzjY
0No24pao/Ha2o9SmYV3R+XEWtd8KkNMgKWQzFs6IEQ1k9CiPb/Xh9OhUnTJ9
ag4EndzSwae8SqPYX8rKyeT5/sUhIyVYDadn05uSkz5/hr/DgrrMm0ZidhAG
FadGc2BoS9LM79bVsi9p+Pk9X8KqNGUGLVzVQVtY8QzUWJo+aTGYsiluzMZT
vCN3JJobSufINhDF+XiXR/pHfbbvfFGE8XCdJ8AiLkd6ZQjyWZmyPR3kLBKd
TCZ3SZhUzJbFp4bOy5qQDZmX14di4VhqyTYRVhqD4IrPcMjAyOXRXmBA1UsF
k5wROA7xHIboOoJslyQGpDlHQVaIoC/Zpqj/I8VXRsmU48yDNUmGtkJsGgs1
1g/OyJzRLhwQF/kSMW8sEge6ElCSGrW9NeTFoOnaOQEhLO+PP/5QL8Lzq/hc
f8bZ3lR2jA2EJ314cjTCw+97j1gZkmz/wtI+/J5U95cTWjh1WOig0/GlyCiQ
mUyYzi+U4CGt2Hr7w2Ty+CkveBdVEt+wAkfqC3P8+VR/MzimtDN+PIhHeclP
D74wxDLcvxUEDdVSl3Dtr3ZCZheKm7qyySoGhY5oPYDsVsKcsth9abnp06Hc
TW2lCCFXh0vBn1IpMiyiKCpqigHFkHsYV9uoIQ/9DgPF2MirYFfugLFCVqhG
UpMgr9SsQO3YbNZSVIUPVtxOOGWAYrSAwTk6VBC5GArDlyyV+JFTFo88UdyX
2ChrcOHzZcXZI5gmWwt5rrAoaGGlSgPMrPs7GNk48AM0uA45P5GZF5YKyXie
+GFK9CiBWXLHi1JQKNRmoxBKYpAVujjXz4hzUJeUgipUlPp1SNvp50ie42Td
7KP+DCeAo32+rjjATj3k0Tl5QM8O4Sg7GUnGbzZFbbJkKF1qEG1oHDNwSalg
bdEZA2Bx5vGNviSF/cynUop/ifqh/k+Iaq7Ug2xO8IW0yXyTN/boBJ0zgIQn
5IoEH4AGRobYc7+KTD4nFAN29F7qwyeP+fdzC5epRKhnqT+gL851AA4Aw/3r
Do+BKcdPj3nZFXd37qW0d8mAyM4BzuEsAdmG8MQeEZCJddWTFGHTtK/BFNw6
RXBEi5h/hzdQ6EU0PpkorqG5MuO4kIdSjleRIUaEidYRKujK3lJrq3W8ssuf
jH7ymNE+6oQTnkk6f6zoO9tA7Al7sGkk4sxBKsqI/5SbhT3Dse7UopKUkM8j
iRb4bGIXJVKjvIIad1SCULz7gdlvK4IUZhBOCAdmxu42GNkq7nIvW8F0AnfS
Lkzl6jE/ePzdd0mu0fv0kMpeQfY6eXn2fxTnXlNmXtWfI0luCaq7txlI8T7f
6wtQPSxAEYa0m8hNYi9E/CiJZgcO6Y20jgj+rjhaRPy76sWOrwBADjURAeHy
fWL3g+DxgyB4D5jF9OkhCOqBkATFPgr1eb0ThrZi6dfi0PHka+gFjKF0/W6f
z0sUmNQHKzZddbW1rZjgkHhWWx+iriAZNZb2mR2y8H1GyVXfAPRC8zu6R71Q
98NCaBlEH8q7hGCPMFTADe4hAlYRqLmE56Qo77XTpJC/1/RJTztW77G4osQz
2P1QytDWfJt5eHy9Nv9ubXDM/SlEv/26aKt5vJQwuwS3mrCxr5lzC95ZT0ms
wgvqILiuFV7QXSTcAsntSF+8lRbRzGLVUWy0zQ0V4FG81FCV1Fr1eJAWVWaL
HLKR4pVkduMo0g7KgaDn+dAOvfRGoJCubAh9D2l8sZ261BD2KIXZ51a23Dq6
4lKt7x6hsN7hLvYmU8FJkq36nE4lx49PRuGzLdEz61SuS7q96S7zekshNyVX
Lj1j6nX3g7Z3iM/p/qViydC5IiuhM7VjiaVtVjW8Sb3t6Ss1oraZktyc1Nt1
focchLpZzDp4rHA6cN9+Q/jpmNEqFR8uhj5pGARtBH2rQV8+SdAMrpJIE1v7
BS+PPQh1fHsc/pNuA98EZHz6mJRVXfUwqAzC1QindXJc6Q7UFMhybrHjcZ4l
f0xl3iBobfVtQ3d65+pYLj2manjdnAAVcuR4GEz06zZDRKdvw33KS+nAxrex
AkvlaLySM8XOPUvqqZuEiYNOLuM2HUo7uT4b9ujD7eC+cu3zN5B1ilvJinlX
OKGFZ5Lt3J2nExqkyz3kU8rmrLEkOep9Op7aISbT44gUIgRvmcweDlVXm8d7
wO362mwHQd6gcflyaZOZqZ6ZcaC+u3ilgP5Q0B8FGKSmaqOCdQR+YvIk/et7
hed7bWukvvRuLO/EAe7jkkAq+HK4dYRQuRvGYX/gl/1r5ZCtJMcMpey+nR4u
aT9UDBh7atiY7/1/rGOvxPiofdfneKvNFkG8ZzlbPbe7ZUbJ5RvqNv0vujts
LHcrXHGTt9okk2FQDHFb0iIKPd9zDTzSPGqBVaKhUcT3oH7Qka4/Xzmx/+Wh
h8UXbdQXWla1k9s/RoI1VQ/TRWPdAyWWhON7LLcLSireluxqRNLPUeg9hwDE
PCa0YZTqJwIqnqMXywPQ+IfcKTFV1RJ0VEqAp13yIdIR0XSu3W+ZMoGd46h4
HE7TGoekkXu8Owsh4/vaagHcWt/v24EmIZAIia9vYrONCV7tCxkx/MRKIcU9
GI2EJ4k8VHwMLulVZokyjDpLublw4Fwrkx+5zE2FoQmfjtgLR7si7SqWkD2k
juA9VXa8Ow+I2ItZgYcHmh3Be8KGOIXstVUzRY+Y12vq2SbG7iYenDtwkwUG
eyjM192cwyBiZ3WJHzwkP2/iNeK8oCEm8PcCmSbfE8Io1XzYPVnyUWWpl6t9
utB3nDUn7+CcyyVmes6h0g3PAx57YyRqL21l000kAMU0DS1wcXRCtVUcmahn
MvWRLgwGOt9OMO7ZW+w0XFWweQSXilMtGcw741kR9gtSI4/s0CxIk/ZP9Y1k
WV4Sk6CR3jhHKtEGUw43OfJFmcCJY4Hb1xaBHQV9oTSgA19xMrt9pxxKNblo
Q+JSt8t4oZem21ZwOrMlLhWRbGv+IilFSjMqpNvyAaFKQphGXem7ty6/NvMN
GTI15J0Jt/EXW2NDMiRCs3qz+pasj29roraphG/CPU9KVTtJyRUE54w0eBLI
cQgKif5WSq7tLQ/RIHyWNBwZN4ilk2ItFhu5F5FqX1qR9MTe0vCRt8HPnXSD
+xVESQGV0yYh/ExJBbIzWjOhvAIM28WCc01De4BtHpOhSlfSXku3wJXhW08F
ofDkMDumSEi8Q84QZweTJvn2SlhKE2ES2CfqDZPfh+AlNey6OhGWhPDEThF6
1XQvVUdBqm6lsBHKpwEnVVvO+jn8cBalf/cSIa20ppKQoRxkgGOiML7lyU1S
RH/KiuHT6AUFljRftFMwC3MqjLH4Xbtztgkjd434vMwbDctkmqShmnIyrI33
oMy9ZRwJQaV4O+7dZFEiR2ke2QMiovVNL/Rqs6SEgDsZVM7V1C9QETP3ZhY0
CE7GyeMFAt7BqEMHd5Alqn1lwYKYwiYWtkso0Cl8oGOeGIBk2yKgwcX09XTH
+4d3+yUPR1c1TxdZydzoszjDOwMLTCrNl007H0Ktue1VrJXglZ70h9q3Q5At
mNuDpHEknPWTtCIWFvxNpl/Ir2RdZSFVHtabh6NKk2gWZw7ZQwmRUGz3pjhl
/ihMbarh7TclsSRNTzfwZO48V7hnxC5acX/EjudwBBe/Ztou4lACCHYAydii
JHiqCzmm7cYs+98z76HtyrMRgyHBZ2FQtDfeqqgaKIqWGrS8jkweQvj222kl
wcOkIdZev7rHWRwYN0UI0IZzFwHAeHl7+u23oCn88hTJ+8urpPXLK+hboAyn
pzeIcd5QoOYbvlzCU4jNN8CMRKvo3+/SYvbYOP2Q6QxBECt6yJEGtIl7ovOC
sYUhi1wnMP/duGlpNIGTg+7y8C5Ceg2UYLbeb00e+B43TJ93ivNVPf7jx4Xp
phZmdiHFCK9bW5fXnBgDOIFpNA7bWZxEXfpHGzD5bsajkGRuHu0uHrtTBV5P
X0xRRtOfH6cvrj6ePP7h409nr6Cgv717efbdyclfvnw5CuPkXCB0aSb3SHQ6
o/8aifcbxRKORHc4j9usmzB/FwJTuKMRkXYr+PLsLmLQl7PQB2WyNOXShZDU
BepxIgNWcUrM57/b1MGVXXGyzK8oFPc+76fyiRRcbd0W3RxWXED5kvnkhd4W
1z6Oj4XRDoJLSmXv6CQcHt8+PT6iAozoTAdN2ztaSWwEHc9SM/S+HsbV7hpj
4STPLjaJ5a5a3E3aQ0Smk1Kk4t8E/ak5m+Ka3tf/CLY/bDjzzM62mw+mPOlu
uKaZudzJAXzvWMPe3JomzuYt5ZlSEoYqcrhll+tw8anlwoJ6k1mv95+gm7GU
vIi25Z4QmVtPnmwD8o8dfOcIZL/hOpgSwjg3yoCpe/9m5X8Al9rOOtU5AAA=

-->
</rfc>