<?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.2.11 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-kuehlewind-masque-quic-substrate-00" category="info" obsoletes="" updates="" submissionType="IETF" xml:lang="en" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.40.1 -->
  <front>
    <title abbrev="QUIC Substrate">Use Cases and Requirements for QUIC as a Substrate</title>
    <seriesInfo name="Internet-Draft" value="draft-kuehlewind-masque-quic-substrate-00"/>
    <author initials="M." surname="Kuehlewind" fullname="Mirja Kuehlewind">
      <organization>Ericsson</organization>
      <address>
        <email>mirja.kuehlewind@ericsson.com</email>
      </address>
    </author>
    <author initials="Z." surname="Sarker" fullname="Zaheduzzaman Sarker">
      <organization>Ericsson</organization>
      <address>
        <email>zaheduzzaman.sarker@ericsson.com</email>
      </address>
    </author>
    <author initials="T." surname="Fossati" fullname="Thomas Fossati">
      <organization>Arm</organization>
      <address>
        <email>thomas.fossati@arm.com</email>
      </address>
    </author>
    <author initials="L." surname="Pardue" fullname="Lucas Pardue">
      <organization>Cloudflare</organization>
      <address>
        <email>lucaspardue.24.7@gmail.com</email>
      </address>
    </author>
    <date year="2020" month="March" day="09"/>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>In situations where direct connectivity is not available or desired, proxies in the network
are used to forward and potentially translate traffic.
TCP is often used as a proxying or tunneling protocol. QUIC is a new,
emerging transport protocol and there is a similar expectation that it too will
be used as a substrate once it is widely deployed. Using QUIC instead of TCP in
existing scenarios will allow proxying and tunneling services to maintain the benefits
of QUIC natively, without degrading the performance and security characteristics.
QUIC also opens up new opportunities for these services to have lower latency and
better multistreaming support. This document summarizes current and future usage
scenarios to derive requirements for QUIC as a substrate and to provide additional
considerations for proxy signaling and control protocol as proposed by MASQUE.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>QUIC is a new transport protocol that was developed with a focus on optimizing
HTTP traffic by supporting multiplexing without head-of-line-blocking and integrating
security directly into the transport. This tight integration of security allows the transport
and security handshakes to be combined into a single round-trip exchange, after which
both the transport connection and authenticated encryption keys are ready.</t>
      <t>Based on the expectation that QUIC will be widely used for HTTP, it follows that there
will also be a need to enable the use of QUIC for HTTP proxy services.</t>
      <t>Beyond HTTP, however, QUIC provides a general-purpose transport protocol that can
be used for many other kinds of traffic, whenever the features provided by QUIC
(compared to existing options, like TCP) are beneficial to the high-layer service.
Specifically, QUIC's ability to multiplex, encrypt data, and migrate between network paths
makes it ideal for solutions that needs to tunnel or proxy traffic.</t>
      <t>Existing proxies that are not based on QUIC are often transparent. That is, they do not
require the cooperation of the ultimate connection endpoints, and are often not
visible to one or both of the endpoints. If QUIC provides the basis for future tunneling
and proxying solutions, it is expected that this relationship will change. At least one
of the endpoints will be aware of the proxy and explicitly coordinate with it. This allows
client hosts to make explicit decisions about the services they request from proxies
(for example, simple forwarding or more advance, e.g. performance-optimizing, services),
and to do so using a secure communication channel between themselves and the proxy.</t>
      <t>MASQUE <xref target="I-D.schinazi-masque" format="default"/> is a proposed framework that allows running multiple network or
application services inside one QUIC connection to be forwarded to one or
more target servers. The end-to-end traffic between the client and the target server
will be tunnelled in a (outer) QUIC connection between the client and the MASQUE server.
This outer connection can also be used to securely exchange additional signal or control
information between the MASQUE server and the client.</t>
      <t>This document describes some of the use cases for using QUIC for proxying and tunneling,
as proposed by MASQUE, and explains the protocol impacts and tradeoffs of such deployments.</t>
    </section>
    <section anchor="usage-scenarios" numbered="true" toc="default">
      <name>Usage Scenarios</name>
      <section anchor="obfuscation-via-tunneling" numbered="true" toc="default">
        <name>Obfuscation via Tunneling</name>
        <t>Tunnels are used in many scenarios within the core of the network
from a client endpoint to a proxy middlepoint on the way towards the server. In many cases, when
the client explicitly decides to use the support of a proxy in order to
connect to a server, it does so because a direct connection may be blocked or impaired. This
can either be the case in e.g. enterprise network where traffic is firewalled
and web traffic needs to be routed over an explicitly provided HTTP proxy, or
other reasons for blocking of certain services e.g. due to censorship, data
exfiltration protection, etc.</t>
        <t>Tunneling through a proxy server can provide various benefits, particularly when
using a proxy that has a secure multiplexed channel like QUIC:</t>
        <ul spacing="normal">
          <li>Obfuscating the traffic patterns of the traffic from the perspective of observers
between the client and the proxy. If the content of connections to many end servers
can be coalesced as one flow, it becomes increasingly difficult for observers to
detect how many inner connections are being used, or what the content of
those connections are.</li>
          <li>Obfuscating the client's IP address from the perspective of observers after the proxy,
to the end server itself. This allows the client to reduce information leaked about its actual
location, improving privacy.</li>
          <li>Obfuscating the end server's IP address from the observers between the client and
the proxy, which protects the identity of a private server's address or circumvents
local firewall rules.</li>
        </ul>
        <t>In any of these tunneling scenarios, including those deployed today, the client
explicitly decides to make use of a proxy service while it is usually fully transparent
for the server, or even with the intention to hide the client's identity from the
server. This is explicitly part of the design as these services are targeting an
impaired or otherwise constrained network setup.</t>
        <t>Therefore, in this usage scenario the client knows the proxy's address and explicitly
selects to connect to the proxy in order to instruct the proxy to forward its
traffic to a specific target server. Often the proxy is also preconfigured to "know" the
client and therefore the client needs to authenticate itself (e.g. using HTTP Transport
Authentication <xref target="I-D.schinazi-httpbis-transport-auth" format="default"/>). But even without authentication,
at a minimum, the client needs to communicate directly with the proxy to provide
the address of the target server it wants to connect to, e.g. using HTTP CONNECT,
and potentially other information needed to inform the behaviour of the proxy.</t>
        <t>Usually the server is not aware of the proxy in the middle, so
the proxy needs to re-write the IP address of any traffic inside the tunnel to
ensure that the return traffic is also routed back to the proxy. This is also often
used to conceal the address/location of the client to the server, e.g. to access
local content that would not be accessible by the client at its current location
otherwise.</t>
      </section>
      <section anchor="advanced-support-of-user-agents" numbered="true" toc="default">
        <name>Advanced Support of User Agents</name>
        <t>Depending on the traffic that is sent "over" the proxy, it is also possible that
the proxy can perform additional support services if requested by the client.
Today, Performance Enhancing Proxies (PEPs) usually work transparently by either
fully or partially terminating the transport connection. For many of these support services
the termination is actually not needed and may even be problematic. However, it is often the only,
or at least easiest, solution if no direct communication with the client is available.
Enabling these services based on an explicit tunnel setup between the client and
the proxy provides such a communication channel and makes it possible to
exchange information in a private and authenticated way.</t>
        <t>It is expected that in-network functions are usually provided close to the
client e.g. hosted by the access network provider. Having this direct relation between
the endpoint and the network service is also necessary in order to discover the
service, as the assumption is that a client knows how to address the proxy
service and which service is offered (besides forwarding). Such a setup is
especially valuable in access networks with challenging link environments such as
satellite or cellular networks. While end-to-end functions need to be designed
to handle all kind of network conditions, direct support from the network can
help to optimize for the specific characteristics of the access network such as use
of link-specific congestion control or local repair mechanisms.</t>
        <t>Further, if not provided by the server directly, a network support function can
also assist the client to adapt or prioritize the traffic based on user preferences
or device characteristics and capabilities. Again, especially if the access network is
constrained, this can benefit both the network provider to save resources and
the client to receive the desired service quicker or less impaired. Such a
service could even be extended to include caching or pre-fetching if the necessary
trust relationship between the client and the proxy exists.</t>
        <t>Depending on the function requested, the proxy would need to access or alter the
traffic or context which is limiting due to the necessary trust. Therefore
alternative models should be pursued in most cases. One such model is
explicit exchange of information about the current network state
from the proxy to the client.
This enables some services to function by having the end-to-end peers
act on or inject the learned information from the proxy into the end-to-end connection(s).
Thus achieving the benefits without the need to access the content or some
of the traffic metadata directly. Especially transport layer optimizations do not need
access to the actual user content. Network functions should generally minimize
dependencies to higher layer characteristics as those may change frequently.</t>
        <t>Similar to previous usage scenario, in this setup the client explicitly
selects the proxy and specifies the requested support function. Often the server
may not need to be aware of it but depending on the optimization function,
server cooperation could be beneficial as well. Usually though, it is expected that
even if the server is aware, no direct information exchange is needed
between the proxy and the server. Instead, any needed information
will be provided "over" the client and thus, the client and the proxy need
a direct and secured communication channel in order to request and configure
a service and exchange or expose the needed information and metadata.</t>
        <section anchor="security-and-access-policy-enforcement" numbered="true" toc="default">
          <name>Security and Access Policy Enforcement</name>
          <t>Some deployment models may wish to enforce security or access policies on
traffic flowing between domains (physical, logical, administrative, security
etc.). To support this, endpoints coordinate through a gateway that can require
information about the transport layer, application layer and application
content. Policy is generally configured out-of-band, either statically or
through some independent control plane.</t>
          <t>In one use case, the enforcement function controls egress traffic; a client
connects to a proxy, typically inside the same domain, in order to cross the
domain boundary. In another use case, the enforcement function controls ingress
traffic; a client connects to a proxy that controls access to the ultimate
destination. This may be deployed inside the target domain, near it, or further
away as a part of a third-party security service. Clients are usually remote and
diverse, and use connections that have crossed several other domains (with or
without tunnels).</t>
          <t>Enforcement functions typically require some form of client authentication such
as username, password, or certificate. Authentication is enforced at the earliest
stage of communication.</t>
          <t>Enforcement rules might require access to transport characteristics of the
ultimate endpoints (such as client source IP address). This might change as
traffic moves between domains, whether tunneling is used or not. Therefore, it
can be desirable to encapsulate original information in form accessible to the
enforcement function.</t>
        </section>
      </section>
      <section anchor="frontend-support-for-load-balancing-and-migrationmobility" numbered="true" toc="default">
        <name>Frontend Support for Load Balancing and Migration/Mobility</name>
        <t>Application service providers aiming to improve access flexibility might use
proxies in front of their services.</t>
        <t>In one usage scenario the client communicates with a reverse proxy that assists
with access to and selection of the content requested. This proxy that may or
may not be under the authority of the service provider. Today such reverse
proxies terminate the connection, including the security association, and as
such appear as the communication endpoint to the client. Terminating both
transport and security may be problematic if the proxy provider is not under the
direct authority of the actual service provider (e.g. a contracted third party).</t>
        <t>In another usage scenario the client communicates with a frontend proxy that
manages traffic steering to assist with load balancing or migration for mobility
support of server or client. This proxy is more likely to be located close to
the server and under the same administrative domain, or at least has some trust
relationship with the application service provider. The server may have its own
communication channel with the proxy or tunnel endpoint in order to provide data
that is used for decision making. Meanwhile, the client is usually not aware of
any specifics of the setup behind the substrate endpoint. However, improving
visibility may benefit future explicit tunneling or proxying approaches.</t>
      </section>
      <section anchor="iot-gateways" numbered="true" toc="default">
        <name>IoT Gateways</name>
        <t>A number of IoT devices are connected via a low-power wireless network (e.g., a
Bluetooth LE piconet) and need to talk to their parent cloud service to provide
sensor readings or receive firmware updates.</t>
        <t>When end-to-end IP connectivity is not possible or desirable for at least
some of the devices, one or more IP capable nodes in the piconet can be
designated as ad-hoc gateways to forward sensor traffic to the cloud and
vice-versa.  In other scenarios, a less
constrained node - sometimes called a "smart gateway" - can provide the
forwarding role permanently.  In both cases, the gateway node routes messages
based on client's session identifiers, which need to be unique among all the
active participants so that the gateway can route unambiguously.  The access
network attachment is expected to change over time but the end-to-end
communication (especially the security association) needs to persist for as
long as possible.</t>
        <t>A strong requirement for these deployments is privacy: data
on the public Internet (i.e., from the gateway to the cloud service) needs to
be made as opaque as possible to passive observers, possibly hiding the natural
traffic patterns associated with the sensor network. A mechanism to provide
discovery of the proxy node to the rest of the piconet is also typically
necessary.</t>
        <t>Today, the above requirements can be met by composing an end-to-end secure
channel (e.g., based on DTLS sessions with client-chosen connection IDs
<xref target="I-D.ietf-tls-dtls-connection-id" format="default"/> or application layer TLS
<xref target="I-D.friel-tls-atls" format="default"/> from the sensors to the cloud together with a
multiplexed secure tunnel (e.g., using HTTP/2 WebSockets <xref target="RFC8441" format="default"/>, or a
proprietary shim) from the gateway to the cloud.  In the future, a more
homogeneous solution could be provided by QUIC for both the end-to-end and
tunneling services, thus simplifying code dependencies on the gateway nodes.</t>
      </section>
      <section anchor="multi-hop-chaining-usage" numbered="true" toc="default">
        <name>Multi-hop Chaining Usage</name>
        <t>Providing a generic approach to use QUIC as a substrate also enables the
combination of multiple of the above use cases. For example, employing multiple
obfuscating proxies in sequence, where the communication with each proxy is
individually secured, can enable onion-like layered security. Each proxy will
only know the address of the prior hop and after itself, similar as provided by
onion routing in Tor project <xref target="TOR" format="default"/>.</t>
        <t>Further, it would also be possible to chain proxies for different
reasons. A client may select proxying support from its access network, while a web
service provider may utilize a front-end load balancing proxy to provide end-to-end
secure communication with the applications components servers. Here the proxy and
the load balancer have different tasks. The access network proxy optimizes the
aggregated data transport. The load balancer needs to route different set of
end-to-end protected data that it aggregates. A third example would be
multiple proxies to cooperate and maybe exchange measurement information in order
to optimize the QUIC connection over a specific segment.</t>
        <t>The above examples indicates that a solution likely have to consider how to
establish a security model so that endpoints can selectively choose what
connection related information to share with the different proxy entities.  The
possible efficiency should also be consider and multiple layers of encapsulation
should be avoided when the security model allows for it.</t>
        <section anchor="considerations-for-multiple-encryption" numbered="true" toc="default">
          <name>Considerations for Multiple Encryption</name>
          <t>Using QUIC in a multi-hop fashion will generally cause all user data to be
encrypted multiple times, once for each hop. There are two main reasons
to encrypt data multiple times in a multi-hop network:</t>
          <ol spacing="normal" type="1">
            <li>To ensure that no hop can see both the connection metadata
of the client and the server (thus obfuscating IP addresses and other related
data that is visible in cleartext in the transport protocol headers).</li>
            <li>To prevent an attacker from being able to correlate data between
different hops to identify a particular flow of data as it passes through multiple
hops.</li>
          </ol>
          <t>However, multiple layers of encryption can have a noticeable impact on the
end-to-end latency of data. When a Tor-like approach is used, each
piece of user data will be encrypted N times, where N is the number of hops.
Devices such as IoT devices that may not have support for cryptographic optimizations,
or are constrained in terms of processing or power usage, could be significantly
slowed down due to the extra overhead or not be able to process such traffic at all.</t>
          <t>Since QUIC is an encrypted transport, the content of all packets after the
handshake is opaque to any attacker. Short-header packets,
particularly those that have zero-length Connection IDs, only send encrypted
fields. Thus, for all packets beyond the QUIC handshake, encrypting packets
multiple times through a multi-hop proxy primarily achieves benefit 2) described
above, since benefit 1) is already achieved by QUIC being forwarded without
re-encryption. If a deployment is more concerned with benefit 1) than benefit 2),
it might be preferable to use a solution that forwards QUIC packets without
re-encrypting once QUIC handshakes are complete.</t>
        </section>
      </section>
    </section>
    <section anchor="requirements" numbered="true" toc="default">
      <name>Requirements</name>
      <t>To use QUIC as a substrate, it could be beneficial if unreliable transmission is
supported as well as having a way to potentially influence or disable congestion
control if the inner tunnel traffic is known to be congestion controlled.</t>
      <t>Communication between the client and proxy is more likely to be realized as a
separate protocol on top of QUIC or HTTP as e.g. proposed by MASQUE.
However, a QUIC extensibility
mechanism could be used to indicate to the receiver that QUIC is used as a
substrate and potentially additional information about which protocol is used for
communication between these entities. A similar mechanism could be realized in HTTP
instead. In both cases it is important that the QUIC connection cannot be identified
as a substrate by an observer on the path.</t>
      <t>With QUIC, the use of proxying functions cannot be done transparently. Instead,
proxies needs to be explicitly discoverable. The simplest form of such discovery
could include pre-configuration or via out-of-band signaling. The proxy could
also be discovered through advertisement when a client is connected to a network
(for example, the Dynamic Host Configuration Protocol). Alternatively, the
client could obtain a white-listed proxy address when making first contact with
the server (CNAME/IPaddress). In both cases the proxy needs to have a routable
address and name.</t>
    </section>
    <section anchor="review-of-existing-approaches" numbered="true" toc="default">
      <name>Review of Existing Approaches</name>
      <t>As already mentioned, HTTP proxies are usually realized by use of the HTTP
CONNECT method (see Section 4.3.6 of <xref target="RFC7231" format="default"/>). This is commonly used to
establish a tunnelled TLS session over a TCP connection to an origin server
identified by a request-target. In HTTP/1.1, the entire client-to-proxy HTTP
connection is converted into a tunnel. In HTTP/2 (see Section 8.3 of
<xref target="RFC7540" format="default"/>) and HTTP/3 (see Section 4.2 of <xref target="I-D.ietf-quic-http" format="default"/>), a single
stream gets dedicated to a tunnel. Conventional HTTP CONNECT is only specified
to open a TCP connection between proxy and server, even in HTTP/3, so it enables
forwarding based on a split TCP-TCP or QUIC-TCP connection but unaltered payload
traffic. There is no currently-specified HTTP mechanism to instruct a proxy to
create a UDP or IP association to the server.
<xref target="HINT" format="default"/> contains a deeper analysis of
the problem space and potential solutions. Of those explored, a good candidate
for MASQUE is the Extended CONNECT method <xref target="RFC8441" format="default"/>, accepts a ":protocol"
pseudo-header that could be used to express an alternative protocol between
proxy and server.</t>
      <t>An explicit proxy control protocol is the SOCKS protocol <xref target="RFC1928" format="default"/>. Version 6
is currently under standardization <xref target="I-D.olteanu-intarea-socks-6" format="default"/> which provides
fast connection establishment. Use of QUIC could even further improve that. However,
SOCKS provides support to establish forwarding sockets using a new connection (with
a different port). This behavior is visible to the path and not necessary if the
underlying transport is multiplexing capable, as QUIC is. A SOCKS-like protocol
could still be used for negotiation and authentication between the client and the
proxy. An example proposal for this approach is <xref target="I-D.piraux-quic-tunnel" format="default"/>.</t>
      <t>In that sense the TCP PROXY protocol could also be seen as a light-weight version
of SOCKS (see https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt). This
protocol was never standardized and only provides a limited set of functionality.</t>
    </section>
    <section anchor="contributors" numbered="true" toc="default">
      <name>Contributors</name>
      <t>Magnus Westerlund has contributed two paragraphs on combining proxies.</t>
      <t>Tommy Pauly has contributed text on multiple layers of encryption, and other
edits to the use cases.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="I-D.schinazi-masque" target="http://www.ietf.org/internet-drafts/draft-schinazi-masque-02.txt">
          <front>
            <title>The MASQUE Protocol</title>
            <seriesInfo name="Internet-Draft" value="draft-schinazi-masque-02"/>
            <author initials="D" surname="Schinazi" fullname="David Schinazi">
              <organization/>
            </author>
            <date month="January" day="8" year="2020"/>
            <abstract>
              <t>This document describes MASQUE (Multiplexed Application Substrate over QUIC Encryption).  MASQUE is a framework that allows concurrently running multiple networking applications inside an HTTP/3 connection.  For example, MASQUE can allow a QUIC client to negotiate proxying capability with an HTTP/3 server, and subsequently make use of this functionality while concurrently processing HTTP/3 requests and responses.  This document is a straw-man proposal.  It does not contain enough details to implement the protocol, and is currently intended to spark discussions on the approach it is taking.  Discussion of this work is encouraged to happen on the MASQUE IETF mailing list masque@ietf.org (mailto:masque@ietf.org) or on the GitHub repository which contains the draft: https://github.com/DavidSchinazi/masque-drafts (https://github.com/DavidSchinazi/masque-drafts).</t>
            </abstract>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="TOR" target="https://www.torproject.org/">
          <front>
            <title>TOR Project</title>
            <author>
              <organization/>
            </author>
            <date year="2019" month="June" day="05"/>
          </front>
        </reference>
        <reference anchor="I-D.schinazi-httpbis-transport-auth" target="http://www.ietf.org/internet-drafts/draft-schinazi-httpbis-transport-auth-01.txt">
          <front>
            <title>HTTP Transport Authentication</title>
            <seriesInfo name="Internet-Draft" value="draft-schinazi-httpbis-transport-auth-01"/>
            <author initials="D" surname="Schinazi" fullname="David Schinazi">
              <organization/>
            </author>
            <date month="January" day="8" year="2020"/>
            <abstract>
              <t>The most common existing authentication mechanisms for HTTP are sent with each HTTP request, and authenticate that request instead of the underlying HTTP connection, or transport.  While these mechanisms work well for existing uses of HTTP, they are not suitable for emerging applications that multiplex non-HTTP traffic inside an HTTP connection.  This document describes the HTTP Transport Authentication Framework, a method of authenticating not only an HTTP request, but also its underlying transport.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.ietf-tls-dtls-connection-id" target="http://www.ietf.org/internet-drafts/draft-ietf-tls-dtls-connection-id-07.txt">
          <front>
            <title>Connection Identifiers for DTLS 1.2</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls-connection-id-07"/>
            <author initials="E" surname="Rescorla" fullname="Eric Rescorla">
              <organization/>
            </author>
            <author initials="H" surname="Tschofenig" fullname="Hannes Tschofenig">
              <organization/>
            </author>
            <author initials="T" surname="Fossati" fullname="Thomas Fossati">
              <organization/>
            </author>
            <date month="October" day="21" year="2019"/>
            <abstract>
              <t>This document specifies the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2.  A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association.  In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple.  If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.friel-tls-atls" target="http://www.ietf.org/internet-drafts/draft-friel-tls-atls-04.txt">
          <front>
            <title>Application-Layer TLS</title>
            <seriesInfo name="Internet-Draft" value="draft-friel-tls-atls-04"/>
            <author initials="O" surname="Friel" fullname="Owen Friel">
              <organization/>
            </author>
            <author initials="R" surname="Barnes" fullname="Richard Barnes">
              <organization/>
            </author>
            <author initials="M" surname="Pritikin" fullname="Max Pritikin">
              <organization/>
            </author>
            <author initials="H" surname="Tschofenig" fullname="Hannes Tschofenig">
              <organization/>
            </author>
            <author initials="M" surname="Baugher" fullname="Mark Baugher">
              <organization/>
            </author>
            <date month="November" day="4" year="2019"/>
            <abstract>
              <t>This document specifies how TLS and DTLS can be used at the application layer for the purpose of establishing secure end-to-end encrypted communication security.  Encodings for carrying TLS and DTLS payloads are specified for HTTP and CoAP to improve interoperability.  While the use of TLS and DTLS is straight forward we present multiple deployment scenarios to illustrate the need for end-to-end application layer encryption and the benefits of reusing a widely deployed and readily available protocol.  Application software architectures for building, and network architectures for deploying application layer TLS are outlined.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8441" target="https://www.rfc-editor.org/info/rfc8441">
          <front>
            <title>Bootstrapping WebSockets with HTTP/2</title>
            <seriesInfo name="DOI" value="10.17487/RFC8441"/>
            <seriesInfo name="RFC" value="8441"/>
            <author initials="P." surname="McManus" fullname="P. McManus">
              <organization/>
            </author>
            <date year="2018" month="September"/>
            <abstract>
              <t>This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7231" target="https://www.rfc-editor.org/info/rfc7231">
          <front>
            <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
            <seriesInfo name="DOI" value="10.17487/RFC7231"/>
            <seriesInfo name="RFC" value="7231"/>
            <author initials="R." surname="Fielding" fullname="R. Fielding" role="editor">
              <organization/>
            </author>
            <author initials="J." surname="Reschke" fullname="J. Reschke" role="editor">
              <organization/>
            </author>
            <date year="2014" month="June"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7540" target="https://www.rfc-editor.org/info/rfc7540">
          <front>
            <title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7540"/>
            <seriesInfo name="RFC" value="7540"/>
            <author initials="M." surname="Belshe" fullname="M. Belshe">
              <organization/>
            </author>
            <author initials="R." surname="Peon" fullname="R. Peon">
              <organization/>
            </author>
            <author initials="M." surname="Thomson" fullname="M. Thomson" role="editor">
              <organization/>
            </author>
            <date year="2015" month="May"/>
            <abstract>
              <t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited push of representations from servers to clients.</t>
              <t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.ietf-quic-http" target="http://www.ietf.org/internet-drafts/draft-ietf-quic-http-27.txt">
          <front>
            <title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-27"/>
            <author initials="M" surname="Bishop" fullname="Mike Bishop">
              <organization/>
            </author>
            <date month="February" day="21" year="2020"/>
            <abstract>
              <t>The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment.  This document describes a mapping of HTTP semantics over QUIC.  This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="HINT" target="http://www.ietf.org/internet-drafts/draft-pardue-httpbis-http-network-tunnelling-01.txt">
          <front>
            <title>HTTP-initiated Network Tunnelling (HiNT)</title>
            <seriesInfo name="Internet-Draft" value="draft-pardue-httpbis-http-network-tunnelling-01"/>
            <author initials="L" surname="Pardue" fullname="Lucas Pardue">
              <organization/>
            </author>
            <date month="October" day="18" year="2018"/>
            <abstract>
              <t>The HTTP CONNECT method allows an HTTP client to initiate, via a proxy, a TCP-based tunnel to a single destination origin.  This memo explores options for expanding HTTP-initiated Network Tunnelling (HiNT) to cater for diverse UDP and IP associations.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC1928" target="https://www.rfc-editor.org/info/rfc1928">
          <front>
            <title>SOCKS Protocol Version 5</title>
            <seriesInfo name="DOI" value="10.17487/RFC1928"/>
            <seriesInfo name="RFC" value="1928"/>
            <author initials="M." surname="Leech" fullname="M. Leech">
              <organization/>
            </author>
            <author initials="M." surname="Ganis" fullname="M. Ganis">
              <organization/>
            </author>
            <author initials="Y." surname="Lee" fullname="Y. Lee">
              <organization/>
            </author>
            <author initials="R." surname="Kuris" fullname="R. Kuris">
              <organization/>
            </author>
            <author initials="D." surname="Koblas" fullname="D. Koblas">
              <organization/>
            </author>
            <author initials="L." surname="Jones" fullname="L. Jones">
              <organization/>
            </author>
            <date year="1996" month="March"/>
            <abstract>
              <t>This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.olteanu-intarea-socks-6" target="http://www.ietf.org/internet-drafts/draft-olteanu-intarea-socks-6-08.txt">
          <front>
            <title>SOCKS Protocol Version 6</title>
            <seriesInfo name="Internet-Draft" value="draft-olteanu-intarea-socks-6-08"/>
            <author initials="V" surname="Olteanu" fullname="Vladimir Olteanu">
              <organization/>
            </author>
            <author initials="D" surname="Niculescu" fullname="Dragos Niculescu">
              <organization/>
            </author>
            <date month="November" day="4" year="2019"/>
            <abstract>
              <t>The SOCKS protocol is used primarily to proxy TCP connections to arbitrary destinations via the use of a proxy server.  Under the latest version of the protocol (version 5), it takes 2 RTTs (or 3, if authentication is used) before data can flow between the client and the server.  This memo proposes SOCKS version 6, which reduces the number of RTTs used, takes full advantage of TCP Fast Open, and adds support for 0-RTT authentication.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.piraux-quic-tunnel" target="http://www.ietf.org/internet-drafts/draft-piraux-quic-tunnel-00.txt">
          <front>
            <title>Tunneling Internet protocols inside QUIC</title>
            <seriesInfo name="Internet-Draft" value="draft-piraux-quic-tunnel-00"/>
            <author initials="M" surname="Piraux" fullname="Maxime Piraux">
              <organization/>
            </author>
            <author initials="O" surname="Bonaventure" fullname="Olivier Bonaventure">
              <organization/>
            </author>
            <date month="November" day="4" year="2019"/>
            <abstract>
              <t>This document specifies methods for tunneling Internet protocols such as TCP, UDP, IP and QUIC inside a QUIC connection.</t>
            </abstract>
          </front>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAGB5Zl4AA5Vc25IbR3J9r69ocx9MRgAQRcnr3XE4vFyKshgrSrQ48voS
DkcBXQB62ejCdnXPCFLw350nL1XVmKE2/CCRBNB1ycrLyZNZvV6v3dRNfbhp
fkyheeVTSI0f2uaH8Ne5G8MpDFNq9nFs/u3HN68aT1827+dtmkY/Bee32zHc
3ch35eM27gZ/oiHb0e+n9Yc5HPtw3w3t+uTTX+ewpqF362S/Xz9/7lr688bt
6P+HOF5umm7YR+e683jTTOOcphfPn//++Qv3IVzu49jeNG+GKYxDmNZfYQrn
0kSL/l/fx4GmvYTkzt1N898pjtMY9mnVpMsJf/kf5/w8HeN445pmTf81NFO6
ad5umj/lVfLHsoG33fgXf/1VHA83zeux26UUB/4knHzX3zQn/HpTtvuHoD/a
7OJpOeF/bZr3fvwQxmqy//LH0M4//+xPfqi//eR8P1cPbBI/8CtT3m6ar2NK
fuqqOW+Pkc5k8QVP93I81TNN/LPNXn72Bz+eHo7/7aZ558d2DtXw3847Gr36
mAd/1ce53fd+DPUcPX575p9uXny5+cc/HPA5z+PcEMcTzXxHSkJqQcpR/kkj
3H7/ww0P1aguP6FPmndj/EvYTU/kG9aw5sXzz3+/fv7b9fN/0N/78RAmeuA4
Ted089ln9/f3mymOZ3l2Q+v97Ilz6/W68ayuO1K2N0OTummmBcQhNffHMIam
JWPZTc0uDgP92d1106XpUjPEqfF3tA+/7QPtvmlDol+2q4Zm+KkjY+sGkm5o
SJdJsz84Ekozp9A2U4TZ3ZM82B7PcSJT7HzfX8gi/JB62g/+tt93u427ffUO
08U9/UqeZ1PFJJduOGDmaaal9fgHfTrFXew3YrgdfjmE+5Ujcx8P+AXPcCbr
yb/lRUy8Vf596k60qbEJP51pvywK+tpPTTfR0mNz3/W924ZqLdnemzjsAn5H
A913baAdteHcx0toN+SFML+sa0hT8C1tquHtDS781KUJ36ddGPzYxcTzNCSV
eF82y0vNu01hvOt2JGmSKGnUMHkV+TYMYd9NydEEPOHAKtVfVjQqafw80boO
o29ZIvTAOYyseFg+5khhN4846N3RQzPI9mh5u7Rx4iz7FJt4DqQj8xkCpn9A
pvPQTTh5eFUaltxuvcSjvwsNbSeMDY542F0wF4lyovGb09xPNMkY/In3NvOI
G7JjEib53RkOmz4+nUg8P9OItMIRH2G9+3maWb38IbgiQpq0paXTtOOnnX45
PZZuhLTv6PAa37YdTt/3jpQ/0UejGgYG4DMhZTnQ93Y09LNpJI0qqpXw93OE
qmwvzduX7//tx9cbsbpT17Z9cO43cPljbOcdBnduobmP6Ssr4z0N3QY6UzqG
lk+VHtiTmMhUBjqOibT4Z1qX++b29p1ZE9aggsWSWeTnnnSP/mGKcSTFXMf9
mjYV1ts+7j7Y7kjBoDR41GUFEe9Aik7fRtalvGI9u6k7HKfyMFa3LwrGCp6W
D7qFCh7pX+noP4gSkeGR39zS4lqZEgY7HMgFjXGmODyN3ZlMl/R2OIRVQyGU
dOv+2O2ObhtJSIuJslOjRWFORFD4IkTrtiENHS9n/pKiMx3ICD3y7YUO8I8e
RxrF3B54Cj5Ctl9arjoCdhdQHBzICk5iH23v9Ag7IKc2n3ifUABxl6TPcLKY
i4ZpzKptNNNFtTUsL1wi7UemOpLJ3YVxJQ+pdkO/DuQmRt+vz/MIFf2kru38
kB0e5iQ/cWkiVtyQcrRwzqZhKwSNAdPxavfBwzCTzcpWgGW4p3SKFBJ1f+b9
IoubUE3ffQjwjc9Y6uLPdhQjGlWyIynVuvcXmke3vXHv6RQ6+hkiiWz272mX
266HFsFFmrqv7GgROv2Kj/7UHdgHkDe6DxRpNGo1Zz8dkzux+sGxt4EWASGk
2M/iDVhGOCpWUHHPTfYQOZC517ZLC5D8IPaHWLo1jRLPNAYNeXIoHq4OBoU4
RPIhGZDtRTzp1LexXHaR/EExM9YY2vUJW6uUPQztOZL5JNl8mQ3j3XWpY3Uj
Hz9waGfL0eHyo5vmzf5KpTj2+NSJh1SnnOMVm3UOZVl+Kw2YYkVQCLEH+mgM
vXjcIxk124bY9aZ5OTV98GnCCt31yrLp+XvZmcQ4Pg6sgWbqSZvgtUheI0VB
iId9aGdeS/yS2/UdYswxpknD7IeQnycHvCNZQQf8Fr4T05SIhyPC2QRa5n6M
Jzt39xTSCT/5EynjCniD/jRIpJDmFEcEoDtEZFLXzWFTx+h18e+rPOGzldMA
RnpBHmRmvOHFkbLXPFF83oluQI5QU1N3Wuwphf5Oc6QsL1JbCVrNL7/83Zv1
V5u0O5K4fu404fn4UUJVjnL7keAxW45ot7i4kXSgjjjZvOLo/BnSlGVl4XUc
b1n/WMUq3ZUgoOIS/yFq6lhognt5pDAmnCZrxnqK64CdWSQsG2/0kG3jixGc
6ZKocc9hhzb8lM47jM8erO5XxlVByrgEbKFmPEr9PPnaHAAMLcsJkrZaXKug
iSIQ6Iyij5JEXC1nMX9elSySznkJtMicd2O3paNI8ZRtCNFnx5k0VHguiDYj
ogcolbTyMRC0ypZIoDWZwknQIYMgzKmaSCg1xP2eg0yad0dF1IzkNkBPPwL0
Ne8N9NFHv2m+3+7npDp11/nmNvsgJ3+VaM4CpuPkgFYjb/I+eoSxOBBLZNiW
vZ2ueZ2GsYg4GYF28rFihHuPGASVTdlNkBYQ9pPZWaoSPV2lO5WrgrNpBQTh
GHgQwXJYoE1N6yaPhvAbnaqVrEwmZGfbRj5WUo6dx1D+OseLWNQFKsgAEHFp
5FNBgicO0kFRQ8cgYKuxh7aA+dlbBdAYZ0obiq1LOmkGiCBBw9172BR7rvuw
zd/mcLplYIewEEVra5FkVFFQ0AqOQLAJYbVkaD0DWRLVLoycKWVnwwum5Bzz
kRKkOCLgrBgdUGa27/pJQypUVARETnlCUM+aRSKghR6O+STUziAnyyjuoF+E
0C0/o1zZExTfzZRv0nb48M1tK3qAEz1KniJ+PKMY2rZ5cUZLsMMbSi2K8mty
ZzIlKANqKZk+2+esz5oFpjPn+KzzcatO1P2KU5MoASgg5jIgmWcpZ13SwElK
HhjXy5iQC4N535OrkVQafnxPAYO1lLSTPA9CwQ4nCZCPdANLJhHwqeYVQtvb
gKMB2pXJOpp/XCxDoCTEAsOHppDIBXtXKyfzAxi+enDzmGRFFoQy37yDSyag
m/62NDUnycJbOcW0RTq0fQrG+wUUqYVPD5AhzuAaKl9PgAimKlCkg//cTTMl
r6T6XlSWTBiayBC0u/O7y6O7Kuv4xM7KVh5XDFf2JqmX2Y1sgiyBcizC5Oq2
aCVTKDPadIho3Ujh6A6unnfRZ5dBiKLnTOcNMreLqnQKNTti/nwFFepnJTtw
tkbKkCBbf1lVy3ePO1yGfZp6+WW6hR32RvrMaWYeaz9nNkugu1NKJLthIEDa
mKBOlgrrnwKcI7zFQsOy0OwUnEUQ1hHBz9kvegkKGAG03GGAdV0xMj6DJYnZ
zhw81sYe9L4TOwA9wgm3efIUpvnMkIE8Ou0srITsYwkgGpvsa8X4MJgWs/yq
k15ictpYL7oSmyqCFQhfhThm0sZ5N1VfV/QiKDDzchIENUVcYrxN872kWmWK
JCDsTGExDvvuMGum+gS7eMLyXzpCkUO93xzCalZBLbt5yjFHfD0Hr9tMfrws
P4c2/PLLvyxwN+jcbZfWOVlfY/yPH59tmj+S3WelghPwi6EIidFHBE6G7jSf
Vo+utWQJoVA7WUezgDWgsaFne90/RM8wi3s/XB+mZjTV9l99/913r1/dSgpT
M8ISyms3h7XKYcinynge/R3F1nGR7ZGK/qgWWWwvk9cPk0MFfQLfKLOKxZMV
EY1hfT92k5x15R7hGoZLwTeSwbBIhBKgGEXgglNiizojGdI41JiI1U4Rz9bv
PixUvxi7MLDQWmdZwg7kMxiSciafmeu3bZb4UfsiPgwo6o78gnlaC4jCNsa5
b4WmCPozpgi2l4Xrl7BjxKxN7rIz2TA4fylpbdu8L/D1R1pL8/LAnt59Fc4U
gxitDQukIjQ8YVcM/wSA8EkVR9UHi+FGXSEeqU6R0Zgk0oskSldS8s+9pe6S
tNSZ0q0EjXcVZ/56ICS2w4rfKbfz9N3rd+lZDgiSEZd4QB/RqIKfnUQLZFBA
g6KuYTyBlqgw3APKElUvI+Ms/F1vhLeeByNxdgYLaBKcp1oTU2AE+dl9bFla
JD1Y3G7TfGMEogg4ZmcZh57gCy3CGx0DoEZCW2V6B5IcYkkwahIi+xXVH6zN
Kkob9xqkp+6/jluZKKtyATMxDkx/E5UUwooTSv8JbkRkosRfUSiyYkvDa7fE
rICBmYdkMuV/QCuPMF3dsLa4up+HCqqa7uQsZ9czSxvr8MO2C3qq6KnYZ2Ew
5XGKct/4O5EnEn05EGPYTGauJtIyyC9xXyCPWRkpIs3kx2VMbru0i8oAO31k
pQCE/kjz6WyqKBzREiEAwMMZqVvNp2ZD8aoEVlbrift9QIx+ug2Jj7bwaRQZ
38s5i3pQ8hoYCLB073w/M7uOA1xITogAqAOlqANXD0kfP5B47roxDlJLEg1K
LtEp9z3CAnAr/RU5XR5p0/yZUWJFRJWzNpZ/a2CN8mEulw0UhYD+mWWHjds5
kA8Q10XYVg/SDD+D9PxbQnbH0J+ZJxPaMDQZjRoeuqrzWby4UiXdLJAwSFdI
Y12GiGQSSSxI62A0iwSTMQBaNqcAw+nSCcj963mE91uJh5gWJYIqWhsKWXE9
xNahm1UZ8iZZI0m9aAdXsc63/jwJI99FCt2QQB1WskeZEYUI80GVBnhPLmuz
il0LiMt9/izlBXJ5G4peBJIpmBbV6h4VIriTgqlXYo6SDTMr0OQ61bUFMxfo
uZqZCOrshKx1y82StAJSTsP+MAqzE3SnfKBxcC5YUqF0xECyie043lswCD+R
w8+YC6kUyB4A0oNINaz3YZJ/d8aVqWdw3OSyZPL/Fp0g9SDoyAMkkE88R+dV
9ZzCFLUnlTvCU68Zd84GlC6lnakroTPoyTY44CoVtNiHNOswnSxQ3/GgUlhv
TrEFp5iOvADEz3lMs5KL5JyF3qM8YwhiRPwAeyKLYDmokGHVcaVUFgxXZSuY
0JJU+AYD5wusAuWS8qEyuXVFPktzizLrXUUAmJc6B3A1pPhcVQYQ/0vQbIsC
/ihV2LLYq8XkmnA1YsEvT9MzLHAGIjl2IU9v7FhOY+QgFoe6oGxG3pm7orVO
YfJg8LIH2TSvi20WQCVVRHWNWuCXyhpP6mzGqMYM8CSeQhewab57EL9VE7TC
2l8k6yLH41pWaXIvnXZFdIcjd0RgFQ+8TFLGAthM9WPPqg8ISQbyXptVOCcL
d8wuLlPwkppL9HuUXC4596JQpr5dK3sFEF/73zqB1rIJFmwi1OCWEy74OG5B
uTLu+gzy2CtnRGpV2tyZnVWVYZLVPcVdNNpYygc+9tHyomPXpr6qpIW8wlWF
V2vdLqgvKWpe8KJFakt6nzt9VpwaKtauBs3VpRz8qqxm4RrntPq0vxQ9tUXn
7glAxkeRbY3WrEKp/SvCdTjf1Gir+CZui4pafni4H8HManic7f2meZ9bPei7
l2JM7yIp3oXSJnpyx105pMrwTqW4Yz4VikS541H6IPj3pTcEvl1GPGNEaCoJ
NRPbfbyHetkxtfHExaan5+MloU9gRfDkIH/xLSyUG4HIoa/yFA40PyHI25i1
Hsa0qqrNVQ251AAO9E+u+WgDhXUgucd9+5U7ovVUVVHxDZxTlE9d9j4qTFLL
4m4q1oqmQD/Plp5fWcUGoUMaJVAusVVzfCCoqR5qKv1MvR+CkK2g6K0KuFLf
ng+xAmTyJJndQVC8HMk/ZbBvxalU1c1ovMtZl1XRJ8lDMfjsVgvV3Y1RQoGT
bwk5zUNLwZrLan4Q7uj/s1rSFizXPVhu88hy9Wzt2WWcsK4L8vdo+vDiJjkc
a2ktk9A1UyTkmW12oBBL7ovZ4r3AZeehVdIC6a30Rxo5tmv8+1Jsw/pimle8
g2VOOYZTlDzVtR2o/CAF2fmq8qH1J4I4LGzGknfQMSXmsklxqhRRLteYLWXW
Z+h7eUTkqTpq619h9WNmBuUj9XNLMhTYyUkCMqIPFwW0lNA4vZK8a5y4A2hC
i8jyUcZBvJC2UfaNpNuDrUCPtQCvhbu8WjpXHNAndJzykqszLwTNo6mUy204
xXE8tXxKNyugvuIUn5nG8KRW+y+c9imiYePKvXERmQ+n1EKYmBdmn6yiQrGI
jlaK42zBa+cPARR/TjP34lLORNmv76/5DmHRChuozMRjJibM39cj+6zC/CEP
/Tb6tvmj75VAgxa+7bRV8LO3Ufq3nHv5sE0kJ0ak2x13jSJB4RpXPpo92hu1
B0zEiOS1alHeY016SF3uJku1t/tURaMiy5O1YI6Bran2EJKTJie/yBojYbrX
entcFlAz1lINqIaD+4gFYKFPZGi1oChXALS2ZjiklhQCWesvkoToWrM0jCe0
VjJzA8sCWhV+aWeRsJf8huNTcqLT5zNclzegXoOQumGiSlWa24ryRArsikkt
+kHVfVYMpQG5BbmXef4sHWf46FpIiumvZaVFGi8u3it4JE/LnvfyzKqPFmb+
P2qyN0soB0snOtAQOVZSkKbkS7VaeQ1+uofBbLPBgAM2e5H2TLOZqj1EMS58
pIm7qBU8DIpXaCPoL4rWmb2vSEdXQWWOFFnpOD4v8VOOYDU3jDYG9vGcSrur
5j7lPB7pBquVt6wBasCBCZlivAceegzqXtWu8m2BooY1orBGDe78sGpD7nu1
dj+wwiT5TfM2+IHLvwtsXtWB6zqT4yYjZctSMVBhrI+dZQ65Hd1WWBPwVsCX
Jk11a2wQwh1pz+UVL56JGmvQOtNfKelmN0d++U28bf5VAGsiT9sM82kbuJSG
b4QBE/ygToEEgrYqj3b+9Zlb+u/JuPqa52LrIbfg/tjPYYogtb593VDQJ6c6
PWMdsuRw8r0VujqugrDZ4C5N1oGq6Ji4RYdbsWkzTPAY6bXvxhOLez7jVgy2
92cCATX/QNH1sassmd+3mywcCPeV/rq6EU5lsrIOWbYfDA1KEP2NsS03YHTP
SvI5IXnZuIDj2vUx7ixfSHX5WjdaVbBFyyAXIDcsYQ0X7jcNEK84oqrvwTPN
5xYlfFpYs2Y7JDyCaxTcgEU/fZJOAJS6kCf0o7p1Cf6zalElxMsdLuSzhIrg
BTBzqZ1sWKolQTwpFzXJ04BPIzfnMuuaexwSgASgBfc67DvamTWQVDQC2TjF
xsafIjS554InGCqcv7RTdWcuOadYCq22Es7EsBAaxp+2lCLFOfHybzNT60yD
/TSRkZzUpguBEA2KSZWDxMh8xpLouvJHTyte+FMx9FkpMqN5CA6fFRAlWew1
ZS3dwErpTPFxdbWlunhTdUk27Oi53+dGPJvyLed5S14i3zhsnnabQBabSbyc
w9aKpwZZ1oqrASeP+zJkimfPZ5PqehljdO6Csr6hlX19QaeLwYoBdwV87x70
q5mI7KKLyI9tQ4+K0H4pLtS+wmpRl2WhnxVStzWC/bBv1VKtwJWTFJeJYLS9
lK4hyuCvbxcpmib7Aq2Kaw5RWvoWbkgIGmdhSp1ltomvbr99b/ZgdSg2k/UO
fOBQt2q++So57RLpwrRfT31at/hf+c26az9+5GD8gFagiezp/diFnh/39D96
IGuCSDstNWGKB8kzBNO4ujNRmxU11uruSr/HZy+aP4fte/SWksRo+h++fvW7
L7/8/ONHgQyApKSyYQLzTgDh9OzXtVLcjxQIEADh+uCS3TGeIlgR8KK5JJ3Z
w+tbKdIqauWX6rS4zPLg3t2KeTlp4O/2HFl3UKwFxau2VrtChCWE3bcQGHn/
c/PqSN4Zz3Mzs3PveGHSCMqkDpmDBW1rAH70BhuU1uh+rhLzXancA5L77w35
svrmrm7pKMg3E8IJPqTu23ex6hWskqjElDTKvNrk+wD1s44EL72AjDkdIR4K
wa0gJSUsV2w+et8pDlBdbm5lXQ0lC9g0r8tYfCMTvQhcQZaNLZuSuPDXQNKc
pXADpnRirfJ9T7+4peR4co4VnEAPlDgxguL6xy+/3H7/w8ePiyqmdclY937t
AXc43ywwxpIdF6wH4GBuU4YLUwAJQCeZYXVdpq7vSnNnXVVcaRuiRxe1e5DJ
YETaSI/KpyYfrNdXqcR1f1cdzh69RvIYbE/i8wYpj9s1jG9MLTJPzglFtQBa
JuP5LBmChemD3uB42NMAMK/lbFF1fziM4cBRgss+i3uI1zOVbi4GA2VOwuPA
6nUJTHpX87B6FThPxycneaFajioCQb1sbznFjrmOEazphiusiihOpAyzBvMr
toWTFFdX8SHA6/sn0iVfCvspHE52v8PsXZcJy201LdVGjOwiNRXkA5HeMr7/
qs0ZjkImmnPS0frSOQ/hmqahroof94MRHbiDTMYQkVKi9dpVK+d88KqcgIL3
EXg+K1o5KS0VoyuW6+84ZZeNLgBCdHzJWGtxZpd5Lyx+OyB2MOwvCvMFlr2U
dP1dZN+ALv0lhJONa5s2jLubtPbx6uG94bc24+t8vRRditXdcMSuHBn2nsIf
Wxoh3Yrfl4sbvVYiRTOxPadXG0O1Nwb6K7mczlfP4DppcOUBpRP4Xu6Q260J
JxxgviV5Ndr1MtUwb5z7nGsldaPjENnzihqEEl/r2yZaMnLLPsVlNa15yuG2
DkGFKtWLa3bzg1XJVQabGrvW2CHjCJQooPjf5QbD65uvuAdNGgGW5wVvCfVV
WZQkBmikYG8sVwqMON3FUaYXsVlfVdFbkgX7Ac1yLsrkyy0QrllBC/lhL61n
nrdnVZocizEQrS6TA4/rsl1hhvjZnD3yXYoO0vTEV60UpNRez27o61LQwBRw
5BQFJSJnOKIMyYrVyp07Asp4quil1TiLZn5nKilo4TtpBQsV7yB7+0qZB+PJ
azYic6HI3nljqSKVeaZ4GP35iG6PurgvDYvjsrMdekDZLAuN9sWUtpImzG4w
u7cqyBEZPFcaBq6e460GFB/i/VA3j5CCjZ498pHf9jDmDlpLjGQm2Z+lPXJr
kmv7MNj8OoChEmDW19WyE2LPLuHsBVfniyYu36HnVjlJ0piCvmRd3jTvj+gm
F723MVZucUNJmhFKUejnMMY1muPIpF8tMpIVN4cicWjLuh3l9H3LIR31bE5u
q/Vu5dZ6Dmt51fnCNoMU+bW7ckil9Fq8khHCHd4ZQauRPpOQL2A1L57li46t
4+AIPAix2y8+fybJIF/8twFKwiC2Xy6javmLQN262B5fj/J1bdsYV+7Z5i4a
DnDVpCTjoVrmytEfUr/gvAUtaqZFcoUvh24+HV1R0gvaKuBHVsfdF7trgRvZ
B5gwcdv24rVJSIE/lYMwEn6sP6MjnzCQa+xk3dDgU6eETzKuWjgx9HHgT+1J
8np7cnExgGBCzzkHM3Zd4lFLD6Kz2rXWBuQ2mHXil357ZAx2p/hhB2MfWtr8
qwXm/UT32q9Q6aQ7QN5C9xGQJpNCfMihhoHOOb/Wwd7q4PVm4mNvEMlO38sz
3KJnjLArVEg+CLslYJCvsB/MnI5NeXGFUd6y2sXbUeoDqNrnH/Y0lGtfcqO3
sOhXvFglzRQqNPcy52WPbCYLlNw2ROX0hTqbJQmpnT8U40izvN1leAw1kx9X
15y5x9Zd5dZbZC2Zw7K8Hu+HAMsM88Wo4pD1qljO3krZu8zUgjpeXAko7UK5
JFffg62vpimtxZ3yUhXhtwgIY3gqd6WN/nIiO+veRMumtYgoOTAyo181i5R3
28gMeoEC4zjD0jY+V8bU/7Z3qMInyWHuBTWUykgpIHAjhd2pXr4SASL86jL4
E9noN2iffLVY6ztVq2ekJqUJsxdKzuWqGzYct3zV10Mhp0DIhfvXNAdVjoDX
KCUdFBCS9HQAFsFf1nWvp6++e/n29Wdv3pX6/FLhli1Z5a1HnvNMnJarL72h
hUGd610XGPfll4S8zDUa516WCHSSS4LAW/nScxeumzvUPLYX00QsjC1FL1oB
cR9j2zwFIn+vVvDl5ovNb/FrIeT+8cUXn/O9Mrt0BMvlqK7OZJEGlvcjVNSl
paN4y9XyFQ4wJW4rsIbBYnhsaVYBX0tLDAuamcPPN59bJ8+EFgylRQm2iuB5
l9VconPQyfLGIFlrGfPFUg6/23wBDkCl8A9fPicp8Hnxj7+4FtoLFVkmYPkl
gLinR8+t8guKnLzcipK4Ca9uavViyGJBr7DSQb1qfTGOcRsDKm3JbIUJEEy+
lK651KqP0y56cdejbvoLXNKBi1S+sC7vlDs2NCGFFEyxxjT65qz19ZQz6uzc
EQ3z8hewLUbkW5rJlTbrYu4v67wV2emCv8/3OnOvVXS4Bo441Pz4FS8EyV8p
niwvtW1wet+8+e72n3Eq8u69fHUSf9qdm7XqLe3640cxfPQzAa2FM5MEvr8k
vmBiF4jQdkBi8burmFheaYN+WMXKcNqRiU3fHGLEpQGKwC13boMNkHdyaP7z
2hrtr6x0SZCDCzsD3jdPbizCPnHnFOY2GnzX1rSr4E+LUd/T1N3rOUxbsnqt
OSg3VZetLBJcvexMN/H++1d/el8+lbV//vsXv/v4cdP8O+padFi/dV0qqqDN
BPyqS2jgz4urr5GW6od5jRfckQqs6cg/pPVv6bgyyuDbXG7v0+IdFtk9MQPG
rwE1jFVdcNDGutw4BNGVkrvL27EbY9oEGsvw9bt7ktY07DUOeIdbtSTuk+NW
3Uxj0WjmY/UW61jTFXb/06PGMrTaVJ3vXWlzGeTXX5YvOAQWrd/wprVpvoql
QA84izcoOb0dmqIFCkSSuecOiCEc4tSVVt+r9rxPX+xwen+V1UhIUoG1+jYt
blCvKQU9+3M3+vkn8ahiqcy6v9E0B3Up4UHhkN798P1//GfRvN2C9ktYGEO6
HmnU+j5wNnUnCgniSU6anXv9zsyjl7XjhZnI8OHaKAr9jv6x+4y/WtuUm+kn
O0uXl4E39ckb0Yp+641L9ujn8kI2voHCVQ7O5Q01eoB6rhkhQEyUrc5THAkX
vPWHYU7Nn9EpNvakBNxjs7PfwOjvUX4dPTMhXIySilBVv+GC5ul0ad75mSnf
qxFAk4Gi+zV2aVXIN0eRbSptsLm05P4P2G7p+5FXAAA=

-->

</rfc>
