<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.23 (Ruby 3.3.6) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-hmntsharma-bmp-over-tls-02" category="info" submissionType="independent" updates="7854" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.26.0 -->
  <front>
    <title abbrev="BMP over TLS (BMPS)">BMPS: Transport Layer Security for BGP Monitoring Protocol</title>
    <seriesInfo name="Internet-Draft" value="draft-hmntsharma-bmp-over-tls-02"/>
    <author fullname="Hemant Sharma">
      <organization>Vodafone</organization>
      <address>
        <email>hemant.sharma@vodafone.com</email>
      </address>
    </author>
    <author fullname="Steven Clarke">
      <organization>Vodafone</organization>
      <address>
        <email>steven.clarke@vodafone.com</email>
      </address>
    </author>
    <date year="2025" month="February" day="04"/>
    <area>Ops &amp; Management</area>
    <workgroup>GROW</workgroup>
    <keyword>BMP Security</keyword>
    <keyword>BMP over TLS</keyword>
    <keyword>BMPS</keyword>
    <abstract>
      <?line 56?>

<t>The BGP Monitoring Protocol (BMP) defines the communication between a BMP station and multiple routers, referred to as network elements (NEs). This document describes BMP over TLS, which uses Transport Layer Security (TLS) to ensure secure transport between the NE and the BMP monitoring station. It updates <xref target="RFC7854"/> regarding BMP session establishment and termination.</t>
    </abstract>
  </front>
  <middle>
    <?line 60?>

<section anchor="requirements-language">
      <name>Requirements Language</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"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>The BGP Monitoring Protocol (BMP), as defined in <xref target="RFC7854"/>, facilitates communication between NEs and a BMP station. Keeping this communication secure is important because it includes sharing sensitive information about BGP peers and monitored prefixes.</t>
      <t>The  <xref section="11" sectionFormat="of" target="RFC7854"/> , "Security Considerations" acknowledges that while routes in public networks are generally not confidential, BGP is also utilized in private L3VPN <xref target="RFC4364"/> networks where confidentiality is crucial. It highlights that without mutual authentication through secure transport mechanisms, the channel is vulnerable to various attacks and recommends using IPSec <xref target="RFC4303"/> in tunnel mode with pre-shared keys for enhanced security in such scenarios.</t>
      <t>Additionally, a recent draft proposal, <xref target="draft-ietf-grow-bmp-tcp-ao"/>, titled "TCP-AO Protection for BGP Monitoring Protocol (BMP)" suggests an alternative approach using the TCP Authentication Option <xref target="RFC5925"/>. This method authenticates the endpoints of the TCP session, thereby safeguarding its integrity. TCP-AO is beneficial in situations where full IPSec security may not be feasible, although unlike IPSec, it does not encrypt the session traffic.</t>
      <t>Alternatively, Transport Layer Security (TLS), offers endpoint authentication, data encryption, and data integrity defined in the Transport Layer Security (TLS) Protocol Version 1.3 <xref target="RFC8446"/>.</t>
      <t>This document describes how to utilize TLS to secure BMP sessions between a monitoring station (acting as the server) and a Network Element (acting as the client). Unlike BGP, where either side can act as the server, BMP's role distinction simplifies the implementation of TLS in a client-server model. Henceforth, the term BMP over TLS will be referred to as BMPS.</t>
    </section>
    <section anchor="bmp-over-tls-bmps">
      <name>BMP over TLS (BMPS)</name>
      <section anchor="operational-summary">
        <name>Operational Summary</name>
        <t>The operation of BMPS is virtually the same as the original BMP specification defined in <xref target="RFC7854"/>, but with an additional layer of security using TLS.</t>
        <t>In BMPS, the BMP station functions as the TLS server, while NEs act as TLS clients. Following the completion of the TCP three-way handshake, as defined in <xref section="3.4" sectionFormat="of" target="RFC793"/>, each NE, functioning as a TLS client, initiates a TLS handshake with the BMP monitoring station, acting as the TLS server. Once the TLS connection is successfully established, NEs can immediately start transmitting BMP messages, as there is no separate BMP initiation or handshake phase.</t>
        <t>The following steps summarize the operational flow of BMPS:</t>
        <ol spacing="normal" type="1"><li>
            <t>The NE initiates and completes a TCP handshake.</t>
          </li>
          <li>
            <t>The NE initiates and completes a TLS handshake with the BMP monitoring station.</t>
          </li>
          <li>
            <t>BMP messages are transmitted by the NE according to <xref target="RFC7854"/>.</t>
          </li>
        </ol>
        <t>A BMPS session ends when the underlying TCP or TLS session is terminated for any reason.</t>
        <t>The <xref section="3.2" sectionFormat="of" target="RFC7854"/> states, "No BMP message is ever sent from the monitoring station to the router." To adhere to this standard, the monitoring station MUST listen on separate ports for BMP (non-TLS) and BMPS (TLS) sessions. This approach also offers a simplified "make before break" migration from BMP to BMPS.</t>
      </section>
      <section anchor="transport-layer-security">
        <name>Transport Layer Security</name>
        <t>In regular TLS connections, the server has a TLS certificate along with a public/private key pair, whereas the client does not.</t>
        <t>For BMP over TLS (BMPS), it is REQUIRED to implement mutual TLS (mTLS), wherein both the server (BMP station) and the client (network element) have certificates, and both sides authenticate each other using their respective public/private key pairs.</t>
        <t>A self-signed "root" TLS certificate is REQUIRED for mTLS, allowing an organization to act as its own certificate authority. The certificates issued to both the BMP station and NEs should correspond to this root certificate.</t>
        <t>The operational flow of BMP over TLS is similar to standard TLS operations:</t>
        <ol spacing="normal" type="1"><li>
            <t>The NE initiates the connection to the BMP station.</t>
          </li>
          <li>
            <t>The station presents its TLS certificate.</t>
          </li>
          <li>
            <t>The NE verifies the station's certificate.</t>
          </li>
          <li>
            <t>The NE presents its TLS certificate.</t>
          </li>
          <li>
            <t>The station verifies the NE's certificate.</t>
          </li>
          <li>
            <t>The TLS connection is established.</t>
          </li>
          <li>
            <t>The NE begins transmitting BMP data to the station over the encrypted TLS channel.</t>
          </li>
        </ol>
        <t>TLS version 1.3, defined in <xref target="RFC8446"/>, streamlines the handshake process and supports more robust cipher suites compared to the previous versions, enhancing both speed and security.</t>
        <t>The BMPS is REQUIRED to support TLS 1.3 which has become a dominant standard.</t>
      </section>
      <section anchor="operational-recommendations-for-bmps">
        <name>Operational Recommendations for BMPS</name>
        <t>The BMP over TLS (BMPS) is RECOMMENDED as an alternative mechanism to safeguard BMP sessions in scenarios where alternative protections like IPSec may not be feasible or deployed.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The BMPS implementation increases computational demands due to continuous encryption and decryption processes, resulting in high CPU utilization and potential vulnerability to denial-of-service attacks.</t>
      <t>The TLS cipher suites that provide only data integrity validation without encryption SHOULD NOT be used by default.</t>
      <t>The BMPS implementation SHOULD follow the best practices and recommendations for using TLS, as per the Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) as defined in <xref target="RFC7525"/>.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-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"/>
            <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="RFC7525">
          <front>
            <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
            <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
            <author fullname="R. Holz" initials="R." surname="Holz"/>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <date month="May" year="2015"/>
            <abstract>
              <t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7525"/>
          <seriesInfo name="DOI" value="10.17487/RFC7525"/>
        </reference>
        <reference anchor="RFC7854">
          <front>
            <title>BGP Monitoring Protocol (BMP)</title>
            <author fullname="J. Scudder" initials="J." role="editor" surname="Scudder"/>
            <author fullname="R. Fernando" initials="R." surname="Fernando"/>
            <author fullname="S. Stuart" initials="S." surname="Stuart"/>
            <date month="June" year="2016"/>
            <abstract>
              <t>This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7854"/>
          <seriesInfo name="DOI" value="10.17487/RFC7854"/>
        </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"/>
            <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="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC793">
          <front>
            <title>Transmission Control Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="September" year="1981"/>
          </front>
          <seriesInfo name="RFC" value="793"/>
          <seriesInfo name="DOI" value="10.17487/RFC0793"/>
        </reference>
        <reference anchor="RFC2818">
          <front>
            <title>HTTP Over TLS</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="May" year="2000"/>
            <abstract>
              <t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2818"/>
          <seriesInfo name="DOI" value="10.17487/RFC2818"/>
        </reference>
        <reference anchor="RFC4303">
          <front>
            <title>IP Encapsulating Security Payload (ESP)</title>
            <author fullname="S. Kent" initials="S." surname="Kent"/>
            <date month="December" year="2005"/>
            <abstract>
              <t>This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4303"/>
          <seriesInfo name="DOI" value="10.17487/RFC4303"/>
        </reference>
        <reference anchor="RFC4364">
          <front>
            <title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="February" year="2006"/>
            <abstract>
              <t>This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4364"/>
          <seriesInfo name="DOI" value="10.17487/RFC4364"/>
        </reference>
        <reference anchor="RFC5925">
          <front>
            <title>The TCP Authentication Option</title>
            <author fullname="J. Touch" initials="J." surname="Touch"/>
            <author fullname="A. Mankin" initials="A." surname="Mankin"/>
            <author fullname="R. Bonica" initials="R." surname="Bonica"/>
            <date month="June" year="2010"/>
            <abstract>
              <t>This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5925"/>
          <seriesInfo name="DOI" value="10.17487/RFC5925"/>
        </reference>
        <reference anchor="RFC8253">
          <front>
            <title>PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)</title>
            <author fullname="D. Lopez" initials="D." surname="Lopez"/>
            <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <author fullname="D. Dhody" initials="D." surname="Dhody"/>
            <date month="October" year="2017"/>
            <abstract>
              <t>The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP.</t>
              <t>This document updates RFC 5440 in regards to the PCEP initialization phase procedures.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8253"/>
          <seriesInfo name="DOI" value="10.17487/RFC8253"/>
        </reference>
        <reference anchor="I-D.ietf-grow-bmp-tcp-ao">
          <front>
            <title>TCP-AO Protection for BGP Monitoring Protocol (BMP)</title>
            <author fullname="Hemant Sharma" initials="H." surname="Sharma">
              <organization>Vodafone</organization>
            </author>
            <author fullname="Jeffrey Haas" initials="J." surname="Haas">
              <organization>Juniper Networks</organization>
            </author>
            <date day="22" month="August" year="2024"/>
            <abstract>
              <t>   This document outlines the utilization of the TCP Authentication
   Option (TCP-AO), as specified in [RFC5925], for the authentication of
   BGP Monitoring Protocol (BMP) sessions, as specified in [RFC7854].
   TCP-AO provides for the authentication of BMP sessions established
   between routers and BMP stations at the TCP layer.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/hmntsharma/draft-hmntsharma-bmp-tcp-ao.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-grow-bmp-tcp-ao-00"/>
        </reference>
        <reference anchor="draft-ietf-grow-bmp-tcp-ao">
          <front>
            <title>TCP-AO Protection for BGP Monitoring Protocol (BMP)</title>
            <author fullname="Hemant Sharma" initials="H." surname="Sharma">
              <organization>Vodafone</organization>
            </author>
            <author fullname="Jeffrey Haas" initials="J." surname="Haas">
              <organization>Juniper Networks</organization>
            </author>
            <date day="22" month="August" year="2024"/>
            <abstract>
              <t>   This document outlines the utilization of the TCP Authentication
   Option (TCP-AO), as specified in [RFC5925], for the authentication of
   BGP Monitoring Protocol (BMP) sessions, as specified in [RFC7854].
   TCP-AO provides for the authentication of BMP sessions established
   between routers and BMP stations at the TCP layer.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/hmntsharma/draft-hmntsharma-bmp-tcp-ao.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-grow-bmp-tcp-ao-00"/>
        </reference>
      </references>
    </references>
    <?line 140?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>This document is the result of studying all the referenced RFCs and drawing some parallels from PCEPS <xref target="RFC8253"/>, leading to the specification for BMP over TLS (BMPS).</t>
      <t>We are grateful to the contributors of the RFCs listed in the References section. Their work has been instrumental in shaping and inspiring the development of this specification.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA5VZa2/cNhb9rl9BTIBdG5hR6leTDFDsOo6TGOvX2k6D/ciR
qBFhSdSSlN1pkP++515SGs34gW6B1hqJ5H2fey47m80Sr32l5mLy8eL6di7u
rGxca6wX53KlrLhVWWe1X4nCWPHxy7W4MI32xupmKa6t8SYz1SSRi4VVD+EQ
YR6w7+78VuzQkbuTJJNeLY1dzYVuCpMkuckaWUNmbmXhZ2XdeFdKW8vZom5n
tH3mKzf7ZT/p2hx73Vy8e390mLhuUWvntGn8qlV0Wq5ahf80Xog3QlbOQIXR
28lUTFTO6sqKfpwdf8QfWDI5u7n7PEmarl4oO09IyjzJTONU4zo3T2DLQSKt
knNx1TrxN3EhG7lUNQ5NHo29X1rTtXPx5ebqe3KvVniVzxMxE2R/77L+d++P
+Ps2SR5U00HeGyHiOd+/0I9g1XccT979Qp/odS11RUv+qf6QdVupNDM1vZc2
K+ei9L5187dvRx/fhuOW2pfdAh5ZO/jtqx6f0K6KHO5pVzx4vTgNJ6bavH7O
61/T0tdImUR2vjSWvJYI/FN0VRWy4quqJSJ6y1v5m7FL2eg/pUfo5+J3k8vC
NIo/qeCdkvekQdw/H+IK9tRTAbdeIQLipJL2Xv1FAY73pBnv2RLQGAj1+gEh
FTefT/b39j6Ep3dH+0fxCfkbnt7vveufDg9/nScJ1cTG/ncfDuJB7/feh6fD
g18O+qdf4/ajD/3h7/eP6OvZ7FOqlS9mSKpHdrnP2pk0kJHMZjMhF85bmfkk
uSvVS7XMRbsrclXoRjnhsRI21l2jM/aOWCj/qOA9ybntfHgrm1zUXeU1UlAg
cb2ybiqsKpS1KhfeCOlEg61IbqEqLiQndi5P3W4q7krtBECho7cQ7TKrFxA+
Lp6peCx1VorO4cOLILWDlbskjcrYKuHogxJ+WN9rT3ZdnrLa9EiS6rUzolWp
OPMiQpD48SOG8edP2LWUNqeV7APFmCRQNnJRaVeyGXy0srVuwlkhBrXO80oh
IG/Ejfpvp230xLlslh0AJsQGiCIIUpyYXHy7vSPkor/i8oqfb07//e3s5vQT
Pd9+PT4/Hx76Fbdfr76df1o/rXeeXF1cnF5+CpvxVmy9ujj+D/6Q8pOr67uz
q8vj8wmAFl4ax0iSUw28iU8wsrXKI8oIcR+8nPZ8PLkWe4fBc1QU8Bw/Uwng
+bFUTRBlmmoVfyIaKyHbVklLR8iqEplstQe4T0mAK81jg3K3KiUnnjXemrzL
yMXJX0jsaVCSkptVHEV1KgqZ6QqiKNzPJz3ylRXeSP5U/EuplmSxkzZ3xgzE
e11TBhKyLVQmkcdCe6iQVR2cJgi5OPWQuZqwQAy4QOW1QEmxZa1CZYVyCzbC
Dri/0H8olwYHwCgUBO/b2xOmEOvEpYToa+UE3U7nyrIENxEyu2/MY6XyJde9
9FRxfTU7clbbIb2zvowdZ8FSNTiiQvwa42F7U2jqvOi3U9YXhlNfFp2Ha/8M
Tm+tfoCTxfnB79eXIQQEa9BvOPqRIrxxHKlM3rVdhl9cmqVelhX+9b2+aE/k
p7rznawENRjaGyPhS1iyLJ9iQq2yEujvajcNeIdfjapI2kNXkXmLitP9ASEy
HQzyHs4KUbCK4g264QBNFMCza3i4N+qXAxhF1dPxibXJFWtJIZtRyOEQFLtj
dqUaCM7wxvUhwk7XAfRcphqSTRE+zkFoYA/5HNlMCjBqUsvFsaY1jnz/48c/
Qhd+riP89lKroCpgPojyvzu5nh1fcf3EbHqFAobqmkDdJdLHk28Qd0BDw42N
KtoayfgdCkUJnC+ON0N01fIfdh61t58/Y3OoFSKbjyMaexMc3xpNCIo870+N
gMzRtGqxEk4WCvAaIFt7x6i1JBenIpoJIQukcqEpu9jxGknEpRGTkfhDjO4Q
oFqGvAcQFko6jUSZkt0lZ1rXVPpehT1TqvbcQG1ar5rMrlrPGvftAwlZQDyF
eO04ivHr3Q50tigIE3pXbOX9VKB/yV4iv6C85ZeDG8aQyF58vcEOUf8dghln
0oMI7eA0iBoB0fM9HfBNpRThgMcE/Iw1OeqmbkQ0nnZmsQMeQ7+liz604Am7
EZsvI884DTxje3FWabwF7/gW4oOUnsYYK00pIwgX0XYgO/ObIqak498dQBGQ
kGuHc0NtOMB7pQsd85J+sfCgLpKTLKWGFsXPwnkMCUCzr4iPQn35MmAQMYcN
/gPYQPohz7Y4FQ0UKfOJZ0YvvH6DoooYj7y+7epa2lXoE6b/QOrRekY8bQk8
gedsNPhy7wAEYKnpEI5SqzJYG+v2pYa66AIoMxoMuIURg3IKQoc6CqgAxWHK
WcPKTAdi1se86IKvXa8RGdqHJfQq7s8hZvQxuNql4rOpKvPYIw8QG9HpLe9R
A/1BqdkjKhownAOc79VTttA31oP0sO+sHw7IVEXgdnk6HbSMCSdHigADkMia
wSu8HyQFN71MRadiM4fXpqfiCqkzvETLbKKOiCa6R4Z6IuharfmpyqfsKcpw
jeaVk0pYgO+oeG6Mtfa+57c1TgA1DfyLIZWObqhqW2mpkdOqaBo71Y4Ma0vp
VGQmxRAGjFMtqUfpSDjgx/mIFCmwrk9LzC971AeYsY88iFqPkQz+RAwHsWmy
/1e2/D8hSJODdMMfgQX33kKGLFbDXJFlJnQbVOmoJAjcQ6kNQwMxB6K+vLVr
QMiqFRcDzDE2Bjqshdf7iQLSqBvLZgVAkI7nCzJ3nKH7m9zPMbEl1m/GZtCp
imDDEVQW1tSsyTOYC1PoS5ju0om4AwDlnA78hdIN9DZHm52+dARPMUhBD3uZ
HMcEolYTSBBpttOYZsaNhgLG7gp9p+8NkRUMpIIZZmyDcg3FIDE1BXZByIo/
8NT9BCPYMsIeG0sCvelxFHj5Uu9jZMLk11XSbpVaJI4R0st12SvrA0oCRSsD
RwQ0jEz6bU+Ead5rpbaxDW30qYE0QLvP0UFbMM/cAv7o50KyZ2hAPRvm5XVg
DCwFeLYwMeOj5jsjuN0dhuOox87W+L4LQ8HsRja6QC34VGqhboOwBYg03GAH
FqgtXErNhFniC25h2gsdq2Lm9JKweGKN8ZMnPh77gJKp5osD2YOObDYueriD
hmZBnJDmyo2A8f1U4Ijlpp0Q5LrQggcXbt+GEMBiWO0qghxLRpomHyqF9B8f
mW615E0IXAecikzXmlKQaFOsN/407HUvAGZofUN7iOU8HmR70OztwJTi+HqC
/LPlbIbDKAParalP3AyStLH6cFj9+qlHmypsHH15un3qr2H10843anZp8m6Q
vVDgMO5pj2M6HD3Si2anhyGDubMKfo7jIUUMvx7WDHj6hAcFNjzFiSjquhpu
1Ebd0Rpq0JwxrmsDDtaEVtYsOocc0S0z0k7HW4lWRvJHB8GVDzySRjVQgWGK
JLtCHbaKbmaa9VQZU60nfGPQiBqwmUTpw5Ub4dmCxlzUBNCI+g/goM+99AnJ
vOlH4jg+RVi/HeRu41dQY7iGYtq0OT4OIzpr2U9zm/MCzWz9nBzp/PiIdphj
nViPZc9NcNR2c9VWZkW5Q9T6hTuTsSM3+T6mAoLxGLHO967J6ZoaDT/vuGki
ZZGBHQVwPZ+F8UwNP2OKKL5PdXTHSkNsw7cf4uT6W5yl1sjTwlC+MhmuLzTf
nkBgrhq8n5mCxw8N3hjvMmJScH5vZBxfrECFBxqJ+J5ua3J8kJUOkR7uX0a2
rK8fycOdCywJdSJhSPqyA+O+QBg51TE8kiJEgzO1dfcySrRhkmC22sYKfi4l
b8PM+c0pHs9en3hJ3CcYDupQv7L2U1j8zBXjEd9mcDadHV8eP5NJ43mZSg4E
m1fKkLRpvMVfIFx0yvFwXcc3yMmPefifWSr/bVKAEKnJz+1TdUCfkEU8f/ku
Z7JJ16zhEziU4ksoKB28nFsZKDsBAPG1qlKVC+Tp+uQUsQtYt3/Eg1ClZE98
GUw3BsXieQID276rcJ1IdBDjSr+dKsRqzJHGDlc8rBmTyOG+4qbX2xHMhUvZ
O2YXzFgCgimqS0AxOyNe8pSyDcyAjnKttv2MmIMTV6Zlv7Fc6rxjW9Lkf/FM
iWs9HQAA

-->

</rfc>
