<?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.37 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-schinazi-masque-protocol-03" category="exp" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title abbrev="MASQUE">The MASQUE Protocol</title>
    <seriesInfo name="Internet-Draft" value="draft-schinazi-masque-protocol-03"/>
    <author initials="D." surname="Schinazi" fullname="David Schinazi">
      <organization>Google LLC</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View, California 94043</city>
          <country>United States of America</country>
        </postal>
        <email>dschinazi.ietf@gmail.com</email>
      </address>
    </author>
    <date year="2021" month="March" day="12"/>
    <keyword>Internet-Draft</keyword>
    <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.</t>
      <t>Discussion of this work is encouraged to happen on the MASQUE IETF mailing
list <eref target="masque@ietf.org"/> or on the GitHub repository which contains the draft:
<eref target="https://github.com/DavidSchinazi/masque-drafts"/>.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <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 (see
<xref target="HTTP3" format="default"/>). 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.</t>
      <t>MASQUE Negotiation is performed using HTTP mechanisms, but MASQUE applications
can subsequently leverage QUIC <xref target="QUIC" format="default"/> features
without using HTTP.</t>
      <t>Discussion of this work is encouraged to happen on the MASQUE IETF mailing
list <eref target="masque@ietf.org"/> or on the GitHub repository which contains the draft:
<eref target="https://github.com/DavidSchinazi/masque-drafts"/>.</t>
      <section anchor="conventions" 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", and "OPTIONAL" in this
document are to be interpreted as described in 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>
      </section>
    </section>
    <section anchor="negotiation" numbered="true" toc="default">
      <name>MASQUE Negotiation</name>
      <t>In order to negotiate the use of the MASQUE protocol, the client starts by
sending a MASQUE request in the HTTP data of an HTTP POST request to
"/.well-known/masque/initial". The client can use this to request specific
MASQUE applications and advertise support for MASQUE extensions. The MASQUE
server indicates support for MASQUE by sending an HTTP status code 200 response,
and can use the data to inform the client of which MASQUE applications are now
in use, and various configuration parameters.</t>
      <t>Both the MASQUE negotiation initial request and its response carry a sequence
of MASQUE applications, as shown in <xref target="fig-masque-app-sequence" format="default"/>:</t>
      <figure anchor="fig-masque-app-sequence">
        <name>Sequence of MASQUE Applications</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   MASQUE Application 1 (*)                  ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   MASQUE Application 2 (*)                  ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   MASQUE Application N (*)                  ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>Each MASQUE Application is encoded as an (identifier, length, value) tuple,
as shown in <xref target="fig-masque-app-encoding" format="default"/>:</t>
      <figure anchor="fig-masque-app-encoding">
        <name>MASQUE Application Encoding</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 MASQUE Application ID (i)                   ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 MASQUE Application Length (i)               ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 MASQUE Application Value (*)                ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>The MASQUE Application Length field contains the length of the MASQUE
Application Value field. The contents of the MASQUE Application Value
field are defined by its corresponding MASQUE application. When parsing,
endpoints MUST ignore unknown MASQUE applications. A given MASQUE application
ID MUST NOT appear twice in a given sequence of MASQUE applications.</t>
    </section>
    <section anchor="applications" numbered="true" toc="default">
      <name>MASQUE Applications</name>
      <t>When the MASQUE server accepts the client's MASQUE initial request, it
advertises support for MASQUE Applications, which will be multiplexed over this
HTTP/3 connection.</t>
      <section anchor="http-proxy" numbered="true" toc="default">
        <name>HTTP Proxy</name>
        <t>The client can make proxied HTTP requests through the server to other
servers. In practice this will mean using the HTTP CONNECT method to establish
a stream over which to run TLS to a different remote destination. The proxy
applies back-pressure to streams in both directions.</t>
        <section anchor="http-proxy-negotiation" numbered="true" toc="default">
          <name>HTTP Proxy Negotiation</name>
          <t>Use of the HTTP Proxying MASQUE application is negotiated by sending the
<tt>http_proxying</tt> (type 0x00) type-length-value during MASQUE negotiation.
The length MUST be zero.</t>
        </section>
      </section>
      <section anchor="doh" numbered="true" toc="default">
        <name>DNS over HTTPS</name>
        <t>The client can send DNS queries using DNS over HTTPS <xref target="DOH" format="default"/> to the
MASQUE server.</t>
        <section anchor="doh-negotiation" numbered="true" toc="default">
          <name>DNS over HTTPS Negotiation</name>
          <t>Use of the DNS over HTTPS MASQUE application is negotiated by sending the
<tt>dns_over_https</tt> (type 0x01) type-length-value during MASQUE negotiation.
When sent by the client, the length MUST be zero. When sent by the server,
the value contains the DoH URI Template encoded as a non-null-terminated
UTF-8 string.</t>
        </section>
      </section>
      <section anchor="quic-proxy" numbered="true" toc="default">
        <name>QUIC Proxying</name>
        <t>By leveraging QUIC client connection IDs, a MASQUE server can act as a QUIC
proxy while only using one UDP port. To allow this, the MASQUE server informs
the client of a required client connection ID length during negotiation. The
client is then able to send proxied packets to the MASQUE server who will
forward them on to the desired IP address and UDP port. Return packets are
similarly forwarded in the opposite direction.</t>
        <t>Compared to UDP proxying, this mode has the advantage of only requiring one UDP
port to be open on the MASQUE server, and can lower the overhead on the link
between client and MASQUE server by compressing connection IDs.</t>
        <section anchor="quic-proxy-compression" numbered="true" toc="default">
          <name>QUIC Proxy Compression</name>
          <t>To reduce the overhead of proxying, QUIC Proxying leverages compression to
elide the connection IDs on the link between the client and MASQUE server.
This uses the concept of a compression context. Compression contexts are
indexed using a datagram flow identifiers
<xref target="H3DGRAM" format="default"/>, and contain the tuple
(client connection ID, server connection ID, server IP address, server port).</t>
          <t>Any time and endpoint wants to send a proxied packet to its peer, it searches
its list of compression contexts looking for one that matches the address, port
and connection IDs from the proxied packet. If there was no match, the endpoint
creates a new compression context and adds it to the list.</t>
          <t>Compression contexts also carry a boolean value representing whether the
context has been validated, which means that this endpoint is confident
that its peer is aware if the given compression context. Compression contexts
that were created by the peer start off validated, whereas locally-created
ones are not validated until the endpoint receives a packet using that
compression context, or an acknowledgement for a sent packet that uses the
context.</t>
          <t>The DATAGRAM frame <xref target="DGRAM" format="default"/> format below allows both
endpoints to immediately start sending proxied QUIC packets using unvalidated
compression contexts. Once contexts are vaidated, the server IP address,
server port and the connection IDs can be ommited.</t>
          <t>TODO: garbage collect obsolete compression contexts.</t>
        </section>
        <section anchor="quic-proxy-negotiation" numbered="true" toc="default">
          <name>QUIC Proxy Negotiation</name>
          <t>Use of the QUIC Proxying MASQUE application is negotiated by sending the
<tt>quic_proxying</tt> (type 0x02) type-length-value during MASQUE negotiation.</t>
          <t>When sent by the client, the value contains a single variable-length
integer, called <tt>new_quic_proxy_compression_context_flow_id</tt>, that represents
the DATAGRAM flow ID used to negotiate compression contexts.</t>
          <t>When sent by the server, the value contains two variable-length integers,
the DATAGRAM flow ID used to negotiate compression contexts (called
<tt>new_quic_proxy_compression_context_flow_id</tt>), followed by the required
connection ID length.</t>
        </section>
        <section anchor="quic-proxy-encoding" numbered="true" toc="default">
          <name>QUIC Proxy Encoding</name>
          <t>Once negotiated, the QUIC Proxying MASQUE Application only uses DATAGRAM
frames, whose content is shown in <xref target="fig-quic-proxy-dgram-unval" format="default"/> and
<xref target="fig-quic-proxy-dgram-val" format="default"/>.</t>
          <figure anchor="fig-quic-proxy-dgram-unval">
            <name>Unvalidated QUIC Proxy Datagram</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Flow Identifier (i)                    ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                New Compression Context ID (i)               ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   CCIDL (8)   |                                               |
+-+-+-+-+-+-+-+-+      Client Connection ID (0..160)            +
|                                                             ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   SCIDL (8)   |                                               |
+-+-+-+-+-+-+-+-+      Server Connection ID (0..160)            +
|                                                             ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Server Port Number (16)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Family (8)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                   Server IP Address (32/128)                ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Byte 1 (8)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                        [Version (32)]                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                     QUIC Payload (*)                        ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Unvalidated QUIC Proxy DATAGRAM frames contain the following fields:</t>
          <dl>
            <dt>
Flow Identifier:  </dt>
            <dd>
              <t>The flow identifier represents the compression context used
by this frame. Unvalidated compression contexts use the
<tt>new_quic_proxy_compression_context_flow_id</tt> value received during
negotiation.</t>
            </dd>
            <dt>
New Compression Context ID:  </dt>
            <dd>
              <t>The new Compression Context ID that this frame uses. The
connection IDs and server IP address family, address, and port
are associated with this context.</t>
            </dd>
            <dt>
CCIDL:  </dt>
            <dd>
              <t>Length of the Client Connection ID field.</t>
            </dd>
            <dt>
Client Connection ID:  </dt>
            <dd>
              <t>The client connection ID associated with this compression context.</t>
            </dd>
            <dt>
SCIDL:  </dt>
            <dd>
              <t>Length of the Server Connection ID field.</t>
            </dd>
            <dt>
Server Connection ID:  </dt>
            <dd>
              <t>The server connection ID associated with this compression context.</t>
            </dd>
            <dt>
Server Port Number:  </dt>
            <dd>
              <t>The UDP port number used by the server.</t>
            </dd>
            <dt>
Family:  </dt>
            <dd>
              <t>The IP address family of the Server IP Address field. Can be either
4 or 6.</t>
            </dd>
            <dt>
Server IP Address:  </dt>
            <dd>
              <t>The IP address of the server. This field is 32 bits long if Family is 4
and 128 bits long if Family is 6.</t>
            </dd>
            <dt>
Byte 1:  </dt>
            <dd>
              <t>The first byte of the QUIC packet being transferred.</t>
            </dd>
            <dt>
Version:  </dt>
            <dd>
              <t>The QUIC version in the long header of the QUIC packet being transferred.
This field is present if and only if the first bit of the Byte 1 field is set.</t>
            </dd>
            <dt>
QUIC Payload:  </dt>
            <dd>
              <t>The contents of the QUIC packet being transmitted, starting after the last
byte of last connection ID field.</t>
            </dd>
          </dl>
          <figure anchor="fig-quic-proxy-dgram-val">
            <name>Validated QUIC Proxy Datagram</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Flow Identifier (i)                    ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Byte 1 (8)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                        [Version (32)]                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                     QUIC Payload (*)                        ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Validated QUIC Proxy DATAGRAM frames contain the following fields:</t>
          <dl>
            <dt>
Flow Identifier:  </dt>
            <dd>
              <t>The flow identifier represents the compression context used
by this frame. Validated compression contexts MUST NOT use the
<tt>new_quic_proxy_compression_context_flow_id</tt> value received during
negotiation.</t>
            </dd>
            <dt>
Byte 1:  </dt>
            <dd>
              <t>The first byte of the QUIC packet being transferred.</t>
            </dd>
            <dt>
Version:  </dt>
            <dd>
              <t>The QUIC version in the long header of the QUIC packet being transferred.
This field is present if and only if the first bit of the Byte 1 field is set.</t>
            </dd>
            <dt>
QUIC Payload:  </dt>
            <dd>
              <t>The contents of the QUIC packet being transmitted, starting after the last
byte of last connection ID field.</t>
            </dd>
          </dl>
        </section>
        <section anchor="quic-proxy-routing" numbered="true" toc="default">
          <name>QUIC Proxy Routing</name>
          <t>A MASQUE server keeps a mapping from client connection IDs to MASQUE clients,
so that it can correctly route return packets. When a MASQUE server receives a
QUIC Proxy DATAGRAM frame, it forwards it to the IP address and UDP port from
the corresponding compression context. Additionally, the MASQUE server will
ensure that the client connection ID from that compression context maps to
that MASQUE client.</t>
          <t>TODO: garbage collect this mapping from client connection ID to MASQUE client.</t>
        </section>
      </section>
      <section anchor="udp-proxy" numbered="true" toc="default">
        <name>UDP Proxying</name>
        <t>In order to support WebRTC to further servers, clients need a way to
relay UDP onwards to a remote server. In practice for most widely deployed
protocols other than DNS, this involves many datagrams over the same ports.
Therefore this mechanism can compress the server's IP address and UDP port
to reduce overhead.</t>
        <section anchor="udp-proxy-compression" numbered="true" toc="default">
          <name>UDP Proxy Compression</name>
          <t>UDP Proxy leverages compression similarly to QUIC proxying, except that it
only compresses the IP address and port, not QUIC connection IDs.</t>
        </section>
        <section anchor="udp-proxy-negotiation" numbered="true" toc="default">
          <name>UDP Proxy Negotiation</name>
          <t>Use of the UDP Proxying MASQUE application is negotiated by sending the
<tt>udp_proxying</tt> (type 0x03) type-length-value during MASQUE negotiation.</t>
          <t>The value contains a single variable-length integer, called
<tt>new_udp_proxy_compression_context_flow_id</tt>, that represents
the DATAGRAM flow ID used to negotiate compression contexts.</t>
        </section>
        <section anchor="udp-proxy-encoding" numbered="true" toc="default">
          <name>UDP Proxy Encoding</name>
          <t>Once negotiated, the UDP Proxying MASQUE Application only uses DATAGRAM
frames, whose content is shown in <xref target="fig-udp-proxy-dgram-unval" format="default"/> and
<xref target="fig-udp-proxy-dgram-val" format="default"/>.</t>
          <figure anchor="fig-udp-proxy-dgram-unval">
            <name>Unvalidated UDP Proxy Datagram</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Flow Identifier (i)                    ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                New Compression Context ID (i)               ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Server Port Number (16)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Family (8)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                   Server IP Address (32/128)                ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                      UDP Payload (*)                        ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Unvalidated UDP Proxy DATAGRAM frames contain the following fields:</t>
          <dl>
            <dt>
Flow Identifier:  </dt>
            <dd>
              <t>The flow identifier represents the compression context used
by this frame. Unvalidated compression contexts use the
<tt>new_udp_proxy_compression_context_flow_id</tt> value received during
negotiation.</t>
            </dd>
            <dt>
New Compression Context ID:  </dt>
            <dd>
              <t>The new Compression Context ID that this frame uses. The
server IP address family, address, and port are associated with this context.</t>
            </dd>
            <dt>
Server Port Number:  </dt>
            <dd>
              <t>The UDP port number used by the server.</t>
            </dd>
            <dt>
Family:  </dt>
            <dd>
              <t>The IP address family of the Server IP Address field. Can be either
4 or 6.</t>
            </dd>
            <dt>
Server IP Address:  </dt>
            <dd>
              <t>The IP address of the server. This field is 32 bits long if Family is 4
and 128 bits long if Family is 6.</t>
            </dd>
            <dt>
UDP Payload:  </dt>
            <dd>
              <t>The contents of the UDP packet being transmitted, starting after the last
byte of the UDP checksum field.</t>
            </dd>
          </dl>
          <figure anchor="fig-udp-proxy-dgram-val">
            <name>Validated UDP Proxy Datagram</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Flow Identifier (i)                    ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                      UDP Payload (*)                        ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>Validated UDP Proxy DATAGRAM frames contain the following fields:</t>
          <dl>
            <dt>
Flow Identifier:  </dt>
            <dd>
              <t>The flow identifier represents the compression context used
by this frame. Validated compression contexts MUST NOT use the
<tt>new_udp_proxy_compression_context_flow_id</tt> value received during
negotiation.</t>
            </dd>
            <dt>
UDP Payload:  </dt>
            <dd>
              <t>The contents of the UDP packet being transmitted, starting after the last
byte of the UDP checksum field.</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="ip-proxy" numbered="true" toc="default">
        <name>IP Proxying</name>
        <t>For the rare cases where the previous mechanisms are not sufficient, proxying
can be performed at the IP layer. This would use a different DATAGRAM_ID and
IP datagrams would be encoded inside it without framing.</t>
        <section anchor="ip-proxy-negotiation" numbered="true" toc="default">
          <name>IP Proxy Negotiation</name>
          <t>Use of the IP Proxying MASQUE application is negotiated by sending the
<tt>ip_proxying</tt> (type 0x04) type-length-value during MASQUE negotiation.</t>
          <t>The value contains a single variable-length integer, called
<tt>ip_proxy_flow_id</tt>, that represents the DATAGRAM flow ID used by IP Proxying
DATAGRAM frames.</t>
        </section>
        <section anchor="ip-proxy-encoding" numbered="true" toc="default">
          <name>IP Proxy Encoding</name>
          <t>Once negotiated, the IP Proxying MASQUE Application only uses DATAGRAM
frames, whose content is shown in <xref target="fig-ip-proxy-dgram" format="default"/>.</t>
          <figure anchor="fig-ip-proxy-dgram">
            <name>IP Proxy Datagram</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Flow Identifier (i)                    ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                       IP Packet (*)                         ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>
          <t>IP Proxy DATAGRAM frames contain the following fields:</t>
          <dl>
            <dt>
Flow Identifier:  </dt>
            <dd>
              <t>The flow identifier MUST be set to the <tt>ip_proxy_flow_id</tt> value received
during negotiation.</t>
            </dd>
            <dt>
IP Packet:  </dt>
            <dd>
              <t>The full IP packet, starting from the IP Version field.</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="service-registration" numbered="true" toc="default">
        <name>Service Registration</name>
        <t>MASQUE can be used to make a home server accessible on the wide area. The home
server authenticates to the MASQUE server and registers a domain name it wishes
to serve. The MASQUE server can then forward any traffic it receives for that
domain name (by inspecting the TLS Server Name Indication (SNI) extension) to
the home server. This received traffic is not authenticated and it allows
non-modified clients to communicate with the home server without knowing it is
not colocated with the MASQUE server.</t>
        <t>To help obfuscate the home server, deployments can use Encrypted Server Name
Indication <xref target="ESNI" format="default"/>. That will require the MASQUE server
sending the cleartext SNI to the home server.</t>
        <t>TODO: define the wire format for Service Registration.</t>
      </section>
    </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Here be dragons. TODO: slay the dragons.</t>
    </section>
    <section anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="iana-uri" numbered="true" toc="default">
        <name>MASQUE Well-Known URI</name>
        <t>This document will request IANA to register the "/.well-known/masque/" URI
(expert review)
<eref target="https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml">https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml</eref>.</t>
      </section>
      <section anchor="iana-apps" numbered="true" toc="default">
        <name>MASQUE Applications Registry</name>
        <t>This document will request IANA to create a new MASQUE Applications registry
which governs a 62-bit space of MASQUE application types. This registry
follows the same registration policy as the QUIC Transport Parameter Registry;
see the IANA Considerations section of <xref target="QUIC" format="default"/>.</t>
        <t>The initial contents of this registry are shown in <xref target="iana-apps-table" format="default"/>:</t>
        <table anchor="iana-apps-table" align="center">
          <name>Initial MASQUE Applications Entries</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Parameter Name</th>
              <th align="left">Specification</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0x00</td>
              <td align="left">http_proxying</td>
              <td align="left">
                <xref target="http-proxy" format="default"/></td>
            </tr>
            <tr>
              <td align="left">0x01</td>
              <td align="left">dns_over_https</td>
              <td align="left">
                <xref target="doh" format="default"/></td>
            </tr>
            <tr>
              <td align="left">0x02</td>
              <td align="left">quic_proxying</td>
              <td align="left">
                <xref target="quic-proxy" format="default"/></td>
            </tr>
            <tr>
              <td align="left">0x03</td>
              <td align="left">udp_proxying</td>
              <td align="left">
                <xref target="udp-proxy" format="default"/></td>
            </tr>
            <tr>
              <td align="left">0x04</td>
              <td align="left">ip_proxying</td>
              <td align="left">
                <xref target="ip-proxy" format="default"/></td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="HTTP3">
          <front>
            <title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
            <author fullname="Mike Bishop">
              <organization>Akamai</organization>
            </author>
            <date day="2" month="February" year="2021"/>
            <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.

DO NOT DEPLOY THIS VERSION OF HTTP

   DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC.  This
   version is still a work in progress.  For trial deployments, please
   use earlier versions.

Note to Readers

   Discussion of this draft takes place on the QUIC working group
   mailing list (quic@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/search/?email_list=quic.

   Working Group information can be found at https://github.com/quicwg;
   source code and issues list for this draft can be found at
   https://github.com/quicwg/base-drafts/labels/-http.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/>
        </reference>
        <reference anchor="QUIC">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="Jana Iyengar">
              <organization>Fastly</organization>
            </author>
            <author fullname="Martin Thomson">
              <organization>Mozilla</organization>
            </author>
            <date day="14" month="January" year="2021"/>
            <abstract>
              <t>   This document defines the core of the QUIC transport protocol.  QUIC
   provides applications with flow-controlled streams for structured
   communication, low-latency connection establishment, and network path
   migration.  QUIC includes security measures that ensure
   confidentiality, integrity, and availability in a range of deployment
   circumstances.  Accompanying documents describe the integration of
   TLS for key negotiation, loss detection, and an exemplary congestion
   control algorithm.

DO NOT DEPLOY THIS VERSION OF QUIC

   DO NOT DEPLOY THIS VERSION OF QUIC UNTIL IT IS IN AN RFC.  This
   version is still a work in progress.  For trial deployments, please
   use earlier versions.

Note to Readers

   Discussion of this draft takes place on the QUIC working group
   mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is
   archived at https://mailarchive.ietf.org/arch/search/?email_list=quic

   Working Group information can be found at https://github.com/quicwg;
   source code and issues list for this draft can be found at
   https://github.com/quicwg/base-drafts/labels/-transport.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-transport-34"/>
        </reference>
        <reference anchor="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">
          <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>
        <reference anchor="DOH">
          <front>
            <title>DNS Queries over HTTPS (DoH)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman">
              <organization/>
            </author>
            <author fullname="P. McManus" initials="P." surname="McManus">
              <organization/>
            </author>
            <date month="October" year="2018"/>
            <abstract>
              <t>This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS.  Each DNS query-response pair is mapped into an HTTP exchange.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8484"/>
          <seriesInfo name="DOI" value="10.17487/RFC8484"/>
        </reference>
        <reference anchor="H3DGRAM">
          <front>
            <title>Using QUIC Datagrams with HTTP/3</title>
            <author fullname="David Schinazi">
              <organization>Google LLC</organization>
            </author>
            <date day="12" month="October" year="2020"/>
            <abstract>
              <t>   The QUIC DATAGRAM extension provides application protocols running
   over QUIC with a mechanism to send unreliable data while leveraging
   the security and congestion-control properties of QUIC.  However,
   QUIC DATAGRAM frames do not provide a means to demultiplex
   application contexts.  This document defines how to use QUIC DATAGRAM
   frames when the application protocol running over QUIC is HTTP/3 by
   adding an identifier at the start of the frame payload.

   Discussion of this work is encouraged to happen on the QUIC IETF
   mailing list (quic@ietf.org (mailto:quic@ietf.org)) or on the GitHub
   repository which contains the draft:
   https://github.com/DavidSchinazi/draft-h3-datagram.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-schinazi-quic-h3-datagram-05"/>
        </reference>
        <reference anchor="DGRAM">
          <front>
            <title>An Unreliable Datagram Extension to QUIC</title>
            <author fullname="Tommy Pauly">
              <organization>Apple Inc.</organization>
            </author>
            <author fullname="Eric Kinnear">
              <organization>Apple Inc.</organization>
            </author>
            <author fullname="David Schinazi">
              <organization>Google LLC</organization>
            </author>
            <date day="16" month="February" year="2021"/>
            <abstract>
              <t>   This document defines an extension to the QUIC transport protocol to
   add support for sending and receiving unreliable datagrams over a
   QUIC connection.

   Discussion of this work is encouraged to happen on the QUIC IETF
   mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub
   repository which contains the draft: https://github.com/quicwg/
   datagram (https://github.com/quicwg/datagram).

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-datagram-02"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="ESNI">
          <front>
            <title>TLS Encrypted Client Hello</title>
            <author fullname="Eric Rescorla">
              <organization>RTFM, Inc.</organization>
            </author>
            <author fullname="Kazuho Oku">
              <organization>Fastly</organization>
            </author>
            <author fullname="Nick Sullivan">
              <organization>Cloudflare</organization>
            </author>
            <author fullname="Christopher A. Wood">
              <organization>Cloudflare</organization>
            </author>
            <date day="8" month="March" year="2021"/>
            <abstract>
              <t>   This document describes a mechanism in Transport Layer Security (TLS)
   for encrypting a ClientHello message under a server public key.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-10"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>This proposal was inspired directly or indirectly by prior work from many
people. The author would like to thank
Nick Harper,
Christian Huitema,
Marcus Ihlar,
Eric Kinnear,
Mirja Kuehlewind,
Brendan Moran,
Lucas Pardue,
Tommy Pauly,
Zaheduzzaman Sarker,
Ben Schwartz,
and
Christopher A. Wood
for their input.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAM2aS2AAA+0823YbN5Lv+AqM/DDSDkld1+NoNrsjk3LME93GlJyzm5Oj
gN0giVFfOI1u07SsfPtUFYBuNNltW46UeHNMPYjsxqWqUPcC0O12Wa7ySB7y
y5nkp0ejf1wd84sszdMgjZgYjzP55tA+Z2EaJCKGtmEmJnlXBzOViHeqGwv9
r0J257Zbd2efBSKX0zRbHnL5ds6YmmeHPM8Kne/t7Hyzs8du5HKRZuEhHya5
zBKZdwc4JmM6F0l4LaI0gXmWUrO5OuQ/wrgdrtMsz+REw7dljF9+YkwU+SzN
DhnvMg4flehDvjHo8ZGFbYMeG6g3BuKNCldepdlUJOqdyFWaQJPv0nQaSX5y
0jevNcwoc3ix+3Rnhx/F85nKZ1LAU34hspuFWJp2gcoB143TtEhyoRL+WslF
h/dFpCZplijBvznYOdi3bbERkmbjKlG5BIhyoJbm6QQmkJkKhGknY6EiILaj
c0/JfPL3KT7tBWnMGOt2u1yMAUYRAOkuZ0pzWKMilknOQ6mDTI1hXLuqm6dF
lKt5JN/ClEfzeQQTIdZ8VNAQueTpG5nxf1wN++w4CbLlHF9v9dwAMLrgkwxo
CUt3w/OZyLmIonShAaUkKLIM5o2WPCuSRCVTHtv5GCwv9sBnoppX42qpUHKR
8JeXlxfb+zhMIgN82eMv0gx4R8QwQMdBEIiE0YwACILJg0ghrnnKE2C3XCES
wIZvlzhXIOZirCJYGb6AVfPm0TIDTDsMWI1rwF4C+xLosbiRvNAS1yJHck6K
hOARZpiZAuaoIQuzBVJrmI/ZwTMcTedALBg9k3oOqErdY2ygdFBAUyC5G54I
Cf9lAkyRiSmsDOAyAypJaJRAo1Ioh8eXLziuPU4VKZ3zH3/aNJL3d2SMHnDy
FrCz6/adyl8WYwBgnmqVgygi9MEMoUcO1dSIBPmQwUizPJ/rw+3tKVCqGCN/
bZO4OGnZtkJOPfRWz3JfrMIQVpg9QUHO0rAgavHbJ8r7effH4k2+qaVkt7d/
wjf73w67A5LM7r8KFXSRjnd3W638y5v5l30O//JW/mWfwb+8gX+Zz78WiTML
KVICZpjLDFRcDOtWlKPwWAYzUKs6BmU9LnKHv09hhsSoAR9JQApkwJAG6Iv/
V8gLvJAARFl+d8cnoIcLAJAhdVKYpQLgDyhtT57wfpq8AVIRf+LSD+REgQWh
37dPguotCZzkYGQR51CDYboaXW50zH9+dk7fXx0DgV8dD/D76OXRyUn5xbUY
vTy/OoH3zH6revbPT0+PzwamMzzlK49Oj/53w/DnxvnF5fD87OhkA2SK1oGV
ekCAGYUVGEt4BW7APJNoDoUuFUSIfZ73L/juATLEqxf9vd3db2DtzY9nu389
uLtji5lMzGRpEiHl8ScQfIkMJ0WGg4DYoUCpXETAkzCFnqWLhM9kJom6vIG7
b58k1S+g6RC4JAtBDdXsDa5saTJKBnLOEAHi5BycmwwEa7xkWiYh6RzX3kqd
oZE0UhSKXOCwVvD5xTksnmsIOmNju7eQUdS9SQAVyzLbxBEi2uiRR2cnRllD
GEkMAHo3iJ7LQE1UwBoElAgqQpDJXEFXXcxR7jgIu4NZvs1lghKme577yIx2
AkxCHAqUfEPX8ZKXJLDYAXHyAtU1qF3wEkvTacx0hYE0dAEsVIKaxycwEMvI
XSM+wG1AKaZoJMMwb0SmUpo1magpKAVa+LlASwIciWrveQq611vZxNd/htgl
PXFIBSvsYAewM9AFghstF5BiboDN40iA7vYWYHFeNTTrut53d4eM/fLLL4zv
8PXPbsOzvYZn+9h9F17t8wP+n/wp/yt/xr+5zzP2l+6v/GPvGwCzhPHt/y7f
/I+t9Za9Xu+3g2HvMWFoAOF3Q/TsMRFFtr095E9aWJtTGPrtxsj9rgTFA1Fv
gBo+FpWA++Bbyx4aEwL6YhM8ODCIE4W+UiSTaT7rgMRHhdzieYGOGfug2NFo
oKL+0GLXQMjhAEjXwAiPxo0NMJzQcjXA8RvC8BpZpUkmHlUiHNc5iWgA7Ng2
2bCOXjv9gPejsO6FGkGouytsHW3qaZ0I6A6CpFdcnLU+zMyGdjZE1xQEEew8
2sMgzYxJJMTWDWCP/wBOG9pddOE7DFyDeapwSnJY1TRJYdAiIU+nyYD2+BGf
KvB/G14y4Gfn9zqPMF+oQJJfaLvpdb1TG9/3EX2FBE6i3w4WhDDxyGTdIREE
cp5rz1v5cxn+rrgRHaAZKz2vRv/pqOY8GJ9nocDHBV869mJpiprJ6V5PsZig
wniWGHMCKhiXdCkAtZzl+Y8UW+I7BeNSrzJSzGdZWkyNl2TRBfcM/CaZWW8Q
Fgi85zkmqpDwJhxDeGNJjh3xu/N7++dnZ8f9S3gHcR3FaDCLGEMYNmOCUnIi
NpgZxNGhLRJ+eTLCr4KHajKRGN8ChHGaIzfqHOIqw2mIFqHIaOGAvmMR3ADW
EAYXJiAxU2ASgI/R+wtVZmhm+KBOtXrEUFGwWw8erqoQoercLA1oycr4IvR9
ZejNfsYprl2W4Ge+mS/nku+83dkBqwZfu0bAu2ToeFhk3iQeSD1aX6sMSDyA
dd7JLLV8MTgbGRojtCPALExn60yBgFFT4IQMaWmWcrXz7Z8G5y+/xYjt4BlE
bEhjRKUmIY60K33r5AUg2um60vPehA0TfY39ryk89yi7e0/KkgrQSCOYohL4
jq9/ayTnaz1cihK/m/lqSnyQvuRXr4b8UsbzCKNQ3/OBKCfpJgVEhhDCxMj4
MmRXly+6z5CzAWi7xJRnKfnw9gllWJz0Py8TMvjSz1Z5mbDhAEOXFU1HWa4g
N6BQxo7GtNknCtENl6SJ5FeDC47KDeQytbkxVA6dBg1qwj3N6vGeIDUEAho2
wufIbVfLXybUBMz2UURWgHscGQ2AfO2U3Rz0g8y15doVqBazlDQZA+AWIgux
SUxpIdMadA8BN7yAYDpEJUNRYoX3K5kXWVJOAtaTaRWrSGRAKDuoSYTgcOmc
Mkyy0kmwmP00BtNp0lk0sF3TjlG0MYbUM2E4B+yKAEaaktTQYhj6eQvCyNqY
xEy6nhvzs4+41rBmZGRMjnYmReg6RCq5YWOZLyQMYimNveoUBI4PAIHMpiHr
7OW0QsWrvO8ak0aomLYbVC9QU2GaIywCuQLaxCNPXQJcAlJzbyRMtMgIc8G5
cYU84Hw8ucPTY881XHsmEV6gVbfDoVdg+NiflFyut8Ad/fWHhkdUEpKFN6Ik
KCkyzcAwTlCGqshHU6Z6f/Ddq6NTSqaWZTuTr97vup53d3ZNjaIhAClMYptN
ktUp5b3xacXv5SNkK8xlHiWg41QsaTbn6vGFSIyMkeyJFemjfE+O6WZkPZVD
K5EFM6kZPqUMLRCxgYTwMk0pvz+hdK00xYFY5NjbioSFEwFklgT+Mk+y1KSZ
6jCBT0OGB5yGBUhXkppRje5yeLEAfAnMgoFalosmCG2iLdSIltUaiJAV7PXV
j3RaJpbGaRqhC2VsRCaxOS494LuYSQSObJubCrXAGLkU2qsQDYPzHtER04Y2
pDTKdVE2O4Ycxei9WwequizQ3VfGABtX+pP52Iy2QPoZIoXO+tHolC2FVZ3U
gYXmAhc1AGsBMm86MlhYl+HLq/YQMuQqqq0H0CiQACcuiGUt534KWKx1MDuY
5ieThtFHJMOppOQ1spMwNtuxKKLjZNuRvGd8psHR5RGKoClSkUdUSmRV3qhE
EYcHboLFonKRKWWhM+rFRigScSxD9GZAjxt6OY/GsSqpOGdcDKZFUhKoCWHw
1c8xEvLVDZDUrYDn5HsyzjwZJ4Zu0JZoLNCkxDGWvZEw54PzQz4V2RjtUZBG
EbTm6VgDT+eyUZob7EHdQ/TsQaujWFf79/YTcYomB3zvnm7ih/3EFa8PWA3G
iSSlrNFNsdMwLJ1MUSmiQAC0P4Oaua5AvPaoeG2peI024lqFP3cMz5ZqwzhX
Fa8i74EPBTwd1oseLUvT5sY2IZQv0lVcuMVFd34NHHzTUILdhxJbHZA4lLJK
CTm/kjU5lA186LIydSYsk4iMkVRVfNVp50U/tWIdZtAqjh6MdAjF/aku0zPI
tCu5TA+MENVKlyQflAuWdluaUIPeHzffSZ8XxFClj9SS7nysXOMZ+AG+Pexb
49yYd304GPr94eCEbz7DGVro0vp5vw6DedE3nmG/JiKbO73e7tOdGiqta/GJ
n4ejw+gx6DAy5u//Ex0czBdoss+KeIyCsPt0qwXPz5rjhYBIdmmI/RBj/qWB
IqPSGTmyAfbm/t727t6zR8rbI17Pl2B8dh8XL/r8+BrMIW062t/b+qmVKx4P
BmOfxDJKIXhurA8+JG39mkiz9XJlkavKifWN8MB60FgaaWtSc8V1Ld41PgBF
i1jL0IeMrdgKeGI2y67E2Z4TZX3f9UAP/RdG3gVuzcLZe9wHstGbsbse7uXN
lOEghTqhdUJZ3ftsN0Mljkm7paoiRRPRoIdiU2p1r582qa3GC3xCiqFTxd7Y
zMTfEG0IrdPAON+09Y3mqQIqsmQE5EmtmNVojEwhCzo1vCwRbUwdtkCxHt0y
NmqBqNEsOIiaXpYQNSVX7gXRmnIvh3a5R54YpU9udc1hh/5Gc5d91pZuBUNP
+9rKYd9Ee1JRGegAo+inFVxV+6Yp7NgWGE5JM1NchC/7e3xMSZ8UxFRNnI2B
NweUvAHN39YAATCquxJjlWkMV/J6dGhD+rGkqA93HU5kllHUajVyOQK1f2PV
tNUjNDXmGwHVTxu2jqNVJQh9ua/NJlkswCp3A1tbVPbVEtff19sVm69Ucltg
gvic4hPKKFB6cZLbFG8kdM4ctfDHCoc63v4aPnx1Nz4Hhi/I3fCcjdcfczWa
G3xRjsbrD7sZ5Q6JR/M3vire30LxrmalXqVFvpaUysxDYNyjlWLcjZRzTDbG
Yj4n7sTSR2PhFxNx7lwDvcckcMpthYCSvbTtJ6BzFzAh8odf6rRV79XycZWf
Z62yRBUgWxv1yyYtRVbCwtSNaxuRGisV4JYoc2QC/dOGgi8We2Vi9ooYJ7jF
f7RlI5E3yihQGGloiiA1QrZmxk0192Mrs7YwttyP1PCq/UVYbfXxd7a73UY/
yPGryz4+mRQZFZLsVp6OW28ID3DHAV+IJSKSyQi+4CxpYhaGduPYPTjOl/O3
AWEJJU6BlReg3oBLQjmP0iWoLrd7XptNREjEBLd32IK2St6kEbJILJJlWfnU
brcTTIYRCWKhaZtLJidpZncdlUdTLIeahfHczT/rNjZieVlSduVkJ3AlbVeq
0yWRV4rTVfvmonO1AwDmNMqiLFrLt1QztoLGSEW5vraiuYIAAt+hypjZx9FY
Ya9AqhdUKhRa6yk1zrp3OQUmaKqm7N+3mnL56UUTvlI0McauBOQ3rZmsEN+r
IlSU/1gRoWkBHqiGUAHRVkJYbfG1gvDQbuqXUkH4mjF+OBjgQ1L7e4Q6jTLd
lFit1FJbXtVr8UVFO/dLq36a5v9ds6r3SKHyT0ihfk0PtqQHPaFsjd6IQp8d
vLkRgpkMbnQRf82ZPbiy+9IVbmNqqVnZNr7/olTtZyWWHlDj/o4Si2H1sBZV
qyqoxhsgaB8RquNAoPdNuxftTlL5hk4eV1cllNsXdTGZqMDsBHOBEbOb56rr
FmzmAaaHsLtUg4u0iEIitX8OxjHMNdaQwHEfXnhRs+kyrs4Q2LsvVM7dzQq4
0uW5gQrllUhRfTRQHP6aOFE1hokHv2mY6GBojwZ5ezQICHkEYCtSvEZcLxJU
nxoINhD4geJAVdNgXwO8B7UVbfUYXE6jtT5grh7BXtUX25mqYZN9Gj6yUXLn
pLQss7zrUrhiJ1jDaR8DKRGzmquIIqSxsQyeHSg3/MNLVxHzdT56qZjAfCWn
iu4nMgpQm8fdzHt8V16cYzW4SwzReUrBZ2lcFvvxjCgYwjEdk6L5F3QJUSaF
ObeIjV0kgFefIZXMHRuNZ5PMDVQIC+CABiGNcUXwOjSj3TUeoKAjF9Dev8TD
P8uF07hkO8eEK2CGBgqHKJP1EzJ2Imf+HJt4/DfBS0Zyd8ATD2laH/8MmwzN
LSFUchydDbeqS0W2THJc+hSyRq70B0pINBlOnyShvYzD7p1neCYuBt05UeVJ
MaIauB9xkVAXFyjVpixtIO7+RywUakeG0wUpnkLwIiy5etoHDyHNZDTn6XhS
6MBdF+MN37FJ75jgcbec2Cuu8G64ilbMo9Xt7f8cA7mq4wN5pLtSJwoUM9AI
j1Xg6Vq7hXkdNOZZVqCGBL5H9w6GdJzkU93VI8ypbsuYmXRnFHDtmyTCHJoe
yQCkMcfMOPkVWXlwWts3ICIv0S8a0xVJU3OfDE2osaKA07nnNOLw6OxofTQl
EnFH0mkx/QHvxvmeTozjUUnTogszrt1HVtIK73Ch0SnTbwSH5m+8amcDx2Wb
8i04ZSgKb5RcbLH/cpc7LRaLHk6Jd0VtQziupgmt8nY1EkKz9rv3dpbH0X9b
VdN05twSeelwAh9KfxpS5riMPYvUNLRVXUtmTgVNsdBBHtLTvS6WPjXoypZD
8uSH6VJE7ThG9euqLOMrRz5PofeS27OJVJ24dFd84Q2L5hqeEuG/Ad8a/mvi
AW2LGgDd7S2ORV4KKjV3wL4eFnhgku/teTwlWbt48NxcvPPe3HLw3oOLVFjt
856P7J1KBsHmz3v2/rCLH/uv5fPht2UrgAyPf8PctaPhq3MCWt75/rtWyOjE
MzSvH4deHwwPhLeMUh9sD5rXzsw0QOadPf4wZPvQ3K8YrTWDwarSZht8drAD
aK7ax6LB1MfGgsHQb1phmdJpsqzXJGzHSY6H5tGNotsU8SICVHBH5VEzYxZu
n4j6kzuY0WTnZPjtxkREWm44BQDAzlMNM+KZRLS+dPzYHBfGvJy5mcv+GuMN
gAqe0d145PZgTZXNZTqPrEdg7li1YWKkbqQxESK5YWcquOEvRTbHo+r9GSgv
wDXhLwuVy1h02KnIAohxh7NIQIPjDEz19ypJJP46Vdk/Bf++kLNIgmENO+w5
xKohdD9NQQV02EkBQTMKW1jIDljSOF7CryJadtj/iZkMi3fvBADLRyK7wfmf
g5syCmbgpuTv6NIwC1E6xxLyUY//kKYhM46KVEiGeYGp0H8DYp9u9gVXAAA=

-->

</rfc>
