<?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-02" 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-02"/>
    <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="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="23"/>
    <area>Security</area>
    <workgroup>IETF</workgroup>
    <keyword>DDoS Detection and Mitigation</keyword>
    <abstract>
      <?line 109?>

<t>This document presents a problem statement on collaborative mitigation of Distributed Denial-of-Service (DDoS) attacks.<br/>
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 that a considerable number of attacks are spread across operators. 
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 118?>

<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:</t>
      <ul spacing="normal">
        <li>
          <t>Increase in peak and average attack traffic, reaching terabit-level peak volume.</t>
        </li>
        <li>
          <t>Rapid surge in attack traffic, capable of escalating to 800 Gbps within seconds.</t>
        </li>
        <li>
          <t>Emergence of combination attacks as the mainstream approach, where attackers employ multiple attack methods concurrently or sequentially.</t>
        </li>
        <li>
          <t>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>
        </li>
      </ul>
    </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:</t>
      <ul spacing="normal">
        <li>
          <t>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.</t>
        </li>
        <li>
          <t>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.</t>
        </li>
        <li>
          <t>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>
        </li>
      </ul>
    </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:</t>
      <ul spacing="normal">
        <li>
          <t>Attack details, including ongoing and historical attacks.</t>
        </li>
        <li>
          <t>Malicious IP addresses or URIs.</t>
        </li>
        <li>
          <t>Threat intelligence.</t>
        </li>
      </ul>
    </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:</t>
      <ul spacing="normal">
        <li>
          <t>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.</t>
        </li>
        <li>
          <t>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.</t>
        </li>
        <li>
          <t>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>
        </li>
      </ul>
    </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 220?>

<section numbered="false" anchor="Acknowledgements">
      <name>Acknowledgements</name>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9Va3XIbR3a+RxXfoVe8iK0CIJJWbArleA2RlM0NKDEkVYm9
5Uo1ZhqYXs5Mz3bPEIIUvUsu8iTJi+U7p7vnByBt71Zu4rINzKCn+/x+5ztn
OJlMDkaulmX67zI3pZqJ2jbqYKQry19dfXJ09Oro5GCUyHomdLky4lCcZSq5
x3PNstDOaVPW2wqPXl7cvTkYSavkTNyqpLG63h6MDoW/84MqlZW5+PPNxfVi
fnbxy8Fos44PHQr+XtbKlqoWF+Val0pZXa7FnXT34o2xCcQ6GKUmKWWBw1Ir
V/UkafRElrWepKlxk8qaZa6KCRSqVaHKekKSHwqzdCZXtXIz8fKb4+Mx/f8E
etyowjwooVeiNLXAgalKX9yoKpd02KFoqlTGp45+c/3BqNZ1DtGuvRjiNoox
OzN5LpfGylrj+XO1UqVTwqzE+bm5FfO6lsm9g+mWS6seZuJglMsS9lDlweh+
MzsYCTHxS8+hRVLD4gIuE1e61mtJlyQtyToTJ0cnJ1Ab/4rJhO8J7cRK57lK
4T8hm9oUeCaReb4Vy634UOQndpVErdaQENthWWYsjp4Ia0gpqG8H6vtAEdgT
BvppKs4aTZfeOz8ZeC7cMRaq3Dn4MmukeF/iAOs4NIRwtVWqZg0T3OIvVq2h
0Uy8VvovFACHfJzMN3LrhHyQGqbM+ejEpDjr+Ojo6PSlv27K2m5nCFBdSjzY
wMp3i3PxhfqQqKoW7//5S4gT17Gs9FyVcejTV1Vg/5lAXG2hwvd1EHuq0maa
lLQCYT0TWV1XsxcvNpvNNCydIm5fdOb6VWstpmLRM9ZClx8zFW6xtX6GQOt1
I8ukKcXCR46xj1pM/L0me/V/YLKexXKdf/z+4zrBSa2xfq8xfs4Q7j17KN3d
+n9lj34IfSQNcqV3jUKZxDFEiEF5G62kUg2lnjDWoQjmupyKP02up+K2sXR2
H05pjbfgqsnzx35lY76za1nqj4wb7YIX5xeLi7u4LhgVCEafTyzy5j7D/59Y
EL1ww597i570Cm/Ofrk2gPKcL54SIvrr/OL3OoseC+66po8ndg5uvKCPJ5aw
G9/fXD7yc4KiaPUSYGsp/m/JGbBqk9SNVUI64QEWaePqscA6sTbKwcW1Eb1n
nQ8Q79UzaV2tSvHa2EKWZc+lLaj+z3/V4rWloiPufr4cKJIgbb6vP+opnuiJ
T0jmAGUoAVNXhcIXT/yT3Ipzmatt7ywq2GKeFrqE6NZH0WJxNjhLfVDJJNUW
tcrY77WqV92prXYcG//hbwo+CvX7QaOmihpw+Pz5v10tnj8XrBjOQLWk26io
qLe1mvrkoX/uMlmLDWz610aj3GUqr5AAvKAkU1HRZYC4eXN2+vXxSfv99Pi4
/f7Naf/+1+33V0dfxe+vjo7+Ed+JBPV3PZtfns/5G6V24ABc+0nmy2txWxmz
0h7OaElbW/1lNPYPVHk5a0Nu95LXrwwe+EKvoRfMlCmKpXKLBPryN3c7jl9O
uu2cvzPbX0PJyfxGQFloAMRwGW/thKqT6d8iUi3tmtAkhpojeyg7TaROJQXG
C9cUhbTbaZVV8aGWzXw1OXrlUVN9kPC9ulErQNjM3xOD3UNJDguniSletMu8
X+7oQwwsS7/2XEKXk19ByvYZL+Hxq9OXk6OXFGwTEC65pKRIarq+y8C8QFgb
4oAIbuXwicwXgaeKlqcK7J8MOGLRUjumiZRqlDOw8LkqtcwnZjW5VfZBJ0p8
QdTwSyE9jZwKQUcroR5M/kDVDyBepq6lm2HdGGCT5E3KKzKlrSAWz7cBMsAS
TRdEM/0DolCwUYp7lQHMUg7AfdBDJBm4pCrXCA2gl/oAYWnTNNBctwVqFZAr
WGRfe/IX+L7jBEffYOlmfBxUOHWJrNRYZHqd5fivDjKLtGeXFDzcbL01V7uH
C5lY45x4kFabxiG2642x96SKJiM7VpS21MVS4siEwbjdBufLpc7ZKKRIj9DD
Q1AqAbTDLZwtarUikk5Mv7N3z6NjwkAHoLNeD6CXbG+xRcumWCpLegRnUQ8l
HEJIplEVUylmQcGwqjP8MJJWFklLyo7F+bu727FwmdmwF9C8KS49VgE5EZ5C
pik+XDCv23NtmZFlhEYUQ0n0EMn2957Oh8OeBfSksoEdK4NAq2E1XwBrjx2k
aI12hYygLDmrJwRcQodXlGLUwghZVTm+kFmnYphwUhcsdVAqaHSvtvCXazja
YHldoOjVwfUADXq0zbuhLmi9stLkZk1BEBMeSZDmyhcj9K/WpE3iO7KD0X7a
0qaPp63IJI5YKmCWIojAIun41AxeB0dIZMOOcYBaTbanHNHONpUPYGhqyhxp
JJw/wMd0iHREydlTAOP9QVqx9QPuk79jIKNTZA6FmPRWbLHmiYx+xPZ9N5Jg
wQnSOYPMIRNtdJ3tmDzmn1xLsN96AGCeAVBXztFbMLguQLobuVYef727oT/g
79nV+9u7Z2P/Kd6+4+83F//y/vLm4py+3/44XyzaL6Ow4vbHd+8X59237smz
d1dXF2/P/cO4Kwa3Rs+u5j898wD67N313eW7t/PFMwrgehilsDgMtVSMuxYp
TqaQbpQqlyB4fNf++uz6v//z+KX49OkPICInx8evPn8OF6fH37zExSZTpT8N
UbANlzD7doQUUdJy74+sApJpcGqCdsdQUHLNno5Gz/9MlvllJr5dJtXxy+/C
DVJ4cDPabHCTbbZ/Z+9hb8RHbj1yTGvNwf0dSw/lnf80uI5279389o+cI5Pj
0z9+xw3Yt39AFh+CVKddH/OLmEy+8zk9nNAcjOZ/SzGmyiBD4SSXwNdFk9ca
OCMy9DY+4ZgRGx7QIBKcpiWyVIA+ONLTG3ZsyHZOppjjVBTLUEly5HCtCyKe
aISs+weUCizhAtFPHMRASQGXUNYbqz9yjOFoghpIKClIiQuIpXSKAioQBI8H
aEKR06axCaF+BlgiFJnw2jEamvL+kds9KNr7tUMTyNlwOvjzcrOBcZzXvo97
HrTHAzgYACioDVCT8BImrEzV5NKOPcD45TAP212XjbcztqTuoyNDBPb6r01E
K0+KVttuRU9qQpoVPGg2Pb4FvKMypcjA7DMiZE1L6XqizyiwnqN8sNAkPfBf
3nvyhf4HeBYDClBNhXcMF8gk49OIM+h6kivgtH+Ozil8h/Rc3CDhU2L6a954
dx9mNjm3KgAcUB9Prow4PToSPywrx1bDgw6WhVph1wvU5rUiMsBlsljq0heT
lrB40C8YtyFsQaXaGgg9DpnQOYJaOrPtUmNIOMlPgRTCT+BXDoDviUO+DeKc
eVeiwKq+YKXatAq3/gQDapKMBCSTwbikcGnIeg9NXrI5PdOjw3zR1SUWhMKp
ZBmILqTW6DxhcpBXN2SMkfVycLgeG+9zwhApTKj78T2kXZER85P9ut0eQUB1
FlcFARaRNzMToUd3OXFIGFUG7syZ2FFkk3qNyI3r3IAWtxlcm4p4EJO/NyCS
ALndn4jBuMrTh7En6x1Bz42nbF1TsitbhKgc/ABW4ZIYUqxLF3pbwPtANJiW
mMYLxR8wKTIWSOWNj0Lq6aJXCiwWnM3n5IeE5nQhWkJTQGEJbF7imq2jgXts
Wz9I0gET/HyLSNC28vN0X3GDpnv+6jcRwMl7GD/HUZmBLCC6nHi07+sfrsUb
UhTmC/F9eXsNME7ulzSvojXIDUuWRi0vW44X1Y3XFFiOrCGXTZlSYEXgDgqY
JXD4SREResFS1HhNPKp0sPej2VD+jEXaYjYya0lvkyg3Awr1DduCTvgCIWS+
dbp1N6qXmlAn1KAfXAfdb82q3nBbEEpsGBNZ6Dv3KIMoqQXX9a71Gweq2q72
8Z62b1AGulLfFiN/X8Ncw0Yq7ZuPACznOA4zkp4Vg0G4dCW+36Fo9FjgeR69
5WJywD0t0WtqPj6wW9QHrjUPrSP5V8OleNW1RYv5Wye+WBiK6zkQVrwNbv+S
C2kbtLzO697eA+2DRcak8tbjmyDw97E1SMi21AdtOeLj6JrUeauIY9AUGMIN
+uIWeB5tccpgiJjAsc+Bt5FzMBkP/iBbWxZYEV+MI5ju9vNtUwyQr2RZ8hyi
1TokLO/RpjIZax4B7kGjYoRJY99P/fa+Ib7F70zjGAIhVsng+6WCltpw815I
9KYsXwh4OuvKWGU4qghblS12JzODSQG25ngNJ60sCt1ElWkUcu+IgTDANs3j
iQKHdu1cO4rRBHLUWD62EQ3nuZcIvNMNiCcL4Lkprmvq96iJp0RGd2FiX90i
L/FCWD430WayzrpKrH8by1saZpFSpc/hxzAaUOl9mqba70e4zNTPezUyw3bQ
tfVZ147LeLbwyLzMog/mDhyATUykDGVtf0REdZSQOoZlzBwyOIhSCgJDI2x2
Q+PG/aaXKFRh+mG/WxqbKhIq6gmQyeEylOp4pqasoNSkwerB6HWPyne4i0Op
PG9gl5Qo1Wrrw6zlsu2wm5+U/q23Cx0rErloSu0xEPlrmnU21CWUat8/EfZK
nQ8mj9DUxLqHiETq+rFOr8V/Lq7a2Ly8jiMFz87e31zGRXeMH+zUPNdMAQMz
uoijqeEE5MrTyzgp4PlUO6769Cm8LEBrHSoIofXKUCFla6z4xdJjw4oB5i23
YiUTiovArL2YxPagVdA8McamxKBhx14dkT7Ip+KyFqokmu72SIs/Z4LY5Kd7
/hrHeR36fF03Mbkk1VLiq74pi/t2Q0tYtzIc0VGqLig98uKcSlo/C/WGOj0+
hqHiyMKFNzXEuMmb3RCQcgp2jo99c0r2JTHiNl/3tvFTozbGSIrYEsS0Z6cl
uVYRIAielG3lenX01efPY39Br2/ogmckNGx00bP83jCRLvAAT/l5a8ac2j0u
xQ7xHs6Ez1oK7wPMJwehY8w92KKbY4ZpGKLWz9n82MfL0I04Hacql9GQrzq8
LesyliZew4lp7B+GKAOHG1tHMr2g/ORWDp4H/3Ki7eUornXpx+SzqG3gupb/
uqQ0KIpeFq6L0npK1A4YYpyXNOdfD6d4foSY752PYi0tY8S+GKhWW3Rvkgcm
hXaDktxFR0gl0IHA16n9q8nxNB6jQlc6rHlkbN1Lo6m4wM7LXLvsCWE2pslT
fu0olgismBskBk1Meanasb7tDy19nx/efw/fNQT8XLrY0sbOcVupMD3ZASFZ
S5T7VOVw1r9mOg/I1oIYpEM2shXIRyHZBqoFlA4zcUSJDIdTR6KZuPeX9rck
QoZD0AGpMgC8BwPIu1NRp/RXXfGlHqiAp5kdwu/yLqtWuS/7w7ER8w4KCCIs
S9VVPX5qlRvTiyKKt+5Fxl5GoMzA0IhtzbSP6oxvZhBn+34cmrublvV8NCh2
QwP7Pq7XzgfjRqfHlGyN7hKANfiuWDc6Zfn3a9CgXvv45r/Qm/X+WKyfCJ5t
c/ZJbjOsykLzMeS5vXdqu0yn4167fAfWvua4ox3+Dqk7vI+mbY0xdF00jeM2
ZeP6qV+bnioh88FPKXtpVFrs2cV7ZpNpcNMne2Pq813GmW9IfTjtsuRRVd44
rr6/9jJtQy+4/MgxzCFi+aXKvP/qaXeUQALG4hVgJnYK9Gt4W8KTGxuGkp53
7JDa0MmF11fzt3OapPn3kB7bPh3S3c/7r7N9VCsG/2A3MiutDnUx/gno/pbx
l8/xbHqRRuMN/+A8uS/NJlfpOuDjp8PdW3jy0yy8JlXpPz1boedQz8J+/wsh
NIP71SoAAA==

-->

</rfc>
