rfc9066xml2.original.xml   rfc9066.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" docName="draft-ietf-dots-signal-
<?rfc inline="yes"?> call-home-14" number="9066" ipr="trust200902" obsoletes="" updates="" submission
<?rfc compact="yes"?> Type="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocD
<?rfc subcompact="no"?> epth="3" symRefs="true" sortRefs="true" version="3">
<rfc category="std" docName="draft-ietf-dots-signal-call-home-14"
ipr="trust200902">
<front> <front>
<title abbrev="DOTS Signal Call Home">Distributed Denial-of-Service Open <title abbrev="DOTS Signal Call Home">Distributed Denial-of-Service Open
Threat Signaling (DOTS) Signal Channel Call Home</title> Threat Signaling (DOTS) Signal Channel Call Home</title>
<seriesInfo name="RFC" value="9066"/>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy"> <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
<organization abbrev="McAfee">McAfee, Inc.</organization> <organization>Akamai</organization>
<address> <address>
<postal> <postal>
<street>Embassy Golf Link Business Park</street> <street>Embassy Golf Link Business Park</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <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 fullname="Mohamed Boucadair" initials="M." role="editor" surname="Bo
<author fullname="Mohamed Boucadair" initials="M." role="editor" ucadair">
surname="Boucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Rennes</city> <city>Rennes</city>
<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 fullname="Jon Shallow" initials="J." surname="Shallow"> <author fullname="Jon Shallow" initials="J." surname="Shallow">
<organization></organization> <organization/>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city/>
<city></city> <code/>
<country>United Kingdom</country>
<code></code>
<country>UK</country>
</postal> </postal>
<email>supjps-ietf@jpshallow.com</email> <email>supjps-ietf@jpshallow.com</email>
</address> </address>
</author> </author>
<date year="2021" month="November" />
<date />
<workgroup>DOTS</workgroup> <workgroup>DOTS</workgroup>
<keyword>Automation</keyword> <keyword>Automation</keyword>
<keyword>Anti-DDoS Automation</keyword> <keyword>Anti-DDoS Automation</keyword>
<keyword>DDoS Mitigation</keyword> <keyword>DDoS Mitigation</keyword>
<keyword>Collaborative Networking</keyword> <keyword>Collaborative Networking</keyword>
<keyword>Protective Networking</keyword> <keyword>Protective Networking</keyword>
<keyword>Security</keyword> <keyword>Security</keyword>
<keyword>Scrubbing</keyword> <keyword>Scrubbing</keyword>
<abstract> <abstract>
<t>This document specifies the DOTS signal channel Call Home, which <t>This document specifies the Denial-of-Service Open Threat Signaling (DO TS) signal channel Call Home, which
enables a Call Home DOTS server to initiate a secure connection to a enables a Call Home DOTS server to initiate a secure connection to a
Call Home DOTS client, and to receive attack traffic information from Call Home DOTS client and to receive attack traffic information from
the Call Home DOTS client. The Call Home DOTS server in turn uses the the Call Home DOTS client. The Call Home DOTS server in turn uses the
attack traffic information to identify compromised devices launching attack traffic information to identify compromised devices launching
outgoing DDoS attacks and take appropriate mitigation action(s).</t> outgoing DDoS attacks and take appropriate mitigation action(s).</t>
<t>The DOTS signal channel Call Home is not specific to home networks; <t>The DOTS signal channel Call Home is not specific to home networks;
the solution targets any deployment in which it is required to block the solution targets any deployment in which it is required to block
DDoS attack traffic closer to the source(s) of a DDoS attack.</t> DDoS attack traffic closer to the source(s) of a DDoS attack.</t>
</abstract> </abstract>
<note title="Editorial Note (To be removed by RFC Editor)">
<t>Please update these statements within the document with the RFC
number to be assigned to this document:<list style="symbols">
<t>"This version of this YANG module is part of RFC XXXX;"</t>
<t>"RFC XXXX: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Call Home";</t>
<t>"| [RFCXXXX] |"</t>
<t>reference: RFC XXXX</t>
</list></t>
<t>Please update this statement with the RFC number to be assigned to
the following documents:<list style="symbols">
<t>"RFC YYYY: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification" (used to be
I-D.ietf-dots-rfc8782-bis)</t>
</list></t>
<t>Please update TBD/TBA statements with the assignments made by IANA to
DOTS Signal Channel Call Home.</t>
<t>Also, please update the "revision" date of the YANG module.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>The Distributed Denial-of-Service Open Threat Signaling (DOTS) signal <t>The Distributed Denial-of-Service Open Threat Signaling (DOTS) signal
channel protocol <xref target="I-D.ietf-dots-rfc8782-bis"></xref> is channel protocol <xref target="RFC9132" format="default"/> is
used to carry information about a network resource or a network (or a used to carry information about a network resource or a network (or a
part thereof) that is under a Distributed Denial of Service (DDoS) part thereof) that is under a Distributed Denial-of-Service (DDoS)
attack <xref target="RFC4732"></xref>. Such information is sent by a attack <xref target="RFC4732" format="default"/>. Such information is sent
by a
DOTS client to one or multiple DOTS servers so that appropriate DOTS client to one or multiple DOTS servers so that appropriate
mitigation actions are undertaken on traffic deemed suspicious. Various mitigation actions are undertaken on traffic deemed suspicious. Various
use cases are discussed in <xref use cases are discussed in <xref target="RFC8903" format="default"/>.</t>
target="I-D.ietf-dots-use-cases"></xref>.</t> <t>However, <xref target="RFC9132" format="default"/> only covers
how to mitigate when being attacked (i.e., protecting a network from
<t>However, <xref target="I-D.ietf-dots-rfc8782-bis"></xref> only covers
how to mitigate when being attacked (i.e., protect a network from
inbound DDoS attacks). It does not cover how to control the attacks inbound DDoS attacks). It does not cover how to control the attacks
close to their source(s) that are misusing network resources (i.e., close to their source(s) that are misusing network resources (i.e.,
outbound DDoS attacks). In particular, the DOTS signal protocol does not outbound DDoS attacks). In particular, the DOTS signal protocol does not
discuss cooperative DDoS mitigation between the network hosting an discuss cooperative DDoS mitigation between the network hosting an
attack source and the Internet Service Provider (ISP) to suppress the attack source and the Internet Service Provider (ISP) to suppress the
outbound DDoS attack traffic originating from that network. As a outbound DDoS attack traffic originating from that network. As a
reminder, the base basic DOTS architecture is depicted in <xref reminder, the base basic DOTS architecture is depicted in <xref target="ba
target="basea"></xref> (Section 2 of <xref sea" format="default"/> (<xref target="RFC8811" sectionFormat="of" section="2"/>
target="RFC8811"></xref>).</t> ).</t>
<figure anchor="basea">
<t><figure align="center" anchor="basea" 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="home" format="default"/> details why the rise of Internet
<t><xref target="home"></xref> details why the rise of Internet of of
Things (IoT) compounds the possibility of these being used as malicious Things (IoT) compounds the possibility of these being used as malicious
actors which need to be controlled. Similar issues can be encountered in actors that need to be controlled. Similar issues can be encountered in
enterprise networks, data centers, etc. The ISP offering a DDoS enterprise networks, data centers, etc. The ISP offering a DDoS
mitigation service can detect outgoing DDoS attack traffic originating mitigation service can detect outgoing DDoS attack traffic originating
from its subscribers or the ISP may receive filtering rules (e.g., using from its subscribers, or the ISP may receive filtering rules (e.g., using
BGP Flowspec <xref target="RFC8955"></xref><xref BGP Flowspec <xref target="RFC8955" format="default"/> <xref target="RFC89
target="RFC8956"></xref>) from a transit provider to filter, block, or 56" format="default"/>) from a transit provider to filter, block, or
rate-limit DDoS attack traffic originating from the ISP's subscribers to rate-limit DDoS attack traffic originating from the ISP's subscribers to
a downstream target. Nevertheless, the DOTS signal channel does not a downstream target. Nevertheless, the DOTS signal channel does not
provide means for the ISP to request blocking such attacks close to the provide means for the ISP to request blocking such attacks close to the
sources without altering legitimate traffic. This document fills that sources without altering legitimate traffic. This document fills that
void by specifying an extension to the DOTS signal channel: DOTS signal void by specifying an extension to the DOTS signal channel: DOTS signal
channel Call Home.<list style="empty"> channel Call Home.</t>
<t>Note: Another design approach would be to extend the DOTS signal
<t indent="3">Note: Another design approach would be to extend the DOTS
signal
channel with a new attribute to explicitly indicate whether a channel with a new attribute to explicitly indicate whether a
mitigation request is about an outbound DDoS attack. In such an mitigation request concerns an outbound DDoS attack. In such an
approach, it is assumed that a DOTS server is deployed within the approach, it is assumed that a DOTS server is deployed within the
domain that is hosting the attack source(s), while a DOTS client is domain that is hosting the attack source(s), while a DOTS client is
enabled within an upstream network (e.g., access network). However, enabled within an upstream network (e.g., access network). However,
initiating a DOTS signal channel from an upstream network to a initiating a DOTS signal channel from an upstream network to a
source network is complicated because of the presence of translators source network is complicated because of the presence of translators
and firewalls. Moreover, the use of the same signal channel to and firewalls. Moreover, the use of the same signal channel to
handle both inbound and outbound attacks complicates both the handle both inbound and outbound attacks complicates both the
heartbeat and redirection mechanisms that are executed as a function heartbeat and redirection mechanisms that are executed as a function
of the attack direction (see Sections <xref format="counter" of the attack direction (see Sections <xref format="counter" target="h
target="hb"></xref> and <xref format="counter" b"/> and <xref format="counter" target="redirect"/>). Also, the DOTS server will
target="redirect"></xref>). Also, the DOTS server will be subject to be subject to
fingerprinting (e.g., using scanning tools) and DoS attacks (e.g., fingerprinting (e.g., using scanning tools) and DoS attacks (e.g.,
by having the DOTS server to perform computationally expensive by having the DOTS server perform computationally expensive
operations). Various management and deployment considerations that operations). Various management and deployment considerations that
motivate the Call Home functionality are listed in Section 1.1 of motivate the Call Home functionality are listed in <xref target="RFC80
<xref target="RFC8071"></xref>.</t> 71" sectionFormat="of" section="1.1"/>.</t>
</list></t>
<t>'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers <t>"DOTS signal channel Call Home" (or "DOTS Call Home" for short) refers
to a DOTS signal channel established at the initiative of a DOTS server to a DOTS signal channel established at the initiative of a DOTS server
thanks to a role reversal at the (D)TLS layer (<xref thanks to a role reversal at the (D)TLS layer (<xref target="proc" format=
target="proc"></xref>). That is, the DOTS server initiates a secure "default"/>). That is, the DOTS server initiates a secure
connection to a DOTS client, and uses that connection to receive the connection to a DOTS client and uses that connection to receive the
attack traffic information (e.g., attack sources) from the DOTS attack traffic information (e.g., attack sources) from the DOTS
client.</t> client.</t>
<t>A high-level DOTS Call Home functional architecture is shown in <xref t
<t>A high-level DOTS Call Home functional architecture is shown in <xref arget="fa" format="default"/>. Attack source(s) are within the DOTS server
target="fa"></xref>. Attack source(s) are within the DOTS server
domain.</t> domain.</t>
<figure anchor="fa">
<t><figure align="center" anchor="fa" <name>Basic DOTS Signal Channel Call Home Functional Architecture</name>
title="Basic DOTS Signal Channel Call Home Functional Architecture"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[ Scope Scope
+.-.-.-.-.-.-.-.-.-.-.-.+ +.-.-.-.-.-.-.-.-.-.-.-.+
+---------------+ : +-------------+ : +---------------+ : +-------------+ :
| Alert | ~~~:~~~ | Call Home | : | Alert | ~~~:~~~ | Call Home | :
| | : | DOTS client | : | | : | DOTS client | :
+---------------+ : +------+------+ : +---------------+ : +------+------+ :
: | : : | :
: | : : | :
: | : : | :
+---------------+ : +------+------+ : +---------------+ : +------+------+ :
| Attack | ~~~:~~~ | Call Home | : | Attack | ~~~:~~~ | Call Home | :
| Source(s) | : | DOTS server | : | Source(s) | : | DOTS server | :
+---------------+ : +-------------+ : +---------------+ : +-------------+ :
+.-.-.-.-.-.-.-.-.-.-.-.+]]></artwork> +.-.-.-.-.-.-.-.-.-.-.-.+]]></artwork>
</figure></t> </figure>
<t>DOTS agents involved in the DOTS Call Home otherwise adhere to the <t>DOTS agents involved in the DOTS Call Home otherwise adhere to the
DOTS roles as defined in <xref target="RFC8612"></xref>. For clarity, DOTS roles as defined in <xref target="RFC8612" format="default"/>. For cl arity,
this document uses "Call Home DOTS client" (or "Call Home DOTS server") this document uses "Call Home DOTS client" (or "Call Home DOTS server")
to refer to a DOTS client (or DOTS server) deployed in a Call Home to refer to a DOTS client (or DOTS server) deployed in a Call Home
scenario (<xref target="fa"></xref>). DOTS Call Home agents may (or not) scenario (<xref target="fa" format="default"/>). Call Home DOTS agents may
be co-located with DOTS agents that are compliant with <xref (or may not)
target="I-D.ietf-dots-rfc8782-bis"></xref> (see <xref be co-located with DOTS agents that are compliant with <xref target="RFC91
target="coex"></xref> for more details).</t> 32" format="default"/> (see <xref target="coex" format="default"/> for more deta
ils).</t>
<t>A Call Home DOTS client relies upon a variety of triggers to make use <t>A Call Home DOTS client relies upon a variety of triggers to make use
of the Call Home function (e.g., scrubbing the traffic from the attack of the Call Home function (e.g., scrubbing the traffic from the attack
source, receiving an alert from an attack target, a peer DDoS Mitigation source or receiving an alert from an attack target, a peer DDoS Mitigation
System (DMS), or a transit provider). The definition of these triggers System (DMS), or a transit provider). The definition of these triggers
is deployment-specific. It is therefore out of the scope of this is deployment specific. It is therefore out of the scope of this
document to elaborate on how these triggers are made available to a Call document to elaborate on how these triggers are made available to a Call
Home DOTS client.</t> Home DOTS client.</t>
<t>In a typical deployment scenario, the Call Home DOTS server is <t>In a typical deployment scenario, the Call Home DOTS server is
enabled on a Customer Premises Equipment (CPE), which is aligned with enabled on a Customer Premises Equipment (CPE), which is aligned with
recent trends to enrich the CPE with advanced security features. For recent trends to enrich the CPE with advanced security features. For
example, the DOTS Call Home service can be part of services supported by example, the DOTS Call Home service can be part of services supported by
an ISP-managed CPE or a managed security service subscribed by the user. an ISP-managed CPE or a managed security service subscribed to by the user
Unlike classic DOTS deployments <xref .
target="I-D.ietf-dots-use-cases"></xref>, a Call Home DOTS server Unlike classic DOTS deployments <xref target="RFC8903" format="default"/>,
a Call Home DOTS server
maintains a single DOTS signal channel session for each DOTS-capable maintains a single DOTS signal channel session for each DOTS-capable
upstream provisioning domain <xref target="I-D.ietf-dots-multihoming"> upstream provisioning domain <xref target="I-D.ietf-dots-multihoming" form
</xref>.</t> at="default">
</xref>.</t>
<t>For instance, the Call Home DOTS server in the home network initiates <t>For instance, the Call Home DOTS server in the home network initiates
the signal channel Call Home in 'idle' time and then subsequently the the signal channel Call Home in "idle" time; subsequently, the
Call Home DOTS client in the ISP environment can initiate a mitigation Call Home DOTS client in the ISP environment can initiate a mitigation
request whenever the ISP detects there is an attack from a compromised request whenever the ISP detects there is an attack from a compromised
device in the DOTS server domain (i.e., from within the home device in the DOTS server domain (i.e., from within the home
network).</t> network).</t>
<t>The Call Home DOTS server uses the DDoS attack traffic information to <t>The Call Home DOTS server uses the DDoS attack traffic information to
identify the compromised device in its domain that is responsible for identify the compromised device in its domain that is responsible for
launching the DDoS attack, optionally notifies a network administrator, launching the DDoS attack, optionally notifies a network administrator,
and takes appropriate mitigation action(s). For example, a mitigation and takes appropriate mitigation action(s). For example, a mitigation
action can be to quarantine the compromised device or block its traffic action can be to quarantine the compromised device or block its traffic
to the attack target(s) until the mitigation request is withdrawn.</t> to the attack target(s) until the mitigation request is withdrawn.</t>
<t>This document assumes that Call Home DOTS servers are provisioned <t>This document assumes that Call Home DOTS servers are provisioned
with a way to know how to reach the upstream Call Home DOTS client(s), with a way to know how to reach the upstream Call Home DOTS client(s),
which could occur by a variety of means (e.g., <xref which could occur by a variety of means (e.g., <xref target="RFC8973" form
target="RFC8973"></xref>). The specification of such means are out of at="default"/>). The specification of such means are out of
scope of this document.</t> scope of this document.</t>
<t>More information about the applicability scope of the DOTS signal <t>More information about the applicability scope of the DOTS signal
channel Call Home is provided in <xref target="as"></xref>.</t> channel Call Home is provided in <xref target="as" format="default"/>.</t>
</section> </section>
<section anchor="notation" numbered="true" toc="default">
<section anchor="notation" title="Terminology"> <name>Terminology</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
<t>The reader should be familiar with the terms defined in Section 1.2 be interpreted as
of <xref target="RFC8612"></xref>.</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
<t>DDoS Mitigation System (DMS) refers to a system that performs DDoS </t>
<t>The reader should be familiar with the terms defined in <xref target="R
FC8612" sectionFormat="of" section="1.2"/>.</t>
<t>"DDoS Mitigation System (DMS)" refers to a system that performs DDoS
mitigation.</t> mitigation.</t>
<t>"Base DOTS signal channel" refers to <xref target="RFC9132" format="def
<t>'Base DOTS signal channel' refers to <xref ault"/>.</t>
target="I-D.ietf-dots-rfc8782-bis"></xref>.</t> <t>The meaning of the symbols in YANG tree diagrams are defined in <xref t
arget="RFC8340" format="default"/> and <xref target="RFC8791" format="default"/>
<t>The meaning of the symbols in YANG tree diagrams are defined in <xref .</t>
target="RFC8340"></xref> and <xref target="RFC8791"></xref>.</t>
<t>(D)TLS is used for statements that apply to both Transport Layer <t>(D)TLS is used for statements that apply to both Transport Layer
Security (TLS) <xref target="RFC8446"></xref> and Datagram Transport Security (TLS) <xref target="RFC8446" format="default"/> and Datagram Tran
Layer Security (DTLS) <xref target="RFC6347"></xref>. Specific terms are sport
used for any statement that applies to either protocol alone.</t> Layer Security (DTLS) <xref target="RFC6347" format="default"/> <xref targ
et="I-D.ietf-tls-dtls13"/>.
Specific terms are used for any statement that applies to either
protocol alone.</t>
</section> </section>
<section anchor="as" numbered="true" toc="default">
<section anchor="as" title="Applicability Scope"> <name>Applicability Scope</name>
<t>The problems discussed in <xref target="introduction"></xref> may be <t>The problems discussed in <xref target="introduction" format="default"/
> may be
encountered in many deployments (e.g., home networks, enterprise encountered in many deployments (e.g., home networks, enterprise
networks, transit networks, data centers). The solution specified in networks, transit networks, data centers). The solution specified in
this document can be used for those deployments to block DDoS attack this document can be used for those deployments to block DDoS attack
traffic closer to the source(s) of the attack. That is, attacks that are traffic closer to the source(s) of the attack. That is, attacks that are
issued, e.g., from within an enterprise network or a data center, will issued, e.g., from within an enterprise network or a data center will
thus be blocked before exiting these networks.</t> thus be blocked before exiting these networks.</t>
<t>An instantiation of the Call Home functional architecture is depicted <t>An instantiation of the Call Home functional architecture is depicted
in <xref target="pb"></xref>.</t> in <xref target="pb" format="default"/>.</t>
<figure anchor="pb">
<t><figure align="center" anchor="pb" <name>DOTS Signal Channel Call Home Reference Architecture</name>
title="DOTS Signal Channel Call Home Reference Architecture"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[ +-------------+ +-------------+
|Attack Target| |Attack Target|
-------------+
+-----+-------+ +-----+-------+
| /\ Target Network | /\ Target Network
......................|.||.................... ......................|.||....................
.--------+-||-------. .--------+-||-------.
( || )-. ( || )-.
.' || ' .' || '
( Internet || ) ( Internet || )
( || -' ( || -'
'-( || ) '-( || )
skipping to change at line 360 skipping to change at line 269
.' Call Home || ' .' Call Home || '
( DOTS server || Outbound ) ( DOTS server || Outbound )
( || DDoS -' ( || DDoS -'
'-( || Attack ) '-( || Attack )
'------+-||---------' '------+-||---------'
| || | ||
+-----+-++----+ +-----+-++----+
|Attack Source| |Attack Source|
+-------------+ +-------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>It is out of the scope of this document to identify an exhaustive <t>It is out of the scope of this document to identify an exhaustive
list of such deployments.</t> list of such deployments.</t>
<t>Call Home DOTS agent relationships are similar to those discussed in <t>Call Home DOTS agent relationships are similar to those discussed in
Section 2.3 of <xref target="RFC8811"></xref>. For example, multiple <xref target="RFC8811" sectionFormat="of" section="2.3"/>. For example, mu ltiple
Call Home DOTS servers of the same domain can be associated with the Call Home DOTS servers of the same domain can be associated with the
same Call Home DOTS client. A Call Home DOTS client may decide to same Call Home DOTS client. A Call Home DOTS client may decide to
contact these Call Home DOTS servers sequentially, fork a mitigation contact these Call Home DOTS servers sequentially, fork a mitigation
request to all of them, or select one Call Home DOTS server to place a request to all of them, or select one Call Home DOTS server to place a
mitigation request. Such decision is implementation-specific.</t> mitigation request. Such a decision is implementation specific.</t>
<t>For some mitigations, feedback may be required from an
<t>For some mitigations, a feedback may be required from an administrator to confirm a filtering action. The means to seek an
administrator to confirm a filtering action. Means to seek for an administrator's consent are deployment specific. Indeed, a variety of
administrator's consent are deployment-specific. Indeed, a variety of implementation options can be considered for any given Call Home
implementation options can be considered as a function of the Call Home DOTS deployment, such as push notifications using a dedicated application,
DOTS deployment: push notifications using a dedicated application,
Syslog, etc. It is out of the scope of this document to make Syslog, etc. It is out of the scope of this document to make
recommendations about how such interactions are implemented (see <xref recommendations about how such interactions are implemented (see <xref tar
target="fa"></xref>).</t> get="fa" format="default"/>).</t>
<t>The Call Home DOTS server can be enabled on a border router or a <t>The Call Home DOTS server can be enabled on a border router or a
dedicated appliance. For the particular case of home networks, the Call dedicated appliance. For the particular case of home networks, the Call
Home DOTS server functionality can be enabled on a managed CPE or be Home DOTS server functionality can be enabled on a managed CPE or
bundled with a CPE management application that is provided by an ISP to bundled with a CPE management application that is provided by an ISP to
its subscribers. These managed services are likely to be designed to its subscribers. These managed services are likely to be designed to
hide the complexity of managing (including configuring) the CPE. For hide the complexity of managing (including configuring) the CPE. For
example, managed CPEs support means to notify the user when a new device example, managed CPEs support the means to notify the user when a new devi
is detected in order to seek a confirmation whether access should be ce
granted or not to the device. These means can be upgraded to interface is detected in order to seek confirmation as to whether or not access shou
ld be
granted to the device. These means can be upgraded to interface
with the Call Home DOTS server. Customized settings can be configured by with the Call Home DOTS server. Customized settings can be configured by
users to control the notifications (e.g., triggers, type) and default users to control the notifications (e.g., triggers, type) and default
actions.</t> actions.</t>
</section> </section>
<section anchor="coex" numbered="true" toc="default">
<section anchor="coex" <name>Coexistence of a Base DOTS Signal Channel and DOTS Call Home</name>
title="Co-existence of Base DOTS Signal Channel and DOTS Call Home" <t>The DOTS signal channel Call Home does not require or preclude the
> activation of the base DOTS signal channel <xref target="RFC9132" format="
<t>The DOTS signal channel Call Home does not require nor preclude the default"/>. Some sample deployment
activation of the base DOTS signal channel <xref
target="I-D.ietf-dots-rfc8782-bis"></xref>. Some sample deployment
schemes are discussed in this section for illustration purposes.</t> schemes are discussed in this section for illustration purposes.</t>
<t>The network that hosts an attack source may also be subject to <t>The network that hosts an attack source may also be subject to
inbound DDoS attacks. In that case, both the base DOTS signal channel inbound DDoS attacks. In that case, both the base DOTS signal channel
and DOTS signal channel Call Home may be enabled as shown in <xref and DOTS signal channel Call Home may be enabled as shown in <xref target=
target="merged"></xref> (Same DMS provider) or <xref "merged" format="default"/> (same DMS provider) or <xref target="merged1" format
target="merged1"></xref> (Distinct DMS providers).</t> ="default"/> (distinct DMS providers).</t>
<figure anchor="merged">
<t><figure align="center" anchor="merged" <name>Activation of a Base DOTS Signal Channel and Call Home (Same DMS P
title="Activation of Base DOTS Signal Channel and Call Home (Same DMS rovider)</name>
Provider)"> <artwork align="center" name="" type="" alt=""><![CDATA[ DOTS Signal
<artwork align="center"><![CDATA[ DOTS Signal Channel Base DOT Channel Base DOTS
S
Call Home Signal Channel Call Home Signal Channel
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
: +------+ :: +------+ : : +------+ :: +------+ :
: | DOTS | :: | DOTS | : : | DOTS | :: | DOTS | :
: |client| :: |server| : : |client| :: |server| :
: +--+---+ :: +---+--+ : : +--+---+ :: +---+--+ :
: /\ | :: | : Network : /\ | :: | : Network
: || | :: | :Provider : || | :: | :Provider
: || | :: | : (DMS) : || | :: | : (DMS)
...:.....||......|.....::.....|.............:........ ...:.....||......|.....::.....|.............:........
Outbound || | :: | || Inbound Outbound || | :: | || Inbound
DDoS || | :: | || DDoS DDoS || | :: | || DDoS
Attack || | :: | \/ Attack Attack || | :: | \/ Attack
: +--+---+ :: +---+--+ : : +--+---+ :: +---+--+ :
: | DOTS | :: | DOTS | : : | DOTS | :: | DOTS | :
: |server| :: |client| : : |server| :: |client| :
: +------+ :: +------+ : : +------+ :: +------+ :
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
Network #A]]></artwork> Network #A]]></artwork>
</figure></t> </figure>
<t>Note that a DMS provider may not be on the default forwarding path of <t>Note that a DMS provider may not be on the default forwarding path of
an inbound DDoS attack traffic targeting a network (e.g., Network #B in inbound DDoS attack traffic targeting a network (e.g., Network #B in
<xref target="merged1"></xref>). Nevertheless, the DOTS signal channel <xref target="merged1" format="default"/>). Nevertheless, the DOTS signal
channel
Call Home requires the DMS provider to be on the default forwarding path Call Home requires the DMS provider to be on the default forwarding path
of the outbound traffic from a given network.</t> of the outbound traffic from a given network.</t>
<figure anchor="merged1">
<t><figure align="center" anchor="merged1" <name>Activation of a Base DOTS Signal Channel and Call Home (Distinct D
title="Activation of Base DOTS Signal Channel and Call Home (Distinct MS Providers)</name>
DMS Providers)"> <artwork align="center" name="" type="" alt=""><![CDATA[ DOTS Signal
<artwork align="center"><![CDATA[ DOTS Signal Channel Base DOT Channel Base DOTS
S
Call Home Signal Channel Call Home Signal Channel
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
: Network +------+ :: +------+ Third : : Network +------+ :: +------+ Third :
: Provider | DOTS | :: | DOTS | Party : : Provider | DOTS | :: | DOTS | Party :
: (DMS) |client| :: |server| DMS : : (DMS) |client| :: |server| DMS :
: +--+---+ :: +---+--+ Provider : : +--+---+ :: +---+--+ Provider :
: /\ | :: | : : /\ | :: | :
: || | :: | : : || | :: | :
: || | :: | : : || | :: | :
...:.....||......|.....::.....|.............:........ ...:.....||......|.....::.....|.............:........
Outbound || | :: | || Inbound Outbound || | :: | || Inbound
DDoS || | :: | || DDoS DDoS || | :: | || DDoS
Attack || | :: | \/ Attack Attack || | :: | \/ Attack
: +--+---+ :: +---+--+ : : +--+---+ :: +---+--+ :
: | DOTS | :: | DOTS | : : | DOTS | :: | DOTS | :
: |server| :: |client| : : |server| :: |client| :
: +------+ :: +------+ : : +------+ :: +------+ :
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
Network #B Network #B
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Figures <xref format="counter" target="snode"/> and <xref format="count
<t>Figures <xref format="counter" target="snode"></xref> and <xref er" target="snode2"/> depict examples where the same
format="counter" target="snode2"></xref> depict examples where the same node embeds both base DOTS and Call Home DOTS agents. For example, a
node embeds both base DOTS and DOTS Call Home agents. For example, a
DOTS server and a Call Home DOTS client may be enabled on the same DOTS server and a Call Home DOTS client may be enabled on the same
device within the infrastructure of a DMS provider (e.g., Node #i in device within the infrastructure of a DMS provider (e.g., Node #i in
<xref target="snode"></xref>) or a DOTS client and a Call Home DOTS <xref target="snode" format="default"/>), or a DOTS client and a Call Home DOTS
server may be enabled on the same device within a source network (e.g., server may be enabled on the same device within a source network (e.g.,
Node #j with Network #D shown in <xref target="snode2"></xref>) .</t> Node #j with Network #D shown in <xref target="snode2" format="default"/>)
.</t>
<t>Whether the same or distinct nodes are used to host base DOTS and <t>Whether the same or distinct nodes are used to host base DOTS and
DOTS Call Home agents is specific to each domain.</t> Call Home DOTS agents is specific to each domain.</t>
<figure anchor="snode">
<t><figure align="center" anchor="snode" <name>The Same Node Embedding a Call Home DOTS Client and a DOTS Server
title="An Example of the Same Node Embedding both a Call Home DOTS Cli at the Network Provider's Side</name>
ent and a DOTS Server at the Network Provider's Side"> <artwork align="center" name="" type="" alt=""><![CDATA[ DOTS Signal
<artwork align="center"><![CDATA[ DOTS Signal Channel Base DOT Channel Base DOTS
S
Call Home Signal Channel Call Home Signal Channel
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
: +----------------------+ : : +----------------------+ :
: | Node #i | : : | Node #i | :
: | +------+ +------+ | : : | +------+ +------+ | :
: | | DOTS | | DOTS | | : : | | DOTS | | DOTS | | :
: | |client| |server| | : : | |client| |server| | :
: | +--+---+ +---+--+ | : : | +--+---+ +---+--+ | :
: +----|-----::-----|----+ : Network : +----|-----::-----|----+ : Network
: /\ | :: | :Provider : /\ | :: | :Provider
skipping to change at line 501 skipping to change at line 394
Outbound || | :: | || Inbound Outbound || | :: | || Inbound
DDoS || | :: | || DDoS DDoS || | :: | || DDoS
Attack || | :: | \/ Attack Attack || | :: | \/ Attack
: +--+---+ :: +---+--+ : : +--+---+ :: +---+--+ :
: | DOTS | :: | DOTS | : : | DOTS | :: | DOTS | :
: |server| :: |client| : : |server| :: |client| :
: +------+ :: +------+ : : +------+ :: +------+ :
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
Network #C Network #C
]]></artwork> ]]></artwork>
</figure></t> </figure>
<figure anchor="snode2">
<t><figure align="center" anchor="snode2" <name>The Same Node Embedding both a DOTS Client and a Call Home DOTS Se
title="Another Example where the Same Node Embeds both a DOTS Client a rver</name>
nd a Call Home DOTS Server"> <artwork align="center" name="" type="" alt=""><![CDATA[ DOTS Signal
<artwork align="center"><![CDATA[ DOTS Signal Channel Base DOT Channel Base DOTS
S
Call Home Signal Channel Call Home Signal Channel
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
: +----------------------+ : : +----------------------+ :
: | Node #k | : : | Node #k | :
: | +------+ +------+ | : : | +------+ +------+ | :
: | | DOTS | | DOTS | | : : | | DOTS | | DOTS | | :
: | |client| |server| | : : | |client| |server| | :
: | +--+---+ +---+--+ | : : | +--+---+ +---+--+ | :
: +----|-----::-----|----+ : Network : +----|-----::-----|----+ : Network
: /\ | :: | :Provider : /\ | :: | :Provider
skipping to change at line 530 skipping to change at line 422
Attack || | :: | \/ Attack Attack || | :: | \/ Attack
: +----|-----::-----|----+ : : +----|-----::-----|----+ :
: | +--+---+ +---+--+ | : : | +--+---+ +---+--+ | :
: | | DOTS | | DOTS | | : : | | DOTS | | DOTS | | :
: | |server| |client| | : : | |server| |client| | :
: | +------+ +------+ | : : | +------+ +------+ | :
: | Node #j | : : | Node #j | :
: +----------------------+ : : +----------------------+ :
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
Network #D]]></artwork> Network #D]]></artwork>
</figure><xref target="app"></xref> elaborates on the considerations </figure>
to unambiguously distinguish DOTS messages which belong to each of these <t><xref target="app" format="default"/> elaborates on the considerations
to unambiguously distinguish DOTS messages that belong to each of these
channels.</t> channels.</t>
</section> </section>
<section anchor="spec" numbered="true" toc="default">
<name>DOTS Signal Channel Call Home</name>
<section anchor="proc" numbered="true" toc="default">
<name>Procedure</name>
<section anchor="spec" title="DOTS Signal Channel Call Home">
<section anchor="proc" title="Procedure">
<t>The DOTS signal channel Call Home preserves all but one of the DOTS <t>The DOTS signal channel Call Home preserves all but one of the DOTS
client/server roles in the DOTS protocol stack, as compared to DOTS client/server roles in the DOTS protocol stack, as compared to the clien
client-initiated DOTS signal channel protocol <xref t-initiated DOTS signal channel protocol <xref target="RFC9132" format="default"
target="I-D.ietf-dots-rfc8782-bis"></xref>. The role reversal that />. The role reversal that
occurs is at the (D)TLS layer; that is, (1) the Call Home DOTS server occurs is at the (D)TLS layer; that is, (1) the Call Home DOTS server
acts as a DTLS client and the Call Home DOTS client acts as a DTLS acts as a DTLS client, and the Call Home DOTS client acts as a DTLS
server or (2) the Call Home DOTS server acts as a TLS client server; or (2) the Call Home DOTS server acts as a TLS client
initiating the underlying TCP connection and the Call Home DOTS client initiating the underlying TCP connection, and the Call Home DOTS client
acts as a TLS server. The Call Home DOTS server initiates (D)TLS acts as a TLS server. The Call Home DOTS server initiates a (D)TLS
handshake to the Call Home DOTS client.</t> handshake to the Call Home DOTS client.</t>
<t>For example, a home network element (e.g., home router) co-located <t>For example, a home network element (e.g., home router) co-located
with a Call Home DOTS server is the (D)TLS client. That is, the Call with a Call Home DOTS server is the (D)TLS client. That is, the Call
Home DOTS server assumes the role of the (D)TLS client, but the Home DOTS server assumes the role of the (D)TLS client, but the
network element's role as a DOTS server remains the same.</t> network element's role as a DOTS server remains the same.</t>
<t>Existing certificate chains and mutual authentication mechanisms <t>Existing certificate chains and mutual authentication mechanisms
between the DOTS agents are unaffected by the Call Home function. From between the DOTS agents are unaffected by the Call Home function. From
a deployment standpoint, and given the scale of Call Home DOTS servers a deployment standpoint, and given the scale of Call Home DOTS servers
that may be involved, enabling means for automating the provisioning that may be involved, enabling means for automating the provisioning
of credentials on Call Home DOTS servers to authenticate to the Call of credentials on Call Home DOTS servers to authenticate to the Call
Home DOTS client is encouraged. It is out of the scope of this Home DOTS client is encouraged. It is out of the scope of this
document to elaborate on these means.</t> document to elaborate on these means.</t>
<t><xref target="signalch" format="default"/> illustrates a sample DOTS
<t><xref target="signalch"></xref> illustrates a sample DOTS Call Home Call Home
flow exchange:</t> flow exchange:</t>
<figure anchor="signalch">
<t><figure align="center" anchor="signalch" <name>DOTS Signal Channel Call Home Sequence Diagram</name>
title="DOTS Signal Channel Call Home Sequence Diagram"> <artwork name="" type="" align="left" alt=""><![CDATA[ +----
<artwork><![CDATA[ +-----------+ +- -------+ +-----------+
----------+
| Call Home | | Call Home | | Call Home | | Call Home |
| DOTS | | DOTS | | DOTS | | DOTS |
| server | | client | | server | | client |
+-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
(D)TLS client (D)TLS server (D)TLS client (D)TLS server
| | | |
| 1. (D)TLS connection | | 1. (D)TLS connection |
|----------------------------------->| |----------------------------------->|
| 2. Mitigation request | | 2. Mitigation request |
|<-----------------------------------| |<-----------------------------------|
| ... | | ... |
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The DOTS signal channel Call Home procedure is as follows:</t> <t>The DOTS signal channel Call Home procedure is as follows:</t>
<ol spacing="normal" type="1"><li>
<t><list style="numbers">
<t>If UDP transport is used, the Call Home DOTS server begins by <t>If UDP transport is used, the Call Home DOTS server begins by
initiating a DTLS connection to the Call Home DOTS client.<vspace initiating a DTLS connection to the Call Home DOTS client.</t>
blankLines="1" />If TCP is used, the Call Home DOTS server begins <t>If TCP is used, the Call Home DOTS server begins
by initiating a TCP connection to the Call Home DOTS client. Once by initiating a TCP connection to the Call Home DOTS client. Once
connected, the Call Home DOTS server continues to initiate a TLS connected, the Call Home DOTS server continues to initiate a TLS
connection to the Call Home DOTS client.<vspace connection to the Call Home DOTS client.</t>
blankLines="1" />Peer DOTS agents may have mutual agreement to use <t>Peer DOTS agents may have mutual agreement to use
a specific port number, such as by explicit configuration or a specific port number, such as by explicit configuration or
dynamic discovery <xref target="RFC8973"></xref>. The interaction dynamic discovery <xref target="RFC8973" format="default"/>. The int eraction
between the base DOTS signal channel and the Call Home is between the base DOTS signal channel and the Call Home is
discussed in <xref target="app"></xref>.<vspace discussed in <xref target="app" format="default"/>.</t>
blankLines="1" />The Happy Eyeballs mechanism explained in Section <t>The Happy Eyeballs mechanism explained in <xref target="RFC9132"
4.3 of <xref target="I-D.ietf-dots-rfc8782-bis"></xref> is used sectionFormat="of" section="4.3"/> is used
for initiating (D)TLS connections.</t> for initiating (D)TLS connections.</t>
</li>
<li>
<t>Using this (D)TLS connection, the Call Home DOTS client may <t>Using this (D)TLS connection, the Call Home DOTS client may
request, withdraw, or retrieve the status of mitigation requests. request, withdraw, or retrieve the status of mitigation requests.
The Call Home DOTS client supplies the source information by means The Call Home DOTS client supplies the source information by means
of new attributes defined in <xref target="mitigation"></xref>. of new attributes defined in <xref target="mitigation" format="defau
<vspace blankLines="1" />The Heartbeat mechanism used for the DOTS lt"/>.
Call Home deviates from the one defined in Section 4.7 of <xref </t>
target="I-D.ietf-dots-rfc8782-bis"></xref>. <xref <t>The heartbeat mechanism used for the DOTS
target="hb"></xref> specifies the behavior to be followed by Call Call Home deviates from the one defined in <xref target="RFC9132" se
ctionFormat="of" section="4.7"/>. <xref target="hb" format="default"/> specifies
the behavior to be followed by Call
Home DOTS agents.</t> Home DOTS agents.</t>
</list></t> </li>
</ol>
<t></t> <t/>
</section> </section>
<section numbered="true" toc="default">
<section title="DOTS Signal Channel Variations"> <name>DOTS Signal Channel Variations</name>
<t></t> <t/>
<section anchor="hb" numbered="true" toc="default">
<section anchor="hb" title="Heartbeat Mechanism"> <name>Heartbeat Mechanism</name>
<t>Once the (D)TLS section is established between the DOTS agents, <t>Once the (D)TLS section is established between the DOTS agents,
the Call Home DOTS client contacts the Call Home DOTS server to the Call Home DOTS client contacts the Call Home DOTS server to
retrieve the session configuration parameters (Section 4.5 of <xref retrieve the session configuration parameters (<xref target="RFC9132"
target="I-D.ietf-dots-rfc8782-bis"></xref>). The Call Home DOTS sectionFormat="of" section="4.5"/>). The Call Home DOTS
server adjusts the 'heartbeat-interval' to accommodate binding server adjusts the "heartbeat-interval" to accommodate binding
timers used by on-path NATs and firewalls. Heartbeats will be then timers used by on-path NATs and firewalls. Heartbeats will then be exc
exchanged by the DOTS agents following the instructions retrieved hanged by the DOTS agents following the instructions retrieved
using the signal channel session configuration exchange.</t> using the signal channel session configuration exchange.</t>
<t>It is the responsibility of Call Home DOTS servers to ensure that <t>It is the responsibility of Call Home DOTS servers to ensure that
on-path translators/firewalls are maintaining a binding so that the on-path translators/firewalls are maintaining a binding so that the
same external IP address and/or port number is retained for the DOTS same external IP address and/or port number is retained for the DOTS
signal channel session. A Call Home DOTS client MAY trigger their signal channel session. A Call Home DOTS client <bcp14>MAY</bcp14> tri gger their
heartbeat requests immediately after receiving heartbeat probes from heartbeat requests immediately after receiving heartbeat probes from
its peer Call Home DOTS server.</t> its peer Call Home DOTS server.</t>
<t>When an outgoing attack that saturates the outgoing link from the <t>When an outgoing attack that saturates the outgoing link from the
Call Home DOTS server is detected and reported by a Call Home DOTS Call Home DOTS server is detected and reported by a Call Home DOTS
client, the latter MUST continue to use the DOTS signal channel even client, the latter <bcp14>MUST</bcp14> continue to use the DOTS signal channel even
if no traffic is received from the Call Home DOTS server.</t> if no traffic is received from the Call Home DOTS server.</t>
<t>If the Call Home DOTS server receives traffic from the Call Home <t>If the Call Home DOTS server receives traffic from the Call Home
DOTS client, the Call Home DOTS server MUST continue to use the DOTS DOTS client, the Call Home DOTS server <bcp14>MUST</bcp14> continue to
signal channel even if the missing heartbeats allowed threshold use the DOTS signal channel even if the threshold of allowed missing heartbeats
('missing-hb-allowed') is reached.</t> ("missing-hb-allowed") is reached.</t>
<t>If the Call Home DOTS server does not receive any traffic from <t>If the Call Home DOTS server does not receive any traffic from
the peer Call Home DOTS client during the time span required to the peer Call Home DOTS client during the time span required to
exhaust the maximum 'missing-hb-allowed' threshold, the Call Home exhaust the maximum "missing-hb-allowed" threshold, the Call Home
DOTS server concludes the session is disconnected. Then, the Call DOTS server concludes the session is disconnected. Then, the Call
Home DOTS server MUST try to establish a new DOTS signal channel Home DOTS server <bcp14>MUST</bcp14> try to establish a new DOTS signa l channel
session, preferably by resuming the (D)TLS session.</t> session, preferably by resuming the (D)TLS session.</t>
</section> </section>
<section anchor="redirect" numbered="true" toc="default">
<name>Redirected Signaling</name>
<t>A Call Home DOTS server <bcp14>MUST NOT</bcp14> support the redirec
ted signaling
mechanism as specified in <xref target="RFC9132" sectionFormat="of" se
ction="4.6"/>
<section anchor="redirect" title="Redirected Signaling"> (i.e., a 5.03 response
<t>A Call Home DOTS server MUST NOT support the Redirected Signaling that conveys an alternate DOTS server's Fully Qualified Domain Name (F
mechanism as specified in Section 4.6 of <xref QDN) or IP address(es)). A Call Home DOTS client <bcp14>MUST</bcp14> silently
target="I-D.ietf-dots-rfc8782-bis"></xref> (i.e., a 5.03 response discard such a message as only a Call Home DOTS server can initiate a
that conveys an alternate DOTS server's FQDN or alternate DOTS
server's IP address(es)). A Call Home DOTS client MUST silently
discard such message as only a Call Home DOTS server can initiate a
new (D)TLS connection.</t> new (D)TLS connection.</t>
<t>If a Call Home DOTS client wants to redirect a Call Home DOTS <t>If a Call Home DOTS client wants to redirect a Call Home DOTS
server to another Call Home DOTS client, it MUST send a server to another Call Home DOTS client, it <bcp14>MUST</bcp14> send a
Non-confirmable PUT request to the predefined resource Non-confirmable PUT request to the predefined resource
&ldquo;.well-known/dots/redirect&rdquo; with the following ".well-known/dots/redirect" with the following
attributes in the body of the PUT request:</t> attributes in the body of the PUT request:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>alt-ch-client:</dt>
<t hangText="alt-ch-client:">The FQDN of an alternate Call Home <dd>
DOTS client. It is also presented as reference identifier for <t>The FQDN of an alternate Call Home
authentication purposes.<vspace blankLines="1" />This is a DOTS client. It is also presented as a reference identifier for
mandatory attribute for DOTS signal Call Home. It MUST NOT be authentication purposes.</t>
<t>This is a
mandatory attribute for DOTS signal Call Home. It <bcp14>MUST NOT<
/bcp14> be
used for base DOTS signal channel operations.</t> used for base DOTS signal channel operations.</t>
</dd>
<t hangText="alt-ch-client-record:">List of IP addresses for the <dt>alt-ch-client-record:</dt>
alternate Call Home DOTS client. If no 'alt-ch-client-record' is <dd>
provided, the Call Home DOTS server passes the 'alt-ch-client' <t>List of IP addresses for the
alternate Call Home DOTS client. If no "alt-ch-client-record" is
provided, the Call Home DOTS server passes the "alt-ch-client"
name to a name resolution library to retrieve one or more IP name to a name resolution library to retrieve one or more IP
addresses of the alternate Call Home DOTS client.<vspace addresses of the alternate Call Home DOTS client.</t>
blankLines="1" />This is an optional attribute for DOTS signal <t>This is an optional attribute for DOTS signal
Call Home. It MUST NOT be used for base DOTS signal channel Call Home. It <bcp14>MUST NOT</bcp14> be used for base DOTS signal
channel
operations.</t> operations.</t>
</dd>
<t hangText="ttl:">The Time to live (TTL) of the alternate Call <dt>ttl:</dt>
Home DOTS client. That is, the time interval that the alternate <dd>
<t>The Time To Live (TTL) of the alternate Call
Home DOTS client. That is, the time interval in which the alternat
e
Call Home DOTS client may be cached for use by a Call Home DOTS Call Home DOTS client may be cached for use by a Call Home DOTS
server.<vspace blankLines="1" />This is an optional attribute server.</t>
for DOTS signal Call Home. It MUST NOT be used for base DOTS <t>This is an optional attribute
for DOTS signal Call Home. It <bcp14>MUST NOT</bcp14> be used for
base DOTS
signal channel operations.</t> signal channel operations.</t>
</list></t> </dd>
</dl>
<t>On receipt of this PUT request, the Call Home DOTS server <t>On receipt of this PUT request, the Call Home DOTS server
responds with a 2.01 (Created), closes this connection and responds with a 2.01 (Created), closes this connection, and
establishes a connection with the new Call Home DOTS client. The establishes a connection with the new Call Home DOTS client. The
processing of the TTL is defined in Section 4.6 of <xref processing of the TTL is defined in <xref target="RFC9132" sectionForm
target="I-D.ietf-dots-rfc8782-bis"></xref>. If the Call Home DOTS at="of" section="4.6"/>. If the Call Home DOTS
server cannot service the PUT request, the response is rejected with server cannot service the PUT request, the response is rejected with
a 4.00 (Bad Request).</t> a 4.00 (Bad Request).</t>
<t><xref target="red-example" format="default"/> shows a PUT request e
<t><xref target="red-example"></xref> shows a PUT request example to xample to
convey the alternate Call Home DOTS client convey the alternate Call Home DOTS client
'alt-call-home-client.example' together with its IP addresses "alt-call-home-client.example" together with its IP addresses
2001:db8:6401::1 and 2001:db8:6401::2. The validity of this 2001:db8:6401::1 and 2001:db8:6401::2. The validity of this
alternate Call Home DOTS client is 10 minutes.</t> alternate Call Home DOTS client is 10 minutes.</t>
<figure anchor="red-example">
<name>Example of a PUT Request for Redirected Signaling</name>
<t><figure anchor="red-example" <sourcecode name="" type="coap"><![CDATA[
title="Example of a PUT Request for Redirected Signaling"> Header: PUT (Code=0.03)
<artwork><![CDATA[ Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "redirect" Uri-Path: "redirect"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:redirected-signal": { "ietf-dots-signal-channel:redirected-signal": {
"ietf-dots-call-home:alt-ch-client": "ietf-dots-call-home:alt-ch-client":
"alt-call-home-client.example", "alt-call-home-client.example",
"ietf-dots-call-home:alt-ch-client-record": [ "ietf-dots-call-home:alt-ch-client-record": [
"2001:db8:6401::1", "2001:db8:6401::1",
"2001:db8:6401::2" "2001:db8:6401::2"
], ],
"ietf-dots-call-home:ttl": 600 "ietf-dots-call-home:ttl": 600
} }
]]></artwork> ]]></sourcecode>
</figure></t> </figure>
<t><xref target="red-example"/> uses the JSON encoding of YANG-modeled
data for the CoAP message body. The same encoding is used in <xref target="examp
le"/> (<xref target="mitigation"/>).
</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="DOTS Signal Channel Extension"> <name>DOTS Signal Channel Extension</name>
<section anchor="mitigation" title="Mitigation Request"> <section anchor="mitigation" numbered="true" toc="default">
<name>Mitigation Request</name>
<t>This specification extends the mitigation request defined in <t>This specification extends the mitigation request defined in
Section 4.4.1 of <xref target="I-D.ietf-dots-rfc8782-bis"></xref> to <xref target="RFC9132" sectionFormat="of" section="4.4.1"/> to
convey the attack source information (e.g., source prefixes, source convey the attack source information (e.g., source prefixes, source
port numbers). The DOTS client conveys the following new parameters port numbers). The DOTS client conveys the following new parameters
in the CBOR body of the mitigation request:<list style="hanging"> in the Concise Binary Object Representation (CBOR) body of the mitigat
<t hangText="source-prefix:">A list of attacker IP prefixes used ion request:</t>
<dl newline="false" spacing="normal">
<dt>source-prefix:</dt>
<dd>
<t>A list of attacker IP prefixes used
to attack the target. Prefixes are represented using Classless to attack the target. Prefixes are represented using Classless
Inter-Domain Routing (CIDR) notation <xref target="RFC4632">BCP Inter-Domain Routing (CIDR) notation (<xref target="RFC4632" forma
122 </xref>. <vspace blankLines="1" />As a reminder, the prefix t="default">BCP
length MUST be less than or equal to 32 (or 128) for IPv4 (or 122 </xref>). </t>
IPv6).<vspace blankLines="1" />The prefix list MUST NOT include <t>As a reminder, the prefix
length <bcp14>MUST</bcp14> be less than or equal to 32 (or 128) fo
r IPv4 (or
IPv6).</t>
<t>The prefix list <bcp14>MUST NOT</bcp14> include
broadcast, loopback, or multicast addresses. These addresses are broadcast, loopback, or multicast addresses. These addresses are
considered as invalid values. Note that link-local addresses are considered invalid values. Note that link-local addresses are
allowed. The Call Home DOTS client MUST validate that attacker allowed. The Call Home DOTS client <bcp14>MUST</bcp14> validate th
at attacker
prefixes are within the scope of the Call Home DOTS server prefixes are within the scope of the Call Home DOTS server
domain (e.g., prefixes assigned to the Call Home DOTS server domain (e.g., prefixes assigned to the Call Home DOTS server
domain or networks it services). This check is meant to avoid domain or networks it services). This check is meant to avoid
contacting Call Home DOTS servers that are not entitled to contacting Call Home DOTS servers that are not entitled to
enforce actions on specific prefixes.<vspace enforce actions on specific prefixes.</t>
blankLines="1" />This is an optional attribute for the base DOTS <t>This is an optional attribute for the base DOTS
signal channel operations.</t> signal channel operations.</t>
</dd>
<t hangText="source-port-range:">A list of port numbers used by <dt>source-port-range:</dt>
the attack traffic flows. <vspace blankLines="1" />A port range <dd>
is defined by two bounds, a lower port number (lower-port) and <t>A list of port numbers used by
an upper port number (upper-port). When only 'lower-port' is the attack traffic flows. </t>
present, it represents a single port number. <vspace <t>A port range
blankLines="1" />For TCP, UDP, Stream Control Transmission is defined by two bounds, a lower port number ("lower-port") and
Protocol (SCTP) <xref target="RFC4960"></xref>, or Datagram an upper port number ("upper-port"). When only "lower-port" is
Congestion Control Protocol (DCCP) <xref present, it represents a single port number. </t>
target="RFC4340"></xref>, a range of ports can be any subrange <t>For TCP, UDP, Stream Control Transmission
of 0-65535, for example, 0-1023, 1024-65535, or 1024-49151. Protocol (SCTP) <xref target="RFC4960" format="default"/>, or Data
<vspace blankLines="1" />This is an optional attribute for the gram
Congestion Control Protocol (DCCP) <xref target="RFC4340" format="
default"/>, a range of ports can be any subrange
of 0-65535 -- for example, 0-1023, 1024-65535, or 1024-49151.
</t>
<t>This is an optional attribute for the
base DOTS signal channel operations.</t> base DOTS signal channel operations.</t>
</dd>
<t hangText="source-icmp-type-range:">A list of ICMP types used <dt>source-icmp-type-range:</dt>
<dd>
<t>A list of ICMP types used
by the attack traffic flows. An ICMP type range is defined by by the attack traffic flows. An ICMP type range is defined by
two bounds, a lower ICMP type (lower-type) and an upper ICMP two bounds, a lower ICMP type (lower-type) and an upper ICMP
type (upper-type). When only 'lower-type' is present, it type (upper-type). When only "lower-type" is present, it
represents a single ICMP type. Both ICMP <xref represents a single ICMP type. Both ICMP <xref target="RFC0792" fo
target="RFC0792"></xref> and ICMPv6 <xref rmat="default"/> and ICMPv6 <xref target="RFC4443" format="default"/> types are
target="RFC4443"></xref> types are supported. Whether ICMP or supported. Whether ICMP or
ICMPv6 types are to be used is determined by the address family ICMPv6 types are to be used is determined by the address family
of the 'target-prefix'. <vspace blankLines="1" />This is an of the "target-prefix". </t>
<t>This is an
optional attribute for the base DOTS signal channel optional attribute for the base DOTS signal channel
operations.</t> operations.</t>
</list></t> </dd>
</dl>
<t>The 'source-prefix' parameter is a mandatory attribute when the <t>The "source-prefix" parameter is a mandatory attribute when the
attack traffic information is signaled by a Call Home DOTS client attack traffic information is signaled by a Call Home DOTS client
(i.e., the Call Home scenario depicted in <xref (i.e., the Call Home scenario depicted in <xref target="signalch" form
target="signalch"></xref>). The 'target-prefix' attribute MUST be at="default"/>). The "target-prefix" attribute <bcp14>MUST</bcp14> be
included in the mitigation request signaling the attack information included in the mitigation request signaling the attack information
to a Call Home DOTS server. The 'target-uri' or 'target-fqdn' to a Call Home DOTS server. The "target-uri" or "target-fqdn"
parameters can be included in a mitigation request for diagnostic parameters can be included in a mitigation request for diagnostic
purposes to notify the Call Home DOTS server domain administrator, purposes to notify the Call Home DOTS server domain administrator
but SHOULD NOT be used to determine the target IP addresses. but <bcp14>SHOULD NOT</bcp14> be used to determine the target IP addre
'alias-name' is unlikely to be conveyed in a Call Home mitigation sses.
"alias-name" is unlikely to be conveyed in a Call Home mitigation
request given that a target may be any IP resource and that there is request given that a target may be any IP resource and that there is
no incentive for a Call Home DOTS server (embedded, for example, in no incentive for a Call Home DOTS server (embedded, for example, in
a CPE) to maintain aliases.</t> a CPE) to maintain aliases.</t>
<t>In order to help attack source identification by a Call Home DOTS <t>In order to help attack source identification by a Call Home DOTS
server, the Call Home DOTS client SHOULD include in its mitigation server, the Call Home DOTS client <bcp14>SHOULD</bcp14> include in its
request additional information such as 'source-port-range' or mitigation
'source-icmp-type-range' to disambiguate nodes sharing the same request additional information such as "source-port-range" or
'source-prefix'. IPv6 addresses/prefixes are sufficient to uniquely "source-icmp-type-range" to disambiguate nodes sharing the same
"source-prefix". IPv6 addresses/prefixes are sufficient to uniquely
identify a network endpoint, without need for port numbers or ICMP identify a network endpoint, without need for port numbers or ICMP
type information. While this is also possible for IPv4, it is much type information. While this is also possible for IPv4, it is much
less often the case than for IPv6. More address sharing implications less often the case than for IPv6. More address sharing implications
on the setting of source information ('source-prefix', on the setting of source information ("source-prefix",
'source-port-range') are discussed in <xref "source-port-range") are discussed in <xref target="nat" format="defau
target="nat"></xref>.</t> lt"/>.</t>
<t>Only immediate mitigation requests (i.e., "trigger-mitigation"
<t>Only immediate mitigation requests (i.e., 'trigger-mitigation' set to "true") are allowed; Call Home DOTS clients <bcp14>MUST NOT</bc
set to 'true') are allowed; Call Home DOTS clients MUST NOT send p14> send
requests with 'trigger-mitigation' set to 'false'. Such requests requests with "trigger-mitigation" set to "false". Such requests
MUST be discarded by the Call Home DOTS server with a 4.00 (Bad <bcp14>MUST</bcp14> be discarded by the Call Home DOTS server with a 4
.00 (Bad
Request).</t> Request).</t>
<t>An example of a mitigation request sent by a Call Home DOTS <t>An example of a mitigation request sent by a Call Home DOTS
client is shown in <xref target="example"></xref>.<figure client is shown in <xref target="example" format="default"/>.</t>
anchor="example" <figure anchor="example">
title="An Example of Mitigation Request Issued by a Call Home DOTS <name>An Example of a Mitigation Request Issued by a Call Home DOTS
Client"> Client</name>
<artwork align="left"><![CDATA[ Header: PUT (Code=0.03) <sourcecode name="" type="json"><![CDATA[
Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=56" Uri-Path: "mid=56"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
skipping to change at line 837 skipping to change at line 729
"target-prefix": [ "target-prefix": [
"2001:db8:c000::/128" "2001:db8:c000::/128"
], ],
"ietf-dots-call-home:source-prefix": [ "ietf-dots-call-home:source-prefix": [
"2001:db8:123::1/128" "2001:db8:123::1/128"
], ],
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></sourcecode>
</figure>
<t>The Call Home DOTS server MUST check that the 'source-prefix' is <t>The Call Home DOTS server <bcp14>MUST</bcp14> check that the "sourc
e-prefix" is
within the scope of the Call Home DOTS server domain. Note that in a within the scope of the Call Home DOTS server domain. Note that in a
DOTS Call Home scenario, the Call Home DOTS server considers, by DOTS Call Home scenario, the Call Home DOTS server considers, by
default, that any routeable IP prefix enclosed in 'target-prefix' is default, that any routable IP prefix enclosed in "target-prefix" is
within the scope of the Call Home DOTS client. Invalid mitigation within the scope of the Call Home DOTS client. Invalid mitigation
requests are handled as per Section 4.4.1 of <xref requests are handled as per <xref target="RFC9132" sectionFormat="of"
target="I-D.ietf-dots-rfc8782-bis"></xref>.<list style="empty"> section="4.4.1"/>.</t>
<t>Note: These validation checks do not apply when the source <t indent="3">
Note: These validation checks do not apply when the source
information is included as a hint in the context of the base information is included as a hint in the context of the base
DOTS signal channel.</t> DOTS signal channel.</t>
</list></t>
<t>The Call Home DOTS server domain administrator consent MAY be <t>Call Home DOTS server domain administrator consent <bcp14>MAY</bcp1 4> be
required to block the traffic from the compromised device to the required to block the traffic from the compromised device to the
attack target. An implementation MAY have a configuration knob to attack target. An implementation <bcp14>MAY</bcp14> have a configurati on knob to
block the traffic from the compromised device to the attack target block the traffic from the compromised device to the attack target
with or without DOTS server domain administrator consent.</t> with or without DOTS server domain administrator consent.</t>
<t>If consent from the Call Home DOTS server domain administrator
<t>If a consent from the Call Home DOTS server domain administrator
is required, the Call Home DOTS server replies with 2.01 (Created) is required, the Call Home DOTS server replies with 2.01 (Created)
and 'status' code set to 1 (attack-mitigation-in-progress). Then, and the "status" code set to 1 (attack-mitigation-in-progress). Then,
the mechanisms defined in Section 4.4.2 of <xref the mechanisms defined in <xref target="RFC9132" sectionFormat="of" se
target="I-D.ietf-dots-rfc8782-bis"></xref> are followed by the DOTS ction="4.4.2"/> are followed by the DOTS
agents to update the mitigation status. Particularly, if the attack agents to update the mitigation status. In particular, if the attack
traffic is blocked, the Call Home DOTS server informs the Call Home traffic is blocked, the Call Home DOTS server informs the Call Home
DOTS client that the attack is being mitigated (i.e., by setting the DOTS client that the attack is being mitigated (i.e., by setting the
'status' code to 2 (attack-successfully-mitigated)).</t> "status" code to 2 (attack-successfully-mitigated)).</t>
<t>If the attack traffic information is identified by the Call Home <t>If the attack traffic information is identified by the Call Home
DOTS server or the Call Home DOTS server domain administrator as DOTS server or the Call Home DOTS server domain administrator as
legitimate traffic, the mitigation request is rejected with a 4.09 legitimate traffic, the mitigation request is rejected with a 4.09
(Conflict) (e.g., when no consent is required from an administrator) (Conflict) (e.g., when no consent is required from an administrator)
or a notification message with the 'conflict-clause' (Section 4.4.1 or a notification message with the "conflict-clause" (<xref target="RF
of <xref target="I-D.ietf-dots-rfc8782-bis"></xref>) set to the C9132" sectionFormat="of" section="4.4.1"/>) set to the
following new value:</t> following new value:</t>
<dl newline="false" spacing="normal">
<t><list style="hanging"> <dt>4:</dt>
<t hangText="4:">Mitigation request rejected. This code is <dd>Mitigation request rejected. This code is
returned by the DOTS server to indicate the attack traffic has returned by the DOTS server to indicate the attack traffic has
been classified as legitimate traffic.</t> been classified as legitimate traffic.</dd>
</list></t> </dl>
<t>Once the request is validated by the Call Home DOTS server, <t>Once the request is validated by the Call Home DOTS server,
appropriate actions are enforced to block the attack traffic within appropriate actions are enforced to block the attack traffic within
the source network. For example, if the Call Home DOTS server is the source network. For example, if the Call Home DOTS server is
embedded in a CPE, it can program the packet processor to punt all embedded in a CPE, it can program the packet processor to punt all
the traffic from the compromised device to the target to slow path. the traffic from the compromised device to the target to slow path.
The CPE inspects the punted slow path traffic to detect and block The CPE inspects the punted slow path traffic to detect and block
the outgoing DDoS attack traffic or quarantine the device (e.g., the outgoing DDoS attack traffic or quarantine the device (e.g.,
using MAC level filtering) until it is remediated, and notifies the using MAC-level filtering) until it is remediated and notifies the
CPE administrator about the compromised device. Note that the Call CPE administrator about the compromised device. Note that the Call
Home DOTS client is informed about the progress of the attack Home DOTS client is informed about the progress of the attack
mitigation following the rules in Section 4.4.2 of <xref mitigation following the rules in <xref target="RFC9132" sectionFormat
target="I-D.ietf-dots-rfc8782-bis"></xref>.</t> ="of" section="4.4.2"/>.</t>
<t>The DOTS agents follow the same procedures specified in <xref targe
<t>The DOTS agents follow the same procedures specified in <xref t="RFC9132" format="default"/> for managing a mitigation
target="I-D.ietf-dots-rfc8782-bis"></xref> for managing a mitigation
request.</t> request.</t>
</section> </section>
<section anchor="nat" numbered="true" toc="default">
<section anchor="nat" title="Address Sharing Considerations"> <name>Address Sharing Considerations</name>
<t><xref target="ex1"></xref> depicts an example of a network <t><xref target="ex1" format="default"/> depicts an example of a netwo
provider that hosts a Call Home DOTS client and deploys a Carrier rk
Grade NAT (CGN) between the DOTS client domain and DOTS server provider that hosts a Call Home DOTS client and deploys a Carrier-Grad
e NAT (CGN) between the DOTS client domain and DOTS server
domain. In such cases, communicating an external IP address in a domain. In such cases, communicating an external IP address in a
mitigation request by a Call Home DOTS client is likely to be mitigation request by a Call Home DOTS client is likely to be
discarded by the Call Home DOTS server because the external IP discarded by the Call Home DOTS server because the external IP
address is not visible locally to the Call Home DOTS server (<xref address is not visible locally to the Call Home DOTS server (<xref tar
target="ex1"></xref>). The Call Home DOTS server is only aware of get="ex1" format="default"/>). The Call Home DOTS server is only aware of
the internal IP addresses/prefixes bound to its domain (i.e., those the internal IP addresses/prefixes bound to its domain (i.e., those
used in the Internal Realm shown in <xref target="ex1"></xref>). used in the internal realm shown in <xref target="ex1" format="default "/>).
Thus, Call Home DOTS clients that are aware of the presence of Thus, Call Home DOTS clients that are aware of the presence of
on-path CGNs MUST NOT include the external IP address and/or port on-path CGNs <bcp14>MUST NOT</bcp14> include the external IP address a nd/or port
number identifying the suspect attack source (i.e., those used in number identifying the suspect attack source (i.e., those used in
the External Realm shown in <xref target="ex1"></xref>), but MUST the external realm shown in <xref target="ex1" format="default"/>) but <bcp14>MUST</bcp14>
include the internal IP address and/or port number. To that aim, the include the internal IP address and/or port number. To that aim, the
Call Home DOTS client SHOULD rely on mechanisms, such as <xref Call Home DOTS client <bcp14>SHOULD</bcp14> rely on mechanisms, such a
target="RFC8512"></xref> or <xref target="RFC8513"></xref>, to s those described in <xref target="RFC8512" format="default"/> or <xref target="
retrieve the internal IP address and port number which are mapped to RFC8513" format="default"/>, to
retrieve the internal IP address and port number that are mapped to
an external IP address and port number. For the particular case of an external IP address and port number. For the particular case of
NAT64 <xref target="RFC6146"></xref>, if the target address is an NAT64 <xref target="RFC6146" format="default"/>, if the target address is an
IPv4 address, the IPv4-converted IPv6 address of this target address IPv4 address, the IPv4-converted IPv6 address of this target address
<xref target="RFC6052"></xref> SHOULD be used.</t> <xref target="RFC6052" format="default"/> <bcp14>SHOULD</bcp14> be use
d.</t>
<t><figure align="center" anchor="ex1" <figure anchor="ex1">
title="Example of a CGN between DOTS Domains"> <name>Example of a CGN between DOTS Domains</name>
<artwork align="center"><![CDATA[ N | .------------------- <artwork align="center" name="" type="" alt=""><![CDATA[ N |
. .-------------------.
E | ( )-. E | ( )-.
T | .' ' T | .' '
W | ( Call Home ) W | ( Call Home )
O | ( DOTS client -' O | ( DOTS client -'
R | '-( ) R | '-( )
K | '-------+-----------' K | '-------+-----------'
| | | |
P | | P | |
R | +---+---+ R | +---+---+
O | | CGN | External Realm O | | CGN | External Realm
skipping to change at line 955 skipping to change at line 835
.' Source Network ' .' Source Network '
( ) ( )
( Call Home -' ( Call Home -'
'-( DOTS server ) '-( DOTS server )
'------+------------' '------+------------'
| |
+-----+-------+ +-----+-------+
|Attack Source| |Attack Source|
+-------------+ +-------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>If a Mapping of Address and Port (MAP) Border Relay <xref target="R
<t>If a MAP Border Relay <xref target="RFC7597"></xref> or lwAFTR FC7597" format="default"/> or Lightweight Address Family Transition Router (lwAF
<xref target="RFC7596"></xref> is enabled in the provider's domain TR) <xref target="RFC7596" format="default"/> is enabled in the provider's domai
n
to service its customers, the identification of an attack source to service its customers, the identification of an attack source
bound to an IPv4 address/prefix MUST also rely on source port bound to an IPv4 address/prefix <bcp14>MUST</bcp14> also rely on sourc e port
numbers because the same IPv4 address is assigned to multiple numbers because the same IPv4 address is assigned to multiple
customers. The port information is required to unambiguously customers. The port information is required to unambiguously
identify the source of an attack.</t> identify the source of an attack.</t>
<t>If a translator is enabled on the boundaries of the domain <t>If a translator is enabled on the boundaries of the domain
hosting the Call Home DOTS server (e.g., a CPE with NAT enabled as hosting the Call Home DOTS server (e.g., a CPE with NAT enabled as
shown in Figures <xref format="counter" target="ex2"></xref> and shown in Figures <xref format="counter" target="ex2"/> and
<xref format="counter" target="ex2b"></xref>), the Call Home DOTS <xref format="counter" target="ex2b"/>), the Call Home DOTS
server uses the attack traffic information conveyed in a mitigation server uses the attack traffic information conveyed in a mitigation
request to find the internal source IP address of the compromised request to find the internal source IP address of the compromised
device and blocks the traffic from the compromised device traffic to device and blocks the traffic from the compromised device traffic to
the attack target until the mitigation request is withdrawn. The the attack target until the mitigation request is withdrawn. The
Call Home DOTS server proceeds with a NAT mapping table lookup using Call Home DOTS server proceeds with a NAT mapping table lookup using
the attack information (or a subset thereof) as a key. The lookup the attack information (or a subset thereof) as a key. The lookup
can be local (<xref target="ex2"></xref>) or via a dedicated can be local (<xref target="ex2" format="default"/>) or via a dedicate
administration interface that is offered by the CPE (<xref d
target="ex2b"></xref>). This identification allows the suspicious administration interface that is offered by the CPE (<xref target="ex2
b" format="default"/>). This identification allows the suspicious
device to be isolated while avoiding disturbances of other device to be isolated while avoiding disturbances of other
services.</t> services.</t>
<figure anchor="ex2">
<t><figure align="center" anchor="ex2" <name>Example of a DOTS Server Domain with a NAT Embedded in a CPE</
title="Example of a DOTS Server Domain with a NAT Embedded in a CP name>
E"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[ .------------------- .-------------------.
.
( )-. ( )-.
.' Network Provider (DMS)' .' Network Provider (DMS)'
( ) ( )
( Call Home -' ( Call Home -'
'-( DOTS client ) '-( DOTS client )
'-------+-----------' '-------+-----------'
| |
--- +---+---+ --- +---+---+
S | | CPE | External Realm S | | CPE | External Realm
O |..............| |................ O |..............| |................
skipping to change at line 1009 skipping to change at line 884
N | .' ' N | .' '
E | ( Call Home ) E | ( Call Home )
T | ( DOTS server -' T | ( DOTS server -'
W | '-( ) W | '-( )
O | '-------+-----------' O | '-------+-----------'
R | | R | |
K | +------+------+ K | +------+------+
| |Attack Source| | |Attack Source|
+-------------+ +-------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<figure anchor="ex2b">
<t><figure align="center" anchor="ex2b" <name>Example of a Call Home DOTS Server and a NAT Embedded in a CPE
title="Example of a Call Home DOTS Server and a NAT Embedded in a </name>
CPE"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[ .------------------- .-------------------.
.
( )-. ( )-.
.' Network Provider (DMS) ' .' Network Provider (DMS) '
( ) ( )
( Call Home -' ( Call Home -'
'-( DOTS client ) '-( DOTS client )
'---------+---------' '---------+---------'
| |
--- +-----+-----+ --- +-----+-----+
S | | CPE/NAT | External Realm S | | CPE/NAT | External Realm
O |..............| |................ O |..............| |................
skipping to change at line 1040 skipping to change at line 914
N | .' ' N | .' '
E | ( Local Area Network ) E | ( Local Area Network )
T | ( -' T | ( -'
W | '-( ) W | '-( )
O | '--------+----------' O | '--------+----------'
R | | R | |
K | +------+------+ K | +------+------+
| |Attack Source| | |Attack Source|
+-------------+ +-------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>If, for any reason, address sharing is deployed in both source and
<t>If for any reason address sharing is deployed in both source and
provider networks, both Call Home DOTS agents have to proceed with provider networks, both Call Home DOTS agents have to proceed with
address mapping lookups following the behavior specified in address mapping lookups following the behavior specified in
reference to <xref target="ex1"></xref> (network provider) and reference to <xref target="ex1" format="default"/> (network provider)
Figures <xref format="counter" target="ex2"></xref> and <xref and
format="counter" target="ex2b"></xref> (source network).</t> Figures <xref format="counter" target="ex2"/> and <xref format="counte
r" target="ex2b"/> (source network).</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="YANG" numbered="true" toc="default">
<section anchor="YANG" title="DOTS Signal Call Home YANG Module "> <name>DOTS Signal Call Home YANG Module</name>
<section title="Tree Structure"> <section numbered="true" toc="default">
<name>Tree Structure</name>
<t>This document augments the "ietf-dots-signal-channel" (dots-signal) <t>This document augments the "ietf-dots-signal-channel" (dots-signal)
DOTS signal YANG module defined in <xref DOTS signal YANG module defined in <xref target="RFC9132" format="defaul
target="I-D.ietf-dots-rfc8782-bis"></xref> for signaling the attack t"/> for signaling the attack
traffic information. This document defines the YANG module traffic information. This document defines the YANG module
"ietf-dots-call-home", which has the following tree structure:<figure> "ietf-dots-call-home", which has the following tree structure:</t>
<artwork><![CDATA[module: ietf-dots-call-home <sourcecode name="" type="yangtree"><![CDATA[
module: ietf-dots-call-home
augment-structure /dots-signal:dots-signal/dots-signal:message-type augment-structure /dots-signal:dots-signal/dots-signal:message-type
/dots-signal:mitigation-scope/dots-signal:scope: /dots-signal:mitigation-scope/dots-signal:scope:
+-- source-prefix* inet:ip-prefix +-- source-prefix* inet:ip-prefix
+-- source-port-range* [lower-port] +-- source-port-range* [lower-port]
| +-- lower-port inet:port-number | +-- lower-port inet:port-number
| +-- upper-port? inet:port-number | +-- upper-port? inet:port-number
+-- source-icmp-type-range* [lower-type] +-- source-icmp-type-range* [lower-type]
+-- lower-type uint8 +-- lower-type uint8
+-- upper-type? uint8 +-- upper-type? uint8
augment-structure /dots-signal:dots-signal/dots-signal:message-type augment-structure /dots-signal:dots-signal/dots-signal:message-type
/dots-signal:redirected-signal: /dots-signal:redirected-signal:
+-- (type)? +-- (type)?
+--:(call-home-only) +--:(call-home-only)
+-- alt-ch-client inet:domain-name +-- alt-ch-client inet:domain-name
+-- alt-ch-client-record* inet:ip-address +-- alt-ch-client-record* inet:ip-address
+-- ttl? uint32 +-- ttl? uint32
]]></artwork> ]]></sourcecode>
</figure></t>
</section> </section>
<section numbered="true" toc="default">
<section title="YANG/JSON Mapping Parameters to CBOR"> <name>YANG/JSON Mapping Parameters to CBOR</name>
<t>The YANG/JSON mapping parameters to CBOR are listed in Table <t>The YANG/JSON mapping parameters to CBOR are listed in <xref target="
1.<list style="symbols"> table1"/>.</t>
<t>Note: Implementers must check that the mapping output provided <t indent="3">
Note: Implementers must check that the mapping output provided
by their YANG-to-CBOR encoding schemes is aligned with the content by their YANG-to-CBOR encoding schemes is aligned with the content
of Table 1.</t> of <xref target="table1"/>.
</list></t> </t>
<t><figure align="center">
<artwork><![CDATA[+--------------------+------------+------+--------
-------+--------+
| Parameter Name | YANG | CBOR | CBOR Major | JSON |
| | Type | Key | Type & | Type |
| | | | Information | |
+====================+============+======+===============+========+
|ietf-dots-call-home:| leaf-list | | | |
| source-prefix | inet: | TBA1 | 4 array | Array |
| | ip-prefix | | 3 text string | String |
+--------------------+------------+------+---------------+--------+
|ietf-dots-call-home:| | | | |
| source-port-range | list | TBA2 | 4 array | Array |
+--------------------+------------+------+---------------+--------+
|ietf-dots-call-home:| | | | |
| source-icmp-type- | list | TBA3 | 4 array | Array |
| range | | | | |
+--------------------+------------+------+---------------+--------+
| lower-type | uint8 | TBA4 | 0 unsigned | Number |
+--------------------+------------+------+---------------+--------+
| upper-type | uint8 | TBA5 | 0 unsigned | Number |
+--------------------+------------+------+---------------+--------+
|ietf-dots-call-home:| inet: | | | |
| alt-ch-client | domain-name| TBA6 | 3 text string | String |
+--------------------+------------+------+---------------+--------+
|ietf-dots-call-home:| leaf-list | TBA7 | 4 array | Array |
| alt-ch-client- | inet: | | | |
| record | ip-address| | 3 text string | String |
+--------------------+------------+------+---------------+--------+
|ietf-dots-call-home:| | | | |
| ttl | uint32 | TBA8 | 0 unsigned | Number |
+--------------------+------------+------+---------------+--------+
Table 1: YANG/JSON Mapping Parameters to CBOR
]]></artwork>
</figure></t>
<t>The YANG/JSON mappings to CBOR for 'lower-port' and 'upper-port' <table anchor="table1">
are already defined in Table 5 of <xref <name>YANG/JSON Mapping Parameters to CBOR</name>
target="I-D.ietf-dots-rfc8782-bis"></xref>.</t> <thead>
<tr>
<th>Parameter Name</th>
<th>YANG Type</th>
<th>CBOR Key Value</th>
<th>CBOR Major Type &amp; Information</th>
<th>JSON Type</th>
</tr>
</thead>
<tbody>
<tr>
<td>ietf-dots-call-home:&zwsp;source-prefix</td>
<td>leaf-list inet:&zwsp;ip-prefix</td>
<td>32768</td>
<td>4 array<br/>3 text string</td>
<td>Array String</td>
</tr>
<tr>
<td>ietf-dots-call-home:&zwsp;source-port-range</td>
<td>list</td>
<td>32769</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>ietf-dots-call-home:&zwsp;source-icmp-type-range</td>
<td>list</td>
<td>32770</td>
<td>4 array</td>
<td>Array</td>
</tr>
<tr>
<td>lower-type</td>
<td>uint8</td>
<td>32771</td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
<tr>
<td>upper-type</td>
<td>uint8</td>
<td>32772</td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
<tr>
<td>ietf-dots-call-home:&zwsp;alt-ch-client</td>
<td>inet: domain-name</td>
<td>32773</td>
<td>3 text string</td>
<td>String</td>
</tr>
<tr>
<td>ietf-dots-call-home:&zwsp;alt-ch-client-record</td>
<td>leaf-list inet:&zwsp;ip-address</td>
<td>32774</td>
<td>4 array<br/>3 text string</td>
<td>Array<br/>String</td>
</tr>
<tr>
<td>ietf-dots-call-home:&zwsp;ttl</td>
<td>uint32</td>
<td>32775</td>
<td>0 unsigned</td>
<td>Number</td>
</tr>
</tbody>
</table>
<t>The YANG/JSON mappings to CBOR for "lower-port" and "upper-port"
are already defined in Table 5 of <xref target="RFC9132" format="default
"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<name>YANG Module</name>
<t>This module uses the common YANG types defined in <xref target="RFC69
91" format="default"/> and the data structure extension defined in
<xref target="RFC8791" format="default"/>.</t>
<section title="YANG Module "> <sourcecode name="ietf-dots-call-home@2021-09-27.yang"
<t>This module uses the common YANG types defined in <xref type="yang" markers="true"><![CDATA[
target="RFC6991"></xref> and the data structure extension defined in
<xref target="RFC8791"></xref>.</t>
<t><figure>
<artwork><![CDATA[<CODE BEGINS> file "ietf-dots-call-home@2020-12-02
.yang"
module ietf-dots-call-home { module ietf-dots-call-home {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home"; namespace "urn:ietf:params:xml:ns:yang:ietf-dots-call-home";
prefix dots-call-home; prefix dots-call-home;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"Section 4 of RFC 6991"; "Section 4 of RFC 6991";
} }
import ietf-dots-signal-channel { import ietf-dots-signal-channel {
prefix dots-signal; prefix dots-signal;
reference reference
"RFC YYYY: Distributed Denial-of-Service Open Threat "RFC 9132: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
} }
import ietf-yang-structure-ext { import ietf-yang-structure-ext {
prefix sx; prefix sx;
reference reference
"RFC 8791: YANG Data Structure Extensions"; "RFC 8791: YANG Data Structure Extensions";
} }
organization organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group"; "IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/dots/> "WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org> WG List: <mailto:dots@ietf.org>
Author: Konda, Tirumaleswar Reddy Author: Konda, Tirumaleswar Reddy
<mailto:TirumaleswarReddy_Konda@McAfee.com>; <mailto:kondtir@gmail.com>;
Author: Mohamed Boucadair Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>; <mailto:mohamed.boucadair@orange.com>;
Author: Jon Shallow Author: Jon Shallow
<mailto:ietf-supjps@jpshallow.com>"; <mailto:ietf-supjps@jpshallow.com>";
description description
"This module contains YANG definitions for the signaling "This module contains YANG definitions for the signaling
messages exchanged between a DOTS client and a DOTS server messages exchanged between a DOTS client and a DOTS server
for the Call Home deployment scenario. for the Call Home deployment scenario.
skipping to change at line 1188 skipping to change at line 1092
Copyright (c) 2021 IETF Trust and the persons identified as Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 9066; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2020-12-02 { revision 2021-09-27 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat "RFC 9066: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Call Home"; Signaling (DOTS) Signal Channel Call Home";
} }
sx:augment-structure "/dots-signal:dots-signal" sx:augment-structure "/dots-signal:dots-signal"
+ "/dots-signal:message-type" + "/dots-signal:message-type"
+ "/dots-signal:mitigation-scope" + "/dots-signal:mitigation-scope"
+ "/dots-signal:scope" { + "/dots-signal:scope" {
description description
"Attack source details."; "Attack source details.";
leaf-list source-prefix { leaf-list source-prefix {
type inet:ip-prefix; type inet:ip-prefix;
skipping to change at line 1224 skipping to change at line 1128
leaf lower-port { leaf lower-port {
type inet:port-number; type inet:port-number;
description description
"Lower port number of the port range."; "Lower port number of the port range.";
} }
leaf upper-port { leaf upper-port {
type inet:port-number; type inet:port-number;
must '. >= ../lower-port' { must '. >= ../lower-port' {
error-message error-message
"The upper port number must be greater than "The upper port number must be greater than
or equal to lower port number."; or equal to the lower port number.";
} }
description description
"Upper port number of the port range."; "Upper port number of the port range.";
} }
} }
list source-icmp-type-range { list source-icmp-type-range {
key "lower-type"; key "lower-type";
description description
"ICMP/ICMPv6 type range. When only lower-type is "ICMP/ICMPv6 type range. When only lower-type is
present, it represents a single ICMP/ICMPv6 type. present, it represents a single ICMP/ICMPv6 type.
The address family of the target-prefix is used The address family of the target-prefix is used
to determine whether ICMP or ICMPv6 are used."; to determine whether ICMP or ICMPv6 is used.";
leaf lower-type { leaf lower-type {
type uint8; type uint8;
description description
"Lower ICMP/ICMPv6 type of the ICMP type range."; "Lower ICMP/ICMPv6 type of the ICMP type range.";
reference reference
"RFC 792: Internet Control Message Protocol "RFC 792: Internet Control Message Protocol
RFC 4443: Internet Control Message Protocol (ICMPv6) RFC 4443: Internet Control Message Protocol (ICMPv6)
for Internet Protocol Version 6 (IPv6) for the Internet Protocol Version 6 (IPv6)
Specification."; Specification.";
} }
leaf upper-type { leaf upper-type {
type uint8; type uint8;
must '. >= ../lower-type' { must '. >= ../lower-type' {
error-message error-message
"The upper ICMP/ICMPv6 type must be greater than "The upper ICMP/ICMPv6 type must be greater than
or equal to lower ICMP type."; or equal to the lower ICMP type.";
} }
description description
"Upper type of the ICMP type range."; "Upper type of the ICMP type range.";
reference reference
"RFC 792: Internet Control Message Protocol "RFC 792: Internet Control Message Protocol
RFC 4443: Internet Control Message Protocol (ICMPv6) RFC 4443: Internet Control Message Protocol (ICMPv6)
for Internet Protocol Version 6 (IPv6) for the Internet Protocol Version 6 (IPv6)
Specification."; Specification.";
} }
} }
} }
sx:augment-structure "/dots-signal:dots-signal" sx:augment-structure "/dots-signal:dots-signal"
+ "/dots-signal:message-type" + "/dots-signal:message-type"
+ "/dots-signal:redirected-signal" { + "/dots-signal:redirected-signal" {
description description
"Augments the redirected signal to communicate an "Augments the redirected signal to communicate an
alternate Call Home DOTS client."; alternate Call Home DOTS client.";
choice type { choice type {
description description
"Indicates the type of the DOTS session (e.g., base "Indicates the type of the DOTS session (e.g., base
DOTS signal channel, DOTS Call Home)."; DOTS signal channel, DOTS Call Home).";
case call-home-only { case call-home-only {
description description
"These attributes appear only in a call home signal "These attributes appear only in a signal Call Home
channel message from a Call Home DOTS client channel message from a Call Home DOTS client
to a Call Home DOTS server."; to a Call Home DOTS server.";
leaf alt-ch-client { leaf alt-ch-client {
type inet:domain-name; type inet:domain-name;
mandatory true; mandatory true;
description description
"FQDN of an alternate Call Home DOTS client. "FQDN of an alternate Call Home DOTS client.
This name is also presented as reference This name is also presented as a reference
identifier for authentication purposes."; identifier for authentication purposes.";
} }
leaf-list alt-ch-client-record { leaf-list alt-ch-client-record {
type inet:ip-address; type inet:ip-address;
description description
"List of IP addresses for the alternate Call "List of IP addresses for the alternate Call
Home DOTS client. Home DOTS client.
If this data node is not present, a Call Home If this data node is not present, a Call Home
DOTS server resolves the alt-ch-client into DOTS server resolves the alt-ch-client into
one or more IP addresses."; one or more IP addresses.";
} }
leaf ttl { leaf ttl {
type uint32; type uint32;
units "seconds"; units "seconds";
description description
"The Time to live (TTL) of the alternate Call Home "The Time To Live (TTL) of the alternate Call Home
DOTS client."; DOTS client.";
reference reference
"Section 4.6 of RFC YYYY"; "Section 4.6 of RFC 9132";
} }
} }
} }
} }
} }
<CODE ENDS>]]></artwork> ]]></sourcecode>
</figure></t>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t></t> <t/>
<section anchor="map" numbered="true" toc="default">
<section anchor="map" title="DOTS Signal Channel CBOR Mappings Registry"> <name>DOTS Signal Channel CBOR Mappings Registry</name>
<t>This specification registers the following comprehension-optional <t>This specification registers the following comprehension-optional
parameters (Table 2) in the IANA "DOTS Signal Channel CBOR Key Values" parameters (<xref target="table2"/>) in the IANA "DOTS Signal Channel CB
registry <xref target="Key-Map"></xref>.</t> OR Key Values"
registry <xref target="Key-Map" format="default"/>.</t>
<t><list style="symbols"> <table anchor="table2">
<t>Note to the RFC Editor: Please delete TBA1-TBA8 once CBOR keys <name>Assigned DOTS Signal Channel CBOR Key Values</name>
are assigned from the 32768-49151 range.</t> <thead>
</list><figure> <tr>
<artwork><![CDATA[ +--------------------+-------+-------+--------- <th>Parameter Name</th>
---+---------------+ <th>CBOR Key Value</th>
| Parameter Name | CBOR | CBOR | Change | Specification | <th>CBOR Major Type</th>
| | Key | Major | Controller | Document(s) | <th>Change Controller</th>
| | Value | Type | | | <th>Reference</th>
+====================+=======+=======+============+===============+ </tr>
|ietf-dots-call-home:| | | | | </thead>
| source-prefix | TBA1 | 4 | IESG | [RFCXXXX] | <tbody>
+--------------------+-------+-------+------------+---------------+ <tr>
|ietf-dots-call-home:| | | | | <td>ietf-dots-call-home:&zwsp;source-prefix</td>
| source-port-range | TBA2 | 4 | IESG | [RFCXXXX] | <td>32768</td>
+--------------------+-------+-------+------------+---------------+ <td>4</td>
|ietf-dots-call-home:| | | | | <td>IESG</td>
| source-icmp-type- | TBA3 | 4 | IESG | [RFCXXXX] | <td>RFC 9066</td>
| range | | | | | </tr>
+--------------------+-------+-------+------------+---------------+ <tr>
| lower-type | TBA4 | 0 | IESG | [RFCXXXX] | <td>ietf-dots-call-home:&zwsp;source-port-range</td>
+--------------------+-------+-------+------------+---------------+ <td>32769</td>
| upper-type | TBA5 | 0 | IESG | [RFCXXXX] | <td>4</td>
+--------------------+-------+-------+------------+---------------+ <td>IESG</td>
|ietf-dots-call-home:| | | | | <td>RFC 9066</td>
| alt-ch-client | TBA6 | 3 | IESG | [RFCXXXX] | </tr>
+--------------------+-------+-------+------------+---------------+ <tr>
|ietf-dots-call-home:| | | | | <td>ietf-dots-call-home:&zwsp;source-icmp-type-range</td>
|alt-ch-client-record| TBA7 | 4 | IESG | [RFCXXXX] | <td>32770</td>
+--------------------+-------+-------+------------+---------------+ <td>4</td>
|ietf-dots-call-home:| | | | | <td>IESG</td>
| ttl | TBA8 | 0 | IESG | [RFCXXXX] | <td>RFC 9066</td>
+--------------------+-------+-------+------------+---------------+ </tr>
<tr>
Table 2: Assigned DOTS Signal Channel CBOR Key Values <td>lower-type</td>
]]></artwork> <td>32771</td>
</figure></t> <td>0</td>
<td>IESG</td>
<t></t> <td>RFC 9066</td>
</tr>
<tr>
<td>upper-type</td>
<td>32772</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9066</td>
</tr>
<tr>
<td>ietf-dots-call-home:&zwsp;alt-ch-client</td>
<td>32773</td>
<td>3</td>
<td>IESG</td>
<td>RFC 9066</td>
</tr>
<tr>
<td>ietf-dots-call-home:&zwsp;alt-ch-client-record</td>
<td>32774</td>
<td>4</td>
<td>IESG</td>
<td>RFC 9066</td>
</tr>
<tr>
<td>ietf-dots-call-home:&zwsp;ttl</td>
<td>32775</td>
<td>0</td>
<td>IESG</td>
<td>RFC 9066</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default">
<section title="New DOTS Conflict Cause"> <name>New DOTS Conflict Cause</name>
<t>This document requests IANA to assign a new code from the "DOTS <t>Per this document, IANA has assigned a new code from the "DOTS
Signal Channel Conflict Cause Codes" registry <xref Signal Channel Conflict Cause Codes" registry <xref target="Cause" forma
target="Cause"></xref>.</t> t="default"/>.</t>
<table align="center">
<texttable> <name>Assigned DOTS Signal Channel Conflict Cause Code</name>
<ttcol>Code</ttcol> <thead>
<tr>
<ttcol>Label</ttcol> <th align="left">Code</th>
<th align="left">Label</th>
<ttcol>Description</ttcol> <th align="left">Description</th>
<th align="left">Reference</th>
<ttcol>Reference</ttcol> </tr>
</thead>
<c>4 (TBA9)</c> <tbody>
<tr>
<c>request-rejected-legitimate-traffic</c> <td align="left">4</td>
<td align="left">request-rejected-legitimate-traffic</td>
<c>Mitigation request rejected. This code is returned by the DOTS <td align="left">Mitigation request rejected. This code is returne
d by the DOTS
server to indicate the attack traffic has been classified as server to indicate the attack traffic has been classified as
legitimate traffic.</c> legitimate traffic.</td>
<td align="left">RFC 9066</td>
<c>[RFCXXXX]</c> </tr>
</texttable> </tbody>
</table>
<t></t> <t/>
</section> </section>
<section anchor="yang" numbered="true" toc="default">
<section anchor="yang" title="DOTS Signal Call Home YANG Module"> <name>DOTS Signal Call Home YANG Module</name>
<t>This document requests IANA to register the following URI in the <t>Per this document, IANA has registered the following URI in the
"ns" subregistry within the "IETF XML Registry" <xref "ns" subregistry within the "IETF XML Registry" <xref target="RFC3688" f
target="RFC3688"></xref>: <figure> ormat="default"/>: </t>
<artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-dot <dl spacing="compact" indent="6">
s-call-home <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-call-home</dd>
Registrant Contact: The IETF. <dt>Registrant Contact:</dt><dd>The IETF.</dd>
XML: N/A; the requested URI is an XML namespace. <dt>XML:</dt><dd> N/A; the requested URI is an XML namespace.</dd>
]]></artwork> </dl>
</figure>This document requests IANA to register the following YANG <t>Per this document, IANA has registered the following YANG
module in the "YANG Module Names" subregistry <xref module in the "YANG Module Names" subregistry <xref target="RFC6020" for
target="RFC6020"></xref> within the "YANG Parameters" registry:<figure> mat="default"/> within the "YANG Parameters" registry:</t>
<artwork><![CDATA[ name: ietf-dots-call-home <dl spacing="compact" indent="6">
namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home <dt>name:</dt><dd>ietf-dots-call-home</dd>
maintained by IANA: N <dt>namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-call-home</dd>
prefix: dots-call-home <dt>maintained by IANA:</dt><dd>N</dd>
reference: RFC XXXX <dt>prefix:</dt><dd>dots-call-home</dd>
]]></artwork> <dt>reference:</dt><dd>RFC 9066</dd>
</figure></t> </dl>
</section> </section>
</section> </section>
<section anchor="security" title="Security Considerations"> <section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>This document deviates from classic DOTS signal channel usage by <t>This document deviates from classic DOTS signal channel usage by
having the DOTS server initiate the (D)TLS connection. DOTS signal having the DOTS server initiate the (D)TLS connection. Security considerat
channel related security considerations discussed in Section 11 of <xref ions related to the DOTS signal
target="I-D.ietf-dots-rfc8782-bis"></xref> MUST be considered. DOTS channel discussed in <xref target="RFC9132" sectionFormat="of" section="11
agents MUST authenticate each other using (D)TLS before a DOTS signal "/> and (D)TLS early data
discussed in <xref target="RFC9132" sectionFormat="of" section="7"/> <bcp1
4>MUST</bcp14> be considered. DOTS
agents <bcp14>MUST</bcp14> authenticate each other using (D)TLS before a D
OTS signal
channel session is considered valid.</t> channel session is considered valid.</t>
<t>The Call Home function enables a Call Home DOTS server to be <t>The Call Home function enables a Call Home DOTS server to be
reachable by only the intended Call Home DOTS client. Appropriate reachable by only the intended Call Home DOTS client. Appropriate
filters (e.g., access control lists) can be installed on the Call Home filters (e.g., access control lists) can be installed on the Call Home
DOTS server and network between the Call Home DOTS agents so that only DOTS server and network between the Call Home DOTS agents so that only
communications from a trusted Call Home DOTS client to the Call Home communications from a trusted Call Home DOTS client to the Call Home
DOTS server are allowed. These filters can be automatically installed by DOTS server are allowed. These filters can be automatically installed by
a Call Home DOTS server based on the configured or discovered peer Call a Call Home DOTS server based on the configured or discovered peer Call
Home DOTS client(s).</t> Home DOTS client(s).</t>
<t>An attacker may launch a DoS attack on the DOTS client by having it <t>An attacker may launch a DoS attack on the DOTS client by having it
perform computationally expensive operations, before deducing that the perform computationally expensive operations before deducing that the
attacker doesn't possess a valid key. For instance, in TLS 1.3 <xref attacker doesn't possess a valid key. For instance, in TLS 1.3 <xref targe
target="RFC8446"></xref>, the ServerHello message contains a Key Share t="RFC8446" format="default"/>, the ServerHello message contains a key share
value based on an expensive asymmetric key operation for key value based on an expensive asymmetric key operation for key
establishment. Common precautions mitigating DoS attacks are establishment. Common precautions mitigating DoS attacks are
recommended, such as temporarily adding to a drop-list the source recommended, such as temporarily adding the source
address after a set number of unsuccessful authentication attempts.</t> address to a drop-list after a set number of unsuccessful authentication a
ttempts.</t>
<t>The DOTS Call Home signal channel can be misused by a misbehaving <t>The DOTS signal Call Home channel can be misused by a misbehaving
Call Home DOTS client by arbitrarily signalling legitimate traffic as Call Home DOTS client by arbitrarily signaling legitimate traffic as
being attack traffic or falsifying mitigation signals so that some being attack traffic or falsifying mitigation signals so that some
sources are disconnected or some traffic is rate-limited. Such sources are disconnected or some traffic is rate-limited. Such
misbehaving Call Home DOTS clients may include sources identified by IP misbehaving Call Home DOTS clients may include sources identified by IP
addresses that are used for internal use only (that is, these addresses addresses that are used for internal use only (that is, these addresses
are not visible outside a Call Home DOTS server domain). Absent explicit are not visible outside a Call Home DOTS server domain). Absent explicit
policy (e.g., the Call Home DOTS client and server are managed by the policy (e.g., the Call Home DOTS client and server are managed by the
same administrative entity), such requests should be discarded by the same administrative entity), such requests should be discarded by the
Call Home DOTS server. More generally, Call Home DOTS servers should not Call Home DOTS server. More generally, Call Home DOTS servers should not
blindly trust mitigation requests from Call Home DOTS clients. For blindly trust mitigation requests from Call Home DOTS clients.
For
example, Call Home DOTS servers could use the attack flow information example, Call Home DOTS servers could use the attack flow information
contained in a mitigation request to enable a full-fledged packet contained in a mitigation request to enable a full-fledged packet
inspection function to inspect all the traffic from the compromised inspection function to inspect all the traffic from the compromised
device to the target, or could re-direct the traffic from the device to the target. They could also redirect the traffic from the
potentially compromised device to the target towards a DDoS mitigation potentially compromised device to the target towards a DDoS mitigation
system that can scrub the suspicious traffic, without blindly blocking system that can scrub the suspicious traffic without blindly blocking
all traffic from the indicated attack source to the target. Call Home all traffic from the indicated attack source to the target. Call Home
DOTS servers can also seek the consent of DOTS server domain DOTS servers can also seek the consent of the DOTS server domain
administrator to block the traffic from the potentially compromised administrator to block the traffic from the potentially compromised
device to the target (see <xref target="mitigation"></xref>). Means to device to the target (see <xref target="mitigation" format="default"/>). T
seek the consent are implementation-specific.</t> he means to
seek consent are implementation specific.</t>
<t>Call Home DOTS agents may interact with on-path address sharing <t>Call Home DOTS agents may interact with on-path address sharing
functions to retrieve an internal IP addresss/external IP address functions to retrieve an internal IP address / external IP address
mapping (<xref target="nat"></xref>) identifying an attack source. mapping (<xref target="nat" format="default"/>) identifying an attack sour
ce.
Blocking access or manipulating the mapping information will complicate Blocking access or manipulating the mapping information will complicate
DDoS attack mitigation close to an attack source. Additional security DDoS attack mitigation close to an attack source. Additional security
considerations are specific to the actual mechanism used to access that considerations are specific to the actual mechanism used to access that
mapping (refer, e.g., to Section 4 of <xref target="RFC8512"></xref> or mapping (refer, e.g., to <xref target="RFC8512" sectionFormat="of" section
Section 4 of <xref target="RFC8513"></xref>).</t> ="4"/> or
<xref target="RFC8513" sectionFormat="of" section="4"/>).</t>
<t> This document augments YANG data structures that are meant to be used
as an abstract representation of DOTS signal channel Call Home messages. As such
, the "ietf-dots-call-home" module does not introduce any new vulnerabilities be
yond those specified above and in <xref target="RFC9132"/>.
</t>
</section> </section>
<section title="Privacy Considerations"> <section numbered="true" toc="default">
<t>The considerations discussed in <xref target="RFC6973"></xref> were <name>Privacy Considerations</name>
<t>The considerations discussed in <xref target="RFC6973" format="default"
/> were
taken into account to assess whether the DOTS Call Home introduces taken into account to assess whether the DOTS Call Home introduces
privacy threats.</t> privacy threats.</t>
<t>Concretely, the protocol does not leak any new information that can <t>Concretely, the protocol does not leak any new information that can
be used to ease surveillance. In particular, the Call Home DOTS server be used to ease surveillance. In particular, the Call Home DOTS server
is not required to share information that is local to its network (e.g., is not required to share information that is local to its network (e.g.,
internal identifiers of an attack source) with the Call Home DOTS internal identifiers of an attack source) with the Call Home DOTS
client. Also, the recommended data to be included in Call Home DOTS client. Also, the recommended data to be included in Call Home DOTS
messages is a subset of the Layer 3/Layer 4 information that can be messages is a subset of the Layer 3 / Layer 4 information that can be
learnt from the overall traffic flows that exit the Call Home DOTS learned from the overall traffic flows that exit the Call Home DOTS
server domain. Furthermore, Call Home DOTS clients do not publicly server domain. Furthermore, Call Home DOTS clients do not publicly
reveal attack identification information; that information is encrypted reveal attack identification information; that information is encrypted
and only shared with an authorized entity in the domain to which the IP and only shared with an authorized entity in the domain to which the IP
address/prefix is assigned, from which an attack was issued.</t> address/prefix is assigned, from which an attack was issued.</t>
<t>The DOTS Call Home does not preclude the validation of mitigation <t>The DOTS Call Home does not preclude the validation of mitigation
requests received from a Call Home DOTS client. For example, a security requests received from a Call Home DOTS client. For example, a security
service running on the CPE may require an administrator's consent before service running on the CPE may require an administrator's consent before
the CPE acts upon the mitigation request indicated by the Call Home DOTS the CPE acts upon the mitigation request indicated by the Call Home DOTS
client. How the consent is obtained is out of scope of this client. How the consent is obtained is out of scope of this
document.</t> document.</t>
<t>Note that a Call Home DOTS server can seek an administrator's <t>Note that a Call Home DOTS server can seek an administrator's
consent, validate the request by inspecting the relevant traffic for consent, validate the request by inspecting the relevant traffic for
attack signatures, or proceed with both courses of action.</t> attack signatures, or proceed with both courses of action.</t>
<t>The DOTS Call Home is only advisory in nature. Concretely, the DOTS <t>The DOTS Call Home is only advisory in nature. Concretely, the DOTS
Call Home does not impose any action to be enforced within the network Call Home does not impose any action to be enforced within the network
hosting an attack source; it is up to the Call Home DOTS server (and/or hosting an attack source; it is up to the Call Home DOTS server (and/or
network administrator) to decide whether and which actions are network administrator) to decide whether and which actions are
required.</t> required.</t>
<t>Moreover, the DOTS Call Home avoids misattribution by appropriately <t>Moreover, the DOTS Call Home avoids misattribution by appropriately
identifying the network to which a suspect attack source belongs to identifying the network to which a suspect attack source belongs
(e.g., address sharing issues discussed in <xref (e.g., address sharing issues discussed in <xref target="mitigation" forma
target="mitigation"></xref>).</t> t="default"/>).</t>
<t>Triggers to send a DOTS mitigation request to a Call Home DOTS server <t>Triggers to send a DOTS mitigation request to a Call Home DOTS server
are deployment-specific. For example, a Call Home DOTS client may rely are deployment specific. For example, a Call Home DOTS client may rely
on the output of some DDoS detection systems (flow exports or similar on the output of some DDoS detection systems (flow exports or similar
functions) deployed within the DOTS client domain to detect potential functions) deployed within the DOTS client domain to detect potential
outbound DDoS attacks or on abuse claims received from remote victim outbound DDoS attacks or may rely on abuse claims received from remote vic tim
networks. These systems may be misused to track users and infer their networks. These systems may be misused to track users and infer their
activities. Such misuses are not required to achieve the functionality activities. Such misuses are not required to achieve the functionality
defined in this document (that is, protect the Internet and avoid defined in this document (that is, protect the Internet and avoid
altering the IP reputation of source networks). It is out of the scope altering the IP reputation of source networks). It is out of the scope
to identify privacy threats specific to a given attack detection to identify privacy threats specific to given attack detection
technology. The reader may refer, for example, to Section 11.8 of <xref technology. The reader may refer, for example, to <xref target="RFC7011" s
target="RFC7011"></xref>.</t> ectionFormat="of" section="11.8"/>.</t>
</section>
<section anchor="contr" title="Contributors">
<t>The following individuals have contributed to this document:</t>
<figure>
<artwork><![CDATA[ Joshi Harsha
McAfee, Inc.
Embassy Golf Link Business Park
Bangalore, Karnataka 560071
India
Email: harsha_joshi@mcafee.com
Wei Pan
Huawei Technologies
China
Email: william.panwei@huawei.com
]]></artwork>
</figure>
</section>
<section anchor="ack" title="Acknowledgements">
<t>Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, T&ouml;ma
Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments.</t>
<t>Benjamin Kaduk's AD review is valuable. Many thanks to him for the
detailed review.</t>
<t>Thanks to Radia Perlman and David Schinazi for the directorate
reviews.</t>
<t>Thanks to Ebben Aries for the yangdoctors review.</t>
<t>Thanks to &Eacute;ric Vyncke, Roman Danyliw, Barry Leiba, Robert
Wilton, and Erik Kline for the IESG review.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-dots-multihoming" to="DOTS-MULTIHOMING"/>
<?rfc include="reference.RFC.2119"?> <displayreference target="I-D.ietf-i2nsf-terminology" to="I2NSF-TERMS"/>
<displayreference target="I-D.ietf-tls-dtls13" to="DTLS13"/>
<?rfc include="reference.RFC.3688"?>
<?rfc include="reference.RFC.8446"?>
<?rfc include='reference.RFC.8174'?>
<?rfc include='reference.RFC.6991'?>
<?rfc include='reference.RFC.6347'?>
<?rfc include='reference.RFC.8791'?>
<?rfc include='reference.RFC.6020'?>
<?rfc include='reference.RFC.0792'?>
<?rfc include='reference.RFC.4443'?>
<?rfc include='reference.RFC.6052'?>
<?rfc include='reference.RFC.6146'?>
<?rfc include='reference.I-D.ietf-dots-rfc8782-bis'?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4732"?>
<?rfc include='reference.RFC.8811'?>
<?rfc include="reference.RFC.4632"?>
<?rfc include="reference.RFC.8071"?>
<?rfc include="reference.RFC.4960"?>
<?rfc include="reference.RFC.4340"?>
<?rfc include="reference.RFC.8955"?>
<?rfc include='reference.I-D.ietf-dots-multihoming'?>
<?rfc include="reference.RFC.8612"?>
<?rfc include='reference.I-D.ietf-dots-use-cases'?>
<?rfc include='reference.RFC.8973'?>
<?rfc include='reference.RFC.8956'?>
<?rfc include='reference.RFC.8512'?>
<?rfc include='reference.RFC.8513'?>
<?rfc include='reference.RFC.6973'?>
<?rfc include='reference.RFC.7596'?>
<?rfc include='reference.RFC.7597'?> <references>
<name>References</name>
<references>
<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.3688.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.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6991.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8791.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6020.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.0792.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4443.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6052.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6146.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.9132.xml"/>
<?rfc include='reference.RFC.8340'?> </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.8811.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4632.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8071.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4960.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8955.xml"/>
<?rfc include='reference.RFC.8517'?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-dots-multihoming.xml"/>
<?rfc include='reference.RFC.8576'?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-tls-dtls13.xml"/>
<?rfc include='reference.RFC.6398'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8612.xml"/>
<?rfc include='reference.RFC.2663'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8903.xml"/>
<?rfc include='reference.I-D.ietf-i2nsf-terminology'?> <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.8956.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.8513.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6973.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7596.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7597.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8517.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8576.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6398.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2663.xml"/>
<?rfc include='reference.RFC.4949'?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-i2nsf-terminology.xml"/>
<?rfc include='reference.RFC.7011'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4949.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7011.xml"/>
<reference anchor="Sec-by-design" <reference anchor="Sec-by-design" target="https://www.gov.uk/government/
target="https://www.gov.uk/government/publications/secure-by-de publications/secure-by-design-report">
sign-report"> <front>
<front> <title>Secure by Design: Improving the cyber security of consumer
<title>Secure by Design: Improving the cyber security of consumer
Internet of Things Report</title> Internet of Things Report</title>
<author fullname="" surname="">
<author fullname="" surname=""> <organization>UK Department for Digital, Culture, Media &amp;
<organization>UK Department for Digital Culture, Media &amp;
Sport</organization> Sport</organization>
</author> </author>
<date month="March" year="2018"/>
<date month="March" year="2018" /> </front>
</front> </reference>
</reference>
<reference anchor="Key-Map"
target="https://www.iana.org/assignments/dots/dots.xhtml#dots-s
ignal-channel-cbor-key-values">
<front>
<title>DOTS Signal Channel CBOR Key Values</title>
<author fullname="IANA">
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="Cause"
target="https://www.iana.org/assignments/dots/dots.xhtml#dots-s
ignal-channel-conflict-cause-codes">
<front>
<title>DOTS Signal Channel Conflict Cause Codes</title>
<author fullname="IANA">
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="RS" <reference anchor="Key-Map" target="https://www.iana.org/assignments/dot
target="https://web.archive.org/web/20150315054838/http://ha.ck s/">
ers.org/slowloris/"> <front>
<front> <title>DOTS Signal Channel CBOR Key Values</title>
<title>Slowloris HTTP DoS</title> <author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<author fullname="RSnake" surname="RSnake"> <reference anchor="Cause" target="https://www.iana.org/assignments/dots/
<organization></organization> ">
</author> <front>
<title>DOTS Signal Channel Conflict Cause Codes</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<date /> <reference anchor="RS" target="https://web.archive.org/web/2015031505483
</front> 8/http://ha.ckers.org/slowloris/">
</reference> <front>
<title>Slowloris HTTP DoS</title>
<author fullname="RSnake" surname="RSnake">
<organization/>
</author>
<date/>
</front>
</reference>
</references>
</references> </references>
<section anchor="home" numbered="true" toc="default">
<section anchor="home" title="Some Home Network Issues"> <name>Some Home Network Issues</name>
<t>Internet of Things (IoT) devices are becoming more and more <t>Internet of Things (IoT) devices are becoming more and more
prevalent, in particular in home networks. With compute and memory prevalent, in particular in home networks. With compute and memory
becoming cheaper and cheaper, various types of IoT devices become becoming cheaper and cheaper, various types of IoT devices become
available in the consumer market at affordable prices. But on the available in the consumer market at affordable prices. But on the
downside, there is a corresponding threat since most of these IoT downside, there is a corresponding threat since most of these IoT
devices are bought off-the-shelf and most manufacturers haven't devices are bought off-the-shelf and most manufacturers haven't
considered security in the product design (e.g., <xref considered security in the product design (e.g., <xref target="Sec-by-desi
target="Sec-by-design"></xref>). IoT devices deployed in home networks gn" format="default"/>). IoT devices deployed in home networks
can be easily compromised, they often do not have an easy mechanism to can be easily compromised, they often do not have an easy mechanism to
upgrade, and even when upgradable, IoT manufacturers may cease upgrade, and even when upgradable, IoT manufacturers may cease
manufacture and/or discontinue patching vulnerabilities on IoT devices manufacture and/or discontinue patching vulnerabilities on IoT devices
(Sections 5.4 and 5.5 of <xref target="RFC8576"></xref>). These (Sections <xref target="RFC8576" sectionFormat="bare" section="5.4"/> and <xref target="RFC8576" sectionFormat="bare" section="5.5"/> of <xref target="RF C8576"/>). These
vulnerable and compromised devices will continue to be used for a long vulnerable and compromised devices will continue to be used for a long
period of time in the home, and the end-user does not know that IoT period of time in the home, and the end-user does not know that IoT
devices in his/her home are compromised. The compromised IoT devices are devices in his/her home are compromised. The compromised IoT devices are
typically used for launching DDoS attacks (Section 3 of <xref typically used for launching DDoS attacks (<xref target="RFC8576" sectionF
target="RFC8576"></xref>) on victims while the owner/administrator of ormat="of" section="3"/>) on victims while the owner/administrator of
the home network is not aware about such misbehaviors. Similar to other the home network is not aware about such misbehaviors. Similar to other
DDoS attacks, the victim in this attack can be an application server, a DDoS attacks, the victim in this attack can be an application server, a
host, a router, a firewall, or an entire network. Such misbehaviors can host, a router, a firewall, or an entire network. Such misbehaviors can
cause collateral damage that will affect end users, and can also harm cause collateral damage that will affect end users, and can also harm
the reputation of an Internet Service Provider (ISP) for being a source the reputation of an Internet Service Provider (ISP) for being a source
of attack traffic.</t> of attack traffic.</t>
<t>Nowadays, network devices in a home network can offer network <t>Nowadays, network devices in a home network can offer network
security functions (e.g., firewall <xref target="RFC4949"></xref> or security functions (e.g., firewall <xref target="RFC4949" format="default"
Intrusion Protection System (IPS) service <xref /> or
target="I-D.ietf-i2nsf-terminology"></xref> on a home router) to protect Intrusion Protection System (IPS) service <xref target="I-D.ietf-i2nsf-ter
minology" format="default"/> on a home router) to protect
the devices connected to the home network from both external and the devices connected to the home network from both external and
internal attacks. It is natural to seek to provide DDoS defense in these internal attacks. It is natural to seek to provide DDoS defense in these
devices as well, and over the years several techniques have been devices as well, and over the years several techniques have been
identified to detect DDoS attacks; some of these techniques can be identified to detect DDoS attacks; some of these techniques can be
enabled on home network devices but most of them are used within the enabled on home network devices but most of them are used within the
ISP's network.</t> ISP's network.</t>
<t>Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris <t>Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris
<xref target="RS"></xref>, and Transport Layer Security (TLS) <xref target="RS" format="default"/>, and Transport Layer Security (TLS)
renegotiation are difficult to detect on a home network device without renegotiation are difficult to detect on a home network device without
adversely affecting its performance. The reason is that typically home adversely affecting its performance. The reason is that typically home
devices such as home routers have fast path to boost the throughput. For devices such as home routers have fast path to boost the throughput. For
every new TCP/UDP flow, only the first few packets are punted through every new TCP/UDP flow, only the first few packets are punted through
the slow path. Hence, it is not possible to detect various DDoS attacks the slow path. Hence, it is not possible to detect various DDoS attacks
in the slow path, since the attack payload is sent to the target server in the slow path, since the attack payload is sent to the target server
after the flow is switched to fast path. The reader may refer to Section after the flow is switched to fast path. The reader may refer to <xref tar
2 of <xref target="RFC6398"></xref> for a brief definition of slow and get="RFC6398" sectionFormat="of" section="2"/> for a brief definition of slow an
d
fast paths.</t> fast paths.</t>
<t>Deep Packet Inspection (DPI) of all the packets of a flow would be <t>Deep Packet Inspection (DPI) of all the packets of a flow would be
able to detect some of the attacks. However, a full-fledged DPI to able to detect some of the attacks. However, a full-fledged DPI to
detect these type of DDoS attacks is functionally or operationally not detect these type of DDoS attacks is functionally or operationally not
possible for all the devices attached to the home network because of the possible for all the devices attached to the home network because of the
memory and CPU limitations of the home routers. Furthermore, for certain memory and CPU limitations of the home routers. Furthermore, for certain
DDoS attacks the logic needed to distinguish legitimate traffic from DDoS attacks the logic needed to distinguish legitimate traffic from
attack traffic on a per-packet basis is complex. This complexity is attack traffic on a per-packet basis is complex. This complexity is
because that the packet itself may look "legitimate" and no attack because that the packet itself may look "legitimate" and no attack
signature can be identified. The anomaly can be identified only after signature can be identified. The anomaly can be identified only after
detailed statistical analysis. In addition, network security services in detailed statistical analysis. In addition, network security services in
skipping to change at line 1762 skipping to change at line 1612
DDoS attacks the logic needed to distinguish legitimate traffic from DDoS attacks the logic needed to distinguish legitimate traffic from
attack traffic on a per-packet basis is complex. This complexity is attack traffic on a per-packet basis is complex. This complexity is
because that the packet itself may look "legitimate" and no attack because that the packet itself may look "legitimate" and no attack
signature can be identified. The anomaly can be identified only after signature can be identified. The anomaly can be identified only after
detailed statistical analysis. In addition, network security services in detailed statistical analysis. In addition, network security services in
home networks may not be able to detect all types of DDoS attacks using home networks may not be able to detect all types of DDoS attacks using
DPI. ISPs offering DDoS mitigation services have a DDoS detection DPI. ISPs offering DDoS mitigation services have a DDoS detection
capability that relies upon anomaly detection to identify zero day DDoS capability that relies upon anomaly detection to identify zero day DDoS
attacks and to detect DDoS attacks that cannot be detected using attacks and to detect DDoS attacks that cannot be detected using
signatures and rate-limit techniques.</t> signatures and rate-limit techniques.</t>
<t>ISPs can detect some DDoS attacks originating from a home network <t>ISPs can detect some DDoS attacks originating from a home network
(e.g., Section 2.6 of <xref target="RFC8517"></xref>), but the ISP (e.g., <xref target="RFC8517" sectionFormat="of" section="2.6"/>), but the ISP
usually does not have a mechanism to detect which device in the home usually does not have a mechanism to detect which device in the home
network is generating the DDoS attack traffic. The primary reason for network is generating the DDoS attack traffic. The primary reason for
this is that devices in an IPv4 home network are typically behind a this is that devices in an IPv4 home network are typically behind a
Network Address Translation (NAT) border <xref target="RFC2663"></xref>. Network Address Translation (NAT) border <xref target="RFC2663" format="de fault"/>.
Even in case of an IPv6 home network, although the ISP can identify the Even in case of an IPv6 home network, although the ISP can identify the
infected device in the home network launching the DDoS traffic by infected device in the home network launching the DDoS traffic by
tracking its unique IPv6 address, the infected device can easily change tracking its unique IPv6 address, the infected device can easily change
its IPv6 address to evade remediation. A security function on the local its IPv6 address to evade remediation. A security function on the local
home network is better positioned to track the compromised device across home network is better positioned to track the compromised device across
IPv6 address (and potentially even MAC address) changes and thus ensure IPv6 address (and potentially even MAC address) changes and thus ensure
that remediation remains in place across such events.</t> that remediation remains in place across such events.</t>
</section> </section>
<section anchor="app" numbered="true" toc="default">
<section anchor="app" <name>Disambiguating Base DOTS Signal vs. DOTS Call Home</name>
title="Disambiguating Base DOTS Signal vs. DOTS Call Home">
<t>With the DOTS signal channel Call Home, there is a chance that two <t>With the DOTS signal channel Call Home, there is a chance that two
DOTS agents can simultaneously establish two DOTS signal channels with DOTS agents can simultaneously establish two DOTS signal channels with
different directions (base DOTS signal channel and DOTS signal channel different directions (base DOTS signal channel and DOTS signal channel
Call Home). Here is one example drawn from the home network. Call Home). Here is one example drawn from the home network.
Nevertheless, the outcome of the discussion is not specific to these Nevertheless, the outcome of the discussion is not specific to these
networks, but applies to any DOTS Call Home scenario.</t> networks, but applies to any DOTS Call Home scenario.</t>
<t>In the Call Home scenario, the Call Home DOTS server in, for example, <t>In the Call Home scenario, the Call Home DOTS server in, for example,
the home network can mitigate the DDoS attacks launched by the the home network can mitigate the DDoS attacks launched by the
compromised device in its domain by receiving the mitigation request compromised device in its domain by receiving the mitigation request
sent by the Call Home DOTS client in the ISP environment. In addition, sent by the Call Home DOTS client in the ISP environment. In addition,
the DOTS client in the home network can initiate a mitigation request to the DOTS client in the home network can initiate a mitigation request to
the DOTS server in the ISP environment to ask for help when the home the DOTS server in the ISP environment to ask for help when the home
network is under a DDoS attack. Such Call Home DOTS server and DOTS network is under a DDoS attack. Such Call Home DOTS server and DOTS
client in the home network can co-locate in the same home network client in the home network can co-locate in the same home network
element (e.g., the Customer Premises Equipment). In this case, with the element (e.g., the Customer Premises Equipment). In this case, with the
same peer at the same time the home network element will have the base same peer at the same time the home network element will have the base
DOTS signal channel defined in <xref DOTS signal channel defined in <xref target="RFC9132" format="default"/> a
target="I-D.ietf-dots-rfc8782-bis"></xref> and the DOTS signal channel nd the DOTS signal channel
Call Home defined in this specification. Thus, these two signal channels Call Home defined in this specification. Thus, these two signal channels
need to be distinguished when they are both supported. Two approaches need to be distinguished when they are both supported. Two approaches
have been considered for distinguishing the two DOTS signal channels, have been considered for distinguishing the two DOTS signal channels,
but only the one that using the dedicated port number has been chosen as but only the one that using the dedicated port number has been chosen as
the best choice.</t> the best choice.</t>
<t>By using a dedicated port number for each, these two signal channels <t>By using a dedicated port number for each, these two signal channels
can be separated unambiguously and easily. For example, the CPE uses the can be separated unambiguously and easily. For example, the CPE uses the
port number 4646 allocated in <xref port number 4646 allocated in <xref target="RFC9132" format="default"/> to
target="I-D.ietf-dots-rfc8782-bis"></xref> to initiate the basic signal initiate the basic signal
channel to the ISP when it acts as the DOTS client, and uses another channel to the ISP when it acts as the DOTS client, and uses another
port number to initiate the signal channel Call Home. Based on the port number to initiate the signal channel Call Home. Based on the
different port numbers, the ISP can directly decide which kind of different port numbers, the ISP can directly decide which kind of
procedures should follow immediately after it receives the DOTS procedures should follow immediately after it receives the DOTS
messages. This approach just requires two (D)TLS sessions to be messages. This approach just requires two (D)TLS sessions to be
established respectively for the basic signal channel and signal channel established respectively for the basic signal channel and signal channel
Call Home.</t> Call Home.</t>
<t>The other approach is signaling the role of each DOTS agent (e.g., by <t>The other approach is signaling the role of each DOTS agent (e.g., by
using the DOTS data channel as depicted in <xref target="data"></xref>). using the DOTS data channel as depicted in <xref target="data" format="def ault"/>).
For example, the DOTS agent in the home network first initiates a DOTS For example, the DOTS agent in the home network first initiates a DOTS
data channel to the peer DOTS agent in the ISP environment, at this time data channel to the peer DOTS agent in the ISP environment, at this time
the DOTS agent in the home network is the DOTS client and the peer DOTS the DOTS agent in the home network is the DOTS client and the peer DOTS
agent in the ISP environment is the DOTS server. After that, the DOTS agent in the ISP environment is the DOTS server. After that, the DOTS
agent in the home network retrieves the DOTS Call Home capability of the agent in the home network retrieves the DOTS Call Home capability of the
peer DOTS agent. If the peer supports the DOTS Call Home, the DOTS agent peer DOTS agent. If the peer supports the DOTS Call Home, the DOTS agent
needs to subscribe to the peer to use this extension. Then, the reversal needs to subscribe to the peer to use this extension. Then, the reversal
of DOTS role can be recognized as done by both DOTS agents. When the of DOTS role can be recognized as done by both DOTS agents. When the
DOTS agent in the ISP environment, which now is the DOTS client, wants DOTS agent in the ISP environment, which now is the DOTS client, wants
to filter the attackers' traffic, it requests the DOTS agent in the home to filter the attackers' traffic, it requests the DOTS agent in the home
network, which now is the DOTS server, for help.</t> network, which now is the DOTS server, for help.</t>
<figure anchor="data">
<t><figure align="center" anchor="data" <name>Example of DOTS Data Channel Augmentation</name>
title="Example of DOTS Data Channel Augmentation"> <sourcecode name="" type="yangtree"><![CDATA[
<artwork><![CDATA[ augment /ietf-data:dots-data/ietf-data:capabilitie augment /ietf-data:dots-data/ietf-data:capabilities:
s: +--ro call-home-support? boolean
+--ro call-home-support? boolean augment /ietf-data:dots-data/ietf-data:dots-client:
augment /ietf-data:dots-data/ietf-data:dots-client: +--rw call-home-enable? boolean
+--rw call-home-enable? boolean ]]></sourcecode>
]]></artwork> </figure>
</figure></t>
<t>Signaling the role will complicate the DOTS protocols, and this <t>Signaling the role will complicate the DOTS protocols, and this
complexity is not required in context where the DOTS Call Home is not complexity is not required in context where the DOTS Call Home is not
required or only when the DOTS Call Home is needed. Besides, the DOTS required or only when the DOTS Call Home is needed. Besides, the DOTS
data channel may not work during attack time. Even if changing the above data channel may not work during attack time. Even if changing the above
example from using the DOTS data channel to the DOTS signal channel, the example from using the DOTS data channel to the DOTS signal channel, the
more procedures will still reduce the efficiency. Using the dedicated more procedures will still reduce the efficiency. Using the dedicated
port number is much easier and more concise compared to the second port number is much easier and more concise compared to the second
approach, and its cost that establishing two (D)TLS sessions is much approach, and its cost that establishing two (D)TLS sessions is much
less. So, using a dedicated port number for the DOTS Call Home is less. So, using a dedicated port number for the DOTS Call Home is
recommended in this specification. The dedicated port number can be recommended in this specification. The dedicated port number can be
configured locally or discovered using means such as <xref configured locally or discovered using means such as <xref target="RFC8973
target="RFC8973"></xref>.</t> " format="default"/>.</t>
</section>
<section anchor="ack" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Thanks to <contact fullname="Wei Pei"/>, <contact fullname="Xia Liang"/
>, <contact fullname="Roman Danyliw"/>, <contact fullname="Dan Wing"/>, <contact
fullname="Toema
Gavrichenkov"/>, <contact fullname="Daniel Migault"/>, <contact fullname="
Sean Turner"/>, and <contact fullname="Valery Smyslov"/> for the
comments.</t>
<t><contact fullname="Benjamin Kaduk"/>'s AD review is valuable. Many than
ks to him for the
detailed review.</t>
<t>Thanks to <contact fullname="Radia Perlman"/> and <contact fullname="Da
vid Schinazi"/> for the directorate
reviews.</t>
<t>Thanks to <contact fullname="Ebben Aries"/> for the YANG Doctors review
.</t>
<t>Thanks to <contact fullname="Éric Vyncke"/>, <contact fullname="Roman D
anyliw"/>, <contact fullname="Barry Leiba"/>, <contact fullname="Robert
Wilton"/>, and <contact fullname="Erik Kline"/> for the IESG review.</t>
</section>
<section anchor="contr" numbered="false" toc="default">
<name>Contributors</name>
<t>The following individuals have contributed to this document:</t>
<contact fullname="Joshi Harsha" >
<organization>McAfee, Inc.</organization>
<address>
<postal>
<street>Embassy Golf Link Business Park</street>
<city>Bangalore</city>
<region>Karnataka</region><code>560071</code>
<country>India</country>
</postal>
<email>harsha_joshi@mcafee.com</email>
</address>
</contact>
<contact fullname="Wei Pan" >
<organization>Huawei Technologies</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country>China</country>
</postal>
<email>william.panwei@huawei.com</email>
</address>
</contact>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 277 change blocks. 
915 lines changed or deleted 966 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/