<?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-01" 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-01"/>
    <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="19"/>
    <area>Security</area>
    <workgroup>IETF</workgroup>
    <keyword>DDoS Detection and Mitigation</keyword>
    <abstract>
      <?line 97?>

<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 107?>

<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>
    <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 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 195?>

<section numbered="false" anchor="Acknowledgements">
      <name>Acknowledgements</name>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9Va3XIbx5W+RxXfoSNerK0CIIJWbArldUyRlM0ElLgkVbtx
yrXVmGlgOhx0I90zhCCt3mUv8iTJi+U7p7vnByBjZ+/WcQzMoKf7/H7nO2c4
Go0OBr6SJv9vWVqjpqJytToY6LXjr746Pjp6dXR8MMhkNRXaLKw4FGeFyu7x
XD1fae+1NdV2jUcvL+7eHAykU3IqblVWO11tDwaHItz5QRnlZCn+dHNxPTs9
u/j5YLBZpocOBX83lXJGVeLCLLVRymmzFHfS34s31mUQ62CQ28zIFQ7LnVxU
o6zWI2kqPcpz60drZ+elWo2gUKVWylSjowntbefelqpSfipefjOZDOm/x9Dj
Rq3sgxJ6IYytBA7MVf7iRq1LSYcdinqdy/TU0S+uPxhUuioh2nUQQ9wmMaZn
tizl3DpZaTx/rhbKeCXsQpyf21txWlUyu/cw3Xzu1MNUHAxKaWAPZQ4G95vp
wUCIUVh6Di2yChYXcJm40pVeSrokaUnWqTg+Oj4eHdG/YjTie0J7sdBlqXL4
T8i6sis8k8my3Ir5VnxYlcdukSWtlpAQ22FZYR2OHglnSalD4XrahzgR2BL2
mY3FTNNV8M1Mm4+FiresgyY/FdYsl7U0WW3ELJjCui397iunVMVKZggY0l7g
rCW0morXSv+ZguCQz5TlRm69kA9Sw5wln5/ZHCdOjhCmL8N1bSqHbc4KbSQe
rGHpu9m5+EJ9yNS6Eu//8CVkSutYYnpuXVD40ze1wvZTUery4/cflxlOGqu8
Hmfm1xvjpwL+69hD6fbW/yt7iI5BPpIGpdK7RhG0qdO0lv53KJKVVK6h1BPG
OhTRXJdj8fvR9Vjc1o7O7uIDrQkWXNRl+divbMx3bimN/siJ0Cx4cX4xu7hL
66JRkZL0+cSiYO4z/PeJBckLN/y5t+hJr/Dm7JdrC2wq+eIpIZK/zi9+rbPo
seiua/p4Yufoxgv6eGIJu/H9zeUjP2dAeafnQA9H8X9LzoBV66yqnRLSi4AY
SBtfDQXWiaVVHi6urOg860OABK+eSecrZcRr61bSmI5L3xvAkPO6+vtfK/Ha
EYqKu58ue4pkSJvvq496jCc64hdVtfbTFy+AaWO/jkieTvy93IpzWapt5yyq
QOI0X2kD0V2IotnsrHeW+qCyUa4dwNe677WqFu2pjXYcG/8Tbgo+CgXpQaNI
iApw+Pz5f13Nnj8XrBjOAPzTbZQIFJBKjUPy0D93hazEBjb9S62B34Uq10gA
XmDIVFRFGCBu3pydfD05br6fTCbN929Ouve/br6/OvoqfX91dPRbfKeq3t31
7PTy/JS/UWrHosbFjGS+vBa3a2sXOsAZLWmKRbhMxv6BSglnbcztTvKGldED
X+gl9IKZCkWxZLZIoC9/cbdJ+nLcbufDnen+GkpOLtgCykIDIIYveGsvVJWN
/xWRKumWhCYp1DzZQ7lxJnUuKTBe+Hq1km47Xhfr9FBTnr8aHb0KqKk+SPhe
3agFIGwa7one7th8s9mM48JxZlcvmmXBL3f0IXqWpV87LqHL0T9ByuaZIOHk
1cnL0dFLCrYRGIScU1JkFV3fFaASYGA1kRoEt/L4ROaLSLxEQ7wE9s96pGfV
cBXmPZRqlDOw8LkyWpYjuxjdKvegMyW+IK7zpZCBF41RWJj8xGtRSOw3VzAG
aorJwC49grGkdFMPSG4cT+zI2zXkJaaDU4aAi5qWCQ/P6gXuYlmuvavXJBQh
FQKk2lh3L3yQg0++Q4qqB1s+0LOoHib3DXGLAg1JirLOeUWhtBPEh/k20A0g
pumCRAoPiJWCc3LcW1vgOyUf4gYGFFkBVqbMEjEJ2FQfSHxsmkfC6LeAy1UU
C67YNzsFCpizZ2QBA3d0Mz0OUpn7TK7VUBR6WZT4fxVlJks0DsnBaO02uHGx
e7iQmbPeiwfptK19YzOoooMhSVHaUq/mEkdmXAWabXC+nOuSjUKKdKgxQgNK
ZagpiAdOU7VYEN0lztzauxNKQwJfD4R1SY9laXEq8prLEsRPQZOkIhAg48J2
RKVxnGYy3ChSanPfej65oB/MCwfcoNVDcf7u7nYofGE37A80RIqrn1MAb2SI
kHmODx8F9HtONgXZSGgkEtSFKNn2157Oh8OyKxiBKhd2XEMr9EOyDDW4CvDl
qFajBRAGqevIbR0h4Bw6fE1ZzpaQ63VJWQMDj0U/56VesdRRqajRvdrCc77m
uEPp0ivU3SoGAXCLHm1Sv68LfFAYW9olhUPCHKRDXqpQD9ETOpvXWehygAR7
yEGbPo4cPaQASmERoIJOLQAa1S9jAjS1BgGhGkjgOIqhgig5ewrjgj9IK7Z+
LD3k7xTSwCumccpFKzZw90RuP2L7rhtJsOgE6b1FDpGJNroqdkyeMlEuJQh4
1YOyQEKo0+XoXTG+z8D7a7lUoQQEd0N/AOGzq/e3d8+G4VO8fcffby7+4/3l
zcU5fb/98XQ2a74M4orbH9+9n52339onz95dXV28PQ8P467o3Ro8uzr947MA
pc/eXd9dvnt7OntGAVz1oxQWh6HmihHYoSyQKaQf5Moj3+ehE359dv23/528
FJ8+/QZc6HgyefX5c7w4mXzzEhebQplwGqJgGy9h9u0AKaKk434aWQVM06D1
BPKeocAwbRgPBs//RJb5eSq+nWfrycvv4g1SuHcz2ax3k222f2fv4WDER249
ckxjzd79HUv35T39Y+862b1z89vfcY6MJie/+457wG9/gyw+BK/P21bqZzEa
fRdyuj/1OBic/it8gGqEjCWUXAJfr+qy0sAZUaC9CgnHpNzy0AOR4DUtkUYB
+uDIwLDYsTHbOZlSjlN5NLGmlMjhSq+I+6IXc/7fUP+wZJ+UADso4IhsLK3T
HznGcDRBDSSUFKTECsRcekUBFalCwAP0wchpW7uMUL8ALBGKjHjtkEvSI7c7
ULT3a4881ZwO4bzSbmAcHylSB/cCaA/Fr6Radl2X0g0DwITlMA/bXZs62Blb
UgPU0iICe/2XOqFVoEeLbbuiIzUhzQIetJsO8wLeUZlSZGD2GVGzumGVHdFB
fZ+jeLDIJDvQX94HEoYGDGiWwglATWV3CAfIrOCz8PtcV6NSAaXDc3TKilq0
5+IGyZ5To7HkbXd3YX5TMvUA2IAABYplxcnRkfhhvvZsMTzoYVWoxHteoCov
FdEALpCruTahjDTsJcD9ihEbgq6oSDsLgYcxB1oXUD9pt21S9EkneSgSQ3gI
HMsD6gNlKLcszFlwIQqr6opl1KZRtvEjmE+dFSQeGQtmJWWNJbs91KVhQwau
R0eFYqsNFsSCqaSJVBcyazS9MDboq+9zxsR7OSh8h493WWGMEKbU3bju063E
ifnJbr1ujiCAOkurogCzxJyZgdCju6w4JooykT1zBrYk2eZBoy5FjZlb2TXx
HyZ9b0AgAW67PxFz8etAG4aBrrcUvbSBqrVtya5sCZpK8AJYhUthTK2UJjR3
510gGAxL/OKF4g8YFHkKfAqmb+kyqwTuCqYWMvFDRgPCGCuxKaCQBCLPcc22
0UA7tmyYYOmIBGGwRtRnuw6T6VBno5573uo2EUDHe5i+xFGFhSygt5xytO/r
H67FG1ITxuPYvry9BgBn93Mak9EKZIUjK6N+N/1fo2y6pqDyZAs5r01OQZXA
Oopv58DeJwVE2EU7Uds1CljSQt2PdkO5MxR5g9PIqjm9laGsjNjTNWsDNvEL
hJDl1uvG1ahYakStUY1ucMma39pFteFGIBbVOJty0PY0oAvioxJcydu2bxjJ
abM6RHrevIfoaUo9W4r5ff1KDQupvGs8Aq6SIzgOZjo2jObgYpWFDociMaBA
YHb0rojpAPezRKip3fjATlEfuLo8NG7kXy0X30XbCM1O33rxxcxSTJ8CWcXb
6PQvuXQ2Acvrgu7NPRA9WGRIKm8DsgmC/BBZvVRsinvUlqM9zctJnbeKWAWN
niFcryduIOfRpsZEQ6TkTZ0NvI18g8l42gjZmnLAioTym2B0t5e3wBt6H0Hw
vpbG8Ayi0TomK+/RpDEZ6zRB24NGrYjjza6fuq19TQyL3zym1h0htpbR93MF
LTWWYZeVRDfK8sVwp7OurFOWo4pQVbnV7lSmNyWIzX46aeFQ4kbK5EnIvSN6
wgDXNI8mVji0beCaMYwmgKNW8rGN6I0Adw+Rafoe1WQBAhvFdUUdHrXtlMbo
J2zqpBvU5eGEoFe10WayKtoarH8Zxxvi5ZBSJuTwY/gMoAw+zXMd9iNMZrIX
vJq4YDPk2oasa0ZlPE14ZFbm0Plyzw2wJgZiYkHbHw9RBSWcbiYzMXPI4CBI
OYgLzc3ZDbUfdttcok4r2w373aJYrxORoi4AmRwvY5FOZ2rKCkpNmuYeDF53
yHuLujiUCvMGdsmJSi22Icwa9tpM2PlJGd4d+9ijIpFXtQljSspfWy+Lvi5c
pEO/RMgrddmbOUJPmyoeTTzRfvAYp2npn4urJi4vr9MAIXCy9zeXYckdIwe7
syw1077Ihi7SGKo/7bgKhDJNBXgW1YymPn2K7ybQRsfaQTi9sFRA2Q4Lfo/1
2GCih3bzrVjIjCIiMukgJjE86BS1zqx1OXFmWLBTQWQI77G4rIQyRMv9HlUJ
54wQlfx0x1PDNJtDT6+rOqWVpCpKHDU0YGnfdlQJ264tx3KSqg3HgLk4Zy1d
mIAGQ51MJjBUGk/4+GKIWDZ5sh34UTbBzumxb07IviRG2ubrzjZhQtREF0mR
moCU8Oy0rNQqQQMBE3A5HfDq6KvPn4fhgt4W0QXPQ2iw6JNn+TVlJn1kAIHm
89aMNpV/XIodst2fBJ81tD0EWEgLwsWUdbBFO7OMky9EbZiphRFPkKEdZ3pO
Ui6gMVN1fDnX5ipNt/rT0dQz9PEFDreuCgR6RpnJrRv8DtblRdO7UVRrE0bj
06Rr5LeO/zbDWBTDIAnXQ+kCFWpGCSnKDc32l/15XRgWlnvno0hLx+iwLwaq
1Bb9muTRyEr7XiluYyMmEmhA5OjU8FXkdhqEUYEzHmseGVB3kmgsLrDzvNS+
eEKYja3LnN9xijnCKmUGiUGzUV6qdmzvuuPJ0NPHl+399wuMm3OfWtjUKW7X
Kk5JdgBIVhJFPlclXPWfhS4jqjUABtmQiWwD8lBMtJ5iEZ3j7BsRIuPh1INo
Juvdpd0tiYbhEPQ8ykRgD0AAeXfq6Jj+Iiq9PwQBCOSyxfZdtuXUogzFvj8e
YrZB4UA0Za7aWsdPLUprOzFE0da+sNjLBhQYGBqRrZnsUYUJDQyibN+LfXO3
U7GOj3pFrm/g0Lt12vdo3ODylI6NyX0GmAbHFcta5yz9fvXp1egQ2/y3bdPO
n1l1kyAwbM48ya2FU0VsOPrctvMObZfdtHxrl+PA1tccdbTD/0HqFumTYRtj
9B2XTOO5Ndn4btpXtqNKzHpwUspcGoiu9uwS/LIpNPjok90w9fW+4Ky3pD5c
dml4LFXWnuvuP3tltqHXWGGwGOcOqfBSTd5/wbQ7OiABU9mKEJO6A/o1vhPh
OY2Lo8fAOHaIbOze+BXV6dtTmprxi8g4i/l0SHc/7781DxGtGPaj1ciotDrW
w/Snk/tbpl8+p7PpZRmNM8KDp9m9sZtS5cuIjJ8Od2/hyU9Tan7nVCL//dkC
XYZ6Fvf7B+/5/RMNKgAA

-->

</rfc>
