rfc9284xml2.original.xml   rfc9284.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc [
<?rfc toc="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocompact="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc tocdepth="3"?> <!ENTITY nbhy "&#8209;">
<?rfc tocindent="yes"?> <!ENTITY wj "&#8288;">
<?rfc symrefs="yes"?> ]>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
<?rfc inline="yes"?> etf-dots-multihoming-13" ipr="trust200902" number="9284" obsoletes="" updates=""
<?rfc compact="yes"?> submissionType="IETF" consensus="true" xml:lang="en" tocInclude="true" tocDept
<?rfc subcompact="no"?> h="3" symRefs="true" sortRefs="true" version="3">
<rfc category="info" docName="draft-ietf-dots-multihoming-13"
ipr="trust200902">
<front> <front>
<title abbrev="DOTS Multihoming">Multi-homing Deployment Considerations
for Distributed-Denial-of-Service Open Threat Signaling (DOTS)</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <title abbrev="DOTS Multihoming">Multihoming Deployment Considerations
for DDoS Open Threat Signaling (DOTS)</title>
<seriesInfo name="RFC" value="9284"/>
<author initials="M" surname="Boucadair" fullname="Mohamed Boucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Rennes</city> <city>Rennes</city>
<region/>
<region></region>
<code>35000</code> <code>35000</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<author initials="T" surname="Reddy.K" fullname="Tirumaleswar Reddy.K">
<author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K"> <organization>Nokia</organization>
<organization>Akamai</organization>
<address> <address>
<postal>
<street>Embassy Golf Link Business Park</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560071</code>
<country>India</country>
</postal>
<email>kondtir@gmail.com</email> <email>kondtir@gmail.com</email>
</address> </address>
</author> </author>
<author initials="W" surname="Pan" fullname="Wei Pan">
<author fullname="Wei Pan" initials="W." surname="Pan">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>william.panwei@huawei.com</email> <email>william.panwei@huawei.com</email>
<uri/>
<uri></uri>
</address> </address>
</author> </author>
<date month="August" year="2022"/>
<date />
<abstract> <abstract>
<t>This document discusses multi-homing considerations for <t>This document discusses multihoming considerations for
Distributed-Denial-of-Service Open Threat Signaling (DOTS). The goal is DDoS Open Threat Signaling (DOTS). The goal is
to provide some guidance for DOTS clients and client-domain DOTS to provide some guidance for DOTS clients and client-domain DOTS
gateways when multihomed.</t> gateways when multihomed.</t>
<!--
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>In many deployments, it may not be possible for a network to <t>In many deployments, it may not be possible for a network to
determine the cause of a distributed Denial-of-Service (DoS) attack determine the cause of a DDoS attack <xref target="RFC4732" format="defaul
<xref target="RFC4732"></xref>. Rather, the network may just realize t"/>. Rather, the network may just realize
that some resources appear to be under attack. To help with such that some resources appear to be under attack. To help with such
situations, the IETF has specified the DDoS Open Threat Signaling (DOTS) situations, the IETF has specified the DDoS Open Threat Signaling (DOTS)
architecture <xref target="RFC8811"></xref>, where a DOTS client can architecture <xref target="RFC8811" format="default"/>, where a DOTS clien t can
inform an upstream DOTS server that its network is under a potential inform an upstream DOTS server that its network is under a potential
attack and that appropriate mitigation actions are required. The DOTS attack and that appropriate mitigation actions are required. The DOTS
protocols can be used to coordinate real-time mitigation efforts which protocols can be used to coordinate real-time mitigation efforts that
can evolve as the attacks mutate, thereby reducing the impact of an can evolve as the attacks mutate, thereby reducing the impact of an
attack and leading to more efficient responsive actions. <xref attack and leading to more-efficient responsive actions. <xref target="RFC
target="RFC8903"></xref> identifies a set of scenarios for DOTS; most of 8903" format="default"/> identifies a set of scenarios for DOTS; most of
these scenarios involve a Customer Premises Equipment (CPE).</t> these scenarios involve a Customer Premises Equipment (CPE).</t>
<t>The high-level base DOTS architecture is illustrated in <xref target="a
<t>The high-level base DOTS architecture is illustrated in <xref rch" format="default"/> (repeated from <xref target="RFC8811" sectionFormat="of"
target="arch"></xref> (<xref target="RFC8811"></xref>):</t> section="2"/>):</t>
<figure anchor="arch">
<t><figure align="center" anchor="arch" title="Basic DOTS Architecture"> <name>Basic DOTS Architecture</name>
<artwork align="center"><![CDATA[+-----------+ +----------- <artwork align="center" name="" type="" alt=""><![CDATA[
--+ +-----------+ +-------------+
| Mitigator | ~~~~~~~~~~ | DOTS Server | | Mitigator | ~~~~~~~~~~ | DOTS Server |
+-----------+ +-------------+ +-----------+ +-------------+
| |
| |
| |
+---------------+ +-------------+ +---------------+ +-------------+
| Attack Target | ~~~~~~ | DOTS Client | | Attack Target | ~~~~~~ | DOTS Client |
+---------------+ +-------------+ +---------------+ +-------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t><xref target="RFC8811" format="default"/> specifies that the DOTS clien
<t><xref target="RFC8811"></xref> specifies that the DOTS client may be t may be
provided with a list of DOTS servers; each of these servers is provided with a list of DOTS servers; each of these servers is
associated with one or more IP addresses. These addresses may or may not 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 be of the same address family. The DOTS client establishes one or more DO
DOTS sessions by connecting to the provided DOTS server(s) addresses TS sessions by
(e.g., by using <xref target="RFC8973"></xref>).</t> connecting to the provided addresses for the DOTS server or
servers <xref target="RFC8973" format="default"/>.</t>
<t>DOTS may be deployed within networks that are connected to one single <t>DOTS may be deployed within networks that are connected to one single
upstream provider. DOTS can also be enabled within networks that are upstream provider. DOTS can also be enabled within networks that are
multi-homed. The reader may refer to <xref target="RFC3582"></xref> for multihomed. The reader may refer to <xref target="RFC3582" format="default
an overview of multi-homing goals and motivations. This document "/> for
discusses DOTS multi-homing considerations. Specifically, the document an overview of multihoming goals and motivations. This document
aims to:<list style="numbers"> discusses DOTS multihoming considerations. Specifically, the document
<t>Complete the base DOTS architecture with multi-homing specifics. aims to:</t>
Those specifics need to be taken into account because: <list <ol spacing="normal"><li>
style="symbols"> <t>Complete the base DOTS architecture with multihoming specifics.
<t>Sending a DOTS mitigation request to an arbitrary DOTS server Those specifics need to be taken into account because: </t>
will not necessarily help in mitigating a DDoS attack.</t> <ul spacing="normal">
<li>Sending a DOTS mitigation request to an arbitrary DOTS server
<t>Randomly replicating all DOTS mitigation requests among all will not necessarily help in mitigating a DDoS attack.</li>
available DOTS servers is suboptimal.</t> <li>Randomly replicating all DOTS mitigation requests among all
available DOTS servers is suboptimal.</li>
<t>Sequentially contacting DOTS servers may increase the delay <li>Sequentially contacting DOTS servers may increase the delay
before a mitigation plan is enforced.</t> before a mitigation plan is enforced.</li>
</list></t> </ul>
</li>
<t>Identify DOTS deployment schemes in a multi-homing context, where <li>Identify DOTS deployment schemes in a multihoming context, where
DOTS services can be offered by all or a subset of upstream DOTS services can be offered by all or a subset of upstream
providers.</t> providers.</li>
<li>
<t>Provide guidelines and recommendations for placing DOTS requests <t>Provide guidelines and recommendations for placing DOTS requests
in multi-homed networks, e.g.,: <list style="symbols"> in multihomed networks, for example: </t>
<t>Select the appropriate DOTS server(s).</t> <ul spacing="normal">
<li>Select the appropriate DOTS server(s).</li>
<t>Identify cases where anycast is not recommended for DOTS.</t> <li>Identify cases where anycast is not recommended for DOTS.</li>
</list></t> </ul>
</list></t> </li>
</ol>
<t>This document adopts the following methodology: <list style="symbols">
<t>Identify and extract viable deployment candidates from <xref
target="RFC8903"></xref>.</t>
<t>Augment the description with multi-homing technicalities, e.g.,
<list style="symbols">
<t>One vs. multiple upstream network providers</t>
<t>One vs. multiple interconnect routers</t>
<t>Provider-Independent (PI) vs. Provider-Aggregatable (PA) IP
addresses</t>
</list></t>
<t>Describe the recommended behavior of DOTS clients and
client-domain DOTS gateways for each case.</t>
</list></t>
<t>Multi-homed DOTS agents are assumed to make use of the protocols <t>This document adopts the following methodology: </t>
defined in <xref target="RFC9132"></xref> and <xref <ul spacing="normal">
target="RFC8783"></xref>. This document does not require any specific <li>Identify and extract viable deployment candidates from <xref target=
extension to the base DOTS protocols for deploying DOTS in a multi-homed "RFC8903" format="default"/>.</li>
<li>
<t>Augment the description with multihoming technicalities, for exampl
e:
</t>
<ul spacing="normal">
<li>One vs. multiple upstream network providers</li>
<li>One vs. multiple interconnect routers</li>
<li>Provider-Independent (PI) vs. Provider-Aggregatable (PA) IP
addresses</li>
</ul>
</li>
<li>Describe the recommended behavior of DOTS clients and
client-domain DOTS gateways for each case.</li>
</ul>
<t>Multihomed DOTS agents are assumed to make use of the protocols
defined in <xref target="RFC9132" format="default"/> and <xref target="RFC
8783" format="default"/>. This document does not require any specific
extension to the base DOTS protocols for deploying DOTS in a multihomed
context.</t> context.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Requirements Language"> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP 14 IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
only when, they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminology"> <name>Terminology</name>
<t>This document makes use of the terms defined in <xref <t>This document makes use of the terms defined in <xref target="RFC8811"
target="RFC8811"></xref>, <xref target="RFC8612"></xref>, and <xref format="default"/>, <xref target="RFC8612" format="default"/>, and <xref target=
target="RFC4116"></xref>. In particular:</t> "RFC4116" format="default"/>. In particular:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>Provider-Aggregatable (PA) addresses:</dt>
<t hangText="Provider-Aggregatable (PA) addresses:">globally-unique <dd>globally unique
addresses assigned by a transit provider to a customer. The addresses assigned by a transit provider to a customer. The
addresses are considered "aggregatable" because the set of routes addresses are considered "aggregatable" because the set of routes
corresponding to the PA addresses are usually covered by an corresponding to the PA addresses are usually covered by an
aggregate route set corresponding to the address space operated by aggregate route set corresponding to the address space operated by
the transit provider, from which the assignment was made (Section 2 the transit provider, from which the assignment was made (<xref target
of <xref target="RFC4116"></xref>).</t> ="RFC4116" section="2" sectionFormat="of"/>).</dd>
<dt>Provider-Independent (PI) addresses:</dt>
<t hangText="Provider-Independent (PI) addresses:">globally-unique <dd>globally unique
addresses that are not assigned by a transit provider, but are addresses that are not assigned by a transit provider, but are
provided by some other organisation, usually a Regional Internet provided by some other organization, usually a Regional Internet
Registry (RIR) (Section 2 of <xref target="RFC4116"></xref>).</t> Registry (RIR) (<xref target="RFC4116" section="2" sectionFormat="of"/
</list></t> >).</dd>
</dl>
<t>IP indifferently refers to IPv4 or IPv6.</t> <t>IP indifferently refers to IPv4 or IPv6.</t>
</section> </section>
<section anchor="msc" numbered="true" toc="default">
<section anchor="msc" title="Multi-Homing Scenarios"> <name>Multihoming Scenarios</name>
<t>This section describes some multi-homing scenarios that are relevant <t>This section describes some multihoming scenarios that are relevant
to DOTS. In the following subsections, only the connections of border to DOTS. In the following subsections, only the connections of border
routers are shown; internal network topologies are not elaborated.</t> routers are shown; internal network topologies are not elaborated.</t>
<t>A multihomed network may enable DOTS for all or a subset of its <t>A multihomed network may enable DOTS for all or a subset of its
upstream interconnection links. In such a case, DOTS servers can be upstream interconnection links. In such a case, DOTS servers can be
explicitly configured or dynamically discovered by a DOTS client using explicitly configured or dynamically discovered by a DOTS client using
means such as those discussed in <xref target="RFC8973"></xref>. These means such as those discussed in <xref target="RFC8973" format="default"/> . These
DOTS servers can be owned by the upstream provider, managed by a DOTS servers can be owned by the upstream provider, managed by a
third-party (e.g., mitigation service provider), or a combination third-party (e.g., mitigation service provider), or a combination
thereof.</t> thereof.</t>
<t>If a DOTS server is explicitly configured, it is assumed that an <t>If a DOTS server is explicitly configured, it is assumed that an
interface is also provided to bind the DOTS service to an interface is also provided to bind the DOTS service to an
interconnection link. If no interface is provided, this means that the interconnection link. If no interface is provided, the
DOTS server can be reached via any active interface.</t> DOTS server can be reached via any active interface.</t>
<t>This section distinguishes between residential CPEs and enterprise
<t>This section distinguishes between residential CPEs vs. enterprise CPEs because PI addresses may be used for enterprises, which is not
CPEs because PI addresses may be used for enterprises while this is not
the current practice for residential CPEs.</t> the current practice for residential CPEs.</t>
<t>In the following subsections, all or a subset of interconnection <t>In the following subsections, all or a subset of interconnection
links are associated with DOTS servers.</t> links are associated with DOTS servers.</t>
<section anchor="sc1" title="Multi-Homed Residential Single CPE"> <section anchor="sc1" numbered="true" toc="default">
<t>The scenario shown in <xref target="rcpe"></xref> is characterized <name>Multihomed Residential: Single CPE</name>
as follows: <list style="symbols"> <t>The scenario shown in <xref target="rcpe" format="default"/> is chara
<t>The home network is connected to the Internet using one single cterized
CPE.</t> as follows: </t>
<ul spacing="normal">
<li>The home network is connected to the Internet using one single
CPE.</li>
<li>
<t>The CPE is connected to multiple provisioning domains (i.e., <t>The CPE is connected to multiple provisioning domains (i.e.,
both fixed and mobile networks). Provisioning domain (PvD) is both fixed and mobile networks). Provisioning Domain (PvD) is
explained in <xref target="RFC7556"></xref>. <vspace explained in <xref target="RFC7556" format="default"/>. </t>
blankLines="1" />In a typical deployment scenario, these <t>In a typical deployment scenario, these
provisioning domains are owned by the same provider (see Section 1 provisioning domains are owned by the same provider (<xref target="R
of <xref target="RFC8803"></xref>). Such a deployment is meant to FC8803" sectionFormat="of" section="1" format="default"/>). Such a deployment is
meant to
seamlessly use both fixed and cellular networks for bonding, seamlessly use both fixed and cellular networks for bonding,
faster hand-overs, or better resiliency purposes.</t> faster handovers, or better resiliency purposes.</t>
</li>
<t>Each of these provisioning domains assigns IP
addresses/prefixes to the CPE and provides additional
configuration information such as a list of DNS servers, DNS
suffixes associated with the network, default gateway address, and
DOTS server's name <xref target="RFC8973"></xref>. These
addresses/prefixes are assumed to be Provider-Aggregatable
(PA).</t>
<t>Because of ingress filtering, packets forwarded by the CPE <li>Each of these provisioning domains assigns IP addresses or prefixes
to the CPE and provides additional configuration information such
as a list of DNS servers, DNS suffixes associated with the
network, the default gateway address, and the DOTS server's name <xref tar
get="RFC8973" format="default"/>. These
addresses or prefixes are assumed to be Provider-Aggregatable
(PA).</li>
<li>Because of ingress filtering, packets forwarded by the CPE
towards a given provisioning domain must be sent with a source IP towards a given provisioning domain must be sent with a source IP
address that was assigned by that domain <xref address that was assigned by that domain <xref target="RFC8043" form
target="RFC8043"></xref>.</t> at="default"/>.</li>
</list></t> </ul>
<figure anchor="rcpe">
<t><figure align="center" anchor="rcpe" <name>Typical Multihomed Residential CPE</name>
title="Typical Multi-homed Residential CPE"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ +-------+ +-------+ +-------+ +-------+
|Fixed | |Mobile | |Fixed | |Mobile |
|Network| |Network| |Network| |Network|
+---+---+ +---+---+ +---+---+ +---+---+
| | Service Providers | | Service Providers
............|....................|....................... ............|....................|.......................
+---------++---------+ Home Network +---------++---------+ Home Network
|| ||
+--++-+ +--++-+
| CPE | | CPE |
+-----+ +-----+
skipping to change at line 292 skipping to change at line 231
|Network| |Network| |Network| |Network|
+---+---+ +---+---+ +---+---+ +---+---+
| | Service Providers | | Service Providers
............|....................|....................... ............|....................|.......................
+---------++---------+ Home Network +---------++---------+ Home Network
|| ||
+--++-+ +--++-+
| CPE | | CPE |
+-----+ +-----+
... (Internal Network) ... (Internal Network)
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
<section anchor="sc2" numbered="true" toc="default">
<section anchor="sc2" <name>Multihomed Enterprise: Single CPE, Multiple Upstream ISPs</name>
title="Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs <t>The scenario shown in <xref target="scmi" format="default"/> is chara
"> cterized
<t>The scenario shown in <xref target="scmi"></xref> is characterized as follows: </t>
as follows: <list style="symbols"> <ul spacing="normal">
<t>The enterprise network is connected to the Internet using a <li>The enterprise network is connected to the Internet using a
single router.</t> single router.</li>
<li>That router is connected to multiple provisioning domains
<t>That router is connected to multiple provisioning domains managed by distinct administrative entities.</li>
managed by distinct administrative entities.</t> </ul>
</list></t>
<t>Unlike the previous scenario, two sub-cases can be considered for <t>Unlike the previous scenario, two sub-cases can be considered for
an enterprise network with regards to assigned addresses:</t> an enterprise network with regard to assigned addresses:</t>
<ol spacing="normal" type="1"><li>PI addresses or prefixes: The enterpri
<t><list style="numbers"> se is the owner of the IP
<t>PI addresses/prefixes: The enterprise is the owner of the IP addresses or prefixes; the same address or prefix is then used when
addresses/prefixes; the same address/prefix is then used when
establishing communications over any of the provisioning establishing communications over any of the provisioning
domains.</t> domains.</li>
<li>PA addresses or prefixes: Each of the provisioning domains assigns
<t>PA addresses/prefixes: Each of the provisioning domains assigns IP addresses or prefixes to the enterprise network. These
IP addresses/prefixes to the enterprise network. These addresses or prefixes are used when communicating over the
addresses/prefixes are used when communicating over the provisioning domain that assigned them.</li>
provisioning domain that assigned them.</t> </ol>
</list></t> <figure anchor="scmi">
<name>Multihomed Enterprise Network (Single CPE Connected to Multiple
<t><figure align="center" anchor="scmi" Networks)</name>
title="Multi-homed Enterprise Network (Single CPE connected to Multi <artwork name="" type="" align="left" alt=""><![CDATA[
ple Networks)"> +------+ +------+
<artwork><![CDATA[ +------+ +------+
| ISP1 | | ISP2 | | ISP1 | | ISP2 |
+---+--+ +--+---+ +---+--+ +--+---+
| | Service Providers | | Service Providers
............|....................|....................... ............|....................|.......................
+---------++---------+ Enterprise Network +---------++---------+ Enterprise Network
|| ||
+--++-+ +--++-+
| CPE | | CPE |
+-----+ +-----+
... (Internal Network) ... (Internal Network)
skipping to change at line 336 skipping to change at line 269
| ISP1 | | ISP2 | | ISP1 | | ISP2 |
+---+--+ +--+---+ +---+--+ +--+---+
| | Service Providers | | Service Providers
............|....................|....................... ............|....................|.......................
+---------++---------+ Enterprise Network +---------++---------+ Enterprise Network
|| ||
+--++-+ +--++-+
| CPE | | CPE |
+-----+ +-----+
... (Internal Network) ... (Internal Network)
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
<section anchor="sc3" numbered="true" toc="default">
<section anchor="sc3" <name>Multihomed Enterprise: Multiple CPEs, Multiple Upstream ISPs</name
title="Multi-homed Enterprise: Multiple CPEs, Multiple Upstream I >
SPs"> <t>This scenario is similar to the one described in <xref target="sc2" f
<t>This scenario is similar to the one described in <xref ormat="default"/>; the main difference is that dedicated routers
target="sc2"></xref>; the main difference is that dedicated routers
(CPE1 and CPE2) are used to connect to each provisioning domain.</t> (CPE1 and CPE2) are used to connect to each provisioning domain.</t>
<figure anchor="mcmi">
<t><figure anchor="mcmi" <name>Multihomed Enterprise Network (Multiple CPEs, Multiple ISPs)</na
title="Multi-homed Enterprise Network (Multiple CPEs, Multiple ISPs) me>
"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ +------+ +------+ +------+ +------+
| ISP1 | | ISP2 | | ISP1 | | ISP2 |
+---+--+ +--+---+ +---+--+ +--+---+
| | Service Providers | | Service Providers
......................|..........|....................... ......................|..........|.......................
| | Enterprise Network | | Enterprise Network
+---+--+ +--+---+ +---+--+ +--+---+
| CPE1 | | CPE2 | | CPE1 | | CPE2 |
+------+ +------+ +------+ +------+
... (Internal Network) ... (Internal Network)
skipping to change at line 360 skipping to change at line 290
| ISP1 | | ISP2 | | ISP1 | | ISP2 |
+---+--+ +--+---+ +---+--+ +--+---+
| | Service Providers | | Service Providers
......................|..........|....................... ......................|..........|.......................
| | Enterprise Network | | Enterprise Network
+---+--+ +--+---+ +---+--+ +--+---+
| CPE1 | | CPE2 | | CPE1 | | CPE2 |
+------+ +------+ +------+ +------+
... (Internal Network) ... (Internal Network)
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
<section anchor="sc4" numbered="true" toc="default">
<section anchor="sc4" title="Multi-homed Enterprise with the Same ISP"> <name>Multihomed Enterprise with the Same ISP</name>
<t>This scenario is a variant of Sections <xref format="counter" <t>This scenario is a variant of Sections <xref format="counter" target=
target="sc2"></xref> and <xref format="counter" target="sc3"></xref> "sc2"/> and <xref format="counter" target="sc3"/>
in which multi-homing is supported by the same ISP (i.e., same in which multihoming is supported by the same ISP (i.e., same
provisioning domain).</t> provisioning domain).</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="DOTS Multi-homing Deployment Considerations"> <name>DOTS Multihoming Deployment Considerations</name>
<t><xref target="dep"></xref> provides some sample, non-exhaustive, <t><xref target="dep" format="default"/> provides some sample, non-exhaust
ive
deployment schemes to illustrate how DOTS agents may be deployed for deployment schemes to illustrate how DOTS agents may be deployed for
each of the scenarios introduced in <xref target="msc"></xref>.</t> each of the scenarios introduced in <xref target="msc" format="default"/>.
</t>
<texttable anchor="dep" style="all" title="Sample Deployment Cases"> <table anchor="dep" align="center">
<ttcol align="center">Scenario</ttcol> <name>Sample Deployment Cases</name>
<thead>
<ttcol align="center">DOTS client</ttcol> <tr>
<th align="center">Scenario</th>
<ttcol align="center">Client-domain DOTS gateway</ttcol> <th align="center">DOTS Client</th>
<th align="center">Client-Domain DOTS Gateway</th>
<c>Residential CPE</c> </tr>
</thead>
<c>CPE</c> <tbody>
<tr>
<c>N/A</c> <td align="center">Residential CPE</td>
<td align="center">CPE</td>
<c>Single CPE, Multiple provisioning domains</c> <td align="center">N/A</td>
</tr>
<c>Internal hosts or CPE</c> <tr>
<td align="center">Single CPE, multiple provisioning domains</td>
<c>CPE</c> <td align="center">Internal hosts or CPE</td>
<td align="center">CPE</td>
<c>Multiple CPEs, Multiple provisioning domains</c> </tr>
<tr>
<c>Internal hosts or all CPEs (CPE1 and CPE2)</c> <td align="center">Multiple CPEs, multiple provisioning domains</td>
<td align="center">Internal hosts or all CPEs (CPE1 and CPE2)</td>
<c>CPEs (CPE1 and CPE2)</c> <td align="center">CPEs (CPE1 and CPE2)</td>
</tr>
<c>Multi-homed enterprise, Single provisioning domain</c> <tr>
<td align="center">Multihomed enterprise, single provisioning domain
<c>Internal hosts or all CPEs (CPE1 and CPE2)</c> </td>
<td align="center">Internal hosts or all CPEs (CPE1 and CPE2)</td>
<c>CPEs (CPE1 and CPE2)</c> <td align="center">CPEs (CPE1 and CPE2)</td>
</texttable> </tr>
</tbody>
</table>
<t>These deployment schemes are further discussed in the following <t>These deployment schemes are further discussed in the following
subsections.</t> subsections.</t>
<section anchor="dcpe" numbered="true" toc="default">
<section anchor="dcpe" title="Residential CPE"> <name>Residential CPE</name>
<t><xref target="dotsrcpe"></xref> depicts DOTS sessions that need to <t><xref target="dotsrcpe" format="default"/> depicts DOTS sessions that
need to
be established between a DOTS client (C) and two DOTS servers (S1, S2) be established between a DOTS client (C) and two DOTS servers (S1, S2)
within the context of the scenario described in <xref within the context of the scenario described in <xref target="sc1" forma
target="sc1"></xref>. As listed in <xref target="dep"></xref>, the t="default"/>. As listed in <xref target="dep" format="default"/>, the
DOTS client is hosted by the residential CPE.</t> DOTS client is hosted by the residential CPE.</t>
<figure anchor="dotsrcpe">
<t><figure align="center" anchor="dotsrcpe" <name>DOTS Associations for a Multihomed Residential CPE</name>
title="DOTS Associations for a Multihomed Residential CPE"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[ +--+ +--+
----------|S1| ----------|S1|
/ +--+ / +--+
/ DOTS Server Domain #1 / DOTS Server Domain #1
/ /
+---+/ +---+/
| C | | C |
+---+\ +---+\
CPE \ CPE \
\ \
\ +--+ \ +--+
----------|S2| ----------|S2|
+--+ +--+
DOTS Server Domain #2 DOTS Server Domain #2
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The DOTS client MUST resolve the DOTS server's name provided by <t>The DOTS client <bcp14>MUST</bcp14> resolve the DOTS server's name pr
each provisioning domain using either the DNS servers learned from the ovided by each
respective provisioning domain or from the DNS servers associated with provisioning domain using the DNS servers either learned from the
the interface(s) for which a DOTS server was explicitly configured respective provisioning domain or associated
(<xref target="msc"></xref>). IPv6-capable DOTS clients MUST use the with the interface(s) for which a DOTS server was explicitly
source address selection algorithm defined in <xref configured
target="RFC6724"></xref> to select the candidate source addresses to (<xref target="msc" format="default"/>). IPv6-capable DOTS clients <bcp1
contact each of these DOTS servers. DOTS sessions MUST be established 4>MUST</bcp14> use the
and MUST be maintained with each of the DOTS servers because the source address selection algorithm defined in <xref target="RFC6724" for
mat="default"/> to select the candidate source addresses to
contact each of these DOTS servers. DOTS sessions <bcp14>MUST</bcp14> be
established
and <bcp14>MUST</bcp14> be maintained with each of the DOTS servers beca
use the
mitigation scope of each of these servers is restricted. The DOTS mitigation scope of each of these servers is restricted. The DOTS
client MUST use the security credentials (a certificate, typically) client <bcp14>MUST</bcp14> use the security credentials (a certificate, typically)
provided by a provisioning domain to authenticate itself to the DOTS provided by a provisioning domain to authenticate itself to the DOTS
server(s) provided by the same provisioning domain. How such security server(s) provided by the same provisioning domain. How such security
credentials are provided to the DOTS client is out of the scope of credentials are provided to the DOTS client is out of the scope of
this document. The reader may refer to Section 7.1 of <xref this document. The reader may refer to <xref target="RFC9132" sectionFor
target="RFC9132"></xref> for more details about DOTS authentication mat="of" section="7.1" format="default"/> for more details about DOTS authentica
tion
methods.</t> methods.</t>
<t>When conveying a mitigation request to protect the attack <t>When conveying a mitigation request to protect the attack
target(s), the DOTS client MUST select an available DOTS server whose target(s), the DOTS client <bcp14>MUST</bcp14> select an available DOTS server whose
network has assigned the IP prefixes from which target network has assigned the IP prefixes from which target
prefixes/addresses are derived. This implies that if no appropriate addresses or prefixes are derived. This implies that if no appropriate
DOTS server is found, the DOTS client MUST NOT send the mitigation DOTS server is found, the DOTS client <bcp14>MUST NOT</bcp14> send the m
itigation
request to any other available DOTS server.</t> request to any other available DOTS server.</t>
<t>For example, a mitigation request to protect target resources bound <t>For example, a mitigation request to protect target resources bound
to a PA IP address/prefix cannot be satisfied by a provisioning domain to a PA IP address or prefix cannot be satisfied by a provisioning domai
other than the one that owns those addresses/prefixes. Consequently, n
other than the one that owns those addresses or prefixes. Consequently,
if a CPE detects a DDoS attack that spreads over all its network if a CPE detects a DDoS attack that spreads over all its network
attachments, it MUST contact all DOTS servers for mitigation attachments, it <bcp14>MUST</bcp14> contact all DOTS servers for mitigat ion
purposes.</t> purposes.</t>
<t>The DOTS client <bcp14>MUST</bcp14> be able to associate a DOTS serve
<t>The DOTS client MUST be able to associate a DOTS server with each r with each
provisioning domain it serves. For example, if the DOTS client is provisioning domain it serves. For example, if the DOTS client is
provisioned with S1 using DHCP when attaching to a first network and provisioned with S1 using DHCP when attaching to a first network and
with S2 using Protocol Configuration Option (PCO) <xref with S2 using Protocol Configuration Option (PCO) <xref target="TS.24008
target="TS.24008"></xref> when attaching to a second network, the DOTS " format="default"/> when attaching to a second network, the DOTS
client must record the interface from which a DOTS server was client must record the interface from which a DOTS server was
provisioned. A DOTS signaling session to a given DOTS server must be provisioned. A DOTS signaling session to a given DOTS server must be
established using the interface from which the DOTS server was established using the interface from which the DOTS server was
provisioned. If a DOTS server is explicitly configured, DOTS signaling provisioned. If a DOTS server is explicitly configured, DOTS signaling
with that server must be established via the interfaces that are with that server must be established via the interfaces that are
indicated in the explicit configuration or via any active interface if indicated in the explicit configuration or via any active interface if
no interface is configured.</t> no interface is configured.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs <name>Multihomed Enterprise: Single CPE, Multiple Upstream ISPs</name>
"> <t><xref target="dotsmcgms" format="default"/> illustrates the DOTS sess
<t><xref target="dotsmcgms"></xref> illustrates the DOTS sessions that ions that
can be established with a client-domain DOTS gateway (hosted within can be established with a client-domain DOTS gateway (hosted within
the CPE as per <xref target="dep"></xref>), which is enabled within the CPE as per <xref target="dep" format="default"/>) that is enabled wi
the context of the scenario described in <xref target="sc2"></xref>. thin
the context of the scenario described in <xref target="sc2" format="defa
ult"/>.
This deployment is characterized as follows:</t> This deployment is characterized as follows:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>One or more DOTS clients are enabled in hosts located in the
<t>One or more DOTS clients are enabled in hosts located in the internal network.</li>
internal network.</t> <li>A client-domain DOTS gateway is enabled to aggregate and then
relay the requests towards upstream DOTS servers.</li>
<t>A client-domain DOTS gateway is enabled to aggregate and then </ul>
relay the requests towards upstream DOTS servers.</t> <figure anchor="dotsmcgms">
</list></t> <name>Multiple DOTS Clients, Single DOTS Gateway, Multiple DOTS Server
s</name>
<t><figure align="center" anchor="dotsmcgms" <artwork align="center" name="" type="" alt=""><![CDATA[
title="Multiple DOTS Clients, Single DOTS Gateway, Multiple DOTS Ser +--+
vers">
<artwork align="center"><![CDATA[ +-
-+
.................... ----------|S1| .................... ----------|S1|
. +---+ . / +--+ . +---+ . / +--+
. | C1|----+ ./ DOTS Server Domain #1 . | C1|----+ ./ DOTS Server Domain #1
. +---+ | . . +---+ | .
. | /. . | /.
.+---+ +-+-+/ . .+---+ +-+-+/ .
.| C3|------| G | . .| C3|------| G | .
.+---+ +-+-+\ . .+---+ +-+-+\ .
. CPE \. . CPE \.
. +---+ | . . +---+ | .
. | C2|----+ .\ . | C2|----+ .\
. +---+ . \ +--+ . +---+ . \ +--+
'..................' ----------|S2| '..................' ----------|S2|
+--+ +--+
DOTS Client Domain DOTS Server Domain #2 DOTS Client Domain DOTS Server Domain #2
]]></artwork> ]]></artwork>
</figure>When PA addresses/prefixes are in use, the same </figure>
considerations discussed in <xref target="dcpe"></xref> need to be <t>When PA addresses or prefixes are in use, the same
considerations discussed in <xref target="dcpe" format="default"/> need
to be
followed by the client-domain DOTS gateway to contact its DOTS followed by the client-domain DOTS gateway to contact its DOTS
server(s). The client-domain DOTS gateways can be reachable from DOTS server(s). The client-domain DOTS gateways can be reachable from DOTS
clients by using a unicast address or an anycast address (Section clients by using a unicast address or an anycast address (<xref target="
3.2.4 of <xref target="RFC8811"></xref>).</t> RFC8811" section="3.2.4" sectionFormat="of"/>).</t>
<t>Nevertheless, when PI addresses or prefixes are assigned, and absent
<t>Nevertheless, when PI addresses/prefixes are assigned and absent any policy, the client-domain DOTS gateway <bcp14>SHOULD</bcp14> send mi
any policy, the client-domain DOTS gateway SHOULD send mitigation tigation
requests to all its DOTS servers. Otherwise, the attack traffic may requests to all its DOTS servers. Otherwise, the attack traffic may
still be delivered via the ISP that hasn&rsquo;t received the still be delivered via the ISP that hasn't received the
mitigation request.</t> mitigation request.</t>
<t>An alternate deployment model is depicted in <xref target="mcms" form
<t>An alternate deployment model is depicted in <xref at="default"/>. This deployment assumes that:</t>
target="mcms"></xref>. This deployment assumes that:</t> <ul spacing="normal">
<li>One or more DOTS clients are enabled in hosts located in the
<t><list style="symbols"> internal network. These DOTS clients may use <xref target="RFC8973"
<t>One or more DOTS clients are enabled in hosts located in the format="default"/> to discover their DOTS server(s).</li>
internal network. These DOTS clients may use <xref <li>These DOTS clients communicate directly with upstream DOTS
target="RFC8973"></xref> to discover their DOTS server(s).</t> servers.</li>
</ul>
<t>These DOTS clients communicate directly with upstream DOTS <figure anchor="mcms">
servers.</t> <name>Multiple DOTS Clients, Multiple DOTS Servers</name>
</list></t> <artwork align="center" name="" type="" alt=""><![CDATA[
..........
<t><figure align="center" anchor="mcms"
title="Multiple DOTS Clients, Multiple DOTS Servers">
<artwork align="center"><![CDATA[ ..........
. +--+ . . +--+ .
+--------|C1|--------+ +--------|C1|--------+
| . +--+ . | | . +--+ . |
| . . | | . . |
+--+ . +--+ . +--+ +--+ . +--+ . +--+
|S2|------|C3|------|S1| |S2|------|C3|------|S1|
+--+ . +--+ . +--+ +--+ . +--+ . +--+
| . . | | . . |
| . +--+ . | | . +--+ . |
+--------|C2|--------+ +--------|C2|--------+
. +--+ . . +--+ .
'........' '........'
DOTS Client DOTS Client
Domain Domain
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>If PI addresses or prefixes are in use, the DOTS client <bcp14>MUST</
<t>If PI addresses/prefixes are in use, the DOTS client MUST send a bcp14> send a
mitigation request to all the DOTS servers. The use of the same mitigation request to all the DOTS servers. The use of the same
anycast addresses to reach these DOTS servers is NOT RECOMMENDED. If a anycast addresses to reach these DOTS servers is <bcp14>NOT RECOMMENDED< /bcp14>. If a
well-known anycast address is used to reach multiple DOTS servers, the well-known anycast address is used to reach multiple DOTS servers, the
CPE may not be able to select the appropriate provisioning domain to CPE may not be able to select the appropriate provisioning domain to
which the mitigation request should be forwarded. As a consequence, which the mitigation request should be forwarded. As a consequence,
the request may not be forwarded to the appropriate DOTS server.</t> the request may not be forwarded to the appropriate DOTS server.</t>
<t>If PA addresses or prefixes are used, the same considerations
<t>If PA addresses/prefixes are used, the same considerations discussed in <xref target="dcpe" format="default"/> need to be followed
discussed in <xref target="dcpe"></xref> need to be followed by the by the
DOTS clients. Because DOTS clients are not embedded in the CPE and DOTS clients. Because DOTS clients are not embedded in the CPE and
multiple addresses/prefixes may not be assigned to the DOTS client multiple addresses or prefixes may not be assigned to the DOTS client
(typically in an IPv4 context), some issues may arise in how to steer (typically in an IPv4 context), some issues may arise in how to steer
traffic towards the appropriate DOTS server by using the appropriate traffic towards the appropriate DOTS server by using the appropriate
source IP address. These complications discussed in <xref source IP address. These complications discussed in <xref target="RFC411
target="RFC4116"></xref> are not specific to DOTS.</t> 6" format="default"/> are not specific to DOTS.</t>
<t>Another deployment approach is to enable many DOTS clients; each of <t>Another deployment approach is to enable many DOTS clients; each of
them is responsible for handling communications with a specific DOTS them is responsible for handling communications with a specific DOTS
server (see <xref target="scms"></xref>).</t> server (see <xref target="scms" format="default"/>).</t>
<figure anchor="scms">
<t><figure align="center" anchor="scms" <name>Single-Homed DOTS Clients</name>
title="Single Homed DOTS Clients"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[ .......... ..........
. +--+ . . +--+ .
+--------|C1| . +--------|C1| .
| . +--+ . | . +--+ .
+--+ . +--+ . +--+ +--+ . +--+ . +--+
|S2| . |C2|------|S1| |S2| . |C2|------|S1|
+--+ . +--+ . +--+ +--+ . +--+ . +--+
'........' '........'
DOTS Client DOTS Client
Domain Domain
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>For both deployments depicted in Figures <xref format="counter" targe
<t>For both deployments depicted in Figures <xref format="counter" t="mcms"/> and <xref format="counter" target="scms"/>, each DOTS client <bcp14>S
target="mcms"></xref> and <xref format="counter" HOULD</bcp14> be provided with
target="scms"></xref>, each DOTS client SHOULD be provided with
policies (e.g., a prefix filter that is used to filter DDoS detection policies (e.g., a prefix filter that is used to filter DDoS detection
alarms) that will trigger DOTS communications with the DOTS servers. alarms) that will trigger DOTS communications with the DOTS servers.
Such policies will help the DOTS client to select the appropriate Such policies will help the DOTS client to select the appropriate
destination DOTS server. The CPE MUST select the appropriate source IP destination DOTS server. The CPE <bcp14>MUST</bcp14> select the appropri ate source IP
address when forwarding DOTS messages received from an internal DOTS address when forwarding DOTS messages received from an internal DOTS
client.</t> client.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Multi-Homed Enterprise: Multiple CPEs, Multiple Upstream I <name>Multihomed Enterprise: Multiple CPEs, Multiple Upstream ISPs</name
SPs"> >
<t>The deployments depicted in Figures <xref format="counter" <t>The deployments depicted in Figures <xref format="counter" target="mc
target="mcms"></xref> and <xref format="counter" target="scms"></xref> ms"/> and <xref format="counter" target="scms"/>
also apply to the scenario described in <xref target="sc3"></xref>. also apply to the scenario described in <xref target="sc3" format="defau
lt"/>.
One specific problem for this scenario is to select the appropriate One specific problem for this scenario is to select the appropriate
exit router when contacting a given DOTS server.</t> exit router when contacting a given DOTS server.</t>
<t>An alternative deployment scheme is shown in <xref target="mcmgms" fo
<t>An alternative deployment scheme is shown in <xref rmat="default"/>:</t>
target="mcmgms"></xref>:<list style="symbols"> <ul spacing="normal">
<t>DOTS clients are enabled in hosts located in the internal <li>DOTS clients are enabled in hosts located in the internal
network.</t> network.</li>
<li>A client-domain DOTS gateway is enabled in each CPE (CPE1 and
<t>A client-domain DOTS gateway is enabled in each CPE (CPE1 and CPE2 per <xref target="dep" format="default"/>).</li>
CPE2 per <xref target="dep"></xref>).</t> <li>Each of these client-domain DOTS gateways communicates with the
DOTS server of the provisioning domain.</li>
<t>Each of these client-domain DOTS gateways communicates with the </ul>
DOTS server of the provisioning domain.</t> <figure anchor="mcmgms">
</list></t> <name>Multiple DOTS Clients, Multiple DOTS Gateways, Multiple DOTS Ser
vers</name>
<t><figure align="center" anchor="mcmgms" <artwork align="center" name="" type="" alt=""><![CDATA[
title="Multiple DOTS Clients, Multiple DOTS Gateways, Multiple DOTS .................................
Servers">
<artwork align="center"><![CDATA[ ............................
.....
. +---+ . . +---+ .
. +------------| C1|----+ . . +------------| C1|----+ .
. | +---+ | . . | +---+ | .
. | | . . | | .
+--+ . +-+-+ +---+ +-+-+ . +--+ +--+ . +-+-+ +---+ +-+-+ . +--+
|S2|------|G2 |------| C3|------|G1 |------|S1| |S2|------|G2 |------| C3|------|G1 |------|S1|
+--+ . +-+-+ +---+ +-+-+ . +--+ +--+ . +-+-+ +---+ +-+-+ . +--+
. CPE2 CPE1 . . CPE2 CPE1 .
. | +---+ | . . | +---+ | .
. +------------| C2|----+ . . +------------| C2|----+ .
. +---+ . . +---+ .
'...............................' '...............................'
DOTS Client Domain DOTS Client Domain
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>When PI addresses or prefixes are used, DOTS clients <bcp14>MUST</bcp
<t>When PI addresses/prefixes are used, DOTS clients MUST contact all 14> contact all
the client-domain DOTS gateways to send a DOTS message. Client-domain the client-domain DOTS gateways to send a DOTS message. Client-domain
DOTS gateways will then relay the request to the DOTS servers as a DOTS gateways will then relay the request to the DOTS servers as a
function of local policy. Note that (same) anycast addresses cannot be function of local policy. Note that (same) anycast addresses cannot be
used to establish DOTS sessions between DOTS clients and client-domain used to establish DOTS sessions between DOTS clients and client-domain
DOTS gateways because only one DOTS gateway will receive the DOTS gateways because only one DOTS gateway will receive the
mitigation request. </t> mitigation request. </t>
<t> When PA addresses/prefixes are used, but no filter rules are provide
d
to DOTS clients, the DOTS clients <bcp14>MUST</bcp14> contact all client-
domain DOTS gateways simultaneously to send a DOTS message.
<t>When PA addresses/prefixes are used, but no filter rules are Client-domain DOTS gateways <bcp14>MUST</bcp14> check whether a received
provided to DOTS clients, the latter MUST contact all client-domain request is to be forwarded upstream (if the target IP prefix is
DOTS gateways simultaneously to send a DOTS message. Upon receipt of a managed by the upstream server) or rejected.
request by a client-domain DOTS gateway, it MUST check whether the
request is to be forwarded upstream (if the target IP prefix is
managed by the upstream server) or rejected.</t>
<t>When PA addresses/prefixes are used, but specific filter rules are </t>
<t>When PA addresses or prefixes are used, but specific filter rules are
provided to DOTS clients using some means that are out of scope of provided to DOTS clients using some means that are out of scope of
this document, the clients MUST select the appropriate client-domain this document, the clients <bcp14>MUST</bcp14> select the appropriate cl
DOTS gateway to reach. The use of the same anycast addresses is NOT ient-domain
RECOMMENDED to reach client-domain DOTS gateways.</t> DOTS gateway to reach. The use of the same anycast addresses is <bcp14>N
OT
RECOMMENDED</bcp14> to reach client-domain DOTS gateways.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Multi-Homed Enterprise: Single ISP"> <name>Multihomed Enterprise: Single ISP</name>
<t>The key difference of the scenario described in <xref <t>The key difference between the scenario described in <xref target="sc
target="sc4"></xref> compared to the other scenarios is that 4" format="default"/> and the other scenarios is that
multi-homing is provided by the same ISP. Concretely, that ISP can multihoming is provided by the same ISP. Concretely, that ISP can
decide to provision the enterprise network with:</t> decide to provision the enterprise network with:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The same DOTS server for all network attachments.</li>
<t>The same DOTS server for all network attachments.</t> <li>Distinct DOTS servers for each network attachment. These DOTS
<t>Distinct DOTS servers for each network attachment. These DOTS
servers need to coordinate when a mitigation action is received servers need to coordinate when a mitigation action is received
from the enterprise network.</t> from the enterprise network.</li>
</list></t> </ul>
<t>In both cases, DOTS agents enabled within the enterprise network <t>In both cases, DOTS agents enabled within the enterprise network
MAY decide to select one or all network attachments to send DOTS <bcp14>MAY</bcp14> decide to select one or all network attachments to se nd DOTS
mitigation requests.</t> mitigation requests.</t>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>A set of security threats related to multihoming is discussed in
<xref target="RFC4218" format="default"/>.</t>
<section anchor="Security" title="Security Considerations"> <t>DOTS-related security considerations are discussed in <xref
<t>A set of security threats related to multihoming are discussed in target="RFC8811" sectionFormat="of" section="5" format="default"/>.</t>
<xref target="RFC4218"></xref>.</t>
<t>DOTS-related security considerations are discussed in Section 4 of
<xref target="RFC8811"></xref>.</t>
<t>DOTS clients should control the information that they share with peer <t>DOTS clients should control the information that they share with peer
DOTS servers. In particular, if a DOTS client maintains DOTS sessions DOTS servers. In particular, if a DOTS client maintains DOTS sessions
with specific DOTS servers per interconnection link, the DOTS client with specific DOTS servers per interconnection link, the DOTS client
SHOULD NOT leak information specific to a given link to DOTS servers on <bcp14>SHOULD NOT</bcp14> leak information specific to a given link to DOT S servers on
different interconnection links that are not authorized to mitigate different interconnection links that are not authorized to mitigate
attacks for that given link. Whether this constraint is relaxed is attacks for that given link. Whether this constraint is relaxed is
deployment-specific and must be subject to explicit consent from the deployment specific and must be subject to explicit consent from the
DOTS client domain administrator. How to seek for such consent is DOTS client domain administrator. How to seek such consent is
implementation- and deployment-specific.</t> implementation and deployment specific.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document does not require any action from IANA.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
<section anchor="Acknowledgements" title="Acknowledgements"> </section>
<t>Thanks to Roland Dobbins, Nik Teague, Jon Shallow, Dan Wing, and
Christian Jacquenet for sharing their comments on the mailing list.</t>
<t>Thanks to Kirill Kasavchenko for the comments.</t>
<t>Thanks to Kathleen Moriarty for the secdir review, Joel Jaeggli for
the opsdir review, Mirja Kuhlewind for the tsvart review, and Dave
Thaler for the Intdir review.</t>
<t>Many thanks to Roman Danyliw for the careful AD review.</t>
<t>Thanks to Lars Eggert, Robert Wilton, Paul Wouters, Erik Kline, and
&Eacute;ric Vyncke for the IESG review.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include="reference.RFC.2119"?> <name>References</name>
<references>
<?rfc include='reference.RFC.6724'?> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.8174'?> FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6724.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.8811.xml"/>
</references>
<references>
<name>Informative References</name>
<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.8973.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4116.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3582.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8043.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7556.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9132.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8783.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8903.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8803.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.4218.xml"/>
<?rfc include='reference.RFC.8811'?> <reference anchor="TS.24008" target="https://www.3gpp.org/DynaReport/240
08.htm">
<front>
<title>Mobile radio interface Layer 3 specification; Core network
protocols; Stage 3</title>
<author>
<organization>3GPP</organization>
</author>
<date month="December" year="2019"/>
</front>
<seriesInfo name="3GPP TS" value="24.008 16.3.0"/>
</reference>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Thanks to <contact fullname="Roland Dobbins"/>, <contact fullname="Nik
Teague"/>, <contact fullname="Jon Shallow"/>, <contact fullname="Dan Wing"/>, an
d
<contact fullname="Christian Jacquenet"/> for sharing their comments on th
e mailing list.</t>
<t>Thanks to <contact fullname="Kirill Kasavchenko"/> for the comments.</t
>
<t>Thanks to <contact fullname="Kathleen Moriarty"/> for the secdir review
, <contact fullname="Joel Jaeggli"/> for
the opsdir review, <contact fullname="Mirja Kühlewind"/> for the tsvart re
view, and <contact fullname="Dave
Thaler"/> for the intdir review.</t>
<t>Many thanks to <contact fullname="Roman Danyliw"/> for the careful AD r
eview.</t>
<t>Thanks to <contact fullname="Lars Eggert"/>, <contact fullname="Robert
Wilton"/>, <contact fullname="Paul Wouters"/>, <contact fullname="Erik Kline"/>,
and
<contact fullname="Éric Vyncke"/> for the IESG review.</t>
</section>
<references title="Informative References">
<?rfc include='reference.RFC.4732'?>
<?rfc include='reference.RFC.8973'?>
<?rfc include='reference.RFC.4116'?>
<?rfc include='reference.RFC.3582'?>
<?rfc include='reference.RFC.8043'?>
<?rfc include='reference.RFC.7556'?>
<?rfc include='reference.RFC.9132'?>
<?rfc include='reference.RFC.8783'?>
<?rfc include='reference.RFC.8903'?>
<?rfc include='reference.RFC.8803'?>
<?rfc include='reference.RFC.8612'?>
<?rfc include='reference.RFC.4218'?>
<reference anchor="TS.24008"
target="http://www.3gpp.org/DynaReport/24008.htm">
<front>
<title>Mobile radio interface Layer 3 specification; Core network
protocols; Stage 3 (Release 16)</title>
<author fullname="" surname="">
<organization>3GPP</organization>
</author>
<date day="0" month="December" year="2019" />
</front>
</reference>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 113 change blocks. 
516 lines changed or deleted 487 lines changed or added

This html diff was produced by rfcdiff 1.48.