<?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.4.15 -->
<!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-stark-add-dns-forwarder-analysis-00" category="info" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.8.0 -->
  <front>
    <title abbrev="Analysis of DNS Forwarder Scenario">Analysis of DNS Forwarder Scenario Relative to DDR and DNR</title>
    <seriesInfo name="Internet-Draft" value="draft-stark-add-dns-forwarder-analysis-00"/>
    <author initials="B." surname="Stark" fullname="Barbara Stark">
      <organization>AT&amp;T</organization>
      <address>
        <postal>
          <city>Austin, TX</city>
          <country>US</country>
        </postal>
        <email>barbara.stark@att.com</email>
      </address>
    </author>
    <author initials="C." surname="Box" fullname="Chris Box">
      <organization>BT</organization>
      <address>
        <postal>
          <city>Bristol</city>
          <country>UK</country>
        </postal>
        <email>chris.box@bt.com</email>
      </address>
    </author>
    <date year="2021" month="June" day="15"/>
    <area>Internet</area>
    <workgroup>ADD Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This draft analyzes the behaviors that residential end users and home network owners (e.g.,
parents of young children) might experience when operating systems and clients support
<xref target="I-D.ietf-add-ddr" format="default"/> and/or <xref target="I-D.ietf-add-dnr" format="default"/> for discovery of encrypted DNS services
and the CE router of the home network offers itself as the Do53 resolver. This use case is
explicitly mentioned in <xref target="I-D.ietf-add-requirements" format="default"/> Section 3.2 and has several
requirements related to it. This draft has two goals: determine if the analysis it provides
is accurate and, if it is accurate, determine if the behavior is acceptable to the WG or if
there should be changes to either of the discovery mechanisms.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
    mailing list (add@ietf.org),
  which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/add/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/bhstark2/dns-forwarder-analysis"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>This draft analyzes the behaviors that residential end users and home network owners (e.g.,
parents of young children) might experience when operating systems and clients support
<xref target="I-D.ietf-add-ddr" format="default"/> and/or <xref target="I-D.ietf-add-dnr" format="default"/> for discovery of encrypted DNS services
and the CE router of the home network offers itself as the Do53 resolver. This use case is
explicitly mentioned in <xref target="I-D.ietf-add-requirements" format="default"/> Section 3.2 and has several
requirements related to it.</t>
      <t>This draft has two goals:</t>
      <ul spacing="normal">
        <li>determine if the analysis it provides is accurate</li>
        <li>if it is accurate, determine if the behavior is acceptable to the WG or if
there should be changes to either of the discovery mechanisms.</li>
      </ul>
      <t>Becoming a WG draft is <em>not</em> a goal of this draft. There is and will be no request for
adoption by any WG.</t>
      <t>While DNS forwarders / proxies may exist in environments other than home networks
(e.g., hotspots, small businesses), this draft does not attempt to examine those usages.
This draft is focused on home networks.</t>
    </section>
    <section anchor="conventions-and-definitions" numbered="true" toc="default">
      <name>Conventions and Definitions</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 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 anchor="background" numbered="true" toc="default">
      <name>Background</name>
      <t>Having a DNS forwarder in the CE router that is advertised
to the LAN using DHCP and RDNSS options is a common
deployment model for many ISPs and is also the default in many retail consumer routers (e.g.,
Netgear).</t>
      <t><xref target="I-D.ietf-add-requirements" format="default"/> contains the following text related to this use case:</t>
      <t>"Many networks offer a Do53 resolver on an address that is not globally meaningful, e.g.
<xref target="RFC1918" format="default"/>, link-local or unique local addresses. To support the discovery of encrypted DNS
in these environments, a means is needed for the discovery process to work from a
locally-addressed Do53 resolver to an encrypted DNS resolver that is accessible either at the
same (local) address, or at a different global address. Both options need to be supported."</t>
      <t>"R4.1 If the local network resolver is a forwarder that does not offer encrypted DNS service, an upstream encrypted resolver SHOULD be retrievable via queries sent to that forwarder."</t>
      <t>"R4.2 Achieving requirement 4.1 SHOULD NOT require any changes to DNS forwarders hosted on non-upgradable legacy network devices."</t>
      <t>In the context of a home network, there are several reasons why this deployment model
is used. Some reasons are:</t>
      <ul spacing="normal">
        <li>Provide local name resolution</li>
        <li>Captive portal (Note that <xref target="RFC8952" format="default"/> defines an architecture that does not rely on
"breaking" DNS; however, there exist many legacy devices with captive portals that do
rely on "breaking" DNS.}</li>
        <li>Provide filtering (aka parental controls) and DNS-based vulnerability assessment
in the CE router. Note that
<xref target="I-D.ietf-add-requirements" format="default"/> describes this sort of filtering and monitoring behavior
as an attack;
nonetheless, this functionality is popular with many people -- especially parents.</li>
        <li>Caching responses to improve DNS performance</li>
      </ul>
    </section>
    <section anchor="scenario-analysis" numbered="true" toc="default">
      <name>Scenario Analysis</name>
      <t>The following sections will analyze what behavior a user is expected to see when
certain conditions exist. In all cases, it's assumed the CE router is advertising itself
as the Do53 server (using DHCP and/or RA). The clients and OSs that are of interest in
these scenarios are using whatever Do53 server is advertised to them by DHCP/RA. There
may be clients and devices that use other Do53 servers; those are out of scope of this
analysis. Analyzing the behavior of clients that do not support either DoH or DoT, or
do not support any mechanism to discover encrypted servers are also out of scope.</t>
      <t>Assumptions common to all scenarios are:</t>
      <ul spacing="normal">
        <li>Common OSs support both DNR and DDR</li>
        <li>Some applications (e.g., browsers) support DDR</li>
        <li>No Certificate Authority will sign a certificate with a private IP address in a SAN</li>
      </ul>
      <section anchor="scenario-1-no-changes-to-ce-router" numbered="true" toc="default">
        <name>Scenario 1: No changes to CE router</name>
        <t>Assumptions:</t>
        <ul spacing="normal">
          <li>The CE router (including its DNS forwarder and DHCP/RA capabilities) are not updated.</li>
        </ul>
        <t>Expected behaviors:</t>
        <ul spacing="normal">
          <li>There will be no DHCP or RA advertisement of encrypted servers.</li>
          <li>The DNS forwarder will forward DDR queries (dns://resolver.arpa) to the DNS recursive resolver the CE router is configured to use.</li>
          <li>If that recursive resolver has the appropriate SVCB record, it will provide that in the response that is returned.</li>
          <li>The querying OS/app will determine that the IP address of its Unencrypted Resolver (the CE router) and the IP address of the Unencrypted Resolver in the supplied certificate do not match and will not do "authenticated discovery".</li>
          <li>The querying OS/app will determine that the IP address of its Unencrypted Resolver (the CE router) does not match the IP address of the Encrypted Resolver and will not do "opportunistic discovery".</li>
          <li>The OS/app will not discover a local Encrypted Resolver.</li>
        </ul>
        <t>The end result is that no Encrypted Resolver will be used by an OS or app that
uses DDR or DNR to discover an Encrypted Resolver, unless the OS or app subsequently
uses some non-standard mechanism to select an Encrypted Resolver. Note that this
suggests that the DDR and DNR proposals in their current form do not satisfy the
requirement "R4.2 Achieving requirement 4.1 SHOULD NOT require any changes to DNS
forwarders hosted on non-upgradable legacy network devices."</t>
        <t>Also note that non-upgraded
legacy routers will not satisfy the <xref target="I-D.ietf-add-ddr" format="default"/> requirement that a "DNS forwarder
SHOULD NOT forward queries for "resolver.arpa" upstream." If the CE router were updated
to not forward queries for "resolver.arpa" upstream, the end result would not change. Since
this scenario provides the same end result, it isn't broken out separately.</t>
      </section>
      <section anchor="scenario-2-ce-router-updated-to-provide-dnr-in-dhcpra" numbered="true" toc="default">
        <name>Scenario 2: CE router updated to provide DNR in DHCP/RA</name>
        <t>Assumptions:</t>
        <ul spacing="normal">
          <li>The CE router is updated to provide Encrypted Resolver info in DHCP/RA</li>
          <li>The CE router gets its Encrypted Resolver info from DHCP; getting that was part of the update</li>
          <li>The upstream ISP has updated its core network resolver to support encryption, and announces this resolver in DHCP</li>
        </ul>
        <t>Expected behaviors:</t>
        <ul spacing="normal">
          <li>OSs will use the Encrypted Resolver</li>
          <li>Applications that try "resolver.arpa" will not do their own upgrade, because that will fail</li>
        </ul>
        <t>Additional results:</t>
        <ul spacing="normal">
          <li>Local name resolution is broken?</li>
          <li>Legacy captive portal is now broken?</li>
          <li>Filtering in the CE router (parental controls and other security mechanisms enabled by the home network owner) is now broken</li>
          <li>Any filtering deployed in the core network resolver continues to operate</li>
          <li>No local caching</li>
        </ul>
      </section>
      <section anchor="scenario-3-ce-router-updated-to-support-opportunistic-encryption-to-its-dns-forwarder" numbered="true" toc="default">
        <name>Scenario 3: CE router updated to support opportunistic encryption to its DNS forwarder</name>
        <t>Assumptions:</t>
        <ul spacing="normal">
          <li>The CE router supports encrypted connectivity to its DNS forwarder</li>
          <li>The CE router is updated to provide Encrypted Resolver info in DHCP/RA</li>
          <li>The CE router is updated to reply to <tt>dns://resolver.arpa</tt>; SVCB record points to the CE router with a self-signed certificate</li>
        </ul>
        <t>Note that the effort do do these upgrades is considered to be rather large.</t>
        <t>Expected behaviors:</t>
        <ul spacing="normal">
          <li>Some OSs and applications accept DDR Opportunistic Discovery, resulting in use of the CE router's Encrypted Resolver.</li>
          <li>Some OSs and applications do not.</li>
          <li>Across a range of households, and even within a single household, there is inconsistent behavior.</li>
        </ul>
      </section>
    </section>
    <section anchor="conclusions" numbered="true" toc="default">
      <name>Conclusions</name>
      <t>Since Scenario 3 is considered a large effort and the resulting behavior is unpredictable,
it is unlikely to be pursued.</t>
      <t>Since Scenario 2 will break some of the functionality that
a significant number of home network owners have purposefully enabled (e.g., router-based
DNS-based parental controls), will break existing captive portal implementations used
to simplify setup of broadband connections, and may break local name resolution (?) it
is unlikely to be pursued.</t>
      <t>This leaves Scenario 1 (do nothing in routers that provide DNS forwarder).</t>
    </section>
    <section anchor="questions-for-the-wg" numbered="true" toc="default">
      <name>Questions for the WG</name>
      <t>Are these the results we want to achieve with Encrypted Resolver discovery mechanisms?</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Breaking the security mechanisms that many users currently have enabled in their home
network routers (e.g., DNS filtering) will worsen the security of those users.
While these mehanisms are not
perfect, and can easily be bypassed by client applications that run DoH, this does not make
them completely useless.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <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>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC1918">
          <front>
            <title>Address Allocation for Private Internets</title>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter">
              <organization/>
            </author>
            <author fullname="B. Moskowitz" initials="B." surname="Moskowitz">
              <organization/>
            </author>
            <author fullname="D. Karrenberg" initials="D." surname="Karrenberg">
              <organization/>
            </author>
            <author fullname="G. J. de Groot" initials="G. J." surname="de Groot">
              <organization/>
            </author>
            <author fullname="E. Lear" initials="E." surname="Lear">
              <organization/>
            </author>
            <date month="February" year="1996"/>
            <abstract>
              <t>This document describes address allocation for private internets.  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="5"/>
          <seriesInfo name="RFC" value="1918"/>
          <seriesInfo name="DOI" value="10.17487/RFC1918"/>
        </reference>
        <reference anchor="RFC8952">
          <front>
            <title>Captive Portal Architecture</title>
            <author fullname="K. Larose" initials="K." surname="Larose">
              <organization/>
            </author>
            <author fullname="D. Dolson" initials="D." surname="Dolson">
              <organization/>
            </author>
            <author fullname="H. Liu" initials="H." surname="Liu">
              <organization/>
            </author>
            <date month="November" year="2020"/>
            <abstract>
              <t>This document describes a captive portal architecture. Network provisioning protocols such as DHCP or Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide the solution.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8952"/>
          <seriesInfo name="DOI" value="10.17487/RFC8952"/>
        </reference>
        <reference anchor="I-D.ietf-add-ddr">
          <front>
            <title>Discovery of Designated Resolvers</title>
            <author fullname="Tommy Pauly">
              <organization>Apple Inc.</organization>
            </author>
            <author fullname="Eric Kinnear">
              <organization>Apple Inc.</organization>
            </author>
            <author fullname="Christopher A. Wood">
              <organization>Cloudflare</organization>
            </author>
            <author fullname="Patrick McManus">
              <organization>Fastly</organization>
            </author>
            <author fullname="Tommy Jensen">
              <organization>Microsoft</organization>
            </author>
            <date day="14" month="June" year="2021"/>
            <abstract>
              <t>   This document defines Discovery of Designated Resolvers (DDR), a
   mechanism for DNS clients to use DNS records to discover a resolver's
   encrypted DNS configuration.  This mechanism can be used to move from
   unencrypted DNS to encrypted DNS when only the IP address of an
   encrypted resolver is known.  It can also be used to discover support
   for encrypted DNS protocols when the name of an encrypted resolver is
   known.  This mechanism is designed to be limited to cases where
   unencrypted resolvers and their designated resolvers are operated by
   the same entity or cooperating entities.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-add-ddr-01"/>
        </reference>
        <reference anchor="I-D.ietf-add-dnr">
          <front>
            <title>DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)</title>
            <author fullname="Mohamed Boucadair">
              <organization>Orange</organization>
            </author>
            <author fullname="Tirumaleswar Reddy">
              <organization>McAfee, Inc.</organization>
            </author>
            <author fullname="Dan Wing">
              <organization>Citrix Systems, Inc.</organization>
            </author>
            <author fullname="Neil Cook">
              <organization>Open-Xchange</organization>
            </author>
            <author fullname="Tommy Jensen">
              <organization>Microsoft</organization>
            </author>
            <date day="17" month="May" year="2021"/>
            <abstract>
              <t>   The document specifies new DHCP and IPv6 Router Advertisement options
   to discover encrypted DNS servers (e.g., DNS-over-HTTPS, DNS-over-
   TLS, DNS-over-QUIC).  Particularly, it allows to learn an
   authentication domain name together with a list of IP addresses and a
   set of service parameters to reach such encrypted DNS servers.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-add-dnr-02"/>
        </reference>
        <reference anchor="I-D.ietf-add-requirements">
          <front>
            <title>Requirements for Discovering Designated Resolvers</title>
            <author fullname="Chris Box">
              <organization>BT</organization>
            </author>
            <author fullname="Tommy Pauly">
              <organization>Apple</organization>
            </author>
            <author fullname="Christopher A. Wood">
              <organization>Cloudflare</organization>
            </author>
            <author fullname="Tirumaleswar Reddy">
              <organization>McAfee</organization>
            </author>
            <author fullname="Daniel Migault">
              <organization>Ericsson</organization>
            </author>
            <date day="8" month="March" year="2021"/>
            <abstract>
              <t>   Adaptive DNS Discovery is chartered to define mechanisms that allow
   clients to discover and select encrypted DNS resolvers.  This
   document describes one common use case, namely that of clients that
   connect to a network but where they cannot securely authenticate the
   identity of that network.  In such cases the client would like to
   learn which encrypted DNS resolvers are designated by that network or
   by the Do53 resolver offered by that network.  It lists requirements
   that any proposed discovery mechanisms should seek to address.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-add-requirements-00"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>Thanks to ...</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAIZjyWAAA+1abW8bxxH+fr9iywKNFJB0pCRoLKNIKNGOhdqSI8p1i6JI
lndLcqHj7eX2TjJj6L/3mZnd4x3JOCn6gqLoh8bi3d7uvDwz88xsR6NRUts6
N2dqUuh8461XbqGmVzP1wlUPuspMpWapKXRlnboxua7tvVG1U9PpjdJFhqU3
iZ7PK3P/a7ZIMpcWeo3jskov6pGvdXU30lk2ygo/WsT1Ix12GuFA4+skxT9L
V23OlC0WLklsWZ2pump8ffrZZ08/O010ZfSZuixqUxWmTh5cdbesXFNCqOlU
vcNPWyzVt/QouTMbvM+2y0dTEiZJIE2Rfa9zV0DAjfGJX+uq/v7HxkGIM1W4
pLRn6q+1S4fKu6quzMLjr82a/vhbkuimXrnqLBkpiIkPzsdqRgomSinR+lxX
c13p7WNXLSHi7e9u6Udqa2g4gVa2GKrbP/Mz1xQ1Kf52Rj/NWtv8TM1lnzHb
7xtd1+PUrdtzL8bq3L3fnnqxquCU8IhPPO+cd46Xtcv7h/2xc1hKn4/n7v03
czknKVy1ZiScYdnNi4vTk5OnZ/AKfNN/cfL05Kvw51dPvzylPy9H07E19UK8
nlX7z4r9Z5X5sbGVWZui9jgoGY1GSs99XekUfrtdQT0GlGLg/GS8qldGzc1K
31tX0S9dq8p4m2EHq3NlAN3GG7wiEK/c2igAgWCj3ENBz4/MeDkeJiWQhUMJ
0htYZwlr2DzDs2O1tstVrcz70lTWFKlRDytTKIefMAFW+o2vzVpOSHPL2/im
LIGc5MOHXTs8PtLCJ65Su+8KegfLqsz61N2bakPS4MRqU9Ym41CDKvc2BWTp
MNL94rkC2IFvWksP+jouFqSjrb3JF0qLuabuy8/JSC7HGWPFVoWNVKrxH+sT
aJpbYCbfKHKERZhkANyuvF1fQfCZSWmp+nx8KrbGad7gBJ0n3aU4mYI9o+Ri
63C8OJU+gdxq6XQOeGcGaq1tAaFEtZgt8J0qK3cPL/sEP3WaNvAFLciGtBjv
O4+H+ztFxIRlpqz1POd8R2/ffavo1SLBj8oov3JNnuEbYEIXSwKdU8bSy2j0
rcfWhhZZv/Zjge/aZllukuS3lIYqlzVspv+D+X8RzD2v9tGcJOrTX4foLnTp
o/8iPJ8blAVCiaY9RU2c+Gnh6k/xjDSVHaIRyCF0pBVAPdg8p3MLp8iKqPgE
kURnrmRzzzdYtsHeOOsdIGsYJi1d8OoJWem9hchrvQGKUdHImaa4t5UrxCWO
FUHwFD34+ESCAw9rX+J/qOhrTfI0Hpb03vjjYUd0lTkcA80Uyq5ZlzVb6b1m
s6P+A16N17DeuOt0/LFwKQCYKbdzPnRCErhwxb3gUEwyNQtbWP5N6DEKrEUR
bfFq8Prt7HYwlH/V1TX/ffP8u7eXN8+n9Pfs5eTVq/aPuGL28vrtK7xPwl/b
Ly+uX79+fjWVj/FU7Tx6PfkL/iGpBtdvbi+vryavBmReMgoxuoYMrJBbyBRw
oyVeVVaGAgBgB3bTys4lvs4v3qiTLxBmgTYgqD58+A3xg5Pff/H4mFDakbNc
gdiUn/AcEFCWRle0B3kn1aWtEUBDOgHIfYBVgagx2fJcp8z+iixJXgL/DMwe
YkT6bmLhpEpwzADv2sJRSYiSV5MrRVBYqulLCE+i3WCzmRJwSlyCOq3XSN+Z
KXO3YXusXWZyTnVrAu/l7I14lpbnXvbOzEI3OWOVF8FmoFzYrPAwahWEa/P3
lamXsMExtPx4nsIG2KiQVLhwee4eSIHavK+7qanuZkWkosFrEiICUxIrma6b
Swm/CCEciie+tRsFxDJ3c/iGkgNSQ7FcNPlQkeQJu5vI4OPjUOW2uBvlLqWk
UKmmsIh4Jb/DrggedetifdnJPLvlIhFfQotuuAMXLAa7pzAmw2LyRX8vZI2U
tXCKS8micmulExYm34yiONmOCbBcFztFa/syIimlrS3l25BENauSeJBydcRn
HEeNh2QKvNcQjqxOABJzxhXE6etVCzpSKYRbMJPJxgO48OaL8Ym6lHQtRo11
spWQAbuNBRa4zWri9IMFmeJSNSVot9HrzpJ245BYIBOADB5xz9Xm3moFF1eU
nj0pxsjT9VaEKPipmoCRGI7YDqIVqbRNWvEV14ROqdqpCUjFtaTbwhWjplxW
OmN5crPUaQtzxCCTDZLhUrICRQ9FCpCme7maMxEdTNVSyj6E0Z4c8rDahCqx
kwISibEMzSBtFddjDyn+b6S+R2dpXgODNswHseBCl9x1k5Ox4ugK7agYkMOK
GiuEfEYFw3iOzQpWrEFVmsrseBfBjwgqkgE6dk098YDM9gxaPpA+UUGpoJyS
grWClVCqAcK0J5GPZyRhd9XfffzYVXNhc6Q08vCRvtNKKKnmnAcanPvjMFaY
jeaaIu++yUFh9dzm6FaR7JEcPBk32U3hY9Ua5heyYyxIXhxGrTz5eisZSYBs
bmvHPyOLSrSYt65RYJ6hCwYsVibn8OWdFk3B/FCzrHhQurLJUbTYamzO0rgS
GEQDYHxpUsv5MvDysXgbzmP8g40UXqBt18QChfaAknObDZJOxa6dzsTpi9CF
bdL3wlm9sKzQUwCucFlLDzX3DyQxdQBpKA/eSBuQpCiJKCfko0w4iSBkjN4l
VGMIihar/sSTi1C7dol7p7SSUELWky5ZpySDhUf9Wks9xM3kmAlj23iQf65n
AXcUjPAekw7DvC+RcuCDZTjWQgkntQnovSN7ZT+Q4zWRThLiyc0ksNWEuOW8
L0UMC5aEKqmwzM7u/llghSxnw0hD+SlNZMRJJPtjceFPXKm75B0L45kh0jiW
Y3kM1WXqXlIRmbpbKibJziLCXsvZScdYBDt5PAjMkjJF6YoLzjEhz4b6I3yH
KyH83zM1pbURCC0vIDdFGeZUwKZXYXA4vaFlnBNB7dCMadk50PF55R6opz1u
Pw9fXDl1Qb5a0BdGTXjoRvHG+PZ2WRAd66zg4EOmqew9/bx805IX4pJqNrlC
HHUC6eSMzugUlhbFPROImrc9lB/ZIs2bLCB8h3Oy1oIoyqCS0lAUj9ng5Kym
zIiawdTPYxi2bX97XGW6/RLHCcfIFsNce3o0KXh2HCXuC8bbhZ882I3V+iiD
mk+etG20rkp9HLtHIT1oPT2Vgg792Ql7JI2FXaIUcWghRlgKZig8x9jbYRWy
AlBROXiNnDb708U5rUUDRGlGRA6dcWBcUg5i2mxpGJhIUxVk1KA7KbchD13P
nuAI2WrbOfN3tFMHJ5Re4M63xdaiN1Hao57CUr32P6cnBz8PYhPGEeJZD7gh
hNe6TlfbPpke4c2Aps3UMabM5ltOO/hPKdpyCpHvsM7P9/fZU8RxeKMP8FDm
kCJd+fmjmLp0IE37p4ylCtJkDOJwixWSJ2LmgFAxorhD53EDTmVOjoOZUjRU
iik4KMcih3VTKFbv7zlEa5NLi2Q6m/lm7mnGUdT5Rjb1zDDBUfn+gWKwl6hR
KJEKDp/R4TxSS3yzRNKKhYLDdHtRQwFTOk+MTWBnK4Xo42aDKEVbWJCJ/WLD
zUqXhv9LKHryz1H0CdWlolV6+x0a9vBVbJpbvHT02ZtH8qyyq4hwCjXopcik
o1pMlDFJUlc56KXIQdskjQexFdumxAfK4CHT04yBJPxH9mSO3kX2A4/taBux
NBoNS+RQyG2sau0YkdMNdRnbLYYySSw+qans3tHgF5XfG/BSSJlvxv0CeXrW
USdoQt6N+ZigBoCFWveLRZP6o/1NDgQp3S91N97baWlqngP/7Mfc39Pnz2ht
LUwL/n5AyYGydUxbIk88oG15L2dvuDpFcekolCSz32LX2+lFSKXQXuZauigc
+oTYfVSdSkCS/XztJyrFmG64vB0yES2bdMmUpIFqs4embgaWTEAjtBBKYF8m
1U2sosIPtM3hykwaAG58CTpBtleHmlfyrODpa14j4dlvHmV29NBd96Ltw/am
dEd77aKMCpkAe6ISRAS3s2kYn/IJp/T9ewO6GznuC8AGRM7a9oLSzsvwUoYD
h/xN4tiikSwntyYmkFUpUam0df1A+vxnAilCp18Zt0CSa4UdfvmLcRZ29R1e
CLELag/vyWwHN/03Rmt/pwp2Zhl+OEA6f3jWZYCAjuVmyO2mVmH61FqOqBHo
86kk6RZL5L/FgoyMAJAYoMm94N8H3kpXbFU7Z4NPCWbo55fmIxSdOxqKVQ72
bjDKDQxX5OueZ6eR8wxDVAXwc0O5Uz8+OZTdxh8/WOo6L5qklfM0/6uoVNDu
K4djVi7PvOQntMcFW5K7I+qac7NdFCdEdDdVsIlQwovtKKG9zUAf5OX2gqtR
B/Q7xtVi0eiOyJ+3huheYjVFiW9syvdYw0QuwMCz7J0R9MBPJRqKhruonZNP
A82j4ZSwrmDc/tyG6Z7mTpKRA+2KZj2XW7BDt6sQj08FtzKLhgY6Me2EXlY8
JwOtZDva2p99DbsS8oiFDLCbMddlzlwleLcJlxWeXljwHI+WpyRhkdN0Nucr
2xDoWC9e5lkGH3Nw7qiOvkZmrJOPWZevt3ID5X2neUbTyGhbBQxHNsZht2UI
nRxzzJc239G1H+sTx/TvvkVK4wmmCQUvlBxQKFRsGSRrZqOhyT+QhQ7dWH7N
c7NYLS4CFHW4bDsPs0shSgdqCmvCwzy5dA8UGhZiIETftxSbIJO0FaN3oyOG
iLXmWLyPdd4U/eMZqHK3yH283IKKZdYmShbmCAmNCOFt8XRKVxXa25yHV/NN
qX1ocmSo1E8V0pQ3BY2T4rXnttG7I1Zp1jT9AQaJGpJA1OWwDy8nV5M9e8ot
aLwlJPqEFoxXagEkpQz+v0TMdXpH20zSO1Rk2HDJE9vkw5nEn8n+MFigezGD
R9pWF3dcA8bjcfJ3sROY3skmAAA=

-->

</rfc>
