<?xml version="1.0" encoding="us-ascii"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 --> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY I-D.ietf-dots-use-cases SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dots-use-cases.xml">
<!ENTITY I-D.ietf-tls-dtls13 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-dtls13.xml">
<!ENTITY I-D.ietf-tram-stunbis SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tram-stunbis.xml">
<!ENTITY I-D.ietf-dots-signal-channel SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dots-signal-channel.xml">
<!ENTITY I-D.ietf-dots-data-channel SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dots-data-channel.xml">
<!ENTITY I-D.ietf-acme-ip SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-acme-ip.xml">
<!ENTITY RFC0768 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml">
<!ENTITY RFC0793 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC1035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2782 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY RFC3235 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3235.xml">
<!ENTITY RFC3261 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC4033 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4271 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4732 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4732.xml">
<!ENTITY RFC4786 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4786.xml">
<!ENTITY RFC5128 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5128.xml">
<!ENTITY RFC5246 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5780 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5780.xml">
<!ENTITY RFC6347 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC6887 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6887.xml">
<!ENTITY RFC6763 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml">
<!ENTITY RFC7092 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7092.xml">
<!ENTITY RFC7094 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7094.xml">
<!ENTITY RFC7350 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7350.xml">
<!ENTITY RFC8085 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml">
<!ENTITY RFC8446 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
<!ENTITY RFC8512 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8512.xml">
<!ENTITY RFC7658 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7658.xml">
<!ENTITY RFC8612 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8612.xml">
<!ENTITY RFC8555 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml">
]>
<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc docmapping="yes"?> "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
ipr="trust200902"
docName="draft-ietf-dots-architecture-18" category="info">
number="8811"
submissionType="IETF"
category="info"
consensus="true"
obsoletes=""
updates=""
xml:lang="en"
tocInclude="true"
sortRefs="true"
symRefs="true"
version="3">
<front>
<title abbrev="DOTS Architecture">Distributed-Denial-of-Service Architecture">DDoS Open Threat Signaling (DOTS) Architecture</title>
<seriesInfo name="RFC" value="8811"/>
<author initials="A." surname="Mortensen" fullname="Andrew Mortensen" role="editor">
<organization>Forcepoint</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<street/>
<city/>
<code/>
<country>United States</country> States of America</country>
</postal>
<email>andrewmortensen@gmail.com</email>
</address>
</author>
<author initials="T." surname="Reddy" surname="Reddy.K" fullname="Tirumaleswar Reddy" Reddy.K" role="editor">
<organization>McAfee, Inc.</organization>
<address>
<postal>
<street>Embassy Golf Link Business Park</street>
<city>Bangalore, Karnataka</city>
<city>Bangalore</city><region>Karnataka</region>
<code>560071</code>
<country>India</country>
</postal>
<email>kondtir@gmail.com</email>
</address>
</author>
<author initials="F." surname="Andreasen" fullname="Flemming Andreasen">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<street/>
<city/>
<code/>
<country>United States</country> States of America</country>
</postal>
<email>fandreas@cisco.com</email>
</address>
</author>
<author initials="N." surname="Teague" fullname="Nik Teague">
<organization>Iron Mountain</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<street/>
<city/>
<code/>
<country>United States</country> States of America</country>
</postal>
<email>nteague@ironmountain.co.uk</email>
</address>
</author>
<author initials="R." surname="Compton" fullname="Rich Compton">
<organization>Charter</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<street/>
<city/>
<code/>
</postal>
<email>Rich.Compton@charter.com</email>
</address>
</author>
<date /> year="2020" month="August"/>
<area>Security</area>
<workgroup>DOTS</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document describes an architecture for establishing and
maintaining Distributed Denial of Service 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 components, and concepts used in a DOTS
deployment.</t>
</abstract>
</front>
<middle>
<section anchor="context-and-motivation" title="Context numbered="true" toc="default">
<name>Context and Motivation"> Motivation</name>
<t>Signaling the need for help to defend against an active distributed denial
of service
denial-of-service (DDoS) attack requires a common understanding of
mechanisms and roles among the parties coordinating a defensive
response. The signaling layer and supplementary messaging is are the focus
of DDoS Open Threat Signaling (DOTS). DOTS defines a method of
coordinating defensive measures among willing peers to mitigate attacks
quickly and efficiently, enabling hybrid attack responses coordinated
locally at or near the target of an active attack, or anywhere in-path in path
between attack sources and target. Sample DOTS use cases are elaborated
in <xref target="I-D.ietf-dots-use-cases"></xref>.</t> target="I-D.ietf-dots-use-cases" format="default"/>.</t>
<t>This document describes an architecture used in establishing, maintaining
maintaining, or terminating a DOTS relationship within a domain or
between domains.</t>
<section anchor="terminology" title="Terminology"> numbered="true" toc="default">
<name>Terminology</name>
<section anchor="key-words" title="Key Words">
<t>The numbered="true" toc="default">
<name>Key Words</name>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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 "OPTIONAL"
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
only when, they appear in all capitals, as shown here.</t> here.
</t>
</section>
<section anchor="definition-of-terms" title="Definition numbered="true" toc="default">
<name>Definition of Terms"> Terms</name>
<t>This document uses the terms defined in <xref target="RFC8612"></xref>.</t> target="RFC8612" format="default"/>.</t>
</section>
</section>
<section anchor="scope" title="Scope"> numbered="true" toc="default">
<name>Scope</name>
<t>In this architecture, DOTS clients and servers communicate using
DOTS signal channel <xref target="I-D.ietf-dots-signal-channel"></xref> target="RFC8782" format="default"/> and data
channel <xref target="I-D.ietf-dots-data-channel"></xref> target="RFC8783" format="default"/> protocols.</t>
<t>The DOTS architecture presented here is applicable across network
administrative
domains – domains, for example, between an enterprise domain and
the domain of a third-party attack mitigation service – service, as well as to
a single administrative domain. DOTS is generally assumed to be most
effective when aiding coordination of attack response between two or
more participating networks, but single domain scenarios are valuable
in their own right, as when aggregating intra-domain DOTS client
signals for an inter-domain coordinated attack response.</t>
<t>This document does not address any administrative or business
agreements that may be established between involved DOTS
parties. Those considerations are out of scope. Regardless, this
document assumes necessary authentication and authorization mechanisms
are put in place so that only authorized clients can invoke the DOTS
service.</t>
<t>A detailed set of DOTS requirements are discussed in <xref target="RFC8612"></xref>,
target="RFC8612" format="default"/>, and the DOTS architecture is
designed to follow those requirements. Only new behavioral
requirements are described in this document.</t>
</section>
<section anchor="assumptions" title="Assumptions"> numbered="true" toc="default">
<name>Assumptions</name>
<t>This document makes the following assumptions:</t>
<t><list style="symbols">
<t>All
<ul spacing="normal">
<li>All domains in which DOTS is deployed are assumed to offer the
required connectivity between DOTS agents and any intermediary
network elements, but the architecture imposes no additional
limitations on the form of
connectivity.</t>
<t>Congestion connectivity.</li>
<li>Congestion and resource exhaustion are intended outcomes of a
DDoS attack <xref target="RFC4732"/>. target="RFC4732" format="default"/>. Some
operators may utilize non-impacted paths or networks for
DOTS, but
DOTS. However,
in general general, conditions should be assumed to be hostile hostile, and DOTS must
be able to function in all circumstances, including when the
signaling path is significantly impaired. Congestion control
requirements are discussed in
Section 3 of <xref target="RFC8612"></xref>. target="RFC8612"
sectionFormat="of" section="3"/>. The DOTS signal channel defined in <xref target="I-D.ietf-dots-signal-channel"></xref>
target="RFC8782" format="default"/> is designed to be extremely
resilient under extremely hostile network conditions conditions, and it
provides
continued contact between DOTS agents even as DDoS attack traffic
saturates the link.</t>
<t>There link.</li>
<li>There is no universal DDoS attack scale threshold triggering a
coordinated response across administrative domains. A network domain administrator,
administrator or service or application owner may arbitrarily set
attack scale threshold triggers, or manually send requests for mitigation.</t>
<t>Mitigation
mitigation.</li>
<li>Mitigation requests may be sent to one or more upstream DOTS
servers based on criteria determined by DOTS client administrators
and the underlying network configuration. The number of DOTS servers
with which a given DOTS client has established communications is
determined by local policy and is
deployment-specific. deployment specific. For example,
a DOTS client of a multi-homed multihomed network may support built-in policies
to establish DOTS relationships with DOTS servers located upstream
of each interconnection link.</t>
<t>The link.</li>
<li>The mitigation capacity and/or capability of domains receiving
requests for coordinated attack response is opaque to the domains
sending the request. The domain receiving the DOTS client signal may
or may not have sufficient capacity or capability to filter any or
all DDoS attack traffic directed at a target. In either case, the
upstream DOTS server may redirect a request to another DOTS
server. Redirection may be local to the redirecting DOTS server's
domain,
domain or may involve a third-party domain.</t>
<t>DOTS domain.</li>
<li>DOTS client and server signals, as well as messages sent through
the data channel, are sent across any transit networks with the same
probability of delivery as any other traffic between the DOTS client
domain and the DOTS server domain. Any encapsulation required for
successful delivery is left untouched by transit network
elements. DOTS server servers and DOTS client clients cannot assume any preferential
treatment of DOTS signals. Such preferential treatment may be
available in some deployments (e.g., intra-domain scenarios), and
the DOTS architecture does not preclude its use when
available. However, DOTS itself does not address how that may be done.</t>
<t>The
done.</li>
<li>The architecture allows for, but does not assume, the presence
of Quality of
Service Quality-of-Service (QoS) policy agreements between DOTS-enabled
peer networks or local QoS prioritization aimed at ensuring delivery
of DOTS messages between DOTS agents. QoS is an operational
consideration only, not a functional part of the DOTS architecture.</t>
<t>The
architecture.</li>
<li>The signal and data channels are loosely coupled, coupled and might not
terminate on the same DOTS server. How the DOTS servers synchronize
the DOTS configuration is out of scope of this specification. </t>
</list></t> </li>
</ul>
</section>
</section>
<section anchor="architecture" title="DOTS Architecture"> numbered="true" toc="default">
<name>DOTS Architecture</name>
<t>The basic high-level DOTS architecture is illustrated in <xref target="fig-basic-arch"/>:</t> target="fig-basic-arch" format="default"/>:</t>
<figure title="Basic anchor="fig-basic-arch">
<name>Basic DOTS Architecture" anchor="fig-basic-arch"><artwork><![CDATA[ Architecture</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-----------+ +-------------+
| Mitigator | ~~~~~~~~~~ | DOTS Server |
+-----------+ +-------------+
|
|
|
+---------------+ +-------------+
| Attack Target | ~~~~~~ | DOTS Client |
+---------------+ +-------------+
]]></artwork></figure>
]]></artwork>
</figure>
<t>A simple example instantiation of the DOTS architecture could be an
enterprise as the attack target for a volumetric DDoS attack, attack and an
upstream DDoS mitigation service as the mitigator. The service provided
by the mitigator is called: DDoS called "DDoS mitigation service. service". The enterprise
(attack target) is connected to the Internet via a link that is getting
saturated, and the enterprise suspects it is under DDoS attack.
The enterprise has a DOTS client, which obtains information about the
DDoS attack, attack and signals the DOTS server for help in mitigating the
attack. The In turn, the DOTS server in turn invokes one or more mitigators, which
are tasked with mitigating the actual DDoS attack, and hence attack and, hence, aim to
suppress the attack traffic while allowing valid traffic to reach the
attack target.</t>
<t>The scope of the DOTS specifications is the interfaces between the
DOTS client and DOTS server. The interfaces to the attack target and the
mitigator are out of scope of DOTS. Similarly, the operation of both the
attack target and the mitigator is out of scope of DOTS. Thus, DOTS
specifies neither how an attack target decides it is under DDoS attack, attack
nor does DOTS specify how a mitigator may actually mitigate such an
attack. A DOTS client's request for mitigation is advisory in nature, nature
and might not lead to any mitigation at all, depending on the DOTS
server domain's capacity and willingness to mitigate on behalf of the
DOTS client domain.</t>
<t>The DOTS client may be provided with a list of DOTS servers, each
associated with one or more IP addresses. These addresses may or may not
be of the same address family. The DOTS client establishes one or more
sessions by connecting to the provided DOTS server addresses.</t>
<t>As illustrated in <xref target="fig-interfaces"/>, target="fig-interfaces" format="default"/>,
there are two interfaces between a DOTS server and a DOTS client; client: a
signal channel and (optionally) a data channel.</t>
<figure title="DOTS Interfaces" anchor="fig-interfaces"><artwork><![CDATA[ anchor="fig-interfaces">
<name>DOTS Interfaces</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---------------+ +---------------+
| | <------- Signal Channel ------> | |
| DOTS Client | | DOTS Server |
| | <======= Data Channel ======> | |
+---------------+ +---------------+
]]></artwork></figure>
]]></artwork>
</figure>
<t>The primary purpose of the signal channel is for a DOTS client to ask
a DOTS server for help in mitigating an attack, attack and for the DOTS server
to inform the DOTS client about the status of such mitigation. The DOTS
client does this by sending a client signal, which signal that contains information
about the attack target(s). The client signal may also include telemetry
information about the attack, if the DOTS client has such information
available. The In turn, the DOTS server in
turn sends a server signal to inform the
DOTS client of whether it will honor the mitigation request. Assuming it
will, the DOTS server initiates attack
mitigation, mitigation and periodically
informs the DOTS client about the status of the mitigation. Similarly,
the DOTS client periodically informs the DOTS server about the client's
status, which which, at a minimum minimum, provides client (attack target) health information, but
information; it should also include efficacy information about the
attack mitigation as it is now seen by the client. At some point, the
DOTS client may decide to terminate the server-side attack mitigation,
which it indicates to the DOTS server over the signal channel. A
mitigation may also be terminated if a DOTS client-specified mitigation
lifetime is exceeded. Note that the signal channel may need to operate
over a link that is experiencing a DDoS attack and hence and, hence, is subject to
severe packet loss and high latency.</t>
<t>While DOTS is able to request mitigation with just the signal
channel, the addition of the DOTS data channel provides for additional and additional,
more efficient capabilities. The primary purpose of the data channel is
to support DOTS related DOTS-related configuration and policy information exchange
between the DOTS client and the DOTS server. Examples of such
information include, but are not limited to:</t>
<t><list style="symbols">
<t>Creating
<ul spacing="normal">
<li>Creating identifiers, such as names or aliases, for resources for
which mitigation may be requested. Such identifiers may then be used
in subsequent signal channel exchanges to refer more efficiently to
the resources under attack. </t>
</list></t>
<t><list style="symbols">
<t>Drop-list </li>
</ul>
<ul spacing="normal">
<li>Drop-list management, which enables a DOTS client to inform the
DOTS server about sources to suppress.</t>
<t>Accept-list suppress.</li>
<li>Accept-list management, which enables a DOTS client to inform the
DOTS server about sources from which traffic is always accepted.</t>
<t>Filter accepted.</li>
<li>Filter management, which enables a DOTS client to install or
remove traffic filters dropping or rate-limiting unwanted traffic.</t>
<t>DOTS
traffic.</li>
<li>DOTS client provisioning.</t>
</list></t> provisioning.</li>
</ul>
<t>Note that that, while it is possible to exchange the above information
before, during during, or after a DDoS attack, DOTS requires reliable delivery
of this information and does not provide any special means for ensuring
timely delivery of it during an attack. In practice, this means that
DOTS deployments should rely on such information being exchanged only
under normal traffic conditions.</t>
<section anchor="operations" title="DOTS Operations"> numbered="true" toc="default">
<name>DOTS Operations</name>
<t>DOTS does not prescribe any specific deployment models, however models; however,
DOTS is designed with some specific requirements around the different
DOTS agents and their relationships.</t>
<t>First of all, a DOTS agent belongs to a domain that has an identity which
that can be authenticated and authorized. DOTS agents communicate
with each other over a mutually authenticated signal channel and
(optionally) data channel. However, before they can do so, a service
relationship needs to be established between them. The details and
means by which this is done is outside the scope of DOTS,
however DOTS; however, an
example would be for an enterprise A (DOTS client) to sign up for DDoS
service from provider B (DOTS server). This would establish a
(service) relationship between the two that enables enterprise A's
DOTS client to establish a signal channel with provider B's DOTS
server. A and B will authenticate each other, and B can verify that A
is authorized for its service.</t>
<t>From an operational and design point of view, DOTS assumes that the
above relationship is established prior to a request for DDoS attack
mitigation. In particular, it is assumed that bi-directional bidirectional
communication is possible at this time between the DOTS client and
DOTS server. Furthermore, it is assumed that additional service
provisioning, configuration configuration, and information exchange can be performed
by use of the data channel, channel if operationally required. It is not until
this point that the mitigation service is available for use.</t>
<t>Once the mutually authenticated signal channel has been
established, it will remain active. This is done to increase the
likelihood that the DOTS client can signal the DOTS server for help
when the attack target is being flooded, and similarly raise the
probability that DOTS server signals reach the client regardless of
inbound link congestion. This does not necessarily imply that the
attack target and the DOTS client have to be co-located in the same
administrative domain, but it is expected to be a common scenario.</t>
<t>DDoS mitigation with the help of an upstream mitigator may involve
some form of traffic redirection whereby traffic destined for the
attack target is steered towards the mitigator. Common mechanisms to
achieve this redirection depend on BGP <xref target="RFC4271"></xref> target="RFC4271"
format="default"/> and DNS <xref target="RFC1035"></xref>. The target="RFC1035"
format="default"/>. In turn, the mitigator in turn inspects and scrubs the traffic,
traffic and forwards the resulting (hopefully non-attack) traffic to
the attack target. Thus, when a DOTS server receives an attack
mitigation request from a DOTS client, it can be viewed as a way of
causing traffic redirection for the attack target indicated.</t>
<t>DOTS relies on mutual authentication and the pre-established
service relationship between the DOTS client domain and the DOTS
server domain to provide authorization. The DOTS server should enforce
authorization mechanisms to restrict the mitigation scope a DOTS
client can request, but such authorization mechanisms are deployment-specific.</t>
deployment specific.</t>
<t>Although co-location of DOTS server and mitigator within the same
domain is expected to be a common deployment model, it is assumed that
operators may require alternative models. Nothing in this document
precludes such alternatives.</t>
</section>
<section anchor="components" title="Components"> numbered="true" toc="default">
<name>Components</name>
<section anchor="dots-client" title="DOTS Client"> numbered="true" toc="default">
<name>DOTS Client</name>
<t>A DOTS client is a DOTS agent from which requests for help
coordinating an attack response originate. The requests may be in
response to an active, ongoing attack against a target in the DOTS
client domain, but no active attack is required for a DOTS client to
request help. Operators may wish to have upstream mitigators in the
network path for an indefinite period, period and are restricted only by
business relationships when it comes to duration and scope of
requested mitigation.</t>
<t>The DOTS client requests attack response coordination from a DOTS
server over the signal channel, including in the request the DOTS
client's desired mitigation scoping, as described in <xref target="RFC8612"></xref>
target="RFC8612" format="default"/> (SIG-008). The actual mitigation
scope and countermeasures used in response to the attack are up to
the DOTS server and mitigator operators, as the DOTS client may have
a narrow perspective on the ongoing attack. As such, the DOTS
client's request for mitigation should be considered advisory:
guarantees of DOTS server availability or mitigation capacity
constitute service level agreements Service Level Agreements (SLAs) and are out of scope for this
document.</t>
<t>The DOTS client adjusts mitigation scope and provides available
mitigation feedback (e.g., mitigation efficacy) at the direction of
its local administrator. Such direction may involve manual or
automated adjustments in response to updates from the DOTS
server.</t>
<t>To provide a metric of signal health and distinguish an idle
signal channel from a disconnected or defunct session, the DOTS
client sends a heartbeat over the signal channel to maintain its
half of the channel. The DOTS client similarly expects a heartbeat
from the DOTS server, server and may consider a session terminated in the
extended absence of a DOTS server heartbeat.</t>
</section>
<section anchor="dots-server" title="DOTS Server"> numbered="true" toc="default">
<name>DOTS Server</name>
<t>A DOTS server is a DOTS agent capable of receiving, processing processing,
and possibly acting on requests for help coordinating attack response
responses from DOTS clients. The DOTS server authenticates and
authorizes DOTS clients as described in <xref target="dots-sessions"/>, target="dots-sessions"
format="default"/> and maintains session state, tracking tracks requests
for mitigation, reporting reports on the status of active mitigations, and terminating
terminates sessions in the extended absence of a client heartbeat
or when a session times out.</t>
<t>Assuming the preconditions discussed below exist, a DOTS client
maintaining an active session with a DOTS server may reasonably
expect some level of mitigation in response to a request for
coordinated attack response.</t>
<t>For a given DOTS client (administrative) domain, the DOTS server
needs to be able to determine whether a given resource is in that
domain. For example, this could take the form of associating a set
of IP addresses and/or prefixes per DOTS client domain. The DOTS
server enforces authorization of signals for mitigation, filtering rules
rules, and aliases for resources from DOTS clients. The mechanism of
enforcement is not in scope for this
document, document but is expected to
restrict mitigation requests, filtering rules and rules, aliases
scope to addresses, for addresses
and prefixes, and/or services owned by the DOTS client domain, such
that a DOTS client from one domain is not able to influence the
network path to another domain. A DOTS server MUST <bcp14>MUST</bcp14>
reject mitigation requests, filtering rules rules, and aliases for
resources not owned by the requesting DOTS client's administrative
domain. The exact mechanism for the DOTS servers to validate that
the resources are within the scope of the DOTS client domain is deployment-specific.
deployment specific. For example, if the DOTS client domain uses
Provider-Aggregatable prefixes for its resources and leverages the
DDoS mitigation service of the Internet Transit Provider (ITP), (ITP); the
ITP knows the prefixes assigned to the DOTS client domain because
they are assigned by the ITP itself. However, if the DDoS Mitigation
is offered by a
third party third-party DDoS mitigation service provider, provider; it
does not know the resources owned by the DOTS client domain. The
DDoS mitigation service provider and the DOTS client domain can opt
to use the identifier validation challenges discussed in <xref target="RFC8555"/>
target="RFC8555" format="default"/> and <xref target="I-D.ietf-acme-ip"></xref> target="RFC8738"
format="default"/> to identify whether or not the DOTS client domain
actually controls the resources. The challenges for validating
control of resources must be performed when no attack traffic is
present and works only for "dns" and "ip" identifier types. Further,
if the DOTS client lies about the resources owned by the DOTS client
domain, the DDoS mitigation service provider can impose penalties
for violating the service level agreement. SLA. A DOTS server MAY <bcp14>MAY</bcp14> also refuse
a DOTS client's mitigation request for arbitrary reasons, within any
limits imposed by business or service level agreements SLAs between client and server
domains. If a DOTS server refuses a DOTS client's request for
mitigation, the DOTS server MUST <bcp14>MUST</bcp14> include the refusal
reason in the server signal sent to the client.</t>
<t>A DOTS server is in regular contact with one or more
mitigators. If a DOTS server accepts a DOTS client's request for
help, the DOTS server forwards a translated form of that request to
the mitigator(s) responsible for scrubbing attack traffic. Note that
the form of the translated request passed from the DOTS server to
the mitigator is not in scope: scope; it may be as simple as an alert to
mitigator operators, or highly automated using vendor or open
application programming interfaces supported by the mitigator. The
DOTS server MUST <bcp14>MUST</bcp14> report the actual scope of any
mitigation enabled on behalf of a client.</t>
<t>The DOTS server SHOULD <bcp14>SHOULD</bcp14> retrieve available metrics
for any mitigations activated on behalf of a DOTS client, client and SHOULD
<bcp14>SHOULD</bcp14> include them in server signals sent to the
DOTS client originating the request for mitigation.</t>
<t>To provide a metric of signal health and distinguish an idle
signal channel from a disconnected or defunct channel, the DOTS
server MUST <bcp14>MUST</bcp14> send a heartbeat over the signal channel
to maintain its half of the channel. The DOTS server similarly
expects a heartbeat from the DOTS client, client and MAY <bcp14>MAY</bcp14>
consider a session terminated in the extended absence of a DOTS
client heartbeat.</t>
</section>
<section anchor="dots-gateway" title="DOTS Gateway"> numbered="true" toc="default">
<name>DOTS Gateway</name>
<t>Traditional client/server relationships may be expanded by
chaining DOTS sessions. This chaining is enabled through "logical
concatenation" of a DOTS server and a DOTS client, resulting in an
application analogous to the Session Initiation Protocol (SIP) <xref target="RFC3261"/>
target="RFC3261" format="default"/> logical entity of a Back-to-Back
User Agent (B2BUA) <xref target="RFC7092"></xref>. target="RFC7092" format="default"/>. The
term DOTS gateway "DOTS gateway" is used here in the descriptions of selected
scenarios involving this application.</t>
<t>A DOTS gateway may be deployed client-side, server-side client side, server side, or both.
The gateway may terminate multiple discrete client connections and
may aggregate these into a single or multiple DOTS sessions.</t> session(s).</t>
<t>The DOTS gateway will appear as a server to its downstream agents
and as a client to its upstream agents, a functional concatenation
of the DOTS client and server roles, as depicted in <xref target="fig-dots-gateway"/>:</t>
target="fig-dots-gateway" format="default"/>:</t>
<figure title="DOTS gateway" anchor="fig-dots-gateway"><artwork><![CDATA[ anchor="fig-dots-gateway">
<name>DOTS Gateway</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-------------+
| | D | |
+----+ | | O | | +----+
| c1 |----------| s1 | T | c2 |---------| s2 |
+----+ | | S | | +----+
| | G | |
+-------------+
]]></artwork></figure>
]]></artwork>
</figure>
<t>The DOTS gateway MUST <bcp14>MUST</bcp14> perform full stack DOTS
session termination and reorigination between its client and server
side. The details of how this is achieved are implementation
specific. </t>
</section>
</section>
<section anchor="agent-relationships" title="DOTS numbered="true" toc="default">
<name>DOTS Agent Relationships"> Relationships</name>
<t>So far, we have only considered a relatively simple scenario of a
single DOTS client associated with a single DOTS server, however server; however, DOTS
supports more advanced relationships.</t>
<t>A DOTS server may be associated with one or more DOTS clients, and those DOTS
clients may belong to different domains. An example scenario is a mitigation
provider serving multiple attack targets (<xref target="fig-multi-client-server"/>).</t> target="fig-multi-client-server" format="default"/>).</t>
<figure title="DOTS server anchor="fig-multi-client-server">
<name>DOTS Server with multiple clients" anchor="fig-multi-client-server"><artwork><![CDATA[ Multiple Clients</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
DOTS clients DOTS server
+---+
| c |-----------
+---+ \
c1.example.org \
\
+---+ \ +---+
| c |----------------| S |
+---+ / +---+
c1.example.com / dots1.example.net
/
+---+ /
| c |-----------
+---+
c2.example.com
]]></artwork></figure>
]]></artwork>
</figure>
<t>A DOTS client may be associated with one or more DOTS servers, and those DOTS
servers may belong to different domains. This may be to ensure high
availability or co-ordinate coordinate mitigation with more than one directly connected
ISP. An example scenario is for an enterprise to have DDoS mitigation service
from multiple providers, as shown in <xref target="fig-multi-homed-client"/>.</t> target="fig-multi-homed-client" format="default"/>.</t>
<figure title="Multi-Homed anchor="fig-multi-homed-client">
<name>Multihomed DOTS Client" anchor="fig-multi-homed-client"><artwork><![CDATA[ Client</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
DOTS client DOTS servers
+---+
-----------| S |
/ +---+
/ dots1.example.net
/
+---+/ +---+
| c |---------------| S |
+---+\ +---+
\ dots.example.org
\
\ +---+
-----------| S |
+---+
c.example.com dots2.example.net
]]></artwork></figure>
]]></artwork>
</figure>
<t>Deploying a multi-homed multihomed client requires extra care and planning, as the DOTS
servers with which the multi-homed multihomed client communicates might not be affiliated.
Should the multi-homed multihomed client simultaneously request for mitigation from all
servers with which it has established signal channels, the client may
unintentionally inflict additional network disruption on the resources it
intends to protect. In one of the worst cases, a multi-homed multihomed DOTS client could
cause a permanent routing loop of traffic destined for the client's
protected services, as the uncoordinated DOTS servers' mitigators all try to
divert that traffic to their own scrubbing centers.</t>
<t>The DOTS protocol itself provides no fool-proof method to prevent such
self-inflicted harms as a result of deploying multi-homed multihomed DOTS clients. If
DOTS client implementations nevertheless include support for multi-homing, multihoming, they
are expected to be aware of the risks, and consequently to include measures
aimed at reducing the likelihood of negative outcomes. Simple measures might
include:</t>
<t><list style="symbols">
<t>Requesting
<ul spacing="normal">
<li>Requesting mitigation serially, ensuring only one mitigation request for
a given address space is active at any given time;</t>
<t>Dividing time;</li>
<li>Dividing the protected resources among the DOTS servers, such that no two
mitigators will be attempting to divert and scrub the same traffic;</t>
<t>Restricting multi-homing traffic;</li>
<li>Restricting multihoming to deployments in which all DOTS servers are
coordinating management of a shared pool of mitigation resources.</t>
</list></t> resources.</li>
</ul>
<section anchor="gatewayed-signaling" title="Gatewayed Signaling"> numbered="true" toc="default">
<name>Gatewayed Signaling</name>
<t>As discussed in <xref target="dots-gateway"/>, target="dots-gateway" format="default"/>, a
DOTS gateway is a logical function chaining DOTS sessions through
concatenation of a DOTS server and DOTS client.</t>
<t>An example scenario, as shown in <xref target="fig-client-gateway-agg"/>
target="fig-client-gateway-agg" format="default"/> and <xref target="fig-client-gateway-noagg"/>,
target="fig-client-gateway-noagg" format="default"/>, is for an
enterprise to have deployed multiple
DOTS capable DOTS-capable devices which that are
able to signal intra-domain using TCP <xref target="RFC0793"></xref> target="RFC0793"
format="default"/> on un-congested uncongested links to a DOTS gateway which that may
then transform these to a UDP <xref target="RFC0768"></xref> target="RFC0768"
format="default"/> transport inter-domain where connection oriented connection-oriented
transports may degrade; this applies to the signal channel only, as
the data channel requires a connection-oriented transport. The
relationship between the gateway and its upstream agents is opaque
to the initial clients.</t>
<figure title="Client-Side anchor="fig-client-gateway-agg">
<name>Client-Side Gateway with Aggregation" anchor="fig-client-gateway-agg"><artwork><![CDATA[ Aggregation</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---+
| c |\
+---+ \ +---+
\-----TCP-----| D | +---+
+---+ | O | | |
| c |--------TCP-----| T |------UDP------| S |
+---+ | S | | |
/-----TCP-----| G | +---+
+---+ / +---+
| c |/
+---+
example.com example.com example.net
DOTS clients DOTS gateway (DOTSG) DOTS server
]]></artwork></figure>
]]></artwork>
</figure>
<figure title="Client-Side anchor="fig-client-gateway-noagg">
<name>Client-Side Gateway without Aggregation" anchor="fig-client-gateway-noagg"><artwork><![CDATA[ Aggregation</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---+
| c |\
+---+ \ +---+
\-----TCP-----| D |------UDP------+---+
+---+ | O | | |
| c |--------TCP-----| T |------UDP------| S |
+---+ | S | | |
/-----TCP-----| G |------UDP------+---+
+---+ / +---+
| c |/
+---+
example.com example.com example.net
DOTS clients DOTS gateway (DOTSG) DOTS server
]]></artwork></figure>
]]></artwork>
</figure>
<t>This may similarly be deployed in the inverse scenario where the gateway resides
in the server-side domain and may be used to terminate and/or aggregate multiple
clients to a single transport as shown in figures <xref target="fig-server-gateway-agg"/> target="fig-server-gateway-agg" format="default"/> and
<xref target="fig-server-gateway-noagg"/>.</t> target="fig-server-gateway-noagg" format="default"/>.</t>
<figure title="Server-Side anchor="fig-server-gateway-agg">
<name>Server-Side Gateway with Aggregation" anchor="fig-server-gateway-agg"><artwork><![CDATA[ Aggregation</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---+
| c |\
+---+ \ +---+
\-----UDP-----| D | +---+
+---+ | O | | |
| c |--------TCP-----| T |------TCP------| S |
+---+ | S | | |
/-----TCP-----| G | +---+
+---+ / +---+
| c |/
+---+
example.com example.net example.net
DOTS clients DOTS gateway (DOTSG) DOTS server
]]></artwork></figure>
]]></artwork>
</figure>
<figure title="Server-Side anchor="fig-server-gateway-noagg">
<name>Server-Side Gateway without Aggregation" anchor="fig-server-gateway-noagg"><artwork><![CDATA[ Aggregation</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---+
| c |\
+---+ \ +---+
\-----UDP-----| D |------TCP------+---+
+---+ | O | | |
| c |--------TCP-----| T |------TCP------| S |
+---+ | S | | |
/-----UDP-----| G |------TCP------+---+
+---+ / +---+
| c |/
+---+
example.com example.net example.net
DOTS clients DOTS gateway (DOTSG) DOTS server
]]></artwork></figure>
]]></artwork>
</figure>
<t>This document anticipates scenarios involving multiple DOTS gateways. An example
is a DOTS gateway at the network client's side, side and another one at the server
side. The first gateway can be located at a Customer Premises Equipment (CPE) to aggregate requests from
multiple DOTS clients enabled in an enterprise network. The second DOTS gateway
is deployed on the provider side. This scenario can be seen as a combination of
the client-side and server-side scenarios.</t>
</section>
</section>
</section>
<section anchor="concepts" title="Concepts"> numbered="true" toc="default">
<name>Concepts</name>
<section anchor="dots-sessions" title="DOTS Sessions"> numbered="true" toc="default">
<name>DOTS Sessions</name>
<t>In order for DOTS to be effective as a vehicle for DDoS mitigation
requests, one or more DOTS clients must establish ongoing
communication with one or more DOTS servers. While the preconditions
for enabling DOTS in or among network domains may also involve
business relationships, service level agreements, SLAs, or other formal or
informal understandings between network operators, such considerations
are out of scope for this document.</t>
<t>A DOTS session is established to support bilateral exchange of data
between an associated DOTS client and a DOTS server. In the DOTS
architecture, data is exchanged between DOTS agents over signal and
data channels. As such, a DOTS session can be a DOTS signal channel
session, a DOTS data channel session, or both. The DOTS server couples
the DOTS signal and data channel sessions using the DOTS client
identity. The DOTS session is further elaborated in the DOTS signal
channel protocol defined in <xref target="I-D.ietf-dots-signal-channel"></xref> target="RFC8782" format="default"/>
and the DOTS data channel protocol defined in <xref target="I-D.ietf-dots-data-channel"></xref>.</t> target="RFC8783"
format="default"/>.</t>
<t>A DOTS agent can maintain one or more DOTS sessions.</t>
<t>A DOTS signal channel session is associated with a single transport
connection (TCP or UDP session) and an a security association (a TLS or
DTLS session). Similarly, a DOTS data channel session is associated
with a single TCP connection and an a TLS security association.</t>
<t>Mitigation requests created using the DOTS signal channel are not bound
to the DOTS signal channel session. Instead, mitigation requests are
associated with a DOTS client and can be managed using different DOTS
signal channel sessions.</t>
<section anchor="dots-session-preconditions" title="Preconditions"> numbered="true" toc="default">
<name>Preconditions</name>
<t>Prior to establishing a DOTS session between agents, the owners
of the networks, domains, services or applications involved are
assumed to have agreed upon the terms of the relationship
involved. Such agreements are out of scope for this
document, document but
must be in place for a functional DOTS architecture.</t>
<t>It is assumed that that, as part of any DOTS service agreement, the
DOTS client is provided with all data and metadata required to
establish communication with the DOTS server. Such data and metadata
would include any cryptographic information necessary to meet the
message confidentiality, integrity integrity, and authenticity requirement
(SEC-002) in <xref target="RFC8612"></xref>, target="RFC8612" format="default"/> and might
also include the pool of DOTS server addresses and ports the DOTS
client should use for signal and data channel messaging.</t>
</section>
<section anchor="establishing-dots-session" title="Establishing numbered="true" toc="default">
<name>Establishing the DOTS Session"> Session</name>
<t>With the required business agreements in place, the DOTS client
initiates a DOTS session by contacting its DOTS server(s) over the
signal channel and (possibly) the data channel. To allow for DOTS
service flexibility, neither the order of contact nor the time
interval between channel creations is specified. A DOTS client MAY
<bcp14>MAY</bcp14> establish the signal channel first, and then the
data channel, or vice versa.</t>
<t>The methods by which a DOTS client receives the address and
associated service details of the DOTS server are not prescribed by
this document. For example, a DOTS client may be directly configured
to use a specific DOTS server IP address and port, and be directly
provided with any data necessary to satisfy the Peer Mutual
Authentication requirement (SEC-001) in <xref target="RFC8612"></xref>, target="RFC8612"
format="default"/>, such as symmetric or asymmetric keys, usernames and usernames,
passwords, etc. All configuration and authentication information
in this scenario is provided out-of-band out of band by the domain operating the
DOTS server.</t>
<t>At the other extreme, the architecture in this document allows
for a form of DOTS client auto-provisioning. For example, the domain
operating the DOTS server or servers might provide the client domain
only with symmetric or asymmetric keys to authenticate the
provisioned DOTS clients. Only the keys would then be directly
configured on DOTS clients, but the remaining configuration required
to provision the DOTS clients could be learned through mechanisms
similar to DNS SRV <xref target="RFC2782"/> target="RFC2782" format="default"/> or DNS
Service Discovery <xref target="RFC6763"/>.</t> target="RFC6763" format="default"/>.</t>
<t>The DOTS client SHOULD <bcp14>SHOULD</bcp14> successfully authenticate
and exchange messages with the DOTS server over both the signal and (if
used) data channel as soon as possible to confirm that both channels
are operational.</t>
<t>As described in <xref target="RFC8612"></xref> target="RFC8612" format="default"/>
(DM-008), the DOTS client can configure preferred values for
acceptable signal loss, mitigation lifetime, and heartbeat intervals
when establishing the DOTS signal channel session. A DOTS signal
channel session is not active until DOTS agents have agreed on the
values for these DOTS session parameters, a process defined by the
protocol.</t>
<t>Once the DOTS client begins receiving DOTS server signals, the
DOTS session is active. At any time during the DOTS session, the
DOTS client may use the data channel to manage aliases, manage drop-
and accept-listed prefixes or addresses, leverage vendor-specific
extensions, and so on. Note that unlike the signal channel, there is
no requirement that the data channel remains operational in attack conditions
conditions. (See Data "Data Channel Requirements, Section 2.3 of Requirements" <xref target="RFC8612"></xref>).</t>
target="RFC8612" sectionFormat="of" section="2.3"/>).</t>
</section>
<section anchor="maintaining-dots-session" title="Maintaining numbered="true" toc="default">
<name>Maintaining the DOTS Session"> Session</name>
<t>DOTS clients and servers periodically send heartbeats to each
other over the signal channel, discussed in <xref target="RFC8612"></xref> target="RFC8612"
format="default"/> (SIG-004). DOTS agent operators SHOULD
<bcp14>SHOULD</bcp14> configure the heartbeat interval such that the
frequency does not lead to accidental denials of service due to the
overwhelming number of heartbeats a DOTS agent must field.</t>
<t>Either DOTS agent may consider a DOTS signal channel session
terminated in the extended absence of a heartbeat from its peer
agent. The period of that absence will be established in the
protocol definition.</t>
</section>
</section>
<section anchor="modes-of-signaling" title="Modes numbered="true" toc="default">
<name>Modes of Signaling"> Signaling</name>
<t>This section examines the modes of signaling between agents in a DOTS
architecture.</t>
<section anchor="direct-signaling" title="Direct Signaling"> numbered="true" toc="default">
<name>Direct Signaling</name>
<t>A DOTS session may take the form of direct signaling between the DOTS
clients and servers, as shown in <xref target="fig-direct-signaling"/>.</t> target="fig-direct-signaling" format="default"/>.</t>
<figure title="Direct Signaling" anchor="fig-direct-signaling"><artwork><![CDATA[ anchor="fig-direct-signaling">
<name>Direct Signaling</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-------------+ +-------------+
| DOTS client |<------signal session------>| DOTS server |
+-------------+ +-------------+
]]></artwork></figure>
]]></artwork>
</figure>
<t>In a direct DOTS session, the DOTS client and server are
communicating directly. Direct signaling may exist inter- or
intra-domain. The DOTS session is abstracted from the underlying
networks or network elements the signals
traverse: traverse; in direct
signaling, the DOTS client and server are logically adjacent.</t>
</section>
<section anchor="redirected-signaling" title="Redirected Signaling"> numbered="true" toc="default">
<name>Redirected Signaling</name>
<t>In certain circumstances, a DOTS server may want to redirect a DOTS client to
an alternative DOTS server for a DOTS signal channel session. Such
circumstances include but are not limited to:</t>
<t><list style="symbols">
<t>Maximum
<ul spacing="normal">
<li>Maximum number of DOTS signal channel sessions with clients has been reached;</t>
<t>Mitigation reached;</li>
<li>Mitigation capacity exhaustion in the mitigator with which the
specific DOTS server is communicating;</t>
<t>Mitigator communicating;</li>
<li>Mitigator outage or other downtime, downtime such as scheduled maintenance;</t>
<t>Scheduled maintenance;</li>
<li>Scheduled DOTS server maintenance;</t>
<t>Scheduled maintenance;</li>
<li>Scheduled modifications to the network path between DOTS server and DOTS
client.</t>
</list></t>
client.</li>
</ul>
<t>A basic redirected DOTS signal channel session resembles the following, as
shown in <xref target="fig-redirected-signaling"/>.</t> target="fig-redirected-signaling" format="default"/>.</t>
<figure title="Redirected Signaling" anchor="fig-redirected-signaling"><artwork><![CDATA[ anchor="fig-redirected-signaling">
<name>Redirected Signaling</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-------------+ +---------------+
| |<-(1)--- DOTS signal ------>| |
| | channel session 1 | |
| |<=(2)== redirect to B ======| |
| DOTS client | | DOTS server A |
| |X-(4)--- DOTS signal ------X| |
| | channel session 1 | |
| | | |
+-------------+ +---------------+
^
|
(3) DOTS signal channel
| session 2
v
+---------------+
| DOTS server B |
+---------------+
]]></artwork></figure>
<t><list style="numbers">
<t>Previously
]]></artwork>
</figure>
<ol spacing="normal" type="1">
<li>Previously established DOTS signal channel session 1 exists between a DOTS
client and DOTS server A.</t>
<t>DOTS A.</li>
<li>DOTS server A sends a server signal redirecting the client to DOTS server B.</t>
<t>If B.</li>
<li>If the DOTS client does not already have a separate DOTS signal channel
session with the redirection target, the DOTS client initiates and
establishes DOTS signal channel session 2 with DOTS server B.</t>
<t>Having B.</li>
<li>Having redirected the DOTS client, DOTS server A ceases sending server
signals. The DOTS client likewise stops sending client signals to DOTS server
A. DOTS signal channel session 1 is terminated.</t>
</list></t> terminated.</li>
</ol>
</section>
<section anchor="recursive-signaling" title="Recursive Signaling"> numbered="true" toc="default">
<name>Recursive Signaling</name>
<t>DOTS is centered around improving the speed and efficiency of
a coordinated response to DDoS attacks. One scenario not yet discussed
involves coordination among federated domains operating DOTS servers
and mitigators.</t>
<t>In the course of normal DOTS operations, a DOTS client communicates the need for
mitigation to a DOTS server, and that server initiates mitigation on a
mitigator with which the server has an established service relationship. The
operator of the mitigator may in turn monitor mitigation performance and
capacity, as the attack being mitigated may grow in severity beyond the
mitigating domain's capabilities.</t>
<t>The operator of the mitigator has limited options in the event a DOTS
client-requested mitigation is being overwhelmed by the severity of the attack.
Out-of-scope business or service level agreements SLAs may permit the mitigating
domain to drop the mitigation and let attack traffic flow unchecked to the
target, but this only encourages attack escalation. In the case where
the mitigating domain is the upstream service provider for the attack target,
this may mean the mitigating domain and its other services and users continue to
suffer the incidental effects of the attack.</t>
<t>A recursive signaling model as shown in <xref target="fig-recursive-signaling"/> target="fig-recursive-signaling" format="default"/> offers
an alternative. In a variation of the use case "Upstream DDoS Mitigation by an
Upstream Internet Transit Provider" described in <xref target="I-D.ietf-dots-use-cases"></xref>, target="I-D.ietf-dots-use-cases" format="default"/>, a
domain operating a DOTS server and mitigator also operates a DOTS client. This
DOTS client has an established DOTS session with a DOTS server belonging to a
separate administrative domain.</t>
<t>With these preconditions in place, the operator of the mitigator being
overwhelmed or otherwise performing inadequately may request mitigation for the
attack target from this separate DOTS-aware domain. Such a request recurses the
originating mitigation request to the secondary DOTS server, server in the hope of
building a cumulative mitigation against the attack.</t>
<figure title="Recursive Signaling" anchor="fig-recursive-signaling"><artwork><![CDATA[ anchor="fig-recursive-signaling">
<name>Recursive Signaling</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
example.net domain
. . . . . . . . . . . . . . . . .
. Gn .
+----+ 1 . +----+ +-----------+ .
| Cc |<--------->| Sn |~~~~~~~| Mitigator | .
+----+ . +====+ | Mn | .
. | Cn | +-----------+ .
example.com . +----+ .
client . ^ .
. . .|. . . . . . . . . . . . . .
|
2 |
|
. . .|. . . . . . . . . . . . . .
. v .
. +----+ +-----------+ .
. | So |~~~~~~~| Mitigator | .
. +----+ | Mo | .
. +-----------+ .
. .
. . . . . . . . . . . . . . . . .
example.org domain
]]></artwork></figure>
]]></artwork>
</figure>
<t>In <xref target="fig-recursive-signaling"/>, target="fig-recursive-signaling" format="default"/>, client Cc signals a request for mitigation
across inter-domain DOTS session 1 to the DOTS server Sn belonging to the
example.net domain. DOTS server Sn enables mitigation on mitigator Mn. DOTS
server Sn is half of DOTS gateway Gn, being deployed logically back-to-back back to back with
DOTS client Cn, which has pre-existing preexisting inter-domain DOTS session 2 with the DOTS
server So belonging to the example.org domain. At any point, DOTS server Sn MAY <bcp14>MAY</bcp14>
recurse an on-going ongoing mitigation request through DOTS client Cn to DOTS server So,
in the expectation that mitigator Mo will be activated to aid in the defense of
the attack target.</t>
<t>Recursive signaling is opaque to the DOTS client. To maximize mitigation
visibility to the DOTS client, however, the recursing domain SHOULD <bcp14>SHOULD</bcp14> provide
recursed mitigation feedback in signals reporting on mitigation status to the
DOTS client. For example, the recursing domain's DOTS server should incorporate
into mitigation status messages
available metrics such as dropped packet or byte counts from the recursed
domain's DOTS server.</t> server into mitigation status messages.
</t>
<t>DOTS clients involved in recursive signaling must be able to withdraw requests
for mitigation without warning or justification, justification per SIG-006 in <xref target="RFC8612"></xref>.</t> target="RFC8612" format="default"/>.</t>
<t>Operators recursing mitigation requests MAY <bcp14>MAY</bcp14>
maintain the recursed mitigation for a brief, brief protocol-defined
period in the event the DOTS client originating the mitigation
withdraws its request for help, as per the discussion of managing
mitigation toggling in SIG-006 of <xref target="RFC8612"></xref>.</t> target="RFC8612"
format="default"/>.</t>
<t>Deployment of recursive signaling may result in traffic
redirection, examination examination, and mitigation extending beyond the initial
bilateral relationship between DOTS client and DOTS server. As such,
client control over the network path of mitigated traffic may be
reduced. DOTS client operators should be aware of any privacy concerns,
concerns and work with DOTS server operators employing recursive
signaling to ensure shared sensitive material is suitably
protected. Typically Typically, there is a contractual Service Level Agreement (SLA) SLA negotiated among the DOTS client domain, the recursed domain domain,
and the recursing domain to meet the privacy requirements of the
DOTS client domain and authorization for the recursing domain to
request mitigation for the resources controlled by the DOTS client
domain. </t>
</section>
<section anchor="anycast-signaling" title="Anycast Signaling"> numbered="true" toc="default">
<name>Anycast Signaling</name>
<t>The DOTS architecture does not assume the availability of anycast
within a DOTS deployment, but neither does the architecture exclude
it. Domains operating DOTS servers MAY <bcp14>MAY</bcp14> deploy DOTS
servers with an anycast Service Address as described in BCP 126
<xref target="RFC4786"></xref>. target="RFC4786" format="default"/>. In such a deployment,
DOTS clients connecting to the DOTS Service Address may be
communicating with distinct DOTS servers, depending on the network
configuration at the time the DOTS clients connect. Among other
benefits, anycast signaling potentially offers the following:</t>
<t><list style="symbols">
<t>Simplified
<ul spacing="normal">
<li>Simplified DOTS client configuration, including service
discovery through the methods described in <xref target="RFC7094"></xref>. target="RFC7094"
format="default"/>. In this scenario, the "instance discovery"
message would be a DOTS client initiating a DOTS session to the
DOTS server anycast Service Address, to which the DOTS server
would reply with a redirection to the DOTS server unicast address
the client should use for DOTS.</t>
<t>Region- DOTS.</li>
<li>Region- or customer-specific deployments, in which the DOTS
Service Addresses route to distinct DOTS servers depending on the
client region or the customer network in which a DOTS client resides.</t>
<t>Operational
resides.</li>
<li>Operational resiliency, spreading DOTS signaling traffic
across the DOTS server domain's networks, and thereby also
reducing the potential attack surface, as described in BCP 126
<xref target="RFC4786"></xref>.</t>
</list></t> target="RFC4786" format="default"/>.</li>
</ul>
<section anchor="anycast-signaling-considerations" title="Anycast numbered="true" toc="default">
<name>Anycast Signaling Considerations"> Considerations</name>
<t>As long as network configuration remains stable, anycast DOTS
signaling is to the individual DOTS client indistinct from direct
signaling. However, the operational challenges inherent in anycast
signaling are anything but negligible, and DOTS server operators
must carefully weigh the risks against the benefits before
deploying.</t>
<t>While the DOTS signal channel primarily operates over UDP per
SIG-001 in <xref target="RFC8612"></xref>, target="RFC8612" format="default"/>, the signal
channel also requires mutual authentication between DOTS agents,
with associated security state on both ends.</t>
<t>Network instability is of particular concern with anycast
signaling, as DOTS signal channels are expected to be long-lived, long lived
and potentially operating under congested network conditions
caused by a volumetric DDoS attack.</t>
<t>For example, a network configuration altering the route to the
DOTS server during active anycast signaling may cause the DOTS
client to send messages to a DOTS server other than the one with
which it initially established a signaling session. That second
DOTS server might not have the security state of the existing
session, forcing the DOTS client to initialize a new DOTS session.
This challenge might in part be mitigated by use of resumption via
a PSK pre-shared key (PSK) in TLS 1.3 <xref target="RFC8446"></xref> target="RFC8446"
format="default"/> and DTLS 1.3 <xref target="I-D.ietf-tls-dtls13"></xref> target="I-D.ietf-tls-dtls13"
format="default"/> (session resumption in TLS 1.2 <xref target="RFC5246"></xref>
target="RFC5246" format="default"/> and DTLS 1.2 <xref target="RFC6347"></xref>),
target="RFC6347" format="default"/>), but keying material must
then be available to all DOTS servers sharing the anycast Service Address in that case
Address, which has operational challenges of its own.</t>
<t>While the DOTS client will try to establish a new DOTS session
with the DOTS server now acting as the anycast DOTS Service
Address, the link between DOTS client and server may be congested
with attack traffic, making signal session establishment
difficult. In such a scenario, anycast Service Address instability
becomes a sort of signal session flapping, with obvious negative
consequences for the DOTS deployment.</t>
<t>Anycast signaling deployments similarly must also take into
account active mitigations. Active mitigations initiated through a
DOTS session may involve diverting traffic to a scrubbing
center. If the DOTS session flaps due to anycast changes as
described above, mitigation may also flap as the DOTS servers
sharing the anycast DOTS service address toggles mitigation on
detecting DOTS session loss, depending on whether or not the client has
configured mitigation on loss of signal (<xref target="auto-mit-signal-loss"/>).</t>
target="auto-mit-signal-loss" format="default"/>).</t>
</section>
</section>
<section anchor="nat-signaling" title="Signaling numbered="true" toc="default">
<name>Signaling Considerations for Network Address Translation"> Translation</name>
<t>Network address translators (NATs) are expected to be a common
feature of DOTS deployments. The Middlebox Traversal Guidelines middlebox traversal guidelines in
<xref target="RFC8085"></xref> target="RFC8085" format="default"/> include general NAT
considerations that are applicable to DOTS deployments when the
signal channel is established over UDP.</t>
<t>Additional DOTS-specific considerations arise when NATs are part
of the DOTS architecture. For example, DDoS attack detection behind
a NAT will detect attacks against internal addresses. A DOTS client
subsequently asked to request mitigation for the attacked scope of
addresses cannot reasonably perform the task, due to the lack of
externally routable addresses in the mitigation scope.</t>
<t>The following considerations do not cover all possible scenarios, scenarios
but are meant rather to highlight anticipated common issues when
signaling through NATs.</t>
<section anchor="direct-provisioning-of-internal-to-external-address-mappings" title="Direct numbered="true" toc="default">
<name>Direct Provisioning of Internal-to-External Address Mappings"> Mappings</name>
<t>Operators may circumvent the problem of translating internal
addresses or prefixes to externally routable mitigation scopes by
directly provisioning the mappings of external addresses to
internal protected resources on the DOTS client. When the operator
requests mitigation scoped for internal addresses, directly or
through automated means, the DOTS client looks up the matching
external addresses or prefixes, prefixes and issues a mitigation request
scoped to that externally routable information.</t>
<t>When directly provisioning the address mappings, operators must ensure the
mappings remain up to date, date or they risk losing the ability to request accurate
mitigation scopes. To that aim, the DOTS client can rely on mechanisms such as
<xref target="RFC8512"></xref> target="RFC8512" format="default"/> or <xref target="RFC7658"></xref> target="RFC7658" format="default"/> to retrieve static explicit mappings. This document does not
prescribe the method by which mappings are maintained once they are provisioned
on the DOTS client.</t>
</section>
<section anchor="resolving-public-mitigation-scope-with-port-control-protocol-pcp" title="Resolving numbered="true" toc="default">
<name>Resolving Public Mitigation Scope with Port Control Protocol (PCP)"> (PCP)</name>
<t>Port Control Protocol (PCP) <xref target="RFC6887"></xref> target="RFC6887" format="default"/> may be used to retrieve the external
addresses/prefixes and/or port numbers if the NAT function embeds a PCP server.</t>
<t>A DOTS client can use the information retrieved by means of PCP to feed the DOTS
protocol(s) messages that will be sent to a DOTS server. These messages will
convey the external addresses/prefixes as set by the NAT.</t>
<t>PCP also enables discovery and configuration of the lifetime of port mappings
instantiated in intermediate NAT devices. Discovery of port mapping lifetimes
can reduce the dependency on heartbeat messages to maintain mappings, and
therefore mappings and,
therefore, reduce the load on DOTS servers and the network.</t>
</section>
<section anchor="resolving-public-mitigation-scope-with-session-traversal-utilities-stun" title="Resolving numbered="true" toc="default">
<name>Resolving Public Mitigation Scope with Session Traversal Utilities (STUN)"> (STUN)</name>
<t>An internal resource, e.g., a Web web server, can discover its reflexive transport
address through a STUN Binding request/response transaction, as described in
<xref target="I-D.ietf-tram-stunbis"></xref>. target="RFC8489" format="default"/>. After learning its reflexive transport address from the STUN server,
the internal resource can export its reflexive transport address and internal
transport address to the DOTS client, thereby enabling the DOTS client to
request mitigation with the correct external scope, as depicted in
<xref target="fig-nat-stun"/>. target="fig-nat-stun" format="default"/>. The mechanism for providing the DOTS client with the reflexive
transport address and internal transport address is unspecified in this
document.</t>
<t>In order to prevent an attacker from modifying the STUN messages in transit, the
STUN client and server must use the message-integrity mechanism discussed in
Section 9 of
<xref target="I-D.ietf-tram-stunbis"></xref> target="RFC8489" sectionFormat="of" section="9"/> or use STUN over DTLS <xref target="RFC7350"></xref> target="RFC7350" format="default"/> or use STUN over TLS.
If the STUN client is behind a NAT that performs Endpoint-Dependent Mapping
<xref target="RFC5128"></xref>, target="RFC5128" format="default"/>, the internal service cannot provide the DOTS client with the
reflexive transport address discovered using STUN. The behavior of a NAT between
the STUN client and the STUN server could be discovered using the experimental
techniques discussed in <xref target="RFC5780"></xref>, target="RFC5780" format="default"/>, but note that there is currently no
standardized way for a STUN client to reliably determine if it is behind a NAT
that performs Endpoint-Dependent Mapping.</t>
<figure title="Resolving mitigation scope anchor="fig-nat-stun">
<name>Resolving Mitigation Scope with STUN" anchor="fig-nat-stun"><artwork><![CDATA[ STUN</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Binding Binding
+--------+ request +---+ request +--------+
| STUN |<----------| N |<----------| STUN |
| server | | A | | client |
| |---------->| T |---------->| |
+--------+ Binding +---+ Binding +--------+
response response |
| reflexive transport address
| & internal transport address
v
+--------+
| DOTS |
| client |
+--------+
]]></artwork></figure>
]]></artwork>
</figure>
</section>
<section anchor="resolving-requested-mitigation-scope-with-dns" title="Resolving numbered="true" toc="default">
<name>Resolving Requested Mitigation Scope with DNS"> DNS</name>
<t>DOTS supports mitigation scoped to DNS names. As discussed in <xref target="RFC3235"></xref>, target="RFC3235" format="default"/>,
using DNS names instead of IP addresses potentially avoids the address
translation problem, as long as the same domain name is internally and externally resolvable.
For example, a detected attack's internal target address can be mapped to a DNS name through a reverse lookup. The DNS name
returned by the reverse lookup can then be provided to the DOTS client as the
external scope for mitigation. For the reverse DNS lookup, DNS Security
Extensions (DNSSEC) <xref target="RFC4033"></xref> target="RFC4033" format="default"/> must be used where the authenticity of response
is critical.</t>
</section>
</section>
</section>
<section anchor="mit-request-triggers" title="Triggering numbered="true" toc="default">
<name>Triggering Requests for Mitigation"> Mitigation</name>
<t><xref target="RFC8612"></xref> target="RFC8612" format="default"/> places no limitation on the circumstances in which a DOTS client
operator may request mitigation, nor does it demand justification for any
mitigation request, thereby reserving operational control over DDoS defense for
the domain requesting mitigation. This architecture likewise does not prescribe
the network conditions and mechanisms triggering a mitigation request from a
DOTS client.</t>
<t>However, considering selected possible mitigation triggers from an architectural
perspective offers a model for alternative or unanticipated triggers for DOTS
deployments. In all cases, what network conditions merit a mitigation request
are at the discretion of the DOTS client operator.</t>
<t>The mitigation request itself is defined by DOTS, however DOTS; however, the interfaces
required to trigger the mitigation request in the following scenarios are
implementation-specific.</t>
implementation specific.</t>
<section anchor="manual-mit-request" title="Manual numbered="true" toc="default">
<name>Manual Mitigation Request"> Request</name>
<t>A DOTS client operator may manually prepare a request for mitigation, including
scope and duration, and manually instruct the DOTS client to send the mitigation
request to the DOTS server. In context, a manual request is a request directly
issued by the operator without automated decision-making decision making performed by a device
interacting with the DOTS client. Modes of manual mitigation requests include
an operator entering a command into a text interface, or directly interacting
with a graphical interface to send the request.</t>
<t>An operator might do this, for example, in response to notice of an attack
delivered by attack detection equipment or software, and the alerting detector
lacks interfaces or is not configured to use available interfaces to translate
the alert to a mitigation request automatically.</t>
<t>In a variation of the above scenario, the operator may have preconfigured on the
DOTS client mitigation requests for various resources in the operator's domain.
When notified of an attack, the DOTS client operator manually instructs the DOTS
client to send the relevant preconfigured mitigation request for the resources
under attack.</t>
<t>A further variant involves recursive signaling, as described in
<xref target="recursive-signaling"/>. target="recursive-signaling" format="default"/>. The DOTS client in this case is the second half of a
DOTS gateway (back-to-back DOTS server and client). As in the previous scenario,
the scope and duration of the mitigation request are pre-existing, but preexisting but, in this
case
case, are derived from the mitigation request received from a downstream DOTS
client by the DOTS server. Assuming the preconditions required by
<xref target="recursive-signaling"/> target="recursive-signaling" format="default"/> are in place, the DOTS gateway operator may at any time
manually request mitigation from an upstream DOTS server, sending a mitigation
request derived from the downstream DOTS client's request.</t>
<t>The motivations for a DOTS client operator to request mitigation manually are
not prescribed by this architecture, architecture but are expected to include some of the
following:</t>
<t><list style="symbols">
<t>Notice
<ul spacing="normal">
<li>Notice of an attack delivered via e-mail email or alternative messaging</t>
<t>Notice messaging</li>
<li>Notice of an attack delivered via phone call</t>
<t>Notice call</li>
<li>Notice of an attack delivered through the interface(s) of networking
monitoring software deployed in the operator's domain</t>
<t>Manual domain</li>
<li>Manual monitoring of network behavior through network monitoring software</t>
</list></t> software</li>
</ul>
</section>
<section anchor="auto-conditional-mit" title="Automated numbered="true" toc="default">
<name>Automated Conditional Mitigation Request"> Request</name>
<t>Unlike manual mitigation requests, which depend entirely on the DOTS client
operator's capacity to react with speed and accuracy to every detected or
detectable attack, mitigation requests triggered by detected attack conditions
reduce the operational burden on the DOTS client operator, operator and minimize the
latency between attack detection and the start of mitigation.</t>
<t>Mitigation requests are triggered in this scenario by operator-specified network
conditions. Attack detection is deployment-specific, deployment specific and not constrained by this
architecture. Similarly Similarly, the specifics of a condition are left to the discretion
of the operator, though common conditions meriting mitigation include the
following:</t>
<t><list style="symbols">
<t>Detected
<ul spacing="normal">
<li>Detected attack exceeding a rate in packets per second (pps).</t>
<t>Detected (pps).</li>
<li>Detected attack exceeding a rate in bytes per second (bps).</t>
<t>Detected (bps).</li>
<li>Detected resource exhaustion in an attack target.</t>
<t>Detected target.</li>
<li>Detected resource exhaustion in the local domain's mitigator.</t>
<t>Number mitigator.</li>
<li>Number of open connections to an attack target.</t>
<t>Number target.</li>
<li>Number of attack sources in a given attack.</t>
<t>Number attack.</li>
<li>Number of active attacks against targets in the operator's domain.</t>
<t>Conditional domain.</li>
<li>Conditional detection developed through arbitrary statistical analysis or deep
learning techniques.</t>
<t>Any techniques.</li>
<li>Any combination of the above.</t>
</list></t> above.</li>
</ul>
<t>When automated conditional mitigation requests are enabled, violations of any of
the above conditions, or any additional operator-defined conditions, will
trigger a mitigation request from the DOTS client to the DOTS server. The
interfaces between the application detecting the condition violation and the
DOTS client are implementation-specific.</t> implementation specific.</t>
</section>
<section anchor="auto-mit-signal-loss" title="Automated numbered="true" toc="default">
<name>Automated Mitigation on Loss of Signal"> Signal</name>
<t>To maintain a DOTS signal channel session, the DOTS client and the DOTS server
exchange regular but infrequent messages across the signal channel. In the
absence of an attack, the probability of message loss in the signaling channel
should be extremely low. Under attack conditions, however, some signal loss may
be anticipated as attack traffic congests the link, depending on the attack
type.</t>
<t>While <xref target="RFC8612"></xref> target="RFC8612" format="default"/> specifies the DOTS protocol be robust when signaling under
attack conditions, there are nevertheless scenarios in which the DOTS signal is
lost in spite of protocol best efforts. To handle such scenarios, a DOTS
operator may request one or more mitigations mitigations, which are triggered only when the
DOTS server ceases receiving DOTS client heartbeats beyond the miss count or
interval permitted by the protocol.</t>
<t>The impact of mitigating due to loss of signal in either direction must be
considered carefully before enabling it. Attack traffic congesting links is not
the only reason why signal could be lost, and as such such, mitigation requests triggered
by signal channel degradation in either direction may incur unnecessary costs due to scrubbing traffic,
adversely impact network performance and operational expense alike.</t>
</section>
</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations"> numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no actions for IANA.</t> IANA actions.</t>
</section>
<section anchor="security-considerations" title="Security Considerations"> numbered="true" toc="default">
<name>Security Considerations</name>
<t>This section describes identified security considerations for the
DOTS architecture.</t>
<t>Security considerations and security requirements discussed in <xref target="RFC8612"></xref> target="RFC8612" format="default"/> need to
be taken into account.</t>
<t>DOTS is at risk from three primary attack vectors: agent
impersonation, traffic injection injection, and signal blocking. These vectors
may be exploited individually or in concert by an attacker to confuse,
disable, take information from, or otherwise inhibit DOTS agents.</t>
<t>Any attacker with the ability to impersonate a legitimate DOTS client
or server or, indeed, inject false messages into the stream may
potentially trigger/withdraw traffic redirection, trigger/cancel
mitigation activities or subvert drop-/accept-lists. From an
architectural standpoint, operators MUST <bcp14>MUST</bcp14> ensure
conformance to the security requirements defined in Section 2.4 of <xref target="RFC8612"></xref>
target="RFC8612" sectionFormat="of" section="2.4"/> to secure data in
transit. Similarly, as the received data may contain network topology,
telemetry, and threat and mitigation information which that could be considered
sensitive in certain environment, environments, it SHOULD <bcp14>SHOULD</bcp14> be protected
at rest per required local policy. </t>
<t>DOTS agents MUST <bcp14>MUST</bcp14> perform mutual authentication to
ensure authenticity of each other other, and DOTS servers MUST <bcp14>MUST</bcp14>
verify that the requesting DOTS client is authorized to request
mitigation for specific target resources (see <xref target="dots-server"></xref>).</t>
<t>An MITM target="dots-server"
format="default"/>).</t>
<t>A man-in-the-middle (MITM) attacker can intercept and drop packets,
preventing the DOTS peers from receiving some or all of the DOTS messages,
messages; automated mitigation on loss of signal can be used as a
countermeasure but with risks discussed in <xref target="auto-mit-signal-loss"></xref>.</t>
target="auto-mit-signal-loss" format="default"/>.</t>
<t>An attacker with control of a DOTS client may negatively influence
network traffic by requesting and withdrawing requests for mitigation
for particular prefixes, leading to route or DNS flapping. DOTS
operators should carefully monitor and audit DOTS clients to detect
misbehavior and deter misuse.
</t>
<t>Any attack targeting the availability of DOTS servers may disrupt the
ability of the system to receive and process DOTS signals resulting in
failure to fulfill a mitigation request. DOTS servers MUST
<bcp14>MUST</bcp14> be given adequate protections, protections in accordance with
best current practices for network and host security.</t>
</section>
<section anchor="contributors" title="Contributors">
<t><list style="hanging">
<t hangText='Mohamed Boucadair'><vspace blankLines='0'/>
Orange</t>
<t>mohamed.boucadair@orange.com</t>
</list></t>
<t><list style="hanging">
<t hangText='Christopher Gray'>
Christopher_Gray3@cable.comcast.com</t>
</list></t>
</section>
</middle>
<back>
<displayreference target="I-D.ietf-dots-use-cases" to="DOTS-USE-CASES"/>
<displayreference target="I-D.ietf-tls-dtls13" to="DTLS-PROTOCOL"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8612.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4786.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6887.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dots-use-cases.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-dtls13.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8782.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8783.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8738.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8489.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7350.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3235.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4732.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5128.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5780.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7092.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7094.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8512.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7658.xml"/>
</references>
</references>
<section anchor="acknowledgments" title="Acknowledgments"> numbered="false" toc="default">
<name>Acknowledgments</name>
<t>Thanks to Matt Richardson, Roman Danyliw, Frank Xialiang, Roland Dobbins, Wei
Pan, Kaname Nishizuka, Jon Shallow, Paul Kyzivat, Warren Kumari, Benjamin Kaduk, and Mohamed Boucadair <contact fullname="Matt Richardson"/>, <contact
fullname="Roman Danyliw"/>, <contact fullname="Frank Xialiang"/>,
<contact fullname="Roland Dobbins"/>, <contact fullname="Wei Pan"/>,
<contact fullname="Kaname Nishizuka"/>, <contact fullname="Jon Shallow"/>,
<contact fullname="Paul Kyzivat"/>, <contact fullname="Warren Kumari"/>,
<contact fullname="Benjamin Kaduk"/>, and <contact fullname="Mohamed Boucadair"/> for
their comments and suggestions.</t>
<t>Special thanks to Roman Danyliw <contact fullname="Roman Danyliw"/> for the AD review. </t>
</section>
</middle>
<back>
<references title='Normative References'>
&RFC2119;
&RFC8174;
&RFC8612;
&RFC4786;
&RFC6887;
&RFC4033;
</references>
<references title='Informative References'>
&I-D.ietf-dots-use-cases;
&I-D.ietf-tls-dtls13;
&I-D.ietf-dots-signal-channel;
&I-D.ietf-dots-data-channel;
&I-D.ietf-acme-ip;
&I-D.ietf-tram-stunbis;
&RFC7350;
&RFC8555;
&RFC0768;
&RFC0793;
&RFC1035;
&RFC2782;
&RFC3235;
&RFC3261;
&RFC4271;
&RFC4732;
&RFC5128;
&RFC5246;
&RFC5780;
&RFC6347;
&RFC6763;
&RFC7092;
&RFC7094;
&RFC8085;
&RFC8446;
&RFC8512;
&RFC7658;
</references>
<section anchor="contributors" numbered="false" toc="default">
<name>Contributors</name>
<ul empty="true" spacing="compact">
<li ><t><contact fullname="Mohamed Boucadair"/></t>
</li>
<li>
<ul empty="true" spacing="compact">
<li>Orange
</li>
<li>mohamed.boucadair@orange.com
</li>
</ul>
</li>
</ul>
<ul empty="true" spacing="compact">
<li><t><contact fullname="Cristopher Gray"/></t>
</li>
<li>
<ul empty="true" spacing="compact">
<li>Christopher_Gray3@cable.comcast.com
</li>
</ul>
</li>
</ul>
</section>
</back>
<!-- ##markdown-source:
H4sIALSi7lwAA919e3Pc2HHv/+dToLRVd8XsDCVS2pUsxylT4u5a8eoRUXud
lK2kMDMYEiYGmAtgSNGS8tlvv08fAENp77XjSmjXipzB4zz69PPX3fP5PPRl
XxVPstOy69tyseuL1fy0qMu8mjfr+VnRXpXLInu1Lers7UVb5H12Vp7XeVXW
59nd01dvzw6yk3Z5UfbFst+1RcgXi7a4gufBV+k3q2ZZ5xt41arN1/28LPr1
fNX03Tx3V82PHoZV3sNVIeTwuifZWbHctWV/E67P+anh8vpJ9rzui7Yu+vkp
Piws8/5JVtbrJoRls4KxPcl28OBuWZZhWz4JWdaul8Wq629wrjdFB5/0zdL9
Wtarou71g65p+7ZYd/b3zSb5E5ZqaRcvm80G7rVvyxpWx14D097k2y2NCT8J
+a6/aFocE/7M5V+8DZ5wcpi9gHcXdVfU9g0v20m9aovria/bBidVrMq+ae3D
poX3/dC0y2LblHVvn8PQi6J/Yn/H9y9hkSc/b1bF9Oe7um9vnmQ/17B7q+ys
h33r7Otik5fVkyynUW900L89x48PYcmm5//2MHtTrFY3g7m/LdvdJq+K7jpv
Bxfsn/2L5cm6KGZAK8vD/fPPvt8s8q67yX5sqnX2U1lfZk93HWxg12Wv8/Yy
XZ/saV6f51XTwnN/n7d13ueXebpU2bff3b//6Gi8Ts/rVZkP1+eyqVd92X5u
XX445P3Px3TxQ1VsNngcxxfQMjwru2Xzd9v/dc6j+u0Sh7F/gi8Ps7dFfr4r
BrN7WV4Ov6BZPW+bGs4CDCEv67/b7IAL4dB+W8JoNjIYmOPh7nJ6lm8Os2fN
Zts3w018Uy4vRl/x9l3kcHbav8EUZQ746kN59W+X/Dbap1A37Sbvyyu6+80P
z46Pjn4lvz4+evTwSQjIct01z+enh5Gv77pivgR67JKv+qqbr+A/Rw/kUfcf
fffYfv2Vfnp0/8G3+tpHj4/l1wfH9umD4++O5NeH9x/obQ+PH9mnjx4c26+P
v5Nfvz061rd9e/zQPn3wWGf27aPH9+XX7x48fKS/Pn5svz76Tt/26P6vjuOv
D/XXB9/qEx7ff6zjffzQ3vYYBqG/foe/hjCfz7N8AXubL/sQ3l6UHQqOHcqV
bFV0SxDNRQfMNPPCMoPFz4quzxdV2V0gC4DDlsGuEh3C38FJ9YyletasM5Xq
d09PG5Dftwr367KHJ+ODw6Lorwu4dNXgKzo4sBeFG2UDA6ybPuu2xbJc32Tb
tgG52lQd0LH9EYr3KAjKpu5meCTg/KxgGkvkuOcZHOlVsaah+4nCqNuiAiqD
uy7KLdwJ5LltahS6Aae8bGqQc30HQh8misNl/WNVbKvmBod3KGu8KVerqgjh
WQNH931PC/aiAfqlp2cfvlryF3P4Yr6xLz6F30z+hBAXrIfVqItiRbtyUVRb
nEtRr2gy57hiPW3gEk9LtnI7s6KdCbAzXbozed/ny0uY/P/ZlS3uP+kaMM4d
aCstbDw/HW7cFHBy67LbdLRVKBThN7iUx7WFU13CJ8umaeEWmBN8QcPrcDDw
bFjOruAt7XRKocpvipbWqNtttyBnYCXz9gbe1nX5OT4D6BSfTzuI48BxTxNU
YII61J1Zo4iFGW0KUIdWeO+ewW1Aeuxam851WdHjtgWsAGhusKV9eQ7MWVar
y2CxlpfVDY27WK/LZQnDrm5mWVHjSYFnXNws2nIlNwSdvVse2JSqWeYVPqVH
+q0LUDxwpjD/86LH4ca95OfM4DqgxpvriwKOZlnPt3l/kemhka3smh2oZLRJ
8qjD7CzfwNryugABZ8QzUfvNgOgXTUvDAaL+4x72+u7wyzmGHhDPNWaeZeAk
QABsdB/kJPnzZzxBOAGuz5A3wHF7S09pqub8hsTNh6/6+MknPI36E8JXX32V
/b64yf4A699l8BfOqMgu4aNr+ujOi5/P3t6Z8b/Zy1f0+5vv/+Xn52++P8Xf
z3538tNP9gtfEeCPVz//JN/jb/HOZ69evPj+5Snf/OLk3+Af3JM7r16/ff7q
5clPd3CVYJpdsFXFHQF6W+DmwlS2bYEbk3e23LSyT5+9PnqYffgg8vLTJ/4d
BeanT7MA1FHzq5oaqIv/BMICQttukchwYasKiGBb9nlFK4mrc0p8kZgU0B6u
ra2T3/kdkjHRKV3Bx4ypR6QNUks4WzbbIos/H77q8BPZlRCe89wT2pkxJSwr
PE5Mwciu8BQiV9rV5RJPIXNyutQYyWE4waMOB21X0dnhb7ps3TYbJTF+MC2G
3E5PB+IEhgNGHYgU+CoAdwUjgPgeHTB4GkhNPOa4Dz1NFzkwPkYOHR+0u93B
jCXmez5wi5uwguPbEp3rM2CDc2UpcC2KrqYhqWkfgvzhM75tqnJ5QwNcgOUL
HLKEl8MTkLnDQ3dwvmid4O8ljNnGw+9Clf4GOCtofvIkpDYTWXMWpHAdHwZa
k+QwAwWCto9EyCyny2gMSzjZMPdl24AJAzYynKDLLF/B0UOZQ8pakHOagUh0
SzKL7ApYBBN52RV6zolpXdifyAMDkEm7mqN8udHpyUIhqao8Q+2my64LIOy8
4zVGMsFhTo1LhARM6Lyoi5b5cNcBia/kBG4akKbA3AvmwHiMsrwkqohiBFRp
HKMKUebyNkVYF9xeME1FPi7LLfM8WTPYZ5DPMlAZWdYtQYq0ZdMRO7jKqx2t
NjGLogSCua6ztjy/AELGGdO4zs/b4pweDQozzHQuz3JkH09E0zJ70Yu8TBpM
Zcz3VQfLV2B0dXhIbwYrTMxa7dscBkZCHXlG3gem5Cgc4JW6WmV91VRXqEbi
oEWfQH2hQYkFoylBI2ERQSvT7HpSaJCtoE1/DvQPOkk3Y8YSmSptK9LpEpUK
UC7QPwLfIDdBEkJ1hl0m5V/4E6/r4N7BHsE6bascCK1raCbMXPU2GLVyrWVe
B5zKZZHyGSBSWM0TYCEgB6sCWRsxKhF+pH/xQuEr8Tzvum7AWGd2QMhNlRzV
kqQE7DFT8LqpquYarsXV848/zF7hyOviGlb+Ir8qQfxXYTwAL3GSBUXufoJr
uuW9YO6ex08GkjcloE1+WahGhyMkDSDeC5bKP2QncIiVfcDbry/QdNXzyuwL
SRVG6Y5sA0eVebLMZUWOs7qmAwyGqxEas7lzkzFIwnQg4Ekl0odytIL1UT6l
6MRDhp+sOdgIHR0IPA8kO8GSqErgT0KoTS1zbTcwwsGIDnGyYCeco1RhQsST
RwocMMyLfCeft6wQgEq+QrIHYViQLpyzNixaZsZ6AFqlnz6B0gdXZXA2WpIo
JEN2fVkBscJ46zmMHZRLeCDKuI41UGZKOFp4GC4T8yfYA+GSOHyeZ5d1F82u
wuM7YJxAcfCagmZDZJplG5gIXYiMDIlzVy9pZqqKlC2QB1obcETRaltWO+K0
xN36xGLIWCgDJeBnKL1y1L1xL3LcdVrUtyquYGdAbUAVAgbvFgvYRo5jARMC
5gHTAFPp/LxoWSF1HBEdu8rXReAN2J0ZqydGOCrN4oVNS8p7ZvIK1ltEKWtc
17UoInm7KOGOtoQ5IYuYHi9SI4+4m5GMyesdCTEQ1ys6AUBTzOujsKSleRFl
p10mXBlFPR2lujC5tduiOyjfeIWpyxY5siZyJAGXgKNT5sjYSPtGln6TSJ5k
HTrjYWRiVjdOHvL5WJfnO2b0bC3Wu80CFkd5pY4BbQThDXl2DjuRiruLHH1p
XtBEHZLol3iJHzLZY6oo4SBL8q5PqEvo9o4aTaJd8rHcgBZazi8aPBVKFLDI
uP9g5jYtnIZdWfVzlCr4PrScYeFttGOTSObrVwCehkPGM2y7BG8vclgR4mfK
a2Cr4ehc6snw6hMYATl69XC+92BS+PcCmAR8Ao9SJtyC6ASOBRvlKYt2a6/q
gOvbbHO4HGcWlbqOSFTdGfI82mgKZdDBie8zEZooMUSwDZ8XVEZAjAH17tQS
x4HpvNI5Ie+BdSeXA32H3MezBVP0gZUseVbwtNwsaTBbCtiHoiUbmk2JqSNC
QwNuRI8hw4TmCQPAx8GY8RHuegpK0MWkf/B5ZIKU1dOHRduHbvy6s2Wb6ZKI
JoXDdrqzKL5IBMnhNCtLNcSZ16TZEVN0whwu2mZ3fsHbmfcYa0BNqS6qGUkp
ukjZJKwwLCfobX0ULUTExNDzDZoXzSKSGx22Cpk16uK8Q7ROuimmVw+IYmA8
iNCRSam+j5ZQUQMtgIUY2R9KDOKSYCSherjeVXEQQMFVsUYC2NV9A1YU84nB
pExNOEwIQMWfDhLEFGw77j5JS5oemFegtKAqivuM3qyNsBBn3cJzz8iCm7wY
pStTS34FeqWaCh0K/8i6uuxucXh+iKLVWQdmaRyYYilyP1VzTOmHIaBkhjew
J1SsD33xYfa75rqAyc90D+C6olqPrYYLUk3zXse+ApFj7Cl5d45KIrEb1kXi
o2gZ+QSymYpSdZ39C8hBoyfzQ/8LOjuVtUebxKuEc3LeoUJUFE4ZAtqgcwhP
g4fAq0BhBv4plkJebohJAGl1u5bdikI9uot2gvzLkA7OmWjwqSX50VhZYyUy
MXjI2JjxtE15QlkFB5sn2k+Z77aiwjXJUQCnVs8sa/pVAzosaA7LZgfibDUT
Fz9zVnXUFSzs7eR61gX2wCgWjxaB+3PCu80uB1Ak4GBfgDk7r4Byqgnqg7Up
q2pH6gObIx8+gIowp1sptP/pE5gN/4k/FHn6xpkf3zgXVPIFfEUXf1SFCPb5
Y/af9gN/0FDO+DR//OVP/tzPx7/6Veko3BCnJ37CIu8t+5t18jrxZ8y2fuGT
eRc+PMm+SrcoIxDIb+48pf0ekcudT2gadyV5zdR7hvGMHNmd+iQniRzpVswQ
71EKeTd20BGnzzOQjsA6EGHhZf9MjEEnz+HLMOFrkkebu47VVOfNupu89QAV
SdHF2ErCuxVfkl2B7pyTgsYskXxSPcn5LsfYVK+HEvmze0u3Q4UUuFhJN5E6
7Sc0GtYFStXEFRpYf24WvRjbEmxFzrYAS5OXfLhG6kka+FGDhaXgjOqyiQ7n
R+SlJDoXdi07f9Ax4EyPkLpDSc9H/3jeXcIqkiIxfAkQRGrm8XgvUDYEYNW4
9qiAkwzy1CEKBrylEpGDz7wCSbLyftuWdGvchmSDxX1KnqiETtVgiBYHfkW6
+TpfOpFgaotTyhLt8G16n9BQStyq/9i6BXGTZeomU5kEGkW5AZndolTBW0zy
4BWLRnS00eND8njS8Cef/vZi14kzvxZ1WZaiYNmf1+kKgtRcgrTbS8oo+1qW
/W5hb/hZkVDYgCYqAIFmYTtygOe1EeGJPwNfd6aco03jjjsK5dVV2TWoCtZZ
nXOMwovHCoPL6Gyub7xVBacYRjBDV7vYOk09PC2imH7dJTaYBh/JeepDjyB+
0V0HypQnMJuCKfdvB7qxKFigaV+VKz03yG66fmhRz9h0BMWqWZbk+6CLvTfg
+WtV4dg1W6BXRD8YWmULOwyoMgTV/dY5kN6NYwUy0miqJ2wARtdRNB9Vb7Vo
6/MgR8AmlujeNkZ0VU6rD/E0ffpEhwCVTeQv183UCc3DULlPOOmvKd5AWpYo
V3TN3WbLqlp1c4DRTKd8He5TWUbKxeTP6A4R6gO9IPtH+V7C5Aj2odHxp/80
vkOf45WA0VUTGkiW6EvxOcPxiPoHl+Ni6HAy/nTfeP4a65OqJp6ZsmpCw39u
H6NK8pYIrNygU3i7a9HZaySdbnbZiW7hKRoZQ3c5IJ09QtLYEzMYjS/6O/tG
BHQYGsBRVsMZ6hknQUzP+f5G5424KcWfFzfmk8lTR4sKXsSs3KIhiAPaoqD8
srHLBpSGRry7GD9Gu7kn5jrx0KDLUY74HSkyNL/kzmiGjrWMQFoGzhJVoMTf
Edd19B5YRrBwSX6BYELWDBKnRvxC6kUzLxbFRQi1wpePY80UYkegny5afAzv
PEjislmVDA3hcXWjgU1tOK6Z3++hjPf33/4SUefiS0zM8NtMHespkl2Xm91G
GXGnrxjowOGiyKs+2TEJLvQaSUiog2A1+fJ24khkrioPNegEHbLsxY0bPOxN
z14RQivPRioX0idrIaRdmd1Li0wLMkeDfByC1tUo+1DWK4IomILmd765kvhU
yjpQHXHTsGOyKAwlg2JrnfIW9UXDV+7mqlwXfbkhm7l4vywKEIyH2cuGppH3
YYJxkbAuJIRGWmDBIx2YJMV7pBlQpAWyg6aRLIWp2BSU2S3+jC5P1LTRFYSR
7+UlaHgV+wRXZOxnFbynXmIE7A+kc2t0TyNEqpK5yZEy8meMJI2nMWOikBhc
oiJ5mRuJlJh1DNmRTofKhqG5gnmNJQq9VxIkLyg7tTHQyR+9+KBMJZENPuqC
yXAUDrsGTzov9vo61Q5MrIPv2WKOfN8/Uk4UnzbUcEhxxRgl7TpFXJ+hO5H4
FuYoIF2hOsh6c0cA4o695SXCwRjkopFKXkw6A+iMTEl5YS5+pETyY7pX0CUY
i8frFDgGFNThLeTbHFCrLk/HNIIR33TbqpvoL9fhkTWBDjeVrx3zB1MF9dK5
GxoqhQw0+uezVy+ZnNsyp/Ap+0lx3xO/E/58SNw1dy76ftsd3XmS/XHkxrlz
9Kvjw/uHx4dHTx4+fHBnNnXB48Nvjw6P7sNVE9e8S/+8A7T9Hmh1+mXH9x/A
y46OHhw+ePLg6Pjx1Pv+eHz//tGT1eLxk3x5dP/Jk6N3fOmtb8235X/s2gpf
y7N9cu8efCaUKa4cBHvjp/eujtyLPw1UsqltUOXsddv07D6xALm7CnW1f8hO
22Y7J8Nmk9f5Obl4lTmzb7cbK2hDyS+yLxNZozTkHAfkVT1ZIhz4b/U2Aq3x
o9T7gLyxus5v4B96tQS6f+Bo1i8aAghxUGToBG+A1esrYBQcGwNrElZyy1DN
DCXCnNgFfrCrr3PCgynCbBhOIg6L9hqB8oLJHvGtsIgG9tmVwumN45EiucAB
ee61KNaUCrMi73pAJrSm+F3qHjh1KBo06IFR4fO9M55ALIk2Ua+CC22QZCBL
nmQrqqxFXjN3M+8+StfqJnkuTIkHF70aFCfcItK+XBaCR+KH0VKcpshxg1Lg
OFp8PPoagVWGdCHwFbpaK3tn4vFTV/yrrUGlPnxlzp0UmYM/fLWP7zDqJy4D
ox51qAiTLDBCeMGBHofKYegRuwxIz7LbB9iiZqcgv3LNAa0RIoeAbiEJf8PU
fihbdlqgb0UJm+6Cxama+lxwfxLdoqUml2ctvKK/UXMmrwlPGXFgGMRBm97w
XIfJoDz8lGZInhKOTrK2FDY7cTulT/2cUyBxCVj8LDDZM2wXR7sC/tPMxHRB
H3QCl0YFrhP4zQS0DvW+DRgElE1B8DNeZibJha4KH5COgnHi2yONt/e+TVyV
WdDtR5e7eOuv1Q1PqlUC7jzhVA9hEQfETGFZst2WXG5EwDovYn1yGNvsqdzJ
fJLsShgYvyqCJfLsrtx+kBBNokShX4dIQjmjH+DX3YBNBv/0wR4SAcQh6r2q
jJ3Q2j4l+y8hMUc0M7kGtxZuYuQxjO2E+HwEFRJWExmEAQh/IDxzGiukuB4d
QDZucJ+uyuJa2KICIOkNxmXTlUIN3xEORTn5NDnnaIKU8Kbm8zowvnUH9uZM
mLyhwvC1i3Ju8AaKbjooTiIRaIhlF8iMuU0JTtb8h12Ly7ohUTF+fXCqvhKa
F1SzbKycT2rlwjhg7fFLhgPspk0Bcly4XapuDHAACyaWao/IgrIKdPR472yX
JgJPOC2L8uOG7Aii+wptL7rli3gQ8sQFLqvb8Zl6LIAsGExBsGc5cMoUSH1Y
Ugoova8qL0EQXjTNKg7b7VPA5VIny8AaNjeYQfzSgEDZicRbV/B4GGDgyJO4
NEAtKWUQHkQSxWsKaYmRGx1aa3hhkuH1gsQSmbxLQ2QSz6TJi4BUDHHJgMPq
xuYdpmMxqdfqStM7ls1coVtl7V3kE8hCc5OIFa5BRJTSmq2lSA4gBjqjQ7MZ
30CrzVlFFuFMIyeKG0LxHQSyagpo6/BJlJzASJgvSIvA8CfYf0VL48bUilH8
9BlPw+GukfcsL8oClwy3wL1ewiqoJT398TWhozEp8x2zhZdn9Almd7479HC3
xkcbJXKKKiBoPGBxsozg+ZgLNo6VE0soa/ECDvV6h6cMYbQ80wMXJQyjBdCA
GKNlEvpkpJukUQ0ZazDeO5HEUvbCjYjVc5pQnl3npJMuc7ZdVbX3m7dnj8R1
hWaFui1KisQIV5lAzSv2Zu5Fh/Cq/YJ4KnCVnhdFtpkm1wRVzxkvkqD1x+5e
UacL5ODLwvl59sP8yZ3ARRdGzJdUn9SOQpC/bI6kcJCr5LYkgum0m5MKbkFE
nXIEcV8Ng02RhiU1zpA4skZwxvYxh6H6PimgE6C4pgOApo0gBeZGrPqTO5Ey
gYd5AYYOY998cPdSjtmzmFHrDBBOPXOxpg9fUe4hLzTBQvzCl12q+DtLOQE9
E7NL0j0HqZhg2pbn5Fxl+hlioQmFKpdSgFck4gxOxHmDpqh6PzXxNp6kvWTO
tILZAj6tE/cuwSKObHblAzirQzHuFNN/jToqXEPSRRm7w07oeBStSOh50dGx
JAkl/RUSERAMTFvYaSg4jRBjRJbUM8AlI1dDbkRZCZib5tUoMxzMDeiDFON4
te3DEE7sk64Shujc6xMObp9NICthWNzxLoES3SYjpPGThjjMwrSknCy7e/b8
x/n9+48l7iUwFMfHhYVQHvmOM00k41idnp7WHHPOCYHvowlhkinY6Z0pOMmv
KZIJkUeegZbQNteowJIEpHQtXhUh6wiS4GM8ih3tx0vEhBAFL6JUEgTFk+x8
l7foO2I3dRJoYp1WcMDtJD4dHwkW/K4vTBtmwKBDcwrthgSUwuIuzV8aEl2+
wrhCN8H10UuvMYOoerutXYPpvcCtEoCte4SGsA4yUY2jDCa3USfA0iQ9Qpzk
KRZcFTPO8iBP/K4HjkJuCxo7L0BZB09Iu+2KglF0WgbSFVehiV6vTPBwljmb
SbxOkktdsmlWgto8OGVBDiSmrRnQDRE7BaFVFcMxDkRqRBbe1vYLTOffc44J
DCNJ5LR2Hgtj/pPBxoZoL7BwTF81tS4R36NETE4XGn4SkONTQ8UmEH6SLwyB
nPIle53lWTuYhAg7vjQKO40VD4QdhaQq4aaSITHDPUSjRItziCV9E3LOFfB5
PrdJxsiCaFncKnbsOkoBMM7A7FLXWeJK6YZ8M3z4IFNmVA/GWXxNkU4Xm2LN
6DxtYXCj1BMffm0LDLY5lFWMiYucjVd3gqSM9QeC4Ytu3VK14SKdtqrP64DR
ZdEh8zmUBEnFJaJiFPPmYmonei2v4X0lapH5gGXHegnoVuZ56JsExOU3hPNN
8q5B75aSOztimU/G/HKk5KF6k7h5bk8I/oE0lHHC1d3Uej0wnWdo+jtvZdB4
r2ViGeBCXyFaVQz7yEblvaV2wIiCZWMRr2dMcJ9LEq7asgptY8e5JOB6TJuk
QQXMtSjfw99bl0EysjPEwOgGir9KNzkBXwefeZ0gNMg6VTOBcrf4iRtRddHl
UNYDQWblIsQxkHoFzIoxfWss1fomznhmc51pDpjI146SElcKo/BbrTtLVg9t
RZ5gKYiDoMPIjBPOXZDNLut1tSvUaZUopqRqk4vUEvVTnkjVOdqCMAZ70hyZ
P2osDZNukonIXZZHZWrNpPdl9P6TfwuEz4BVQ89fPnjIGBXEyrZkdeohRW8A
GXJYz4Wj8Z2kE9NATdeO+zHWd9Sqjl5R1Q4tJ/X5UBzxsLvRuKd1uvHhpfU3
CBctJzyQ6ifhvMydxZqdyHBNLHVwnAlZRzzpHF3IjDdb9tkIgBrtGjc304mX
XKPplrmR+BvPynw9eaDsLkJsGNsgCo8ZfKnz6m53oNyxVLcsuZQWzki0ehwx
Hur5kvie9L36qm1OYkLVlEQAD4cxZBdP0CTTzLBOUys4GpZXRUtBjkkDAhep
PL9gL7IomexNAna84oolDdZfcvnL6J85b3OuEuiglQKEiYdvkDMxcbLxenah
sRllBuQAY63ZWhQaVWUwj+Q1fLyU52lRz0WvotPmSfUVTFDyko4VCILvDN6T
+OJQpZDnu6Oxoc1I/dByEkYITvVGDPJixwnc/4VKu8dWjXeKEs2dNh324Nt+
oeJujOPLFXe/C8Ce/78V96GqlyjuP8JD0Mkqmvs5/4lY4Ta3GBM/4Z6xXO8u
0Qoo77c5vR9R7Rei6QkzY31UYi/2JQp6oXlNw71TNecI4qTydIioo/fciXPx
3oIBzUaPNrlfk2oEOUyiOW92hmM8k3V8zuhVvOa11NtD78frAy49gRUTP33K
dFQFx9xpNE+BDc77Zo7/Zj/DsMIJ2TR3nx4//fnkgNwpWOxQfPa4YTxeWWFK
C+msEBFvIhsWXDmEi9tVTMWxhg6bznysYvkiOUwn6Ss0GVUrjCjUskT0nMeA
YoUbUFJEg5PbqbZNxI1SCQDkuXi8sJCX+Y4tK78zW1ML+BDf6CjVpwlWwQh5
gD5NDomQiGNzOglCKUulr9yBnVHv6tELcl1L8MeXQEHJ5zBCmN67TS6bpZmn
CcFNpKR4ZYRKBYoDbcsuRYPeJYfo0whOl/58WZblR/7PqfwS3L3fjK56pb8k
79BHf8yWR9nH+MqPWQd/Z2/xi2P3BXx+/Lk3nd36pj2T+DGdxOcWJMXT+bVN
khzkM81wSMiHeLvEtzMMc6E1DUfW0100nwVF1RYmv0hMSkGnvnPUECXhSlzu
CkUB6uF8cIo0Bwn7sRua1BYqCsn2i1XgsIFr3c8YpFURDLI8KJRrXVD2Vqdo
XKRyP+/OZQom3mXnKeXSeox7GfEmqZSWCEvxY1CgOIqg7p6FHshVS3nakkFN
LPFNIi8+fEUHcJ5IkRGQywVUzppsjSiM64KdvlSoyntkRSBdIdJM9ELll8yr
he14iy4mhanzwV1krrMEFSa6X8eKe766wuo+qxGqKzUDTGNNX+dNAG9ba14s
wrHdcFXKVlSdtHFIs1isJyKXbPLkb3NOEsP4kAUGjzIunMROu+wuMzOu+qJS
g316nw58olfiGeMfr/XIkSamACzGs565fenO/5/ww+WRwWyb9lw/Hf/8aeoJ
+Pn+dwpzO2MGNHHvvXivG8YSjg99mSELip+DpT85tHtTT7936yLQG4/9GwfM
b2IvEh4oH3EasW6r7MydUdjxS8nSMikHZKk1iz5LlqzzyesQHYvA04IMslGY
ZNnM1U83AnxsGD2IQLFaAw+V5U/CMXx+9hretucUjCF8GmAcoks02k8s09ZR
Dw5L/e4CSxaayHe1kTTK+2nPGVFa8Gu7rx6CkYX9TNFwJNz9d/rvbqPgSLbJ
Hbec4fFx+tOtk0i/xaH4o+6GnBx5f9cvW5XJoSyH51qGcpysytTp83ush+8F
ffM7qox1GsP+eOROSe9m36wvoOUiw4TuBtOtBUOf6v9hwKMCG1JDtIMwaVIl
jBFyo+c6bG/nc5fRY1OVDIk549DmnieAEIUP87oAi0lgfmPbXbSKqpoaWslI
5QRHk1jR3cw5zwiiAUPGkoAGLkSnKvp9HdTRytGVXbvbSiGZQXIMZa31FIXr
ybWAaRaEXyfmxoo9PKXruWr0bLA5/rSS1z0g9gidE6A5bfKadq7ZkaFZNc32
1mq66rELW0v3UGe07S7YIC484TnD1847SIW9MLcU7CguwStet1jMobdqquau
y5bE8hK7yvRLqWVk4eAai2w21Rw+oPLoVGSc1hB0oJohQQFvmcvWoPGaY6Jl
7koVr4zo96wqOTqDX+ZUJ8bCpji/i4LAjKr8agraWo1HfDKdEsSUc+3vAV7o
mspF8I4D078UMYaqI+djcXKVvkExDMFqIIF2uVuqB8thQ+GZNZWnvSqsfCWV
oNhWrvj6BmvaBnk6ZaW9iZ76VOSUSPGzmJVBKi7S67T3nSq4cTRJixB021zw
tIrEIdefhJxgQr+mxJbyqlzFKN4wBcnXv0/FfwyMAJXAIYyJcQ0dfCDOBWmR
BdY9VW2AyJRBM0CQEeIlRPtrXhOO7yQUo09wKSVWN5Uq3LnBEUIiSyPAMX1I
DACgU0SBp3WpeVVl6uoUE38Y9i+xEp1YcyEpYCsxX7PzZxMGVG5uI6sOqq4v
dXxLnFa9XyMfRBrpGBRgQ1NjrO1MKSiiNMrY5vn5+adPZOZOfl03dMHsdr3J
fEqqI8mJloj+quCIWyxzo7EyEQNJ3Tb2xr99xthXbGnyLlDLhrlAlwtGMks+
TOoeojdY3iVFHTQnTWPBP5++Dn+Uvinv+BLiJUnVaC5Q7kpMNpgeLKlhfANj
CVfFeZuvil87B1xMkB74irnOmXD6JLE2dqgI8Z3z8TsVzbcHfKrLQAj/vgsD
L9e4aCXn61fGjFMPlVevSNn7k/8iu127I12NFDHYSlHITkcFMPxNExaYc2Il
n0WnUaKExje91Q9ht8fq4J43nd36Jvm5N3jTj18wp30atI7/3sSCj9XS8Sf+
06i8j83w5IxQztGPB6ltniq4Yx6hCi7rs/Mz9BP/aD5Z0PROtEh7U6O2+7cm
o8Hm/o8go8/O6b85GZEs+RwhIbpxQEvmNIhhMx/HkGhJWaP8d5Y+s3DPFoHB
om4bkig+xzwcUF/cExSOSWplCIAkRjNM2ukqkUQjx2EUK14CUxIWcHkWtfL+
fZJ48LVI4r8Ni1ai+7uwaP3ofxCLxsqH8edvcbbGxKMni8GXfxcWnZDRYHP/
u5JRnNOPXzCn/+ZklLDofYS0j0XHniS1NINBjMxErDoN92qMykctQgQHm07b
J3i6WLSJ4tdc3FRS1utCrza8hUbl1pRlr8+UFDNNViSk37PX35OdYFw+4vDa
ZhPSsevaK3ShHHb+keFKYzgCyibTCr7nh7ivYmBGhl3GZdQhU4mXXDraLUqz
EkN0NElBJ4tN8t+2H5y0JH3/qG8f/RprGUvU7kwNU0NzC7Q5DdJRzyswuiX5
lW6VlH3rMkTjvSrARhMk2dDfrks9C/tCYtxsI6ava15HmnI9DF94bBnQGRdl
GmOXuRaG9LijW7g5G/tBtIuDFvp3Jd84f2E6g2i2F+FIPTOYZCkZm1IfJDG7
SlsURjSk0r+DtJErbrqF0O2JIhac5FDuIEveVXpalBhWxg4pliuO/RPQgo0N
r4KLHw2wEqnvgvyv5lVKW6TRMynbTyuBTPW1aVx9u1HZb5fcYzAhnqCcHR1M
apxbEof2vvT2uX0JO0bYGFs8zV2oIwxsIm5mgJaT294taYvToeioUUYPQbiL
bhJ4FwgpfciBFnouthdAZy0BVLkFeESIw7vu5tnbn87w5lP4V9foICmee8tS
3DbWgKNyvpPRgPDFU4OCBZpq4II5+RGnObWAWviL89yThLLJlUYSpN6psyn2
o82XBpNLEAPoOmZyYveijm5Q9mX69eZffJ3wn5TDzhPmBEL2tZatSFvWpofY
zqPgmij5DdvvaBXF2J1NOZlxqG7Qt0dl9rgdFefbISfD7iwstwK3TFQXe1J/
Qx4j6V8+qW0fnxrkAWiPJWtUxpmkDrM1Yiawxs/HmcAgg6SvALnEjS1R5XMd
1ziTq+zCoMgwdvHCc8GlZvqc/rBE16TdzYRw6odF7jgvbvRALgbjMD9wGG62
PcKRtxdYOCvW8QixBRyCUotCcr25QQPXAKFCQdRBgpplFOetVma2lCf4wPdL
y+6eff9sfv/+8cFErzYKagzqnqJUZc96mlLlk1Ay9p+O0uU4DokBNsKZpww+
WFFH7Z6rp+h7fx7soaK4wKny52Xujxgcqj9oAQnbuqnufkp2I8IIruLp4CDe
KM6fK6YmdXQQVj9AFNv0qIiS5rkdjHzFoBA2XMQ9KlpWXqgq3pcMoZgFrU1O
HIAUM+oRzKkHtcQkuZ4m6qtXeRVTLmQoxHiZEXTBanIOSowTKjkS+4DjkcJt
Bf7rZCcJjU8DR70sl7gkxxpd5aYUuGw1JQhFb30aV55hK27DYfCGKG+VGFYU
TED8XkMaNMJKwpSKpnXYE/bu0NnnGLHVCPMvjglZQU/CTCDt8qgBo4EzT/uf
HO8O9qXjjq7Z6wJMnBdcxuIkLWMxcZCPhgdZ62B2NxtF3Legy9lflwXiB2FG
LVfKpFHDYlNj4VlW9NiItarGRYbCoKZGWraT19rjcmzeIBDmzXq+wDdxZoV2
D5WKQ+OoJKpWzO9YoUYURaENdNKGK8PCDrEHDwoUaWWYKLC7vpknlf9SwqAT
+pnxBcl0IpgUcU3Nc3DAB30INTamSnNuS7K4JQG3hIxUX3/LTEcc5SjKTm0x
8RK691oBH1TwaYqImyT9UVq5Mp/cCGQ/3XAn+oINY8guNXcRje4ib2uH9ncF
RcTPSyjWl2fh7M3/ln7Qjx4ff/pEKuvLM+t+dIoJHlSukC767tF3D8hN+nYg
XSSFJbbCGlSSIsI2+8b6Gk2Ja+bd1EnCCam75Zq8xmnZOzpaDZdwdpUhuWAu
RSaxgBg+Kulb5GprcZn/veUZTl9QdYaxzoL6qe1o4AZbuEHYdFeLBFNOGUVj
ZSJYyDhRirXqskKINSFGhYaUyCgmZfA+7Tsxg8KEaUEJlew1oBpiifnntU+h
sTinwKHeRBaDxgesq2fInqaUW3NvSd5SKIwvOeaXc1Gcp90CPUFYc7khQDoY
CoNqdFPbOJS5UuByePl4F6mzKRcDCwldUeYRmh6xcLH8jQVO5ywTYyHXYhXz
fhunj83IL9HifZwBZwV8OIuoi3nlHTbP9BW3dzXiYCZC3dpygnuUeilk2YGD
+DdZIsHX/SutZpQzke6eFUXaW+GNq785A6bAJufx4QNk43ZODlRXfOFSzydU
RZeZPtQUEzbmu7cn5eYpccxOCfe9HFTTxJ0cLtd0R2QrvvIQ7HLvb4j1jJir
Wflt3oyYS2aqXcTsUGommbr18ibmFUizlwAkQ2ZCjq0C6zJn9Uk1zFXEDuBc
4OhXhM+JXUzd3EVj4iGTBQfqY4U1uL5n1dR/ndakuM1LMkp3C9PpboOMOlTB
qfkdvVCKntPWWRas3B4UwuTdYWWdcIlMagux1yK8aFZc+SXihOajH/GTd0Kj
qECgpcFmmj7AegEPTHk6D+yDGFi5nL7HvTjt9ehMoI/m9sBPI48fAWWGZQSk
q+d4HOZTmTgEU0ij0fuHwctRis8wUDMMpbhL7REfE275UTrCWGo2u1Lo558+
Jiz7419jFIOcpMGMDZM/2BwMmTyvKTmVvrhdArj0opxASeZNIH8T626H4XS4
b7i7VH5DoE3sXo5IqyQvVSVvgDOARUl6l5o90cvYt9S2FqFOEHSYaU4B+SdI
EEOa+uwkBS2HhV5Wf86X7K8mQtdOsh6TB8Te2scJwcMqL4uW3LKDNtzjAiNY
+5uLTFhjWz9C5I11UjPOP8BVNtun9JyRn96PwrwmtzQveJG/pw4kwz7R045F
Vlf1gFotVCoQWqx+PWiRbfWnXDt24XNpSb6IMceuBVNmbdmlhOlfhSn1ux41
DPyNOD8marJWaeYnDnCHQTSSwWAWwgrRU87sm3TH9l0FrNS1pRNpldThSGIK
A0AlokdjEQeuyBiJ61bBhElyG6q+zPxUOu0hbwwD3jhJrn9F/phySP8DHPLu
0QFckEzFOGT683HfQ/if4QIcTVx6y0P+8Td3jw9+85t44GCvnkqvrNsekjD8
W5YkSxn+yf6R/Ov87sM9a/Kv/7Vrcvt09j3kr0In8vPvww+GSTR3HxxMHYPR
bfyPrsPx8PurPaOfEO6ygU/3zngsiqcOmIrjKRGCIvnoEAMyVyUnunjl77ZT
f8RC1jXTUz6yp6B3dnJI70ppc7p7l++L7jxFmt+rC8MPfD5OVI8NpSuQASur
lNgVaBP3k2Z6cLt2Hd3jsWgfJ4ZOBEmiL7xe4VN808PblvCY3zMxpd/lV1wd
zXZs8NLZYBmXWL6bKpFQakNMPbV240O/EJqw19Rxtm+28U7LfpJusMmK4wNP
Dj9DFtgtyUyVqL4sd22H2kOqvcinifJCj0fBWqD+RlE4im+WG3KwCUmAOJb+
DtonaMlVkmMiUVI30ZW5J7+gg0wiodxgv1JnjVLkrksKlAYGRKwLwhtgtw6B
RET3p1urLq3mibFPif8vm13L5eVrxjzQXbGhx7BsXJLLxkKd06t8nc6YFOBL
HpJ5p6qKkamvqlUnrVYHiXVa7ZArDE0UhE7inURjQW10jT4Mq5FzsW5YybJP
U+mkPgFqNnSQVEuz1AFxi3AFee2hysDV87a55sI82HihxxjFTSNNtVw/xqQ7
q/UBY5/p/nHj9FU75S4fsawgJYUlMfL5ZI02q3xv7oPogbNBy5u17csrjgdw
gPiLaofhUmCGXpnWuwar3Ipuk5cs+VaQChUWuE87J68x2rarQcNcXhaKLwjK
BtkzjrkV6GOH4wdkTa5jeUrRgSVjvSSY8rHHAAGUQzo+V1OODC9N4Ej6OijI
ytGCjIVbLeDssftJNv1syQ4RTdxi//gxRnk6ChKWNXl6QrdDPIMgrM0zxJiu
brhRoDAbJ/OGKNbWnnAQTHG9T/DMNSZCp7YWrVyeXQGbSoqyoGeUFvPOz76v
uTdyFhjgDva1dSZ/i4AaIJDXsqR3Bi725/PTw7Lo1+wHhBfNKUUUQ9/jcNQ4
OSseG4qPS/fBQfk2Rvcl0aYJHpOY6BPVMTnnXtLk8mCyfbrkX4x5d0MAXBrm
3s8I6AQHf4LVsCNBKgyMqy/lK2ADMJrqRqp4jlofCikPekyI84H8ZU5XmXMi
p3owGE9iT2WKYukQfNWxidRJzdGiBcCwaiI0hK9dcHm2sNiVlbaQ3W12VT6o
vGqF0pPjcEu5Hw/x5clMX3f4uf/tuw1+fqwnv6Pv9bZYz+eIb0sK/Hgt+xt/
28fs2dKcbWw5ntXZx//kn4/O8v84/TYZ5Ddo631jD8WfF7X+vn9u8PrazKE9
gxzCqodz27skaXkGWsl/33PPbYOE/338xftGP3urFmTHt3y3977/x6HQxK/2
v23/bV9GQqPbgISaz5PQ7W8TEmr099vm5n6+fJC3/txGC7/8DPu6N8Iihjbu
SH5GE3dkZojT+RbRO1PKh7Otdk9aO9mVD8qXbUMZ+S5rNhFUR1Ntgs/qVFpx
9GbICg+H92hXs1RhjwLphdwS4i1lrMV46vMIfsQ+FaSBGu7enM3ZQur4Uc17
lLSJaH5m3ZBRSFNrmPdch/KWZTiONnQywma0EBMbbjFjaes8WBYs1ysij7qm
1XNGw09JO4FZpPMZOhLOmplmx3H9BLGp0Hpyq93EJH+tIEqqR2lhslWxLqgP
yXqiYVAIbya0xFFycqonYbT7PRgff0kaFCDMRLtjje6ykl0zcWHQS6MiLIgQ
0al1JRNzxRoglLUdiaQiuy/dwIXZhaqT0Y/wQsOxxNrKjXX4AX27aeFVsLyI
tmgm3mUolXG9V/WrU7dTLHfAjapRe7uBB1KrDtc8YWLyh4OYt4GBqZTxhJov
GF1N7ke6X7X5teGqw6BmjCYTgUZH8Xj4Frs9mPN+RgXKOQL+XRIYR4yGhcDj
Wk5huRGdaND8PTMlH0KeLdqyWM8sxDtXgIhEiRNTd+j7GpS4DYNp4jp0ZHWN
yzXnXIidjg07XsTAITgHatqJe+P8vJK6proycKlfmdPYEYl7KYx3ipNhsUJL
WU/1QJtJcFpYfZ0sFkfbOTKszgWrJBBTRSarFDj/wLjPoeVtxFqifYtQYkXK
JkEcYC3R96FzsK7cq93S2pzqFhnFxF4uVhYGyyluW+BlS8IhLMFGFNQLvXHk
n4wPKzZa48aWOjh5bFXOpOxIh5Aath5woXDNqLF82VNrA6vDog7Dk/oG7M7e
FyAxD2YCbIyuXsK7syWSFFWjWdLDpM2W+GtiZRVp4STIYXriCEBZvOeYZQl8
7XTS8Wc1oPDs8cNTh6AAW204CuU7UTjvoKvG02evs6Pj77gZ3qPH370jdwBz
uMyPPuFXmoESBSwNbvgyIZk0rE4j5CLTy6TnIhAFN+hj/h88WQ4QsH1EWE/A
IGlsWKSOfKncFGBR1MByuPAjr0wkpG1D9bBITWEXSRplpGAxVR0ikPbAceoG
5ntGGazHMJSqJ3CoV7HYI/Dho/u/evhO3FkOxsvC7Q514a79c+/QwzgTwXrp
pt5dcctO5LSM9UiseTRNOzOSPOa49UeW3wvSW+G1OTwmiWuM9VWiiK43oLmL
wQyyFfCuQ65hdI6QE6phCNKs2RQOUueKGM1iFSMHREsmU2A9QKwvxl1Epsgx
oUY/vJaGkWntMRkJPE+pNdZQGuDrqUgCTeWVg+Ph5xUFF2ZZt8Vg0iAZq4wd
GTMxDuzMZbqepu1YFpKmBlDLTek94QptGdlrizt41I7q74+blo3ZBPPQCSaa
PUvyJQlhS4Ur827PcRaIYkZ+uSKe0MEKoOOWC+Bjz0nQK3ca1zAyt30k5WsI
jYltstmJ5bZgCQZNVWANJHjKBWeZlfUEr+DigTfcyRA4eqgLUBrOSxn4ao8k
IwUOKw8yOPq6KM8l+If10ryLyziVdLCPhd7QvWjptVPxMRCyG24xay5Rku+Y
whjVvSNk+y5JYQwxVVqRwknTbTwTtUNT4vjs+2wRyUSknkzUcgHh2BiPhdm8
tOOCO8+StCTPd2wKrRqDZWyk+0GUyoIxLXuYTRSqQyqcV6AfSLvChO+bmCVE
VogFsRzNqjOXKhVSbCXPQHHfSSaBC/9Ju6OY4bJPkqEfXg+ksaMhSxZEs5ac
GxElITxzgTIPkFUMmzVrhtzYCY32nMmUaze/YlBfUtTPQdg+j68PBsN6y6HA
mIrvIGCoPnEjY/YMJ3SxFm+FmPyG18OmRgmc2JWa52Gh0YqLe53ItcOgLRD4
VEtiSFlzhuKicLG92Ikb9fYNl7u8KnN47Ouz3+M9mMR7dPiALYGHD7+ThsGY
aksfWzijr7r5Cv5z9ADxxQ67pI+1hx3Tw749HjyMP/7uwcNH7w5YYbwsuMaj
KrRmCZpViuC5Yak+VIh13fZpgtoMC0MvY9YiC03OCC6H6RLRxgs+nctRN9eZ
ZOlpfNWz9rF+cVFwJ21hLmmuUIQxml6pZ5SZQxJZRMg+tX+TTAgdqM2CrDjM
KUZG03u119X4m1674DnWouAGpnBfw9mvKUI2W1f5lluBcvGEBcFgrLJlsDqZ
S0kdsU2IKg0VIRwee1+2MRZwIgohDk74Y3Jv5EtySggHcUYvpvSPWt1ZGD+m
EA3URtdbUqqkehWFcALD2qgphsavTSfQ96CrzXlCA1slXzTYRNcZy1YlAh+S
tC/Vis9Tx8AuKJcxyZFM/5ETFHvLEfUmdSQljydRDrX3nFMS0Y8Zk75C+mR8
RKQUtUf3qVBEFCos9fi+lbZPnFxR5ykaXa+2CcrVqIvcfXnytjuYEpDW+Vm6
HqiH15mxgvJ5Ua5WVbFo3uM4KMW0yn7cwZArgt2rQ+n+42/fGRIXdAT0XgR4
veUjuAk6iheoAWU/TagnaTWNoDoOnpFYw5gimmYcjGp4lIwSqDNcDFoLzV03
zTrJBUj9jE7SK5Vwm6eSKnLgDIlz8ncSfo1qHrm0KbdNjZFh4m+3W8TauXkn
0AhxcIVxhFcGU7i+yTEtfAnL1vS+y6P26WCsRXc589knFc4Kewq+51FiZWoE
GaOwiQ9NwczkOMU3C9LFbOfhyq8YCkWmK2X6W+Kelc+ZGWYbkRZ9gFsvuA8N
tRfjxHirg7RSmi27blcI0TizSRgYbrPZLILnf+0ST6mho2wLhim+l8nbeXvB
TLzz7lHSuwh1bo7LbdvAZDZSrZpPqAYxkh3PfLdIlK4Tqz1cXMrcTpOZdfjk
GJUh+s1zLySlST6dqkncjPJQsJ6PHEFDLMR+54PBcTXu8URnMQmWaFUEirWI
w03uxojHqmkuO+phfUH+vCVaXGFiWvDQpBOlEkI+FauRkRKl532YWnSXS01q
UVHvX3Ljr7r0s6HNJx7KZHvY3pX+3CtqVosLC5YgCgZ7dAy+6OhBjO8oZjEi
DIricKJVuZnOV20LqnXtsoEtQ4DNwW8xLY7eJp3uUDmnXEUsW0JdAXkCUjjL
0rzVPRos4583jSubL2LtYJk/HW2JG1CeKaeE3jAbjnnWYZzlbEf4DZAtlzx7
vQNBsPSwpDNigaRsvUaV7Jk4u2PnsdfPXh+EcMuXrIc/fvzo3bBopa0OR/KY
foKR4z0701LTkuoKcYYJME0WLygfrFh1AV8RPBne61LuR/un5p3P9dfB0CrT
QcKzjw+CkWKALZ5oDb1gfYxoDSLFaMBRm20OKkq9JTSTS9quKlRZr4qbZAmy
qSVAhFGvGESYNUwMB0damwaeo4NUisY781jEsSZKk2sA11NJiRXxWpRVBPch
+9kUK/yAllkKZB+6XPbBQ+zpXeBjgvENibSiiseg39rlPHpj2uJfkQMgsJS8
buS+cc+rmjxm/3sEr/N0/1IC1/zaqIb93AvoNLt79vbnlwdUvtzYsrL7WcZt
5/PsD8XCoFm4ALofElKjwidXrkhWiA5btQ3wPdnTktVhYVb3IjAa78wl+DWM
P5AZ/ODxr96BBrSGMXLxglLquky83liuxVfp7TIDcQ8OJkvzAjZGtcg/81iS
IPKAMP56KhSuLlYrcDd2V4QJcJ6BF5ZNS/qIHSXi6cPGd1K7ljT9fld/+nQ4
aAO9JknYuM4DqSVv6QYy+YnZ+clPrA22UqytWI3W+wiu7p1VKnT9LHLNNkds
LbX7wSyyGx0kbZ8dqVJKy5e8roG+HXsAqNucckS5eR7LLsVF8Xj7oCnsR/c1
sEukh9IXn0XvItIndwwFYx58e3/ie/j6MIg960dIEGxnBBB/FWW7y76vVwQ2
mZ8KY+lVq+RjcHT8WPyxtgdqqIoK7yubTG1uuI2y9WBbQTUcORMRNqi9KhmP
yiNXD8xwhsqu3KGLhUdGb1C0S1tS2xE4ULAxdYlHYZyX/+2jx/ffSZjUdzvm
Ygeg+bRsDtVNoOKNebsq/4LOHxDQnCPqB0qiuirJ3IlN4kEAl6NtCl+6Tcic
p4GnyvwGf4cEAfdNZpqcVs9N/nYZWh8znowHgs4/Zi8Hf+tFco+mX7uBfcTc
vORvze7T98jn8bH/5Cr/yt960Wg+Nu9vJv4eZJzpjwmGib9vw2COfz7exsl/
4ZP+1y2M7xc96urLr75lkW4ZKZ/8X7JUg03/pWNLoZEqgCIeUhWVoVUiGgqQ
KAIkh2rNG8thmdZssD6RON6sIeTI5OQ6RhmVzyKUy4irPDh+8O27WZACl3ot
xZywLAea/a+dNeljQvlVU66SamjW5J2SidjUJzmtAU7S5LD1TtkZPVU3Uv9I
/8ScMVgEsjY1PwfvwRuHldHEhUQllFGGft05OiXMn+ljVjRzKyuT23ydroZC
GUGNaF/vtpKzJ5fBwDBzKqYNpRfTG3qubBVLio01IlmIkOozw5bkNFH/EhwF
v2gmVag4SBS+t2I52V344uz7Z2yfPbz/4ME7i4iQgeZaE/iyixLdITaDZYNA
/8RAJnle37bl+TkH4d5YPWqEYkZi+/AVjFuTruY933BLL9X4E2KklfM/qGoP
ZXqZM5hUwEHtgin8QEx7m872mFHpQTLGS+wPtkGqS1B/2qk+jD0jUYvFVHvu
WpoEyD1gjNyfikOVwlCK/Gynem+JxyABO1lyqKGrzH0whP5o3JXrd1oxsz7u
3KSzhxvnJXDREAwCoI5JDjhK/2/zRnpcoOy3PK/20wCVxjX6VfRQLnlZtNyu
qgXqkbV3XcZHiwM89bRjYhaW/+MSVNfUFmy8KhvM7JtcAerWpkWhuJu4s6r9
iVXS0kKR48WULnZlUtwLHxG795rmihiSLriydTrRocvYHl6niCtX2x67jqWN
68yrr3ETUM9qRCi4EysnmcpO4Xdzd4BHTVqTc8XXk68Pk6OKvTB9B/YKzOCo
1KRBwbjhiTwMxU27W47BrRqgTxcmDDKpEofMc6o91wN3pZ6KPHdbSZ9XoH7L
QC5R4+o2X0UJR2fsClaWyvpI8FSUYgU7sDeFC9RJYDeB4Bsq24o2yfCm4MMS
F8J0RBsRhQolGazZbMQeRVGG843URR5Tc8u68QRJ4pMqvtwBje9J1lpGwc3d
IgFQcGHVkF0746r1KoqJt8Vcb2BYpZTDUvs2YPiLzR9crWF4CI/DlrHDbdY1
6x4BsgbSgpMuYVS+A7hqRUGjeKKoylAn8ZNRTVQDBLgb6OSxxsJMlV7CusHE
MRQ64IyNQymkNEoMpUjsAJeYHCGCeXD6o6t52afI/UmSwAXH92F83LUaTUMQ
X3eWb0needwJ8kf4vRj7wN0QB4fSoekmTiVYkcUV1i9KZzTdMVLukJEHwhL5
HN71rqVgFi0qYcykCMAElnzsLPvwYTK5aFx4QSuxUv6uJDwLLkczd0QuWkOT
JD/HgzjIK0uPPSAN26q1cTmPSAhEYGNOOMhxTeiN/P0x14eNf3Ur0eApIxVY
wpUvmjXxKKldLBflVAVJs5bdxgoHTPjpCYK6DRSZZO3GytU3+xafRjhRxFoX
NjkZeSxTGYwMp/J2RdOwJHU34JnV0cinJMZosQYrEdu7RBZIIr+hdCMLx+fT
h8dFoxIohswFpfWe2s9pNwoN8XoEgrWgbTaGCUtB2C/HTDeLTBdBWwVIrpLa
fXjFy+qaf9lDthcIg0Mu+PnrHao7cl4qQr5WZY0dQVKOgrQbYf6jTmsjFsdl
yliExvvjo6PnTsehX0y8TtMeTNo/U0rfpzxRfeZlvArVKFCffubipPtluybz
cQQFpXqp4ccBWw5uylYzjYgMa6lzqWarwsLxzyWj0SiWY9YxiEv+nWEKIgOm
ZIyookyZA+vaqdXBBW68IbTYtauinpiJbZ4W8K85pQ6pGOUvhpGsjtFQN1Al
ACxARqEkuWJTnTuQfOJURkW/F5HzzKPHXhvtxGliGuRgLNY3CXUVU7Z5VqJ7
YOGDWOAXSxsmWBnrc8Jzkid07F22d3M1wmJtWm40UYLIjLikqKieXyjWY2j9
DLxPrmPCgIGcDva7eL8E4mJmSoUQCCKK6XycOSZC8+522x0cfukDMAswvX0x
ut1CU2l9wMhhLKHz8zdxbBF13XHGIz3gpRU4hAWtXf8YxgNPvTPeIt85Zcx6
Yqtek1yufbFTyBM/+jZdDp7i+VGkxxWWoGFvn3qx2kUJFNgyfhh1hyUVCs+r
m64kNXlVFFvguRZMjHEHetEJdvtIuntFzVZBH9Eocgxwb08baVM2A/nRSHKe
NkLRRF1SmyPlkgmD3+cRtGZHVm1sfzlF3tWQ3u/wmLAwRyoPCPzgzARfhtY1
qYkASAlT6sG1OSrfSoG6qBDdbrFHEeRYG/z/J8FFMhJSBRDa7qxxzRE4iU3x
XOD9Mz2nRr7JejVcD2uJhZk9lHTAaqiUcnYBf5d8k75Pyw8FXyY5tUXQXezy
BTVlq2o6OxURtqb14mI6pbRdAJ4K7Oww+9lZFgmVWF42aVGu9Dz11EaQp/M/
5d0ANa2Y6k5wF/XlAOnaG9Yw9DfbCByPbk6VNg6Pa5WdMX+0WaDDdgDT46SL
ielw/I8KuOK04M8Kfd2+9+EoJ006n3cBpk3mRLctOcvADQSxWes1hhUIOwXr
vUIQIgKiHBJR0jgnPa++GZlHT8de7FE+c+MJAdMlGHmpqjeofa8g4ljx2yUE
b8qOuj2QJ8G6BUhVrn6y7D5q+HAmUadyygU6Gxj3mQKScc00UdVS+MTPbu3w
kDtZQpPkKhkCAjNYzxztqdvCEmeozbzLsplA8IMGD0ssDSgl6/5WhS4sboZs
gHvIq1YwMSkCsoNWCRQYu8AsG+qUWMaegIPCcYlGiCYMOoVyVIqRwz0/eXky
hHD7nw9fge2fz1NkbOwO6X6G7T8RVF43Wb6Mdhq+DF+q0ZJ9L/7wlSbdfMmL
3cs7E8Ns0cFmUq8rUigtkWcC0G1OlUFRdSJwNAh7xjyK1GqLQjLYzHd2RX6w
7kkmleyBgosWMczkYQ1KJ2X9Z6dGCwUsQCO6pKQ/QbDJwxTPh6jGBuvthZhN
yBDVspaks54LnEX0ChwU9AABDVNbAc5WlCyL2CwM5zNLy3aV9UUJKoukllOy
HGd0xGebH9XhPuN80Q1dFedA/RsrLWrlEVSMNVRcC1Sf1UzWJFvnlQfvkS+V
7QxyCFAxvxjxVO3intWXmCxgoFct8TgkKhEpfww+A87U7RbIsrlpxj3XMANY
bvbDVDAlI2CHVGQZdWIQLC3xboGDAMXgOzVzhsgxSTgXM6NZ0BoxRll7wQ07
GP6CPm4wgWcEY5XgIxJBHWJFAvK6Ip8WgyrirZGktvDnFr2qBbW1oDELDFoz
dFUWSkYu3oYAto7FsFhWZGOK879sY8nMLlMkNul3h8E1njRHGa8CZSVbB58F
lWpti9h1EtVreAh8eEPMtKDCM3rsuX/OBrVYH5u/AZa+0fINGSUIabY5pQWN
UrVsq4PWFJLODDIuWdVTl4bDajemThMCFJ/9Iq/nZT2HlZlzfkq4C+rli4NY
kvWkHhw4C2uuBw4vSlmUDC0MoNTrijK0TCLoyViYQkBGYL2yoiQODNkNSzwR
Vi8muUYAeyXZ3+gCoXRQacmkSWQJ2xCryhDjg5IUCc4UJwQ8q91te89m1NLm
PWPPCxEIZ8hKPx+nV3VS3kQKpazhlUTwTQBNYI1Q4inTJOmx0jlyE0tSKhnq
OSHdL5DtSAbnctm0KxK+tGu3cADdHuqohOqfI9VAWO8SlHtkKhM/1KvZrkgF
IzYiucgxEva02S1Bpyjb8CR71aLdAL9s+MvDhX7524a+whp5CJ256kD5Kn5z
5z5CYZ5dgODrmy3qIj+2oJY/ydxH/4EfPfjtEsUL3o5pa/QY2PrlZd1cg515
zhlS4wnk6RUj4Y5CPQfVi89L32dvQFnN21WHjP0NGGV1dgrHuSqvZ8Ci4crs
X5Eb5uicfwNWH+aqNpjXB7T6h6IMr3O47/c5gUxeYo+qv+wu81n2z4jluaD+
b6zAjRZPVYSyJXaNgw3Ek3fnqBKSbyr8X/TLN9AG9AAA
-->
</rfc>