<?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.1 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-cui-anti-ddos-problem-statement-00" category="info" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.1 -->
  <front>
    <title>Problem Statement:Collaborative Defense of DDoS Attacks</title>
    <seriesInfo name="Internet-Draft" value="draft-cui-anti-ddos-problem-statement-00"/>
    <author initials="Y." surname="Cui" fullname="Yong Cui">
      <organization>Tsinghua University</organization>
      <address>
        <postal>
          <region>Beijing</region>
          <code>100084</code>
          <country>China</country>
        </postal>
        <email>cuiyong@tsinghua.edu.cn</email>
        <uri>http://www.cuiyong.net/</uri>
      </address>
    </author>
    <author initials="J." surname="Wu" fullname="Jianping Wu">
      <organization>Tsinghua University</organization>
      <address>
        <postal>
          <region>Beijing</region>
          <code>100084</code>
          <country>China</country>
        </postal>
        <email>jianping@cernet.edu.cn</email>
      </address>
    </author>
    <author initials="L." surname="Li" fullname="Linzhe Li">
      <organization>Zhongguancun Laboratory</organization>
      <address>
        <postal>
          <region>Beijing</region>
          <code>100094</code>
          <country>China</country>
        </postal>
        <email>lilz@zgclab.edu.cn</email>
      </address>
    </author>
    <author initials="L." surname="Zhang" fullname="Lei Zhang">
      <organization>Zhongguancun Laboratory</organization>
      <address>
        <postal>
          <region>Beijing</region>
          <code>100094</code>
          <country>China</country>
        </postal>
        <email>zhanglei@zgclab.edu.cn</email>
      </address>
    </author>
    <date year="2023" month="October" day="16"/>
    <area>Security</area>
    <workgroup>IETF</workgroup>
    <keyword>DDoS Detection and Mitigation</keyword>
    <abstract>
      <?line 120?>

<t>This document presents a problem statement on collaborative mitigation of Distributed Denial-of-Service (DDoS) attacks. 
DDoS attacks have become increasingly prevalent and sophisticated, causing significant disruptions in network services. 
The evolving trends of DDoS attacks, including their types, intensities, and attack methods, pose formidable challenges to existing defense systems. 
This problem statement examines the current defense landscape, highlighting the distributed deployment of defense systems across various network positions and the imbalances in defense capabilities. 
Collaboration is crucial for effective DDoS attack mitigation, considering the global nature of attacks and the need to protect critical network links. 
The existing collaborative framework, DOTS, shows promise but requires addressing these challenges to enhance its efficacy. 
The existing collaborative framework DOTS demonstrates potential, but there are still numerous challenges in its practical application. This document aims to address these key issues that impact the implementation of collaborative technologies.</t>
    </abstract>
  </front>
  <middle>
    <?line 130?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Distributed Denial of Service (DDoS) attacks have become a pervasive threat, causing significant disruptions to online services and networks. Collaborative mitigation strategies are needed to effectively counter these attacks. This problem statement aims to address the challenges and issues associated with collaborative defense against DDoS attacks.</t>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" 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>
        <?line -18?>

<!-- # Body [REPLACE] -->

</section>
    </section>
    <section anchor="ddos-attacks">
      <name>DDoS Attacks</name>
      <t>A Distributed Denial-of-Service (DDoS) attack is a method where multiple hosts are controlled to simultaneously target and disrupt the services, hindering legitimate users' access. 
DDoS attacks can be categorized into three main types based on their effects: resource exhaustion-based, link exhaustion-based, and network exhaustion-based attacks. 
Due to their low cost and significant impact, DDoS attacks have become increasingly popular, with attackers continuously improving their techniques and intensifying their attacks. 
The following trends characterize the evolution of DDoS attacks:
* Increase in peak and average attack traffic, reaching terabit-level peak volume.
* Rapid surge in attack traffic, capable of escalating to 800 Gbps within seconds.
* Emergence of combination attacks as the mainstream approach, where attackers employ multiple attack methods concurrently or sequentially.
* Continual emergence of new attack techniques, such as leveraging novel vulnerabilities or using innovative means to exploit weaknesses in defense systems.
These evolving DDoS attack trends pose significant challenges to current DDoS mitigation systems.</t>
    </section>
    <section anchor="current-defense-landscape">
      <name>Current Defense Landscape</name>
      <t>DDoS defense systems have been deployed at various nodes in the global network topology. 
From a network topology perspective, the deployment locations of DDoS defense systems can be classified as follows:
* International ingress/egress points: These critical nodes handle the exchange of network packets between different countries and regions. Typically, they deploy DDoS mitigation capabilities like blackhole routing and BGP Flowspec.
* ISP backbone and metropolitan networks: These networks possess abundant resources and robust mitigation capabilities to handle high-volume attacks. However, due to the substantial volume of network traffic, traffic analysis can be time-consuming.
* Software service providers: As the last line of defense, these providers have detection capabilities for various attacks. However, limited resources are allocated for mitigation due to cost constraints.
The internet is a highly complex and extensive network composed of numerous LANs (Local Area Networks). 
Different LANs have different owners, varying in scale and DDoS defense resource allocations.</t>
    </section>
    <section anchor="the-necessity-of-collaboration">
      <name>The Necessity of Collaboration</name>
      <t>DDoS attacks have become an international threat, often traversing multiple LANs and involving various network operators, spanning different regions and countries. 
A global view of the internet is crucial for understanding the propagation behavior of malicious traffic. 
Moreover, in terms of DDoS attack mitigation, protecting the front-end of the malicious traffic propagation chain is more effective. 
This is because malicious traffic not only disrupts the services of target victims but can also impact critical links along the path, such as international ingress/egress points and interconnections between different ISPs. 
Additionally, with the increasing intensity and evolving tactics of DDoS attacks, relying solely on the defense capabilities at one network location is inadequate. 
Thus, collaboration among multiple defense systems upstream and downstream in the network is necessary.
Based on the analysis above, we identify the following information that needs to be communicated through collaboration:
* Attack details, including ongoing and historical attacks.
* Malicious IP addresses or URIs.
* Threat intelligence.</t>
      <section anchor="existing-collaborative-methods">
        <name>Existing Collaborative Methods</name>
        <t>The DOTS framework<xref target="RFC8612"/> provides a foundation for collaborative defense DDoS attacks by facilitating threat signaling and coordinated mitigation actions. It enables the exchange of attack-related information, enhances situational awareness, and enables effective response coordination among involved parties. <xref target="RFC8811"/> describes the technical framework of DOTS. <xref target="RFC8782"/> and <xref target="RFC8816"/> describe the communication methods between DOTS clients and servers. <xref target="RFC8903"/>, <xref target="RFC9005"/>, and others provide use cases for using DOTS and its communication methods.</t>
      </section>
    </section>
    <section anchor="current-collaboration-challenges">
      <name>Current Collaboration Challenges</name>
      <t>Through an analysis of practical issues encountered in DOTS applications, we have identified the following key challenges in current collaboration efforts:
* Lack of consensus on attack definitions: Currently, there is no unified standard for categorizing and naming DDoS attacks. This lack of consensus regarding attack definitions may lead to misunderstandings between mitigators and requesters when transmitting collaborative information. Establishing attack definitions would help both parties better define collaboration requirements and available capabilities.
* Absence of attack type-based collaborative data models: While DOTS provides parameters for describing attack details, the importance of specific attack detail parameters varies depending on the type of DDoS attack. For example, source IP address is crucial for reflection-based attacks but may not be necessary for flooding attacks. To enhance collaboration efficiency, it is essential to define collaborative data models based on attack types, including attack details and mitigation specifics.
* Lack of specific scenario guidance for collaborative information transmission: Mitigation requesters often lack a comprehensive understanding of defense capabilities at different network locations. Providing guidance for collaborative information transmission methods based on specific collaboration scenarios allows mitigators to understand when to initiate mitigation requests and which mitigation capabilities they should offer.
In conclusion, addressing these challenges will improve the effectiveness of collaborative DDoS mitigation and provide better protection against the growing threat of DDoS attacks.</t>
    </section>
    <section anchor="IANA">
      <name>IANA Considerations</name>
      <t>This document includes no request to IANA.</t>
    </section>
    <section anchor="Security">
      <name>Security Considerations</name>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="RFC8612">
        <front>
          <title>DDoS Open Threat Signaling (DOTS) Requirements</title>
          <author fullname="A. Mortensen" initials="A." surname="Mortensen"/>
          <author fullname="T. Reddy" initials="T." surname="Reddy"/>
          <author fullname="R. Moskowitz" initials="R." surname="Moskowitz"/>
          <date month="May" year="2019"/>
          <abstract>
            <t>This document defines the requirements for the Distributed Denial-of- Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8612"/>
        <seriesInfo name="DOI" value="10.17487/RFC8612"/>
      </reference>
      <reference anchor="RFC8811">
        <front>
          <title>DDoS Open Threat Signaling (DOTS) Architecture</title>
          <author fullname="A. Mortensen" initials="A." role="editor" surname="Mortensen"/>
          <author fullname="T. Reddy.K" initials="T." role="editor" surname="Reddy.K"/>
          <author fullname="F. Andreasen" initials="F." surname="Andreasen"/>
          <author fullname="N. Teague" initials="N." surname="Teague"/>
          <author fullname="R. Compton" initials="R." surname="Compton"/>
          <date month="August" year="2020"/>
          <abstract>
            <t>This document describes an architecture for establishing and maintaining Distributed Denial-of-Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components, and concepts used in a DOTS deployment.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8811"/>
        <seriesInfo name="DOI" value="10.17487/RFC8811"/>
      </reference>
      <reference anchor="RFC8782">
        <front>
          <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification</title>
          <author fullname="T. Reddy.K" initials="T." role="editor" surname="Reddy.K"/>
          <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
          <author fullname="P. Patil" initials="P." surname="Patil"/>
          <author fullname="A. Mortensen" initials="A." surname="Mortensen"/>
          <author fullname="N. Teague" initials="N." surname="Teague"/>
          <date month="May" year="2020"/>
          <abstract>
            <t>This document specifies the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.</t>
            <t>A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8782"/>
        <seriesInfo name="DOI" value="10.17487/RFC8782"/>
      </reference>
      <reference anchor="RFC8816">
        <front>
          <title>Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases</title>
          <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
          <author fullname="J. Peterson" initials="J." surname="Peterson"/>
          <date month="February" year="2021"/>
          <abstract>
            <t>The Personal Assertion Token (PASSporT) format defines a token that can be carried by signaling protocols, including SIP, to cryptographically attest the identity of callers. However, not all telephone calls use Internet signaling protocols, and some calls use them for only part of their signaling path, while some cannot reliably deliver SIP header fields end-to-end. This document describes use cases that require the delivery of PASSporT objects outside of the signaling path, and defines architectures and semantics to provide this functionality.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8816"/>
        <seriesInfo name="DOI" value="10.17487/RFC8816"/>
      </reference>
      <reference anchor="RFC8903">
        <front>
          <title>Use Cases for DDoS Open Threat Signaling</title>
          <author fullname="R. Dobbins" initials="R." surname="Dobbins"/>
          <author fullname="D. Migault" initials="D." surname="Migault"/>
          <author fullname="R. Moskowitz" initials="R." surname="Moskowitz"/>
          <author fullname="N. Teague" initials="N." surname="Teague"/>
          <author fullname="L. Xia" initials="L." surname="Xia"/>
          <author fullname="K. Nishizuka" initials="K." surname="Nishizuka"/>
          <date month="May" year="2021"/>
          <abstract>
            <t>The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoS Mitigation solutions. This document presents sample use cases that describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. These use cases are meant to identify the interacting DOTS components, how they collaborate, and what the typical information to be exchanged is.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8903"/>
        <seriesInfo name="DOI" value="10.17487/RFC8903"/>
      </reference>
      <reference anchor="RFC9005">
        <front>
          <title>Path Computation Element Communication Protocol (PCEP) Extension for Associating Policies and Label Switched Paths (LSPs)</title>
          <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
          <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
          <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
          <author fullname="J. Hardwick" initials="J." surname="Hardwick"/>
          <author fullname="C. Li" initials="C." surname="Li"/>
          <date month="March" year="2021"/>
          <abstract>
            <t>This document introduces a simple mechanism to associate policies with a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element Communication Protocol (PCEP). The extension allows a PCEP speaker to advertise to a PCEP peer that a particular LSP belongs to a particular Policy Association Group (PAG).</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9005"/>
        <seriesInfo name="DOI" value="10.17487/RFC9005"/>
      </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"/>
          <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"/>
          <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>
    <?line 218?>

<section numbered="false" anchor="Acknowledgements">
      <name>Acknowledgements</name>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9Va7XIbN5b9zyq9A8b6sYmLpCnFm8isbMa0JCfKUrZWkms2
mUptgd0gG6PuBgfoFk17/C7zY55k9sX23AugP0gpH1tTNTWpJGQ30cD9PPfc
2xqNRgcDV8ky/R+Zm1JNRWVrdTDQa8tfXXU8mbyYHB8MEllNhS6XRhyK00wl
d3iuXhTaOW3KarvGoxfnt68PBtIqORU3KqmtrrYHg0Ph73yrSmVlLv54fX41
n52e/3Qw2KziQ4eCv5eVsqWqxHm50qVSVpcrcSvdnXhtbAKxDgapSUpZ4LDU
ymU1Smo9kmWlR2lq3GhtzSJXxQgKVapQZTWaTGhvs3AmV5VyU/H8q6OjIf3/
GHpcq8LcK6GXojSVwIGpSp9dq3Uu6bBDUa9TGZ+a/OL6g0GlqxyiXXkxxE0U
Y3pq8lwujJWVxvNnaqlKp4RZirMzcyNmVSWTOwfTLRZW3U/FwSCXJeyhyoPB
3WZ6MBBi5JeeQYukgsUFXCYudaVXki5JWpJ1Ko4nx8ejCf0rRiO+J7QTS53n
KoX/hKwrU+CZROb5Viy24n2RH9tlErVaQUJsh2WZsTh6JKwhpaC+7anvA0Vg
Txjoh7E4rTVdeu/8YOC5cMdYqHLr4MusluJdiQOs49AQwlVWqYo1THCLv1i1
gkZT8UrpP1EAHPJxMt/IrRPyXmqYMuejE5PirKPJZHLy3F/XZWW3UwSoLiUe
rGHl2/mZ+Ey9T9S6Eu/+83OIE9exrPTcOuPQp6+qwP5TgbjaQoWXVRB7rNJ6
nJS0AmE9FVlVrafPnm02m3FYOkbcPmvN9bPW+n4s/lC3xvpey3JNmvqbv8Ve
4p9psI69/hRUeJlwAjfm+lXmmI/FvBM7c11+yFS4xcb4EcetVrUsk7oUc59I
xv5jDfLiH2uQXOcfXn5YJTjpNxvjxwzZ37GH0u2tfyl7dDPqA2mQK71rFAIW
TikCUIKxaCWVaij1iLEORTDXxVh8P7oai5va0tnd6kJrvAWXdZ4/9Csb861d
yVJ/YBhtFjw7O5+f38Z1wagAdPp8ZJE39yn+/8iC6IVr/txb9KhXeHP2y5VB
Zcv54jEhor/Ozn+ts+ix4K4r+nhk5+DGc/p4ZAm78d31xQM/J+AIVi9QeyzF
/w05A1atk6q2SkgnfL1B2rhqKLBOrIxycHFlROdZ5wPEe/VUWlepUrwytpBl
2XFpg5n/+7dKvLJUg8Xtjxc9RRKkzcvqgx7jiY74BOwOyI6KOHbrwAPiid/L
rTiTudp2ziL+ImZpoUuIbn0UzeenvbPUe5WMUm1Ruo19qVW1bE9ttOPY+Iu/
Kfgo0Jl7DYohKsDh06f/fTl/+lSwYjgD5IFug2CAflRq7JOH/rnNZCU2sOmf
a43qn6l8jQTgBSWZijgIA8T169OTL4+Om+8nR0fN969Ouve/bL6/mHwRv7+Y
TP4d34kTdnc9nV2czfgbpXagREyFSOaLK3GzNmapPZzRkoZq+Mto7G+JiHDW
htzuJK9fGTzwmV5BL5gpUxRL5RYJ9Pkv7nYUvxy32zl/Z7q/hpKT6Z6AstAA
iOEy3toJVSXj3yJSJe2K0CSGmiN7KDtOpE4lBcYzVxeFtNvxOlvHhxpy98Vo
8sKjpnov4Xt1rZaAsKm/J3q7B4YSFo4TUzxrlnm/3NKH6FmWfu24hC5HP4OU
zTNewqMXJ89Hk+cUbCPwT7mgpEgqur7NQETB32uixAhu5fCJzBeBtouGtgvs
n/Qoc9EwXWbNlGqUM7DwmSq1zEdmObpR9l4nSnxGTPlzIT2rHqOwMHUO1yKT
2G+hYAzUlDJBb0JUK6d0U/dIbhxP3NqZNeQlnoxThoCLmpYJB8/qJe5iWaqd
rdckFCEVAqTaGHsnnJeDT75Fiqp7k9/Ts6geZeoa2h8EGpIUeZ3yikxpK6ib
4ttAN4CYpgsSyT8gCgXnpLi3NsB3Sj7EDQwokgycXpUrxCRgU70n8bFpGtoN
twVcFkEsuGLf7BQo6LscIwv6N0s34+NoSVKXyLUaikyvshz/VUFmskTjkBT9
kNl6Ny53DxcyscY5cS+tNrVrbAZVtDckKUpb6mIhcWTCVaDZBufLhc7ZKKRI
p7FCaECpBDUF8cBpqpZLapao42rt3QmlIYGvA8LaqMcqNzgVec1lCeLHoIlS
EQiQcWE7asRwnOZWqlEk1+Vd6/nogn4wLy1wg1YPxdnb25uhcJnZsD/QTiuu
flYBvJEhQqYpPlwQ0O05uczIRkIjkaAuREm2v/Z0PhyWLWAEqlzYcQ2t0E3L
3NfgysOXpVqNBlKUSF1LbusIAefQ4WvKcraEXK9zyhoYeCz6OS91wVIHpYJG
d2oLz7ma4w6lSxeou1UIAuAWPdqkfl8X+CArTW5WFA4Rc5AOaa58PbxAcTVp
nfgeGUiwhxy06cPI0UMKoBQWASro1AygUf0yJkBTUyIgVAMJHEchVBAlp49h
nPcHacXWD6WH/B1DGnjFNE7ZYMUG7h7J7Qds33UjCRacIJ0zyCEy0UZX2Y7J
YybKlQQBr3pQ5kkIzUk4egvG9zl4fy1XypcA727oDyB8cvnu5vbJ0H+KN2/5
+/X5f727uD4/o+83383m8+bLIKy4+e7tu/lZ+6198vTt5eX5mzP/MO6K3q3B
k8vZD088lD55e3V78fbNbP6EArjqRyksDkMtFCOwRVkgU0g3SJVDvi/8HOXV
6dXf/3r0XHz8+DtwoeOjoxefPoWLk6OvnuNik6nSn4Yo2IZLmH07QIooaXka
g6wCpmnQegJ5x1BQMm0YDwZP/0iW+Wkqvl4k66Pn34QbpHDvZrRZ7ybbbP/O
3sPeiA/ceuCYxpq9+zuW7ss7+6F3He3eufn17zlHRkcnv/+Ge8Cvf4csPgSv
T9tW6icxGn3jc7o/MzsYzH4LH6AaIUMJJZfA10WdVxo4IzK0Vz7hmJQbHpkh
EpymJbJUgD440jMsdmzIdk6mmONUHstQU3LkcKUL4r7oxaz7N9Q/LNknJcAO
CjgiGytj9QeOMRxNUAMJJQUpsQKxkE5RQAWq4PEAfTBy2tQ2IdTPAEuEIiNe
O+SS9MDtDhTt/dojTzWngz8vNxsYxwWK1ME9D9pD8SupllnXubRDDzB+OczD
dtdl7e2MLakBamkRgb3+cx3RytOj5bZd0ZGakGYJD5pNh3kB76hMKTIw+4yo
Wd2wyo7ooL5PUTxYZJId6C/vPAlDAwY0i+EEoKayO4QDZJLxWfh9oatRroDS
/jk6paAW7am4RrKn1GiseNvdXZjf5Ew9ADYgQJ5iGXEymYhvF2vHFsODDlaF
SrznOaryShEN4AJZLHTpy0jDXjzcF4zYELSgIm0NBB6GHGhdQP2k2bZJ0Sed
5KFADOEhcCwHqPeUId+yMKfehSisqitWqTaNso0fwXzqJCPxyFgwKylbGrLb
fZ2XbEjP9egoX2x1iQWhYCpZBqoLmTWaXhgb9NX1OWPkvRwUrsPHu6wwRAhT
6m5c9+lW5MT8ZLdeN0cQQJ3GVUGAeWTOzEDo0V1WHBJFlYE9cwa2JNmkXqMu
RQ2ZW5k18R8mfa9BIAFuuz8Rc3FrTxuGnq63FD03nqq1bcmubBGacvACWIVL
YUitmCb01oZ3gWAwLPGLZ4o/YFDkKfDJm76ly6wSuCuYms/E9wkNCEOshKaA
QhKIvMA120YD7diyfoKlAxL4wRpRn+3av9fwdTboueetbhMBdLyD6XMclRnI
AnrLKUf7vvr2SrwmNWE8ju2LmysAcHK3oDEZrUBWWLIy6nfT/zXKxmsKKke2
kIu6TCmoIlgH8c0C2PuogAi7YCdqu0YeS1qo+85sKHeGIm1wGlm1oHd6lJUB
e7pmbcAmfIEQMt863bgaFUuNqDWq0Q2uWPMbs6w23AiEohpmUxbazjy6ID4q
wZW8bfuGgZw2q32kp81brJ6m1LPFmN/XL9ewkEq7xiPgyjmCw2CmY8NgDi5W
ie9wKBI9CnhmR28amQ5wP0uEmtqN9+wU9Z6ry33jRv7VcPFdto3QfPbGic/m
hmJ6BmQVb4LTP+fS2QQsr/O6N/dA9GCRIam89cgmCPJ9ZPVSsSnuQVuO9jgv
J3XeKGIVNHqGcL2euIGcB5uaMhgiJm/sbOBt5BtMxtNGyNaUA1bEl98Io7u9
vAHe0PsIgve1LEueQTRah2TlPZo0JmPNIrTda9SKMN7s+qnb2tfEsPi9dWzd
EWJrGXy/UNBSYxl2KSS6UZYvhDuddWmsMhxVhKrKFrtTmd6UIDT78aSlRYkb
qTKNQu4d0RMGuKZ5NFHg0LaBa8YwmgCOWsmHNqI3Atw9BKbpelSTBfBsFNcV
dXjUtlMao58wsZNuUJeHE4Je9AebySpra7D+ZRxviJdFSpU+hx/CZwCl92ma
ar8fYTKTPe/VyAWbIdfWZ10zKuNpwgOzMovOl3tugDUxkDIUtP3xEFVQwulm
MhMyhwwOgpSCuNDcnN1Qu2G3zSXqVJhu2O8WxXodiRR1AcjkcBmKdDxTU1ZQ
atI092DwqkPeW9TFoVSYN7BLSlRqufVh1rDXZsLOT0r/lwcu9KhI5KIu/ZiS
8tfUq6yvCxdp3y8R8kqd92aO0NPEikcTT7QfPMZpWvqn4rKJy4urOEDwnOzd
9YVfcsvIwe7Mc820L04DzuMcqj/uuPSMMo4FeBjVzKY+fgwvJ9BHh+JBQL00
VEHZEEt+kfXQZKIHd4utWMqEQiJQaS8nUTwoFdROjLEpkWaYsFNCpI/vsbio
hCqJl7s9ruLPGSEs+emOq4ZxOIemXld1zCtJZZRIqu/A4r7trBLGXRsO5ihV
G48edHHOWlo/AvWGOjk6gqHifMKFN0NEs8mV7cSP0gl2jo99dUL2JTHiNl92
tvEjoia8SIrYBcSMZ6cluVYRGwiZAMzxgBeTLz59GvoLel1EFzwQocmii57l
95SJdIECeJ7PWzPcVO5hKXbYdn8UfNrwdh9gPi8IGGPawRbt0DKMvhC2fqjm
Zzxehnae6ThLuYKGVNXh7VybrDTe6o9HY9PQBxg43NjKM+g5pSb3bvA7aJcT
TfNGUa1LPxufRl0DwbX8pz2lQTX0knBBlNZzoWaWEKO8pOH+qj+w89PCfO98
VGlpGR72xUCZ2qJhkzwbKbTr1eI2NkIigQcEkk4dX0Vup0kYVbjSYc0DE+pO
Eo3FOXZe5NpljwizMXWe8ktOsUBYxcwgMWg4ykvVju1tdz7pm/rwtr3/goGB
c+FiDxtbxe1ahTHJDgDJSqLKpyqHq/6Q6TygWgNgkA2ZyDYgD4VE6ykW4DkM
vxEhMhxOTYhmtt5d2t2SeBgOQdOjyoDsHggg704hHdMf1MUXiGAAnl224L5L
t6xa5r7a9+dDTDcoHIinLFRb7PipZW5MJ4Yo2to3FnvZgAoDQyOyNbM9KjG+
g0GU7Xuxb+52LNbxUa/K9Q3sm7dO/x6M610e07ExuUsA0yC5YlXrlKXfrz69
Iu1jm/80ctr5K71uEniKzZknubewKgsdR5/cdl6i7dKblnDtkhzY+oqjjnb4
f0jdIn00bGOMvuOiaRz3JhvXTfvKdFQJWQ9SSplLE9Fizy7eL5tMg5A+2g5T
Y+8yznpD6sNlFyXPpfLacd39uXdmG3qP5SeLYfAQCy/V5P03TLuzAxIwlq0A
MbE9oF/DSxEe1Ngwe/SMY4fJhvaN31HN3sxobMZvIsMw5uMh3f20/9rcR7Ri
2A9WI6PS6lAP41/e7m8Zf/kUz6a3ZTTP8A/OkrvSbHKVrgIyfjzcvYUnP06p
+11QifyPJ0u0GepJ2O//AE/jefhMLAAA

-->

</rfc>
