rfc8811xml2.original.xml   rfc8811.xml 
<?xml version="1.0" encoding="us-ascii"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8174.xml">
<!ENTITY I-D.ietf-dots-use-cases SYSTEM "https://xml2rfc.tools.ietf.org/public/r
fc/bibxml3/reference.I-D.ietf-dots-use-cases.xml">
<!ENTITY I-D.ietf-tls-dtls13 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/b
ibxml3/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/pub
lic/rfc/bibxml3/reference.I-D.ietf-dots-signal-channel.xml">
<!ENTITY I-D.ietf-dots-data-channel SYSTEM "https://xml2rfc.tools.ietf.org/publi
c/rfc/bibxml3/reference.I-D.ietf-dots-data-channel.xml">
<!ENTITY I-D.ietf-acme-ip SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibx
ml3/reference.I-D.ietf-acme-ip.xml">
<!ENTITY RFC0768 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.0768.xml">
<!ENTITY RFC0793 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.0793.xml">
<!ENTITY RFC1035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.1035.xml">
<!ENTITY RFC2782 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.2782.xml">
<!ENTITY RFC3235 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.3235.xml">
<!ENTITY RFC3261 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.3261.xml">
<!ENTITY RFC4033 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4033.xml">
<!ENTITY RFC4271 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4271.xml">
<!ENTITY RFC4732 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4732.xml">
<!ENTITY RFC4786 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.4786.xml">
<!ENTITY RFC5128 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5128.xml">
<!ENTITY RFC5246 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5246.xml">
<!ENTITY RFC5780 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5780.xml">
<!ENTITY RFC6347 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6347.xml">
<!ENTITY RFC6887 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6887.xml">
<!ENTITY RFC6763 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6763.xml">
<!ENTITY RFC7092 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7092.xml">
<!ENTITY RFC7094 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7094.xml">
<!ENTITY RFC7350 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7350.xml">
<!ENTITY RFC8085 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8085.xml">
<!ENTITY RFC8446 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8446.xml">
<!ENTITY RFC8512 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8512.xml">
<!ENTITY RFC7658 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7658.xml">
<!ENTITY RFC8612 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8612.xml">
<!ENTITY RFC8555 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8555.xml">
]>
<?rfc rfcedstyle="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc docmapping="yes"?>
<rfc docName="draft-ietf-dots-architecture-18" category="info"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
ipr="trust200902"
docName="draft-ietf-dots-architecture-18"
number="8811"
submissionType="IETF"
category="info"
consensus="true"
obsoletes=""
updates=""
xml:lang="en"
tocInclude="true"
sortRefs="true"
symRefs="true"
version="3">
<front> <front>
<title abbrev="DOTS Architecture">Distributed-Denial-of-Service Open Threat <title abbrev="DOTS Architecture">DDoS Open Threat Signaling (DOTS) Architec
Signaling (DOTS) Architecture</title> ture</title>
<seriesInfo name="RFC" value="8811"/>
<author initials="A." surname="Mortensen" fullname="Andrew Mortensen" role=" editor"> <author initials="A." surname="Mortensen" fullname="Andrew Mortensen" role=" editor">
<organization>Forcepoint</organization> <organization>Forcepoint</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city></city> <city/>
<code></code> <code/>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<email>andrewmortensen@gmail.com</email> <email>andrewmortensen@gmail.com</email>
</address> </address>
</author> </author>
<author initials="T." surname="Reddy" fullname="Tirumaleswar Reddy" role="ed itor"> <author initials="T." surname="Reddy.K" fullname="Tirumaleswar Reddy.K" role ="editor">
<organization>McAfee, Inc.</organization> <organization>McAfee, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Embassy Golf Link Business Park</street> <street>Embassy Golf Link Business Park</street>
<city>Bangalore, Karnataka</city> <city>Bangalore</city><region>Karnataka</region>
<code>560071</code> <code>560071</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>kondtir@gmail.com</email> <email>kondtir@gmail.com</email>
</address> </address>
</author> </author>
<author initials="F." surname="Andreasen" fullname="Flemming Andreasen"> <author initials="F." surname="Andreasen" fullname="Flemming Andreasen">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city></city> <city/>
<code></code> <code/>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<email>fandreas@cisco.com</email> <email>fandreas@cisco.com</email>
</address> </address>
</author> </author>
<author initials="N." surname="Teague" fullname="Nik Teague"> <author initials="N." surname="Teague" fullname="Nik Teague">
<organization>Iron Mountain</organization> <organization>Iron Mountain</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city></city> <city/>
<code></code> <code/>
<country>United States</country> <country>United States of America</country>
</postal> </postal>
<email>nteague@ironmountain.co.uk</email> <email>nteague@ironmountain.co.uk</email>
</address> </address>
</author> </author>
<author initials="R." surname="Compton" fullname="Rich Compton"> <author initials="R." surname="Compton" fullname="Rich Compton">
<organization>Charter</organization> <organization>Charter</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city></city> <city/>
<code></code> <code/>
</postal> </postal>
<email>Rich.Compton@charter.com</email> <email>Rich.Compton@charter.com</email>
</address> </address>
</author> </author>
<date year="2020" month="August"/>
<date />
<area>Security</area> <area>Security</area>
<workgroup>DOTS</workgroup> <workgroup>DOTS</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>This document describes an architecture for establishing and
<t>This document describes an architecture for establishing and maintaining maintaining Distributed Denial-of-Service (DDoS) Open Threat Signaling
Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) within and (DOTS) within and between domains. The document does not specify
between domains. The document does not specify protocols or protocol protocols or protocol extensions, instead focusing on defining
extensions, instead focusing on defining architectural relationships, components architectural relationships, components, and concepts used in a DOTS
and concepts used in a DOTS deployment.</t> deployment.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="context-and-motivation" title="Context and Motivation"> <section anchor="context-and-motivation" numbered="true" toc="default">
<name>Context and Motivation</name>
<t>Signaling the need for help to defend against an active distributed denial <t>Signaling the need for help to defend against an active distributed
of service (DDoS) attack requires a common understanding of mechanisms and denial-of-service (DDoS) attack requires a common understanding of
roles among the parties coordinating defensive response. The signaling mechanisms and roles among the parties coordinating a defensive
layer and supplementary messaging is the focus of DDoS Open Threat Signaling response. The signaling layer and supplementary messaging are the focus
(DOTS). DOTS defines a method of coordinating defensive measures among willing of DDoS Open Threat Signaling (DOTS). DOTS defines a method of
peers to mitigate attacks quickly and efficiently, enabling hybrid attack coordinating defensive measures among willing peers to mitigate attacks
responses coordinated locally at or near the target of an active attack, or quickly and efficiently, enabling hybrid attack responses coordinated
anywhere in-path between attack sources and target. Sample DOTS use cases locally at or near the target of an active attack, or anywhere in path
are elaborated in <xref target="I-D.ietf-dots-use-cases"></xref>.</t> between attack sources and target. Sample DOTS use cases are elaborated
in <xref target="I-D.ietf-dots-use-cases" format="default"/>.</t>
<t>This document describes an architecture used in establishing, maintaining or <t>This document describes an architecture used in establishing,
terminating a DOTS relationship within a domain or between domains.</t> maintaining, or terminating a DOTS relationship within a domain or
between domains.</t>
<section anchor="terminology" title="Terminology"> <section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name>
<section anchor="key-words" title="Key Words"> <section anchor="key-words" 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", and "OPTIONAL"
in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <
xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t>
</section>
<section anchor="definition-of-terms" title="Definition of Terms">
<t>This document uses the terms defined in <xref target="RFC8612"></xref>.</t>
</section>
</section>
<section anchor="scope" title="Scope">
<t>In this architecture, DOTS clients and servers communicate using DOTS
signal channel <xref target="I-D.ietf-dots-signal-channel"></xref> and
data channel <xref target="I-D.ietf-dots-data-channel"></xref> protocols.</t>
<t>The DOTS architecture presented here is applicable across network administrat
ive
domains &#8211; for example, between an enterprise domain and the domain of a
third-party attack mitigation service &#8211; as well as to a single administrat
ive
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 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>, 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">
<t>This document makes the following assumptions:</t>
<t><list style="symbols">
<t>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 and resource exhaustion are intended outcomes of a DDoS attack
<xref target="RFC4732"/>. Some operators may utilize non-impacted paths or netwo
rks for
DOTS, but in general conditions should be assumed to be 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>. DOTS signal channel defined in
<xref target="I-D.ietf-dots-signal-channel"></xref> is designed to be extremely
resilient under extremely hostile network conditions and provides continued cont
act between
DOTS agents even as DDoS attack traffic saturates the link.</t>
<t>There is no universal DDoS attack scale threshold triggering a coordinated
response across administrative domains. A network domain administrator, or
service or application owner may arbitrarily set attack scale threshold
triggers, or manually send requests for mitigation.</t>
<t>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. For example, a DOTS client of a multi-homed network may
support built-in policies to establish DOTS relationships with DOTS servers
located upstream of each interconnection link.</t>
<t>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, or may involve a third-party domain.</t>
<t>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 and DOTS client 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 architecture allows for, but does not assume, the presence of Quality o
f
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 signal and data channels are loosely coupled, and might not terminate o
n
the same DOTS server. How the DOTS servers synchronize the DOTS configuration is
out of scope of this specification. </t>
</list></t>
</section>
</section>
<section anchor="architecture" title="DOTS Architecture">
<t>The basic high-level DOTS architecture is illustrated in <xref target="fig-ba <t>
sic-arch"/>:</t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY<
/bcp14>", and
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as describe
d in
BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
only when, they appear in all capitals, as shown here.
</t>
<figure title="Basic DOTS Architecture" anchor="fig-basic-arch"><artwork><![CDAT </section>
A[ <section anchor="definition-of-terms" numbered="true" toc="default">
<name>Definition of Terms</name>
<t>This document uses the terms defined in <xref target="RFC8612" form
at="default"/>.</t>
</section>
</section>
<section anchor="scope" numbered="true" toc="default">
<name>Scope</name>
<t>In this architecture, DOTS clients and servers communicate using
DOTS signal channel <xref target="RFC8782" format="default"/> and data
channel <xref target="RFC8783" format="default"/> protocols.</t>
<t>The DOTS architecture presented here is applicable across network
administrative domains, for example, between an enterprise domain and
the domain of a third-party attack mitigation 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" 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" numbered="true" toc="default">
<name>Assumptions</name>
<t>This document makes the following assumptions:</t>
<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.</li>
<li>Congestion and resource exhaustion are intended outcomes of a
DDoS attack <xref target="RFC4732" format="default"/>. Some
operators may utilize non-impacted paths or networks for
DOTS. However,
in general, conditions should be assumed to be 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 <xref target="RFC8612"
sectionFormat="of" section="3"/>. The DOTS signal channel defined in <
xref
target="RFC8782" format="default"/> is designed to be extremely
resilient under extremely hostile network conditions, and it
provides
continued contact between DOTS agents even as DDoS attack traffic
saturates the link.</li>
<li>There is no universal DDoS attack scale threshold triggering a
coordinated response across administrative domains. A network domain
administrator or service or application owner may arbitrarily set
attack scale threshold triggers, or manually send requests for
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. For example,
a DOTS client of a multihomed network may support built-in policies
to establish DOTS relationships with DOTS servers located upstream
of each interconnection 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 or may involve a third-party 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 servers and DOTS 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.</li>
<li>The architecture allows for, but does not assume, the presence
of 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.</li>
<li>The signal and data channels are loosely 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. </li>
</ul>
</section>
</section>
<section anchor="architecture" numbered="true" toc="default">
<name>DOTS Architecture</name>
<t>The basic high-level DOTS architecture is illustrated in <xref target="
fig-basic-arch" format="default"/>:</t>
<figure anchor="fig-basic-arch">
<name>Basic DOTS Architecture</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-----------+ +-------------+ +-----------+ +-------------+
| Mitigator | ~~~~~~~~~~ | DOTS Server | | Mitigator | ~~~~~~~~~~ | DOTS Server |
+-----------+ +-------------+ +-----------+ +-------------+
| |
| |
| |
+---------------+ +-------------+ +---------------+ +-------------+
| Attack Target | ~~~~~~ | DOTS Client | | Attack Target | ~~~~~~ | DOTS Client |
+---------------+ +-------------+ +---------------+ +-------------+
]]></artwork></figure> ]]></artwork>
</figure>
<t>A simple example instantiation of the DOTS architecture could be an enterpris <t>A simple example instantiation of the DOTS architecture could be an
e enterprise as the attack target for a volumetric DDoS attack and an
as the attack target for a volumetric DDoS attack, and an upstream DDoS upstream DDoS mitigation service as the mitigator. The service provided
mitigation service as the mitigator. The service provided by the mitigator by the mitigator is called "DDoS mitigation service". The enterprise
is called: DDoS mitigation service. The enterprise (attack target) is (attack target) is connected to the Internet via a link that is getting
connected to the Internet via a link that is getting saturated, and the saturated, and the enterprise suspects it is under DDoS attack.
enterprise suspects it is under DDoS attack. The enterprise has a DOTS client,
which obtains information about the DDoS attack, and signals the DOTS server
for help in mitigating the attack. The DOTS server in turn invokes one or more
mitigators, which are tasked with mitigating the actual DDoS 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, nor does DOTS specify how a
mitigator may actually mitigate such an attack. A DOTS client's request for
mitigation is advisory in 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"/>, there are two interfaces b
etween a
DOTS server and a DOTS client; a signal channel and (optionally) a data channel.
</t>
<figure title="DOTS Interfaces" anchor="fig-interfaces"><artwork><![CDATA[
+---------------+ +---------------+
| | <------- Signal Channel ------> | |
| DOTS Client | | DOTS Server |
| | <======= Data Channel ======> | |
+---------------+ +---------------+
]]></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, 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 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 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, 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 at a minimum provides client (attack target)
health information, but 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 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 more efficient
capabilities. The primary purpose of the data channel is to support 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 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 management, which enables a DOTS client to inform the DOTS server
about sources to suppress.</t>
<t>Accept-list management, which enables a DOTS client to inform the DOTS serv
er
about sources from which traffic is always accepted.</t>
<t>Filter management, which enables a DOTS client to install or remove traffic
filters dropping or rate-limiting unwanted traffic.</t>
<t>DOTS client provisioning.</t>
</list></t>
<t>Note that while it is possible to exchange the above information before, duri
ng
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">
<t>DOTS does not prescribe any specific deployment models, however DOTS is desig
ned
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 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 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 communication is possible at this
time between the DOTS client and DOTS server. Furthermore, it is assumed that
additional service provisioning, configuration and information exchange can be
performed by use of the data 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> and DNS <xref target="RFC1035"></xr
ef>. The mitigator in turn inspects and
scrubs the 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>
<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">
<section anchor="dots-client" title="DOTS Client">
<t>A DOTS client is a DOTS agent from which requests for help coordinating attac
k
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, 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> (SIG-008). T
he 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 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, and may consider a session
terminated in the extended absence of a DOTS server heartbeat.</t>
</section>
<section anchor="dots-server" title="DOTS Server">
<t>A DOTS server is a DOTS agent capable of receiving, processing and possibly
acting on requests for help coordinating attack response from DOTS clients. The
DOTS server authenticates and authorizes DOTS clients as described in
<xref target="dots-sessions"/>, and maintains session state, tracking requests f
or
mitigation, reporting on the status of active mitigations, and terminating
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 a
n
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 and aliases for resources from DOTS clie
nts.
The mechanism of enforcement is not in scope for this
document, but is expected to restrict mitigation requests, filtering rules and a
liases
scope to addresses, prefixes, and/or services owned by the DOTS client domain, s
uch that a DOTS
client from one domain is not able to influence the network path to another
domain. A DOTS server MUST reject mitigation requests, filtering rules and alias
es for
resources not owned by the requesting DOTS client's administrative domain. The e
xact mechanism
for the DOTS servers to validate that the resources are within the scope of
the DOTS client domain is deployment-specific. For example, if the DOTS client d
omain uses Provider-Aggregatable prefixes for its resources and
leverages the DDoS mitigation service of the Internet Transit Provider (ITP), th
e 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 DDoS mitigation service provider, it does not know the resources own
ed by the DOTS client domain. The DDoS mitigation
service provider and the DOTS client domain can opt to use the identifier valida
tion
challenges discussed in <xref target="RFC8555"/> and <xref target="I-D.ietf-acme
-ip"></xref>
to identify whether 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 D
OTS client
lies about the resources owned by the DOTS client domain, the DDoS mitigation se
rvice provider
can impose penalties for violating the service level agreement. A DOTS server MA
Y also
refuse a DOTS client's mitigation request for arbitrary reasons, within any limi
ts
imposed by business or service level agreements between client and server domain
s.
If a DOTS server refuses a DOTS client's request for mitigation, the DOTS server
MUST
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: 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 report
the actual scope of any mitigation enabled on behalf of a client.</t>
<t>The DOTS server SHOULD retrieve available metrics for any mitigations activat
ed
on behalf of a DOTS client, and SHOULD 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 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, and MAY consider a session
terminated in the extended absence of a DOTS client heartbeat.</t>
</section> The enterprise has a DOTS client, which obtains information about the
<section anchor="dots-gateway" title="DOTS Gateway"> DDoS attack and signals the DOTS server for help in mitigating the
attack. In turn, the DOTS server invokes one or more mitigators, which
are tasked with mitigating the actual DDoS 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
nor does DOTS specify how a mitigator may actually mitigate such an
attack. A DOTS client's request for mitigation is advisory in 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" format="default"/>,
there are two interfaces between a DOTS server and a DOTS client: a
signal channel and (optionally) a data channel.</t>
<figure anchor="fig-interfaces">
<name>DOTS Interfaces</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---------------+ +---------------+
| | <------- Signal Channel ------> | |
| DOTS Client | | DOTS Server |
| | <======= Data Channel ======> | |
+---------------+ +---------------+
]]></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 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 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. In turn, the DOTS server 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 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, at a minimum, provides client (attack target) health
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, 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,
more efficient capabilities. The primary purpose of the data channel is
to support 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>
<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. </li>
</ul>
<ul spacing="normal">
<li>Drop-list management, which enables a DOTS client to inform the
DOTS server about sources to suppress.</li>
<li>Accept-list management, which enables a DOTS client to inform the
DOTS server about sources from which traffic is always accepted.</li>
<li>Filter management, which enables a DOTS client to install or
remove traffic filters dropping or rate-limiting unwanted
traffic.</li>
<li>DOTS client provisioning.</li>
</ul>
<t>Note that, while it is possible to exchange the above information
before, 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" numbered="true" toc="default">
<name>DOTS Operations</name>
<t>DOTS does not prescribe any specific deployment 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
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, 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 bidirectional
communication is possible at this time between the DOTS client and
DOTS server. Furthermore, it is assumed that additional service
provisioning, configuration, and information exchange can be performed
by use of the data 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"
format="default"/> and DNS <xref target="RFC1035"
format="default"/>. In turn, the mitigator inspects and scrubs the
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>
<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" numbered="true" toc="default">
<name>Components</name>
<t>Traditional client/server relationships may be expanded by chaining DOTS <section anchor="dots-client" numbered="true" toc="default">
sessions. This chaining is enabled through "logical concatenation" of a DOTS <name>DOTS Client</name>
server and a DOTS client, resulting in an application analogous to the Session <t>A DOTS client is a DOTS agent from which requests for help
Initiation Protocol (SIP) <xref target="RFC3261"/> logical entity of a Back-to-B coordinating an attack response originate. The requests may be in
ack User response to an active, ongoing attack against a target in the DOTS
Agent (B2BUA) <xref target="RFC7092"></xref>. The term DOTS gateway is used here client domain, but no active attack is required for a DOTS client to
in the descriptions request help. Operators may wish to have upstream mitigators in the
of selected scenarios involving this application.</t> network path for an indefinite 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" 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 (SLAs) and are out of scope for th
is
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 and may consider a session terminated in the
extended absence of a DOTS server heartbeat.</t>
</section>
<t>A DOTS gateway may be deployed client-side, server-side or both. The gateway <section anchor="dots-server" numbered="true" toc="default">
may terminate multiple discrete client connections and may aggregate these into <name>DOTS Server</name>
a single or multiple DOTS sessions.</t>
<t>The DOTS gateway will appear as a server to its downstream agents and as a <t>A DOTS server is a DOTS agent capable of receiving, processing,
client to its upstream agents, a functional concatenation of the DOTS client and and possibly acting on requests for help coordinating attack
server roles, as depicted in <xref target="fig-dots-gateway"/>:</t> responses from DOTS clients. The DOTS server authenticates and
authorizes DOTS clients as described in <xref target="dots-sessions"
format="default"/> and maintains session state, tracks requests
for mitigation, reports on the status of active mitigations, and
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>
<figure title="DOTS gateway" anchor="fig-dots-gateway"><artwork><![CDATA[ <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, and aliases for resources from DOTS clients. The mechanism of
enforcement is not in scope for this document but is expected to
restrict mitigation requests, filtering rules, aliases 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 <bcp14>MUST</bcp14>
reject mitigation requests, filtering 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. 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); 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 DDoS mitigation service 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" format="default"/> and <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 SLA. A DOTS server <bcp14>MAY</bcp14> also refuse
a DOTS client's mitigation request for arbitrary reasons, within any
limits imposed by business or SLAs between client and server
domains. If a DOTS server refuses a DOTS client's request for
mitigation, the DOTS server <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; 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 <bcp14>MUST</bcp14> report the actual scope of any
mitigation enabled on behalf of a client.</t>
<t>The DOTS server <bcp14>SHOULD</bcp14> retrieve available metrics
for any mitigations activated on behalf of a DOTS client and
<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 <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 and <bcp14>MAY</bcp14>
consider a session terminated in the extended absence of a DOTS
client heartbeat.</t>
</section>
<section anchor="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" format="default"/> logical entity of a Back-to-Back
User Agent (B2BUA) <xref target="RFC7092" format="default"/>. The
term "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, or both.
The gateway may terminate multiple discrete client connections and
may aggregate these into a single or multiple DOTS 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" format="default"/>:</t>
<figure anchor="fig-dots-gateway">
<name>DOTS Gateway</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-------------+ +-------------+
| | D | | | | D | |
+----+ | | O | | +----+ +----+ | | O | | +----+
| c1 |----------| s1 | T | c2 |---------| s2 | | c1 |----------| s1 | T | c2 |---------| s2 |
+----+ | | S | | +----+ +----+ | | S | | +----+
| | G | | | | G | |
+-------------+ +-------------+
]]></artwork></figure> ]]></artwork>
</figure>
<t>The DOTS gateway MUST perform full stack DOTS session termination and <t>The DOTS gateway <bcp14>MUST</bcp14> perform full stack DOTS
reorigination between its client and server side. The details of how this is session termination and reorigination between its client and server
achieved are implementation specific. </t> side. The details of how this is achieved are implementation
specific. </t>
</section> </section>
</section> </section>
<section anchor="agent-relationships" title="DOTS Agent Relationships"> <section anchor="agent-relationships" numbered="true" toc="default">
<name>DOTS Agent Relationships</name>
<t>So far, we have only considered a relatively simple scenario of a single DOTS <t>So far, we have only considered a relatively simple scenario of a
client associated with a single DOTS server, however DOTS supports more advanced single DOTS client associated with a single DOTS server; however, DOTS
relationships.</t> supports more advanced relationships.</t>
<t>A DOTS server may be associated with one or more DOTS clients, and th
<t>A DOTS server may be associated with one or more DOTS clients, and those DOTS ose DOTS
clients may belong to different domains. An example scenario is a mitigation clients may belong to different domains. An example scenario is a mitigation
provider serving multiple attack targets (<xref target="fig-multi-client-server" provider serving multiple attack targets (<xref target="fig-multi-client-server"
/>).</t> format="default"/>).</t>
<figure anchor="fig-multi-client-server">
<figure title="DOTS server with multiple clients" anchor="fig-multi-client-serve <name>DOTS Server with Multiple Clients</name>
r"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
DOTS clients DOTS server DOTS clients DOTS server
+---+ +---+
| c |----------- | c |-----------
+---+ \ +---+ \
c1.example.org \ c1.example.org \
\ \
+---+ \ +---+ +---+ \ +---+
| c |----------------| S | | c |----------------| S |
+---+ / +---+ +---+ / +---+
c1.example.com / dots1.example.net c1.example.com / dots1.example.net
/ /
+---+ / +---+ /
| c |----------- | c |-----------
+---+ +---+
c2.example.com c2.example.com
]]></artwork></figure> ]]></artwork>
</figure>
<t>A DOTS client may be associated with one or more DOTS servers, and those DOTS <t>A DOTS client may be associated with one or more DOTS servers, and th
ose DOTS
servers may belong to different domains. This may be to ensure high servers may belong to different domains. This may be to ensure high
availability or co-ordinate mitigation with more than one directly connected availability or coordinate mitigation with more than one directly connected
ISP. An example scenario is for an enterprise to have DDoS mitigation service 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 from multiple providers, as shown in <xref target="fig-multi-homed-client" forma
> t="default"/>.</t>
<figure anchor="fig-multi-homed-client">
<figure title="Multi-Homed DOTS Client" anchor="fig-multi-homed-client"><artwork <name>Multihomed DOTS Client</name>
><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
DOTS client DOTS servers DOTS client DOTS servers
+---+ +---+
-----------| S | -----------| S |
/ +---+ / +---+
/ dots1.example.net / dots1.example.net
/ /
+---+/ +---+ +---+/ +---+
| c |---------------| S | | c |---------------| S |
+---+\ +---+ +---+\ +---+
\ dots.example.org \ dots.example.org
\ \
\ +---+ \ +---+
-----------| S | -----------| S |
+---+ +---+
c.example.com dots2.example.net c.example.com dots2.example.net
]]></artwork></figure> ]]></artwork>
</figure>
<t>Deploying a multi-homed client requires extra care and planning, as the DOTS <t>Deploying a multihomed client requires extra care and planning, as th
servers with which the multi-homed client communicates might not be affiliated. e DOTS
Should the multi-homed client simultaneously request for mitigation from all servers with which the multihomed client communicates might not be affiliated.
Should the multihomed client simultaneously request for mitigation from all
servers with which it has established signal channels, the client may servers with which it has established signal channels, the client may
unintentionally inflict additional network disruption on the resources it unintentionally inflict additional network disruption on the resources it
intends to protect. In one of the worst cases, a multi-homed DOTS client could intends to protect. In one of the worst cases, a multihomed DOTS client could
cause a permanent routing loop of traffic destined for the client's cause a permanent routing loop of traffic destined for the client's
protected services, as the uncoordinated DOTS servers' mitigators all try to protected services, as the uncoordinated DOTS servers' mitigators all try to
divert that traffic to their own scrubbing centers.</t> divert that traffic to their own scrubbing centers.</t>
<t>The DOTS protocol itself provides no fool-proof method to prevent suc
<t>The DOTS protocol itself provides no fool-proof method to prevent such h
self-inflicted harms as a result deploying multi-homed DOTS clients. If self-inflicted harms as a result of deploying multihomed DOTS clients. If
DOTS client implementations nevertheless include support for multi-homing, they DOTS client implementations nevertheless include support for multihoming, they
are expected to be aware of the risks, and consequently to include measures are expected to be aware of the risks, and consequently to include measures
aimed at reducing the likelihood of negative outcomes. Simple measures might aimed at reducing the likelihood of negative outcomes. Simple measures might
include:</t> include:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Requesting mitigation serially, ensuring only one mitigation reque
<t>Requesting mitigation serially, ensuring only one mitigation request for st for
a given address space is active at any given time;</t> a given address space is active at any given time;</li>
<t>Dividing the protected resources among the DOTS servers, such that no two <li>Dividing the protected resources among the DOTS servers, such that
mitigators will be attempting to divert and scrub the same traffic;</t> no two
<t>Restricting multi-homing to deployments in which all DOTS servers are mitigators will be attempting to divert and scrub the same traffic;</li>
coordinating management of a shared pool of mitigation resources.</t> <li>Restricting multihoming to deployments in which all DOTS servers a
</list></t> re
coordinating management of a shared pool of mitigation resources.</li>
<section anchor="gatewayed-signaling" title="Gatewayed Signaling"> </ul>
<section anchor="gatewayed-signaling" numbered="true" toc="default">
<t>As discussed in <xref target="dots-gateway"/>, a DOTS gateway is a logical fu <name>Gatewayed Signaling</name>
nction chaining <t>As discussed in <xref target="dots-gateway" format="default"/>, a
DOTS sessions through concatenation of a DOTS server and DOTS client.</t> 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"/> and <t>An example scenario, as shown in <xref
<xref target="fig-client-gateway-noagg"/>, is for an enterprise to have deployed target="fig-client-gateway-agg" format="default"/> and <xref
multiple target="fig-client-gateway-noagg" format="default"/>, is for an
DOTS capable devices which are able to signal intra-domain using TCP <xref targe enterprise to have deployed multiple DOTS-capable devices that are
t="RFC0793"></xref> able to signal intra-domain using TCP <xref target="RFC0793"
on un-congested links to a DOTS gateway which may then transform these to a UDP format="default"/> on uncongested links to a DOTS gateway that may
<xref target="RFC0768"></xref> transport inter-domain where connection oriented then transform these to a UDP <xref target="RFC0768"
transports may format="default"/> transport inter-domain where connection-oriented
degrade; this applies to the signal channel only, as the data channel requires a transports may degrade; this applies to the signal channel only, as
connection-oriented transport. The relationship between the gateway and its the data channel requires a connection-oriented transport. The
upstream agents is opaque to the initial clients.</t> relationship between the gateway and its upstream agents is opaque
to the initial clients.</t>
<figure title="Client-Side Gateway with Aggregation" anchor="fig-client-gateway- <figure anchor="fig-client-gateway-agg">
agg"><artwork><![CDATA[ <name>Client-Side Gateway with Aggregation</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---+ +---+
| c |\ | c |\
+---+ \ +---+ +---+ \ +---+
\-----TCP-----| D | +---+ \-----TCP-----| D | +---+
+---+ | O | | | +---+ | O | | |
| c |--------TCP-----| T |------UDP------| S | | c |--------TCP-----| T |------UDP------| S |
+---+ | S | | | +---+ | S | | |
/-----TCP-----| G | +---+ /-----TCP-----| G | +---+
+---+ / +---+ +---+ / +---+
| c |/ | c |/
+---+ +---+
example.com example.com example.net example.com example.com example.net
DOTS clients DOTS gateway (DOTSG) DOTS server DOTS clients DOTS gateway (DOTSG) DOTS server
]]></artwork></figure> ]]></artwork>
</figure>
<figure title="Client-Side Gateway without Aggregation" anchor="fig-client-gatew <figure anchor="fig-client-gateway-noagg">
ay-noagg"><artwork><![CDATA[ <name>Client-Side Gateway without Aggregation</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---+ +---+
| c |\ | c |\
+---+ \ +---+ +---+ \ +---+
\-----TCP-----| D |------UDP------+---+ \-----TCP-----| D |------UDP------+---+
+---+ | O | | | +---+ | O | | |
| c |--------TCP-----| T |------UDP------| S | | c |--------TCP-----| T |------UDP------| S |
+---+ | S | | | +---+ | S | | |
/-----TCP-----| G |------UDP------+---+ /-----TCP-----| G |------UDP------+---+
+---+ / +---+ +---+ / +---+
| c |/ | c |/
+---+ +---+
example.com example.com example.net example.com example.com example.net
DOTS clients DOTS gateway (DOTSG) DOTS server DOTS clients DOTS gateway (DOTSG) DOTS server
]]></artwork></figure> ]]></artwork>
</figure>
<t>This may similarly be deployed in the inverse scenario where the gateway resi <t>This may similarly be deployed in the inverse scenario where the ga
des teway resides
in the server-side domain and may be used to terminate and/or aggregate multiple in the server-side domain and may be used to terminate and/or aggregate multiple
clients to single transport as shown in figures <xref target="fig-server-gateway clients to a single transport as shown in <xref target="fig-server-gateway-agg"
-agg"/> and format="default"/> and
<xref target="fig-server-gateway-noagg"/>.</t> <xref target="fig-server-gateway-noagg" format="default"/>.</t>
<figure anchor="fig-server-gateway-agg">
<figure title="Server-Side Gateway with Aggregation" anchor="fig-server-gateway- <name>Server-Side Gateway with Aggregation</name>
agg"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+---+ +---+
| c |\ | c |\
+---+ \ +---+ +---+ \ +---+
\-----UDP-----| D | +---+ \-----UDP-----| D | +---+
+---+ | O | | | +---+ | O | | |
| c |--------TCP-----| T |------TCP------| S | | c |--------TCP-----| T |------TCP------| S |
+---+ | S | | | +---+ | S | | |
/-----TCP-----| G | +---+ /-----TCP-----| G | +---+
+---+ / +---+ +---+ / +---+
| c |/ | c |/
+---+ +---+
example.com example.net example.net example.com example.net example.net
DOTS clients DOTS gateway (DOTSG) DOTS server DOTS clients DOTS gateway (DOTSG) DOTS server
]]></artwork></figure> ]]></artwork>
</figure>
<figure title="Server-Side Gateway without Aggregation" anchor="fig-server-gatew <figure anchor="fig-server-gateway-noagg">
ay-noagg"><artwork><![CDATA[ <name>Server-Side Gateway without Aggregation</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---+ +---+
| c |\ | c |\
+---+ \ +---+ +---+ \ +---+
\-----UDP-----| D |------TCP------+---+ \-----UDP-----| D |------TCP------+---+
+---+ | O | | | +---+ | O | | |
| c |--------TCP-----| T |------TCP------| S | | c |--------TCP-----| T |------TCP------| S |
+---+ | S | | | +---+ | S | | |
/-----UDP-----| G |------TCP------+---+ /-----UDP-----| G |------TCP------+---+
+---+ / +---+ +---+ / +---+
| c |/ | c |/
+---+ +---+
example.com example.net example.net example.com example.net example.net
DOTS clients DOTS gateway (DOTSG) DOTS server DOTS clients DOTS gateway (DOTSG) DOTS server
]]></artwork></figure> ]]></artwork>
</figure>
<t>This document anticipates scenarios involving multiple DOTS gateways. An exam <t>This document anticipates scenarios involving multiple DOTS gateway
ple s. An example
is a DOTS gateway at the network client's side, and another one at the server is a DOTS gateway at the network client's side and another one at the server
side. The first gateway can be located at a Customer Premises Equipment (CPE) to side. The first gateway can be located at Customer Premises Equipment (CPE) to a
aggregate requests from ggregate requests from
multiple DOTS clients enabled in an enterprise network. The second DOTS gateway 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 is deployed on the provider side. This scenario can be seen as a combination of
the client-side and server-side scenarios.</t> the client-side and server-side scenarios.</t>
</section>
</section> </section>
</section> </section>
</section> <section anchor="concepts" numbered="true" toc="default">
<section anchor="concepts" title="Concepts"> <name>Concepts</name>
<section anchor="dots-sessions" numbered="true" toc="default">
<section anchor="dots-sessions" title="DOTS Sessions"> <name>DOTS Sessions</name>
<t>In order for DOTS to be effective as a vehicle for DDoS mitigation
<t>In order for DOTS to be effective as a vehicle for DDoS mitigation requests, requests, one or more DOTS clients must establish ongoing
one or more DOTS clients must establish ongoing communication with one or more communication with one or more DOTS servers. While the preconditions
DOTS servers. While the preconditions for enabling DOTS in or among network for enabling DOTS in or among network domains may also involve
domains may also involve business relationships, service level agreements, or business relationships, SLAs, or other formal or
other formal or informal understandings between network operators, such informal understandings between network operators, such considerations
considerations are out of scope for this document.</t> are out of scope for this document.</t>
<t>A DOTS session is established to support bilateral exchange of data
<t>A DOTS session is established to support bilateral exchange of data between a between an associated DOTS client and a DOTS server. In the DOTS
n architecture, data is exchanged between DOTS agents over signal and
associated DOTS client and a DOTS server. In the DOTS architecture, data is data channels. As such, a DOTS session can be a DOTS signal channel
exchanged between DOTS agents over signal and data channels. As such, a DOTS session, a DOTS data channel session, or both. The DOTS server couples
session can be a DOTS signal channel session, a DOTS data channel session, or the DOTS signal and data channel sessions using the DOTS client
both. The DOTS server couples the DOTS signal and data channel sessions identity. The DOTS session is further elaborated in the DOTS signal
using the DOTS client identity. The DOTS session is further elaborated in the channel protocol defined in <xref target="RFC8782" format="default"/>
DOTS signal channel protocol defined in <xref target="I-D.ietf-dots-signal-chann and the DOTS data channel protocol defined in <xref target="RFC8783"
el"></xref> format="default"/>.</t>
and the DOTS data channel protocol defined in <xref target="I-D.ietf-dots-data-c <t>A DOTS agent can maintain one or more DOTS sessions.</t>
hannel"></xref>.</t> <t>A DOTS signal channel session is associated with a single transport
connection (TCP or UDP session) and a security association (a TLS or
<t>A DOTS agent can maintain one or more DOTS sessions.</t> DTLS session). Similarly, a DOTS data channel session is associated
with a single TCP connection and a TLS security association.</t>
<t>A DOTS signal channel session is associated with a single transport connectio <t>Mitigation requests created using the DOTS signal channel are not bou
n nd
(TCP or UDP session) and an security association (a TLS or DTLS to the DOTS signal channel session. Instead, mitigation requests are
session). Similarly, a DOTS data channel session is associated with a single associated with a DOTS client and can be managed using different DOTS
TCP connection and an TLS security association.</t> signal channel sessions.</t>
<section anchor="dots-session-preconditions" numbered="true" toc="defaul
<t>Mitigation requests created using DOTS signal channel are not bound to the DO t">
TS <name>Preconditions</name>
signal channel session. Instead, mitigation requests are associated with a DOTS <t>Prior to establishing a DOTS session between agents, the owners
client and can be managed using different DOTS signal channel sessions.</t> of the networks, domains, services or applications involved are
assumed to have agreed upon the terms of the relationship
<section anchor="dots-session-preconditions" title="Preconditions"> involved. Such agreements are out of scope for this document but
must be in place for a functional DOTS architecture.</t>
<t>Prior to establishing a DOTS session between agents, the owners of the networ <t>It is assumed that, as part of any DOTS service agreement, the
ks, DOTS client is provided with all data and metadata required to
domains, services or applications involved are assumed to have agreed upon the establish communication with the DOTS server. Such data and metadata
terms of the relationship involved. Such agreements are out of scope for this would include any cryptographic information necessary to meet the
document, but must be in place for a functional DOTS architecture.</t> message confidentiality, integrity, and authenticity requirement
(SEC-002) in <xref target="RFC8612" format="default"/> and might
<t>It is assumed that as part of any DOTS service agreement, the DOTS client is also include the pool of DOTS server addresses and ports the DOTS
provided with all data and metadata required to establish communication with the client should use for signal and data channel messaging.</t>
DOTS server. Such data and metadata would include any cryptographic information </section>
necessary to meet the message confidentiality, integrity and authenticity <section anchor="establishing-dots-session" numbered="true" toc="default
requirement (SEC-002) in <xref target="RFC8612"></xref>, and might also include ">
the pool of <name>Establishing the DOTS Session</name>
DOTS server addresses and ports the DOTS client should use for signal and data <t>With the required business agreements in place, the DOTS client
channel messaging.</t> initiates a DOTS session by contacting its DOTS server(s) over the
signal channel and (possibly) the data channel. To allow for DOTS
</section> service flexibility, neither the order of contact nor the time
<section anchor="establishing-dots-session" title="Establishing the DOTS Session interval between channel creations is specified. A DOTS client
"> <bcp14>MAY</bcp14> establish the signal channel first, and then the
data channel, or vice versa.</t>
<t>With the required business agreements in place, the DOTS client <t>The methods by which a DOTS client receives the address and
initiates a DOTS session by contacting its DOTS server(s) over the signal associated service details of the DOTS server are not prescribed by
channel and (possibly) the data channel. To allow for DOTS service flexibility, this document. For example, a DOTS client may be directly configured
neither the order of contact nor the time interval between channel creations is to use a specific DOTS server IP address and port, and be directly
specified. A DOTS client MAY establish signal channel first, and then data provided with any data necessary to satisfy the Peer Mutual
channel, or vice versa.</t> Authentication requirement (SEC-001) in <xref target="RFC8612"
format="default"/>, such as symmetric or asymmetric keys, usernames,
<t>The methods by which a DOTS client receives the address and associated servic passwords, etc. All configuration and authentication information
e in this scenario is provided out of band by the domain operating the
details of the DOTS server are not prescribed by this document. For example, a DOTS server.</t>
DOTS client may be directly configured to use a specific DOTS server IP address <t>At the other extreme, the architecture in this document allows
and port, and directly provided with any data necessary to satisfy the Peer for a form of DOTS client auto-provisioning. For example, the domain
Mutual Authentication requirement (SEC-001) in <xref target="RFC8612"></xref>, s operating the DOTS server or servers might provide the client domain
uch as symmetric or only with symmetric or asymmetric keys to authenticate the
asymmetric keys, usernames and passwords, etc. All configuration and provisioned DOTS clients. Only the keys would then be directly
authentication information in this scenario is provided out-of-band by the configured on DOTS clients, but the remaining configuration required
domain operating the DOTS server.</t> to provision the DOTS clients could be learned through mechanisms
similar to DNS SRV <xref target="RFC2782" format="default"/> or DNS
<t>At the other extreme, the architecture in this document allows for a form of Service Discovery <xref target="RFC6763" format="default"/>.</t>
DOTS client auto-provisioning. For example, the domain operating the DOTS server <t>The DOTS client <bcp14>SHOULD</bcp14> successfully authenticate
or servers might provide the client domain only with symmetric or asymmetric and exchange messages with the DOTS server over both the signal and (i
keys to authenticate the provisioned DOTS clients. Only the keys would then be f
directly configured on DOTS clients, but the remaining configuration required to used) data channel as soon as possible to confirm that both channels
provision the DOTS clients could be learned through mechanisms similar to DNS are operational.</t>
SRV <xref target="RFC2782"/> or DNS Service Discovery <xref target="RFC6763"/>.< <t>As described in <xref target="RFC8612" format="default"/>
/t> (DM-008), the DOTS client can configure preferred values for
acceptable signal loss, mitigation lifetime, and heartbeat intervals
<t>The DOTS client SHOULD successfully authenticate and exchange messages with t when establishing the DOTS signal channel session. A DOTS signal
he channel session is not active until DOTS agents have agreed on the
DOTS server over both signal and (if used) data channel as soon as possible to values for these DOTS session parameters, a process defined by the
confirm that both channels are operational.</t> protocol.</t>
<t>Once the DOTS client begins receiving DOTS server signals, the
<t>As described in <xref target="RFC8612"></xref> (DM-008), the DOTS client can DOTS session is active. At any time during the DOTS session, the
configure DOTS client may use the data channel to manage aliases, manage drop-
preferred values for acceptable signal loss, mitigation lifetime, and heartbeat and accept-listed prefixes or addresses, leverage vendor-specific
intervals when establishing the DOTS signal channel session. A DOTS signal extensions, and so on. Note that unlike the signal channel, there is
channel session is not active until DOTS agents have agreed on the values for no requirement that the data channel remains operational in attack
these DOTS session parameters, a process defined by the protocol.</t> conditions. (See "Data Channel Requirements" <xref
target="RFC8612" sectionFormat="of" section="2.3"/>).</t>
<t>Once the DOTS client begins receiving DOTS server signals, the DOTS session </section>
is active. At any time during the DOTS session, the DOTS client may use the <section anchor="maintaining-dots-session" numbered="true" toc="default"
data channel to manage aliases, manage drop- and accept-listed >
prefixes or addresses, leverage vendor-specific extensions, and so on. Note that <name>Maintaining the DOTS Session</name>
unlike the signal channel, there is no requirement that the data channel remains <t>DOTS clients and servers periodically send heartbeats to each
operational in attack conditions (See Data Channel Requirements, Section 2.3 of other over the signal channel, discussed in <xref target="RFC8612"
<xref target="RFC8612"></xref>).</t> format="default"/> (SIG-004). DOTS agent operators
<bcp14>SHOULD</bcp14> configure the heartbeat interval such that the
</section> frequency does not lead to accidental denials of service due to the
<section anchor="maintaining-dots-session" title="Maintaining the DOTS Session"> overwhelming number of heartbeats a DOTS agent must field.</t>
<t>Either DOTS agent may consider a DOTS signal channel session
<t>DOTS clients and servers periodically send heartbeats to each other over the terminated in the extended absence of a heartbeat from its peer
signal channel, discussed in <xref target="RFC8612"></xref> (SIG-004). DOTS ag agent. The period of that absence will be established in the
ent operators SHOULD protocol definition.</t>
configure the heartbeat interval such that the frequency does not lead to </section>
accidental denials of service due to the overwhelming number of heartbeats a </section>
DOTS agent must field.</t> <section anchor="modes-of-signaling" numbered="true" toc="default">
<name>Modes of Signaling</name>
<t>Either DOTS agent may consider a DOTS signal channel session terminated in th <t>This section examines the modes of signaling between agents in a DOTS
e
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 of Signaling">
<t>This section examines the modes of signaling between agents in a DOTS
architecture.</t> architecture.</t>
<section anchor="direct-signaling" numbered="true" toc="default">
<section anchor="direct-signaling" title="Direct Signaling"> <name>Direct Signaling</name>
<t>A DOTS session may take the form of direct signaling between the DO
<t>A DOTS session may take the form of direct signaling between the DOTS TS
clients and servers, as shown in <xref target="fig-direct-signaling"/>.</t> clients and servers, as shown in <xref target="fig-direct-signaling" format="def
ault"/>.</t>
<figure title="Direct Signaling" anchor="fig-direct-signaling"><artwork><![CDATA <figure anchor="fig-direct-signaling">
[ <name>Direct Signaling</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-------------+ +-------------+ +-------------+ +-------------+
| DOTS client |<------signal session------>| DOTS server | | DOTS client |<------signal session------>| DOTS server |
+-------------+ +-------------+ +-------------+ +-------------+
]]></artwork></figure> ]]></artwork>
</figure>
<t>In a direct DOTS session, the DOTS client and server are communicating direct <t>In a direct DOTS session, the DOTS client and server are
ly. communicating directly. Direct signaling may exist inter- or
Direct signaling may exist inter- or intra-domain. The DOTS session is intra-domain. The DOTS session is abstracted from the underlying
abstracted from the underlying networks or network elements the signals networks or network elements the signals traverse; in direct
traverse: in direct signaling, the DOTS client and server are logically signaling, the DOTS client and server are logically adjacent.</t>
adjacent.</t> </section>
<section anchor="redirected-signaling" numbered="true" toc="default">
</section> <name>Redirected Signaling</name>
<section anchor="redirected-signaling" title="Redirected Signaling"> <t>In certain circumstances, a DOTS server may want to redirect a DOTS
client to
<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 an alternative DOTS server for a DOTS signal channel session. Such
circumstances include but are not limited to:</t> circumstances include but are not limited to:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Maximum number of DOTS signal channel sessions with clients has
<t>Maximum number of DOTS signal channel sessions with clients has been reache been reached;</li>
d;</t> <li>Mitigation capacity exhaustion in the mitigator with which the
<t>Mitigation capacity exhaustion in the mitigator with which the specific DOTS server is communicating;</li>
specific DOTS server is communicating;</t> <li>Mitigator outage or other downtime such as scheduled maintenance
<t>Mitigator outage or other downtime, such as scheduled maintenance;</t> ;</li>
<t>Scheduled DOTS server maintenance;</t> <li>Scheduled DOTS server maintenance;</li>
<t>Scheduled modifications to the network path between DOTS server and DOTS <li>Scheduled modifications to the network path between DOTS server
client.</t> and DOTS
</list></t> client.</li>
</ul>
<t>A basic redirected DOTS signal channel session resembles the following, as <t>A basic redirected DOTS signal channel session resembles the follow
shown in <xref target="fig-redirected-signaling"/>.</t> ing, as
shown in <xref target="fig-redirected-signaling" format="default"/>.</t>
<figure title="Redirected Signaling" anchor="fig-redirected-signaling"><artwork> <figure anchor="fig-redirected-signaling">
<![CDATA[ <name>Redirected Signaling</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-------------+ +---------------+ +-------------+ +---------------+
| |<-(1)--- DOTS signal ------>| | | |<-(1)--- DOTS signal ------>| |
| | channel session 1 | | | | channel session 1 | |
| |<=(2)== redirect to B ======| | | |<=(2)== redirect to B ======| |
| DOTS client | | DOTS server A | | DOTS client | | DOTS server A |
| |X-(4)--- DOTS signal ------X| | | |X-(4)--- DOTS signal ------X| |
| | channel session 1 | | | | channel session 1 | |
| | | | | | | |
+-------------+ +---------------+ +-------------+ +---------------+
^ ^
| |
(3) DOTS signal channel (3) DOTS signal channel
| session 2 | session 2
v v
+---------------+ +---------------+
| DOTS server B | | DOTS server B |
+---------------+ +---------------+
]]></artwork></figure> ]]></artwork>
</figure>
<t><list style="numbers"> <ol spacing="normal" type="1">
<t>Previously established DOTS signal channel session 1 exists between a DOTS <li>Previously established DOTS signal channel session 1 exists betw
client and DOTS server A.</t> een a DOTS
<t>DOTS server A sends a server signal redirecting the client to DOTS server B client and DOTS server A.</li>
.</t> <li>DOTS server A sends a server signal redirecting the client to DO
<t>If the DOTS client does not already have a separate DOTS signal channel TS server 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 session with the redirection target, the DOTS client initiates and
establishes DOTS signal channel session 2 with DOTS server B.</t> establishes DOTS signal channel session 2 with DOTS server B.</li>
<t>Having redirected the DOTS client, DOTS server A ceases sending server <li>Having redirected the DOTS client, DOTS server A ceases sending
server
signals. The DOTS client likewise stops sending client signals to DOTS server signals. The DOTS client likewise stops sending client signals to DOTS server
A. DOTS signal channel session 1 is terminated.</t> A. DOTS signal channel session 1 is terminated.</li>
</list></t> </ol>
</section>
</section> <section anchor="recursive-signaling" numbered="true" toc="default">
<section anchor="recursive-signaling" title="Recursive Signaling"> <name>Recursive Signaling</name>
<t>DOTS is centered around improving the speed and efficiency of
<t>DOTS is centered around improving the speed and efficiency of coordinated a coordinated response to DDoS attacks. One scenario not yet discussed
response to DDoS attacks. One scenario not yet discussed involves coordination involves coordination among federated domains operating DOTS servers
among federated domains operating DOTS servers and mitigators.</t> and mitigators.</t>
<t>In the course of normal DOTS operations, a DOTS client communicates
<t>In the course of normal DOTS operations, a DOTS client communicates the need the need for
for
mitigation to a DOTS server, and that server initiates mitigation on a mitigation to a DOTS server, and that server initiates mitigation on a
mitigator with which the server has an established service relationship. The mitigator with which the server has an established service relationship. The
operator of the mitigator may in turn monitor mitigation performance and operator of the mitigator may in turn monitor mitigation performance and
capacity, as the attack being mitigated may grow in severity beyond the capacity, as the attack being mitigated may grow in severity beyond the
mitigating domain's capabilities.</t> mitigating domain's capabilities.</t>
<t>The operator of the mitigator has limited options in the event a DO
<t>The operator of the mitigator has limited options in the event a DOTS TS
client-requested mitigation is being overwhelmed by the severity of the attack. client-requested mitigation is being overwhelmed by the severity of the attack.
Out-of-scope business or service level agreements may permit the mitigating Out-of-scope business or SLAs may permit the mitigating
domain to drop the mitigation and let attack traffic flow unchecked to the domain to drop the mitigation and let attack traffic flow unchecked to the
target, but this only encourages attack escalation. In the case where target, but this only encourages attack escalation. In the case where
the mitigating domain is the upstream service provider for the attack target, 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 this may mean the mitigating domain and its other services and users continue to
suffer the incidental effects of the attack.</t> suffer the incidental effects of the attack.</t>
<t>A recursive signaling model as shown in <xref target="fig-recursive
<t>A recursive signaling model as shown in <xref target="fig-recursive-signaling -signaling" format="default"/> offers
"/> offers
an alternative. In a variation of the use case "Upstream DDoS Mitigation by an 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>, a Upstream Internet Transit Provider" described in <xref target="I-D.ietf-dots-use -cases" format="default"/>, a
domain operating a DOTS server and mitigator also operates a DOTS client. This 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 DOTS client has an established DOTS session with a DOTS server belonging to a
separate administrative domain.</t> separate administrative domain.</t>
<t>With these preconditions in place, the operator of the mitigator be
<t>With these preconditions in place, the operator of the mitigator being ing
overwhelmed or otherwise performing inadequately may request mitigation for the overwhelmed or otherwise performing inadequately may request mitigation for the
attack target from this separate DOTS-aware domain. Such a request recurses the attack target from this separate DOTS-aware domain. Such a request recurses the
originating mitigation request to the secondary DOTS server, in the hope of originating mitigation request to the secondary DOTS server in the hope of
building a cumulative mitigation against the attack.</t> building a cumulative mitigation against the attack.</t>
<figure anchor="fig-recursive-signaling">
<figure title="Recursive Signaling" anchor="fig-recursive-signaling"><artwork><! <name>Recursive Signaling</name>
[CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
example.net domain example.net domain
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Gn . . Gn .
+----+ 1 . +----+ +-----------+ . +----+ 1 . +----+ +-----------+ .
| Cc |<--------->| Sn |~~~~~~~| Mitigator | . | Cc |<--------->| Sn |~~~~~~~| Mitigator | .
+----+ . +====+ | Mn | . +----+ . +====+ | Mn | .
. | Cn | +-----------+ . . | Cn | +-----------+ .
example.com . +----+ . example.com . +----+ .
client . ^ . client . ^ .
. . .|. . . . . . . . . . . . . . . . .|. . . . . . . . . . . . . .
skipping to change at line 943 skipping to change at line 943
| |
. . .|. . . . . . . . . . . . . . . . .|. . . . . . . . . . . . . .
. v . . v .
. +----+ +-----------+ . . +----+ +-----------+ .
. | So |~~~~~~~| Mitigator | . . | So |~~~~~~~| Mitigator | .
. +----+ | Mo | . . +----+ | Mo | .
. +-----------+ . . +-----------+ .
. . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
example.org domain example.org domain
]]></artwork></figure> ]]></artwork>
</figure>
<t>In <xref target="fig-recursive-signaling"/>, client Cc signals a request for <t>In <xref target="fig-recursive-signaling" format="default"/>, clien
mitigation t Cc signals a request for mitigation
across inter-domain DOTS session 1 to the DOTS server Sn belonging to the 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 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 with server Sn is half of DOTS gateway Gn, being deployed logically back to back with
DOTS client Cn, which has pre-existing inter-domain DOTS session 2 with the DOTS DOTS client Cn, which has preexisting inter-domain DOTS session 2 with the DOTS
server So belonging to the example.org domain. At any point, DOTS server Sn MAY server So belonging to the example.org domain. At any point, DOTS server Sn <bcp
recurse an on-going mitigation request through DOTS client Cn to DOTS server So, 14>MAY</bcp14>
recurse an 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 in the expectation that mitigator Mo will be activated to aid in the defense of
the attack target.</t> the attack target.</t>
<t>Recursive signaling is opaque to the DOTS client. To maximize mitig
<t>Recursive signaling is opaque to the DOTS client. To maximize mitigation ation
visibility to the DOTS client, however, the recursing domain SHOULD provide visibility to the DOTS client, however, the recursing domain <bcp14>SHOULD</bcp1
4> provide
recursed mitigation feedback in signals reporting on mitigation status to the recursed mitigation feedback in signals reporting on mitigation status to the
DOTS client. For example, the recursing domain's DOTS server should incorporate DOTS client. For example, the recursing domain's DOTS server should incorporate
into mitigation status messages available metrics such as dropped packet or byte available metrics such as dropped packet or byte counts from the recursed
counts from the recursed domain's DOTS server.</t> domain's DOTS server into mitigation status messages.
</t>
<t>DOTS clients involved in recursive signaling must be able to withdraw request
s
for mitigation without warning or justification, per SIG-006 in <xref target="RF
C8612"></xref>.</t>
<t>Operators recursing mitigation requests MAY maintain the recursed mitigation
for
a 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>
<t>Deployment of recursive signaling may result in traffic redirection, examinat
ion
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, and work with DOTS server operators employing recursive
signaling to ensure shared sensitive material is suitably protected. Typically t
here
is a contractual Service Level Agreement (SLA) negotiated among the DOTS client
domain,
the recursed 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">
<t>The DOTS architecture does not assume the availability of anycast within a DO
TS
deployment, but neither does the architecture exclude it. Domains operating DOTS
servers MAY deploy DOTS servers with an anycast Service Address as described in
BCP 126 <xref target="RFC4786"></xref>. In such a deployment, DOTS clients conne
cting 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 DOTS client configuration, including service discovery through t
he
methods described in <xref target="RFC7094"></xref>. In this scenario, the "inst
ance 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- or customer-specific deployments, in which the DOTS Service Address
es
route to distinct DOTS servers depending on the client region or the customer
network in which a DOTS client resides.</t>
<t>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>
<section anchor="anycast-signaling-considerations" title="Anycast Signaling Cons
iderations">
<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>, the signal channel also requires mutual authenti
cation 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, 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 in TLS
1.3 <xref target="RFC8446"></xref> and DTLS 1.3 <xref target="I-D.ietf-tls-dtls1
3"></xref> (session resumption in TLS
1.2 <xref target="RFC5246"></xref> and DTLS 1.2 <xref target="RFC6347"></xref>),
but keying material must be available to
all DOTS servers sharing the anycast Service Address in that case which has oper
ational 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 the client has configured
mitigation on loss of signal (<xref target="auto-mit-signal-loss"/>).</t>
</section>
</section>
<section anchor="nat-signaling" title="Signaling Considerations for Network Addr
ess Translation">
<t>Network address translators (NATs) are expected to be a common feature of DOT
S
deployments. The Middlebox Traversal Guidelines in <xref target="RFC8085"></xref
> include general
NAT considerations that are applicable to DOTS deployments when the signal chann
el 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, but are mea <t>DOTS clients involved in recursive signaling must be able to withdr
nt aw requests
rather to highlight anticipated common issues when signaling through NATs.</t> for mitigation without warning or justification per SIG-006 in <xref target="RFC
8612" format="default"/>.</t>
<t>Operators recursing mitigation requests <bcp14>MAY</bcp14>
maintain the recursed mitigation for a 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"
format="default"/>.</t>
<t>Deployment of recursive signaling may result in traffic
redirection, 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 and work with DOTS server operators employing recursive
signaling to ensure shared sensitive material is suitably
protected. Typically, there is a contractual SLA negotiated among the
DOTS client domain, the recursed 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="direct-provisioning-of-internal-to-external-address-mappings" t <section anchor="anycast-signaling" numbered="true" toc="default">
itle="Direct Provisioning of Internal-to-External Address Mappings"> <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 <bcp14>MAY</bcp14> deploy DOTS
servers with an anycast Service Address as described in BCP 126
<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>
<ul spacing="normal">
<li>Simplified DOTS client configuration, including service
discovery through the methods described in <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.</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.</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" format="default"/>.</li>
</ul>
<section anchor="anycast-signaling-considerations" numbered="true" toc
="default">
<name>Anycast Signaling 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" 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
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 pre-shared key (PSK) in TLS 1.3 <xref target="RFC8446"
format="default"/> and DTLS 1.3 <xref target="I-D.ietf-tls-dtls13"
format="default"/> (session resumption in TLS 1.2 <xref
target="RFC5246" format="default"/> and DTLS 1.2 <xref
target="RFC6347" format="default"/>), but keying material must
then be available to all DOTS servers sharing the anycast Service
Address, which has operational challenges of its own.</t>
<t>Operators may circumvent the problem of translating internal addresses or <t>While the DOTS client will try to establish a new DOTS session
prefixes to externally routable mitigation scopes by directly provisioning the with the DOTS server now acting as the anycast DOTS Service
mappings of external addresses to internal protected resources on the DOTS Address, the link between DOTS client and server may be congested
client. When the operator requests mitigation scoped for internal addresses, with attack traffic, making signal session establishment
directly or through automated means, the DOTS client looks up the matching difficult. In such a scenario, anycast Service Address instability
external addresses or prefixes, and issues a mitigation request scoped to that becomes a sort of signal session flapping, with obvious negative
externally routable information.</t> 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" format="default"/>).</t>
</section>
</section>
<t>When directly provisioning the address mappings, operators must ensure the <section anchor="nat-signaling" numbered="true" toc="default">
mappings remain up to date, or risk losing the ability to request accurate <name>Signaling Considerations for Network Address Translation</name>
<t>Network address translators (NATs) are expected to be a common
feature of DOTS deployments. The middlebox traversal guidelines in
<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
but are meant rather to highlight anticipated common issues when
signaling through NATs.</t>
<section anchor="direct-provisioning-of-internal-to-external-address-m
appings" numbered="true" toc="default">
<name>Direct Provisioning of Internal-to-External Address 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 and issues a mitigation request
scoped to that externally routable information.</t>
<t>When directly provisioning the address mappings, operators must e
nsure the
mappings remain up to date or they risk losing the ability to request accurate
mitigation scopes. To that aim, the DOTS client can rely on mechanisms such as mitigation scopes. To that aim, the DOTS client can rely on mechanisms such as
<xref target="RFC8512"></xref> or <xref target="RFC7658"></xref> to retrieve sta tic explicit mappings. This document does not <xref target="RFC8512" format="default"/> or <xref target="RFC7658" format="defa ult"/> to retrieve static explicit mappings. This document does not
prescribe the method by which mappings are maintained once they are provisioned prescribe the method by which mappings are maintained once they are provisioned
on the DOTS client.</t> on the DOTS client.</t>
</section>
</section> <section anchor="resolving-public-mitigation-scope-with-port-control-p
<section anchor="resolving-public-mitigation-scope-with-port-control-protocol-pc rotocol-pcp" numbered="true" toc="default">
p" title="Resolving Public Mitigation Scope with Port Control Protocol (PCP)"> <name>Resolving Public Mitigation Scope with Port Control Protocol (
PCP)</name>
<t>Port Control Protocol (PCP) <xref target="RFC6887"></xref> may be used to ret <t>Port Control Protocol (PCP) <xref target="RFC6887" format="defaul
rieve the external t"/> may be used to retrieve the external
addresses/prefixes and/or port numbers if the NAT function embeds a PCP server.< /t> 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 t
<t>A DOTS client can use the information retrieved by means of PCP to feed the D o feed the DOTS
OTS
protocol(s) messages that will be sent to a DOTS server. These messages will 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> convey the external addresses/prefixes as set by the NAT.</t>
<t>PCP also enables discovery and configuration of the lifetime of p
<t>PCP also enables discovery and configuration of the lifetime of port mappings ort mappings
instantiated in intermediate NAT devices. Discovery of port mapping lifetimes instantiated in intermediate NAT devices. Discovery of port mapping lifetimes
can reduce the dependency on heartbeat messages to maintain mappings, and can reduce the dependency on heartbeat messages to maintain mappings and,
therefore reduce the load on DOTS servers and the network.</t> therefore, reduce the load on DOTS servers and the network.</t>
</section>
</section> <section anchor="resolving-public-mitigation-scope-with-session-traver
<section anchor="resolving-public-mitigation-scope-with-session-traversal-utilit sal-utilities-stun" numbered="true" toc="default">
ies-stun" title="Resolving Public Mitigation Scope with Session Traversal Utilit <name>Resolving Public Mitigation Scope with Session Traversal Utili
ies (STUN)"> ties (STUN)</name>
<t>An internal resource, e.g., a web server, can discover its reflex
<t>An internal resource, e.g., a Web server, can discover its reflexive transpor ive transport
t
address through a STUN Binding request/response transaction, as described in address through a STUN Binding request/response transaction, as described in
<xref target="I-D.ietf-tram-stunbis"></xref>. After learning its reflexive trans port address from the STUN server, <xref target="RFC8489" format="default"/>. After learning its reflexive transpor t address from the STUN server,
the internal resource can export its reflexive transport address and internal the internal resource can export its reflexive transport address and internal
transport address to the DOTS client, thereby enabling the DOTS client to transport address to the DOTS client, thereby enabling the DOTS client to
request mitigation with the correct external scope, as depicted in request mitigation with the correct external scope, as depicted in
<xref target="fig-nat-stun"/>. The mechanism for providing the DOTS client with the reflexive <xref 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 transport address and internal transport address is unspecified in this
document.</t> document.</t>
<t>In order to prevent an attacker from modifying the STUN messages
<t>In order to prevent an attacker from modifying the STUN messages in transit, in transit, the
the
STUN client and server must use the message-integrity mechanism discussed in STUN client and server must use the message-integrity mechanism discussed in
Section 9 of <xref target="I-D.ietf-tram-stunbis"></xref> or use STUN over DTLS <xref target="RFC7350"></xref> or use STUN over TLS. <xref target="RFC8489" sectionFormat="of" section="9"/> or use STUN over DTLS <x ref target="RFC7350" format="default"/> or STUN over TLS.
If the STUN client is behind a NAT that performs Endpoint-Dependent Mapping If the STUN client is behind a NAT that performs Endpoint-Dependent Mapping
<xref target="RFC5128"></xref>, the internal service cannot provide the DOTS cli ent with the <xref target="RFC5128" format="default"/>, the internal service cannot provide t he DOTS client with the
reflexive transport address discovered using STUN. The behavior of a NAT between 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 the STUN client and the STUN server could be discovered using the experimental
techniques discussed in <xref target="RFC5780"></xref>, but note that there is c urrently no techniques discussed in <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 standardized way for a STUN client to reliably determine if it is behind a NAT
that performs Endpoint-Dependent Mapping.</t> that performs Endpoint-Dependent Mapping.</t>
<figure anchor="fig-nat-stun">
<figure title="Resolving mitigation scope with STUN" anchor="fig-nat-stun"><artw <name>Resolving Mitigation Scope with STUN</name>
ork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Binding Binding Binding Binding
+--------+ request +---+ request +--------+ +--------+ request +---+ request +--------+
| STUN |<----------| N |<----------| STUN | | STUN |<----------| N |<----------| STUN |
| server | | A | | client | | server | | A | | client |
| |---------->| T |---------->| | | |---------->| T |---------->| |
+--------+ Binding +---+ Binding +--------+ +--------+ Binding +---+ Binding +--------+
response response | response response |
| reflexive transport address | reflexive transport address
| & internal transport address | & internal transport address
v v
+--------+ +--------+
| DOTS | | DOTS |
| client | | client |
+--------+ +--------+
]]></artwork></figure> ]]></artwork>
</figure>
</section> </section>
<section anchor="resolving-requested-mitigation-scope-with-dns" title="Resolving <section anchor="resolving-requested-mitigation-scope-with-dns" number
Requested Mitigation Scope with DNS"> ed="true" toc="default">
<name>Resolving Requested Mitigation Scope with DNS</name>
<t>DOTS supports mitigation scoped to DNS names. As discussed in <xref target="R <t>DOTS supports mitigation scoped to DNS names. As discussed in <xr
FC3235"></xref>, ef target="RFC3235" format="default"/>,
using DNS names instead of IP addresses potentially avoids the address using DNS names instead of IP addresses potentially avoids the address
translation problem, as long as the same domain name is internally and externall y resolvable. translation problem, as long as the same domain name is internally and externall y resolvable.
For example, a detected attack's internal target address can be mapped to a DNS name through a reverse lookup. The DNS name 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 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 external scope for mitigation. For the reverse DNS lookup, DNS Security
Extensions (DNSSEC) <xref target="RFC4033"></xref> must be used where the authe nticity of response Extensions (DNSSEC) <xref target="RFC4033" format="default"/> must be used wher e the authenticity of response
is critical.</t> is critical.</t>
</section>
</section> </section>
</section> </section>
</section> <section anchor="mit-request-triggers" numbered="true" toc="default">
<section anchor="mit-request-triggers" title="Triggering Requests for Mitigation <name>Triggering Requests for Mitigation</name>
"> <t><xref target="RFC8612" format="default"/> places no limitation on the
circumstances in which a DOTS client
<t><xref target="RFC8612"></xref> places no limitation on the circumstances in w
hich a DOTS client
operator may request mitigation, nor does it demand justification for any operator may request mitigation, nor does it demand justification for any
mitigation request, thereby reserving operational control over DDoS defense for mitigation request, thereby reserving operational control over DDoS defense for
the domain requesting mitigation. This architecture likewise does not prescribe the domain requesting mitigation. This architecture likewise does not prescribe
the network conditions and mechanisms triggering a mitigation request from a the network conditions and mechanisms triggering a mitigation request from a
DOTS client.</t> DOTS client.</t>
<t>However, considering selected possible mitigation triggers from an architectu ral <t>However, considering selected possible mitigation triggers from an ar chitectural
perspective offers a model for alternative or unanticipated triggers for DOTS perspective offers a model for alternative or unanticipated triggers for DOTS
deployments. In all cases, what network conditions merit a mitigation request deployments. In all cases, what network conditions merit a mitigation request
are at the discretion of the DOTS client operator.</t> are at the discretion of the DOTS client operator.</t>
<t>The mitigation request itself is defined by DOTS; however, the interf
<t>The mitigation request itself is defined by DOTS, however the interfaces aces
required to trigger the mitigation request in the following scenarios are required to trigger the mitigation request in the following scenarios are
implementation-specific.</t> implementation specific.</t>
<section anchor="manual-mit-request" numbered="true" toc="default">
<section anchor="manual-mit-request" title="Manual Mitigation Request"> <name>Manual Mitigation Request</name>
<t>A DOTS client operator may manually prepare a request for mitigatio
<t>A DOTS client operator may manually prepare a request for mitigation, includi n, including
ng
scope and duration, and manually instruct the DOTS client to send the mitigation 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 request to the DOTS server. In context, a manual request is a request directly
issued by the operator without automated decision-making performed by a device issued by the operator without automated decision making performed by a device
interacting with the DOTS client. Modes of manual mitigation requests include interacting with the DOTS client. Modes of manual mitigation requests include
an operator entering a command into a text interface, or directly interacting an operator entering a command into a text interface, or directly interacting
with a graphical interface to send the request.</t> with a graphical interface to send the request.</t>
<t>An operator might do this, for example, in response to notice of an
<t>An operator might do this, for example, in response to notice of an attack attack
delivered by attack detection equipment or software, and the alerting detector delivered by attack detection equipment or software, and the alerting detector
lacks interfaces or is not configured to use available interfaces to translate lacks interfaces or is not configured to use available interfaces to translate
the alert to a mitigation request automatically.</t> the alert to a mitigation request automatically.</t>
<t>In a variation of the above scenario, the operator may have preconf
<t>In a variation of the above scenario, the operator may have preconfigured on igured on the
the
DOTS client mitigation requests for various resources in the operator's domain. 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 When notified of an attack, the DOTS client operator manually instructs the DOTS
client to send the relevant preconfigured mitigation request for the resources client to send the relevant preconfigured mitigation request for the resources
under attack.</t> under attack.</t>
<t>A further variant involves recursive signaling, as described in
<t>A further variant involves recursive signaling, as described in <xref target="recursive-signaling" format="default"/>. The DOTS client in this c
<xref target="recursive-signaling"/>. The DOTS client in this case is the second ase is the second half of a
half of a
DOTS gateway (back-to-back DOTS server and client). As in the previous scenario, 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 in this the scope and duration of the mitigation request are preexisting but, in this
case are derived from the mitigation request received from a downstream DOTS case, are derived from the mitigation request received from a downstream DOTS
client by the DOTS server. Assuming the preconditions required by client by the DOTS server. Assuming the preconditions required by
<xref target="recursive-signaling"/> are in place, the DOTS gateway operator may at any time <xref target="recursive-signaling" format="default"/> are in place, the DOTS gat eway operator may at any time
manually request mitigation from an upstream DOTS server, sending a mitigation manually request mitigation from an upstream DOTS server, sending a mitigation
request derived from the downstream DOTS client's request.</t> request derived from the downstream DOTS client's request.</t>
<t>The motivations for a DOTS client operator to request mitigation ma
<t>The motivations for a DOTS client operator to request mitigation manually are nually are
not prescribed by this architecture, but are expected to include some of the not prescribed by this architecture but are expected to include some of the
following:</t> following:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Notice of an attack delivered via email or alternative messaging
<t>Notice of an attack delivered via e-mail or alternative messaging</t> </li>
<t>Notice of an attack delivered via phone call</t> <li>Notice of an attack delivered via phone call</li>
<t>Notice of an attack delivered through the interface(s) of networking <li>Notice of an attack delivered through the interface(s) of networ
monitoring software deployed in the operator's domain</t> king
<t>Manual monitoring of network behavior through network monitoring software</ monitoring software deployed in the operator's domain</li>
t> <li>Manual monitoring of network behavior through network monitoring
</list></t> software</li>
</ul>
</section> </section>
<section anchor="auto-conditional-mit" title="Automated Conditional Mitigation R <section anchor="auto-conditional-mit" numbered="true" toc="default">
equest"> <name>Automated Conditional Mitigation Request</name>
<t>Unlike manual mitigation requests, which depend entirely on the DOT
<t>Unlike manual mitigation requests, which depend entirely on the DOTS client S client
operator's capacity to react with speed and accuracy to every detected or operator's capacity to react with speed and accuracy to every detected or
detectable attack, mitigation requests triggered by detected attack conditions detectable attack, mitigation requests triggered by detected attack conditions
reduce the operational burden on the DOTS client operator, and minimize the reduce the operational burden on the DOTS client operator and minimize the
latency between attack detection and the start of mitigation.</t> latency between attack detection and the start of mitigation.</t>
<t>Mitigation requests are triggered in this scenario by operator-spec
<t>Mitigation requests are triggered in this scenario by operator-specified netw ified network
ork conditions. Attack detection is deployment specific and not constrained by this
conditions. Attack detection is deployment-specific, and not constrained by this architecture. Similarly, the specifics of a condition are left to the discretion
architecture. Similarly the specifics of a condition are left to the discretion
of the operator, though common conditions meriting mitigation include the of the operator, though common conditions meriting mitigation include the
following:</t> following:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Detected attack exceeding a rate in packets per second (pps).</l
<t>Detected attack exceeding a rate in packets per second (pps).</t> i>
<t>Detected attack exceeding a rate in bytes per second (bps).</t> <li>Detected attack exceeding a rate in bytes per second (bps).</li>
<t>Detected resource exhaustion in an attack target.</t> <li>Detected resource exhaustion in an attack target.</li>
<t>Detected resource exhaustion in the local domain's mitigator.</t> <li>Detected resource exhaustion in the local domain's mitigator.</l
<t>Number of open connections to an attack target.</t> i>
<t>Number of attack sources in a given attack.</t> <li>Number of open connections to an attack target.</li>
<t>Number of active attacks against targets in the operator's domain.</t> <li>Number of attack sources in a given attack.</li>
<t>Conditional detection developed through arbitrary statistical analysis or d <li>Number of active attacks against targets in the operator's domai
eep n.</li>
learning techniques.</t> <li>Conditional detection developed through arbitrary statistical an
<t>Any combination of the above.</t> alysis or deep
</list></t> learning techniques.</li>
<li>Any combination of the above.</li>
<t>When automated conditional mitigation requests are enabled, violations of any </ul>
of <t>When automated conditional mitigation requests are enabled, violati
ons of any of
the above conditions, or any additional operator-defined conditions, will the above conditions, or any additional operator-defined conditions, will
trigger a mitigation request from the DOTS client to the DOTS server. The trigger a mitigation request from the DOTS client to the DOTS server. The
interfaces between the application detecting the condition violation and the interfaces between the application detecting the condition violation and the
DOTS client are implementation-specific.</t> DOTS client are implementation specific.</t>
</section>
</section> <section anchor="auto-mit-signal-loss" numbered="true" toc="default">
<section anchor="auto-mit-signal-loss" title="Automated Mitigation on Loss of Si <name>Automated Mitigation on Loss of Signal</name>
gnal"> <t>To maintain a DOTS signal channel session, the DOTS client and the
DOTS server
<t>To maintain a DOTS signal channel session, the DOTS client and the DOTS serve
r
exchange regular but infrequent messages across the signal channel. In the exchange regular but infrequent messages across the signal channel. In the
absence of an attack, the probability of message loss in the signaling channel 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 should be extremely low. Under attack conditions, however, some signal loss may
be anticipated as attack traffic congests the link, depending on the attack be anticipated as attack traffic congests the link, depending on the attack
type.</t> type.</t>
<t>While <xref target="RFC8612" format="default"/> specifies the DOTS
<t>While <xref target="RFC8612"></xref> specifies the DOTS protocol be robust wh protocol be robust when signaling under
en signaling under
attack conditions, there are nevertheless scenarios in which the DOTS signal is 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 lost in spite of protocol best efforts. To handle such scenarios, a DOTS
operator may request one or more mitigations which are triggered only when the operator may request one or more mitigations, which are triggered only when the
DOTS server ceases receiving DOTS client heartbeats beyond the miss count or DOTS server ceases receiving DOTS client heartbeats beyond the miss count or
interval permitted by the protocol.</t> interval permitted by the protocol.</t>
<t>The impact of mitigating due to loss of signal in either direction
<t>The impact of mitigating due to loss of signal in either direction must be must be
considered carefully before enabling it. Attack traffic congesting links is not considered carefully before enabling it. Attack traffic congesting links is not
the only reason why signal could be lost, and as such mitigation requests trigge red the only reason why signal could be lost, and as such, mitigation requests trigg ered
by signal channel degradation in either direction may incur unnecessary costs du e to scrubbing traffic, by signal channel degradation in either direction may incur unnecessary costs du e to scrubbing traffic,
adversely impact network performance and operational expense alike.</t> adversely impact network performance and operational expense alike.</t>
</section>
</section> </section>
</section> </section>
</section> <section anchor="iana-considerations" numbered="true" toc="default">
<section anchor="iana-considerations" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
<t>This document has no actions for IANA.</t> </section>
<section anchor="security-considerations" numbered="true" toc="default">
</section> <name>Security Considerations</name>
<section anchor="security-considerations" title="Security Considerations"> <t>This section describes identified security considerations for the
DOTS architecture.</t>
<t>This section describes identified security considerations for the DOTS <t>Security considerations and security requirements discussed in <xref ta
architecture.</t> rget="RFC8612" format="default"/> need to
<t>Security considerations and security requirements discussed in <xref target="
RFC8612"></xref> need to
be taken into account.</t> be taken into account.</t>
<t>DOTS is at risk from three primary attack vectors: agent
<t>DOTS is at risk from three primary attack vectors: agent impersonation, impersonation, traffic injection, and signal blocking. These vectors
traffic injection and signal blocking. These vectors may be exploited may be exploited individually or in concert by an attacker to confuse,
individually or in concert by an attacker to confuse, disable, take information disable, take information from, or otherwise inhibit DOTS agents.</t>
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
<t>Any attacker with the ability to impersonate a legitimate DOTS client or serv potentially trigger/withdraw traffic redirection, trigger/cancel
er mitigation activities or subvert drop-/accept-lists. From an
or, indeed, inject false messages into the stream may potentially architectural standpoint, operators <bcp14>MUST</bcp14> ensure
trigger/withdraw traffic redirection, trigger/cancel mitigation activities or conformance to the security requirements defined in <xref
subvert drop-/accept-lists. From an architectural standpoint, operators MUST target="RFC8612" sectionFormat="of" section="2.4"/> to secure data in
ensure conformance to the security requirements defined in Section 2.4 of transit. Similarly, as the received data may contain network topology,
<xref target="RFC8612"></xref> to secure data in transit. Similarly, as the rece telemetry, and threat and mitigation information that could be considered
ived data may sensitive in certain environments, it <bcp14>SHOULD</bcp14> be protected
contain network topology, telemetry, threat and mitigation information which cou at rest per required local policy. </t>
ld be considered <t>DOTS agents <bcp14>MUST</bcp14> perform mutual authentication to
sensitive in certain environment, it SHOULD be protected at rest per required ensure authenticity of each other, and DOTS servers <bcp14>MUST</bcp14>
local policy. </t> verify that the requesting DOTS client is authorized to request
mitigation for specific target resources (see <xref target="dots-server"
<t>DOTS agents MUST perform mutual authentication to ensure authenticity of each format="default"/>).</t>
other and DOTS servers MUST verify that the <t>A man-in-the-middle (MITM) attacker can intercept and drop packets,
requesting DOTS client is authorized to request mitigation for specific target r preventing the DOTS peers from receiving some or all of the DOTS
esources (see <xref target="dots-server"></xref>).</t> messages; automated mitigation on loss of signal can be used as a
countermeasure but with risks discussed in <xref
<t>An MITM attacker can intercept and drop packets, preventing the DOTS peers fr target="auto-mit-signal-loss" format="default"/>.</t>
om receiving some <t>An attacker with control of a DOTS client may negatively influence
or all of the DOTS messages, automated mitigation on loss of signal can be used network traffic by requesting and withdrawing requests for mitigation
as a countermeasure for particular prefixes, leading to route or DNS flapping. DOTS
but with risks discussed in <xref target="auto-mit-signal-loss"></xref>.</t> operators should carefully monitor and audit DOTS clients to detect
misbehavior and deter misuse.
<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>
<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
<bcp14>MUST</bcp14> be given adequate protections in accordance with
best current practices for network and host security.</t>
</section>
<t>Any attack targeting the availability of DOTS servers may disrupt the ability </middle>
of the system to receive and process DOTS signals resulting in failure to <back>
fulfill a mitigation request. DOTS servers MUST be given adequate 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> <displayreference target="I-D.ietf-dots-use-cases" to="DOTS-USE-CASES"/>
<section anchor="acknowledgments" title="Acknowledgments"> <displayreference target="I-D.ietf-tls-dtls13" to="DTLS-PROTOCOL"/>
<t>Thanks to Matt Richardson, Roman Danyliw, Frank Xialiang, Roland Dobbins, Wei <references>
Pan, Kaname Nishizuka, Jon Shallow, Paul Kyzivat, Warren Kumari, Benjamin Kaduk, <name>References</name>
and Mohamed Boucadair for their comments <references>
and suggestions.</t> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8612.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4786.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6887.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4033.xml"/>
</references>
<references>
<name>Informative References</name>
<t>Special thanks to Roman Danyliw for the AD review. </t> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe rence.I-D.ietf-dots-use-cases.xml"/>
</section> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe rence.I-D.ietf-tls-dtls13.xml"/>
</middle> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8782.xml"/>
<back> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8783.xml"/>
<references title='Normative References'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8738.xml"/>
&RFC2119; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC8174; FC.8489.xml"/>
&RFC8612;
&RFC4786;
&RFC6887;
&RFC4033;
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7350.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8555.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.0768.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.0793.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1035.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2782.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3235.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3261.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4271.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4732.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5128.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5246.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5780.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6347.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6763.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7092.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7094.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8085.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8512.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7658.xml"/>
</references>
</references> </references>
<references title='Informative References'> <section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>Thanks to <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 Bouca
dair"/> for
their comments and suggestions.</t>
<t>Special thanks to <contact fullname="Roman Danyliw"/> for the AD review
. </t>
</section>
&I-D.ietf-dots-use-cases; <section anchor="contributors" numbered="false" toc="default">
&I-D.ietf-tls-dtls13; <name>Contributors</name>
&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> <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>
</back> <ul empty="true" spacing="compact">
<li><t><contact fullname="Cristopher Gray"/></t>
</li>
<li>
<ul empty="true" spacing="compact">
<!-- ##markdown-source: <li>Christopher_Gray3@cable.comcast.com
H4sIALSi7lwAA919e3Pc2HHv/+dToLRVd8XsDCVS2pUsxylT4u5a8eoRUXud </li>
lK2kMDMYEiYGmAtgSNGS8tlvv08fAENp77XjSmjXipzB4zz69PPX3fP5PPRl </ul>
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
</li>
</ul>
</section>
</back>
</rfc> </rfc>
 End of changes. 112 change blocks. 
1651 lines changed or deleted 1187 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/