draft-ietf-dots-signal-call-home-04.txt   draft-ietf-dots-signal-call-home-05.txt 
DOTS T. Reddy DOTS T. Reddy
Internet-Draft McAfee Internet-Draft McAfee
Intended status: Standards Track M. Boucadair Intended status: Standards Track M. Boucadair
Expires: January 26, 2020 Orange Expires: January 31, 2020 Orange
J. Shallow J. Shallow
July 25, 2019 July 30, 2019
Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Call Home Channel Call Home
draft-ietf-dots-signal-call-home-04 draft-ietf-dots-signal-call-home-05
Abstract Abstract
This document specifies the DOTS signal channel Call Home service, This document specifies the DOTS signal channel Call Home, which
which enables a DOTS server to initiate a secure connection to a DOTS enables a DOTS server to initiate a secure connection to a DOTS
client, and to receive the attack traffic information from the DOTS client, and to receive the attack traffic information from the DOTS
client. The DOTS server in turn uses the attack traffic information client. The DOTS server in turn uses the attack traffic information
to identify the compromised devices launching the outgoing DDoS to identify the compromised devices launching the outgoing DDoS
attack and takes appropriate mitigation action(s). attack and takes appropriate mitigation action(s).
The DOTS Call Home service is not specific to the home networks; the The DOTS signal channel Call Home is not specific to the home
solution targets any deployment which requires to block DDoS attack networks; the solution targets any deployment which requires to block
traffic closer to the source(s) of a DDoS attack. DDoS attack traffic closer to the source(s) of a DDoS attack.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Please update these statements within the document with the RFC Please update these statements within the document with the RFC
number to be assigned to this document: number to be assigned to this document:
o "This version of this YANG module is part of RFC XXXX;" o "This version of this YANG module is part of RFC XXXX;"
o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Call Home"; (DOTS) Signal Channel Call Home";
skipping to change at page 2, line 22 skipping to change at page 2, line 22
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 26, 2020. This Internet-Draft will expire on January 31, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 46 skipping to change at page 2, line 46
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 5 1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 6 1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 6
1.4. Co-existence of Base DOTS Signal Channel & DOTS Call Home 7 1.4. Co-existence of Base DOTS Signal Channel & DOTS Call Home 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 11 3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 12
3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 12 3.2. Heartbeat Mechanism . . . . . . . . . . . . . . . . . . . 13
3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 13 3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 14
3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 13 3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 14
3.3.2. Address Sharing Considerations . . . . . . . . . . . 15 3.3.2. Address Sharing Considerations . . . . . . . . . . . 17
3.3.3. DOTS Signal Call Home YANG Module . . . . . . . . . . 18 3.3.3. DOTS Signal Call Home YANG Module . . . . . . . . . . 20
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 22 4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 24
4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 22 4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 24
4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 23 4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 25
4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 24 4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 26
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . 26 9.1. Normative References . . . . . . . . . . . . . . . . . . 28
9.2. Informative References . . . . . . . . . . . . . . . . . 27 9.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Disambiguate Base DOTS Signal vs. Call Home . . . . 29 Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
1.1. The Problem 1.1. The Problem
The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] 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. Such information is sent by a DOTS client to one or multiple attack [RFC4732]. Such information is sent by a DOTS client to one
DOTS servers so that appropriate mitigation actions are undertaken on or multiple DOTS servers so that appropriate mitigation actions are
traffic deemed suspicious. Various use cases are discussed in undertaken on traffic deemed suspicious. Various use cases are
[I-D.ietf-dots-use-cases]. discussed in [I-D.ietf-dots-use-cases].
Internet of Things (IoT) devices are becoming more and more prevalent Internet of Things (IoT) devices are becoming more and more prevalent
in home networks, and with compute and memory becoming cheaper and in home networks, in particular. With compute and memory becoming
cheaper, various types of IoT devices become available in the cheaper and cheaper, various types of IoT devices become available in
consumer market at affordable prices. But on the downside, the main the consumer market at affordable prices. But on the downside, the
threat being most of these IoT devices are bought off-the-shelf and main threat being most of these IoT devices are bought off-the-shelf
most manufacturers haven't considered security in the product design. and most manufacturers haven't considered security in the product
IoT devices deployed in home networks can be easily compromised, they design (e.g., [Sec]). IoT devices deployed in home networks can be
do not have an easy mechanism to upgrade, and IoT manufactures may easily compromised, they do not have an easy mechanism to upgrade,
cease manufacture and/or discontinue patching vulnerabilities on IoT and IoT manufactures may cease manufacture and/or discontinue
devices (Sections 5.4 and 5.5 of [RFC8576]). However, these patching vulnerabilities on IoT devices (Sections 5.4 and 5.5 of
vulnerable and compromised devices will continue to be used for a [RFC8576]). These vulnerable and compromised devices will continue
long period of time in the home, and the end-user does not know that to be used for a long period of time in the home, and the end-user
IoT devices in his/her home are compromised. The compromised IoT does not know that IoT devices in his/her home are compromised. The
devices are typically used for launching DDoS attacks (Section 3 of compromised IoT devices are typically used for launching DDoS attacks
[RFC8576]) on victims while the owner/administrator of the home (Section 3 of [RFC8576]) on victims while the owner/administrator of
network is not aware about such misbehaviors. Similar to other DDoS the home network is not aware about such misbehaviors. Similar to
attacks, the victim in this attack can be an application server, a other DDoS attacks, the victim in this attack can be an application
host, a router, a firewall, or an entire network. server, a host, a router, a firewall, or an entire network. Such
misbehaviors will have a collateral damage that affects end users and
the reputation of an Internet Service Provider (ISP).
Nowadays, network devices in a home network offer network security Nowadays, network devices in a home network offer network security
(e.g., firewall or Intrusion Protection System (IPS) service on a (e.g., firewall [RFC4949] or Intrusion Protection System (IPS)
home router) to protect the devices connected to the home network service [I-D.ietf-i2nsf-terminology] on a home router) to protect the
from both external and internal attacks. Over the years several devices connected to the home network from both external and internal
techniques have been identified to detect DDoS attacks, some of these attacks. Over the years several techniques have been identified to
techniques can be enabled on home network devices but most of them detect DDoS attacks, some of these techniques can be enabled on home
are used in the Internet Service Provider (ISP)'s network. The ISP network devices but most of them are used within the ISP's network.
offering DDoS mitigation service can detect outgoing DDoS attack The ISP offering a DDoS mitigation service can detect outgoing DDoS
traffic originating from its subscribers or the ISP may receive attack traffic originating from its subscribers or the ISP may
filtering rules (e.g., using BGP flowspec [RFC5575]) from a receive filtering rules (e.g., using BGP Flowspec
downstream service provider to filter, block, or rate-limit DDoS [RFC5575][I-D.ietf-idr-flow-spec-v6]) from a downstream service
attack traffic originating from the ISP's subscribers to a downstream provider to filter, block, or rate-limit DDoS attack traffic
target. originating from the ISP's subscribers to a downstream target.
Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris, Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris,
and Transport Layer Security (TLS) re-negotiation are difficult to and Transport Layer Security (TLS) re-negotiation are difficult to
detect on a home network device without adversely affecting its detect on a home network device without adversely affecting its
performance. The reason is typically home devices such as home performance. The reason is typically home devices such as home
routers have fast path to boost the throughput. For every new TCP/ routers have fast path to boost the throughput. For every new TCP/
UDP flow, only the first few packets are punted through the slow UDP flow, only the first few packets are punted through the slow
path. Hence, it is not possible to detect various DDoS attacks in 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 the slow path, since the attack payload is sent to the target server
after the flow is switched to fast path. Deep Packet Inspection after the flow is switched to fast path. The reader may refer to
(DPI) of all the packets of a flow would be able to detect some of Section 2 of [RFC6398] for a brief definition of slow and fast paths.
the attacks. However, a full-fledged DPI to detect these type of
DDoS attacks is functionally or operationally not possible for all
the devices attached to the home network owing to the memory and CPU
limitations of the home routers. Further, for certain DDoS attacks
the ability to distinguish legitimate traffic from attacker traffic
on a per packet basis is complex. This complexity is due to that the
packet itself may look "legitimate" and no attack signature can be
identified. The anomaly can be identified only after detailed
statistical analysis.
The ISP on the other hand can detect some DDoS attacks originating Deep Packet Inspection (DPI) of all the packets of a flow would be
from a home network (e.g., Section 2.6 of [RFC8517]), but the ISP able to detect some of the attacks. However, a full-fledged DPI to
does not have a mechanism to detect which device in the home network detect these type of DDoS attacks is functionally or operationally
is generating the DDoS attack traffic. The primary reason being that not possible for all the devices attached to the home network owing
devices in an IPv4 home network are typically behind a Network to the memory and CPU limitations of the home routers. Furthermore,
Address Translation (NAT) border. Even in case of an IPv6 home for certain DDoS attacks the ability to distinguish legitimate
network, although the ISP can identify the infected device in the traffic from attack traffic on a per packet basis is complex. This
home network launching the DDoS traffic by tracking its unique IPv6 complexity is due to that the packet itself may look "legitimate" and
address, the infected device can easily change its IPv6 address to no attack signature can be identified. The anomaly can be identified
evade remediation. only after detailed statistical analysis.
ISPs can detect some DDoS attacks originating from a home network
(e.g., Section 2.6 of [RFC8517]), but the ISP does not have a
mechanism to detect which device in the home network is generating
the DDoS attack traffic. The primary reason being that devices in an
IPv4 home network are typically behind a Network Address Translation
(NAT) border [RFC2663]. 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 tracking its unique IPv6 address, the
infected device can easily change its IPv6 address to evade
remediation.
Existing approaches are still suffering from misused access network Existing approaches are still suffering from misused access network
resources by abusing devices; the support of means for blocking such resources by abusing devices; the support of means for blocking such
attacks close to the sources are missing. In particular, the DOTS attacks close to the sources are missing. In particular, the DOTS
signal protocol does not discuss cooperative DDoS mitigation between signal protocol does not discuss cooperative DDoS mitigation between
the network hosting an attack source and the ISP to the suppress the the network hosting an attack source and the ISP to the suppress the
outbound DDoS attack traffic originating from that network. outbound DDoS attack traffic originating from that network.
1.2. The Solution 1.2. The Solution
This specification addresses the problems discussed in Section 1.1 This specification addresses the problems discussed in Section 1.1
and presents the DOTS signal channel Call Home extension, which and presents an extension to the DOTS signal channel: DOTS signal
enables the DOTS server to initiate a secure connection to the DOTS channel Call Home.
client, and the DOTS client then conveys the attack traffic
information to the DOTS server. '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. That is, the DOTS server initiates a secure connection to a
DOTS client, and uses that connection to receive the attack traffic
information (e.g., attack sources) from the DOTS client. More
details are provided in Section 3.
DOTS agents involved in the DOTS Call Home adhere to the DOTS roles
as defined in [RFC8612]. For clarity, 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 scenario (Figure 1).
A high-level DOTS Call Home functional architecture is shown in
Figure 1. Attack source(s) are within the DOTS server domain.
Scope
+.-.-.-.-.-.-.-.-.-.-.-.+
+---------------+ : +-------------+ :
| Alert/DMS/ | ~~~:~~~ | Call Home | :
| Peer DMS/... | : | DOTS client | :
+---------------+ : +------+------+ :
: | :
: | :
: | :
+---------------+ : +------+------+ :
| Attack | ~~~:~~~ | Call Home | :
| Source(s) | : | DOTS server | :
+---------------+ : +-------------+ :
+.-.-.-.-.-.-.-.-.-.-.-.+
Figure 1: Basic DOTS Signal Channel Call Home Functional Architecture
A DOTS client relies upon a variety of triggers to make use of the A DOTS client relies upon a variety of triggers to make use of the
Call Home function (e.g., scrubbing the traffic from the attack Call Home function (e.g., scrubbing the traffic from the attack
source, receiving an alert from an attack target, a peer DDoS source, receiving an alert from an attack target, a peer DDoS
Mitigation System (DMS), or a transit provider). The definition of Mitigation System (DMS), or a transit provider). The definition of
these triggers is deployment-specific. It is therefore out of the these triggers is deployment-specific. It is therefore out of the
scope of this document to elaborate on how these triggers are made scope of this document to elaborate on how these triggers are made
available to a DOTS client. available to a Call Home DOTS client.
In a typical deployment scenario, the DOTS server is enabled on a In a typical deployment scenario, the Call Home DOTS server is
Customer Premises Equipment (CPE), which is aligned with recent enabled on a Customer Premises Equipment (CPE), which is aligned with
trends to enrich the CPE with advanced security features. Unlike recent trends to enrich the CPE with advanced security features.
classic DOTS deployments [I-D.ietf-dots-use-cases], such DOTS server Unlike classic DOTS deployments [I-D.ietf-dots-use-cases], such DOTS
maintains a single DOTS signal channel session for each DOTS-capable server maintains a single DOTS signal channel session for each DOTS-
upstream provisioning domain [I-D.ietf-dots-multihoming]. capable upstream provisioning domain [I-D.ietf-dots-multihoming].
For instance, the DOTS server in the home network initiates the Call For instance, the Call Home DOTS server in the home network initiates
Home in 'idle' time and then subsequently the DOTS client in the ISP the signal channel Call Home in 'idle' time and then subsequently the
environment can initiate a mitigation request whenever the ISP Call Home DOTS client in the ISP environment can initiate a
detects there is an attack from a compromised device in the DOTS mitigation request whenever the ISP detects there is an attack from a
server domain (i.e., from within the home network). compromised device in the DOTS server domain (i.e., from within the
home network).
The DOTS server uses the DDoS attack traffic information to identify The Call Home DOTS server uses the DDoS attack traffic information to
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 launching the DDoS attack, optionally notifies a network
administrator, and takes appropriate mitigation action(s). A administrator, and takes appropriate mitigation action(s). For
mitigation action can be to quarantine the compromised device or example, a mitigation action can be to quarantine the compromised
block its traffic to the attack target(s) until the mitigation device or block its traffic to the attack target(s) until the
request is withdrawn. mitigation request is withdrawn.
Other motivations for introducing the Call Home function are Other motivations for introducing the Call Home function are
discussed in Section 1.1 of [RFC8071]. discussed in Section 1.1 of [RFC8071].
This document assumes that DOTS servers are provisioned with a way to This document assumes that Call Home DOTS servers are provisioned
know how to reach the upstream DOTS client(s), which could occur by a with a way to know how to reach the upstream Call Home DOTS
variety of means (e.g., [I-D.ietf-dots-server-discovery]). The client(s), which could occur by a variety of means (e.g.,
specification of such means are out of scope of this document. [I-D.ietf-dots-server-discovery]). The specification of such means
are out of scope of this document.
More information about the applicability scope of the DOTS signal
channel Call Home is provided in Section 1.3.
1.3. Applicability Scope 1.3. Applicability Scope
The aforementioned problems may be encountered in other deployments The aforementioned problems may be encountered in other deployments
than those discussed in Section 1.1 (e.g., data centers, enterprise than those discussed in Section 1.1 (e.g., data centers, enterprise
networks). The solution specified in this document can be used for networks). The solution specified in this document can be used for
those deployments to block DDoS attack traffic closer to the those deployments to block DDoS attack traffic closer to the
source(s) of the attack. The Call Home reference architecture is source(s) of the attack.
shown in Figure 1.
An instantiation of the Call Home functional architecture is depicted
in Figure 2.
+-------------+ +-------------+
|Attack Target| |Attack Target|
+-----+-------+ +-----+-------+
| /\ Target Network | /\ Target Network
......................|.||.................... ......................|.||....................
| ||
.--------+-||-------. .--------+-||-------.
( || )-. ( || )-.
.' || ' .' || '
( Internet || ) ( Internet || )
( || -' ( || -'
'-( || ) '-( || )
'------+-||---------' '------+-||---------'
......................|.||..................... ......................|.||.....................
| ||Network Provider (DMS) .--------+-||-------. Network
.--------+-||-------. ( || )-. Provider
( || )-. .' Call Home || ' (DMS)
.' DOTS || ' ( DOTS client || )
( client || )
( || -' ( || -'
'-( || ) '-( || )
'------+-||---------' '------+-||---------'
| ||
......................|.||....................... ......................|.||.......................
| || Source Network .--------+-||-------. Source Network
.--------+-||-------.
( || )-. ( || )-.
.' DOTS || ' .' Call Home || '
( server || Outbound ) ( DOTS server || Outbound )
( || DDoS -' ( || DDoS -'
'-( || Attack ) '-( || Attack )
'------+-||---------' '------+-||---------'
| || | ||
+-----+-++----+ +-----+-++----+
|Attack Source| |Attack Source|
+-------------+ +-------------+
Figure 1: Call Home Reference Architecture Figure 2: DOTS Signal Channel Call Home Reference Architecture
It is out of the scope of this document to identify an exhaustive It is out of the scope of this document to identify an exhaustive
list of such deployments. list of such deployments.
1.4. Co-existence of Base DOTS Signal Channel & DOTS Call Home 1.4. Co-existence of Base DOTS Signal Channel & DOTS Call Home
The DOTS Call Home does not require nor preclude the activation of The DOTS signal channel Call Home does not require nor preclude the
the base DOTS signal channel. Some sample deployment schemes are activation of the base DOTS signal channel
[I-D.ietf-dots-signal-channel]. Some sample deployment schemes are
discussed in this section for illustration purposes. discussed in this section for illustration purposes.
The network that hosts an attack source may also be subject to The network that hosts an attack source may also be subject to
inbound DDoS attacks. In that case, both the base DOTS signal inbound DDoS attacks. In that case, both the base DOTS signal
channel and DOTS Call Home may be enabled as shown in Figure 3 (Same channel and DOTS signal channel Call Home may be enabled as shown in
DMS provider) or Figure 2 (Distinct DMS providers). Figure 3 (Same DMS provider) or Figure 4 (Distinct DMS providers).
Call Home Base Signal Channel DOTS Signal Channel Base DOTS
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 Network #A
Figure 2: Activation of Base DOTS Signal Channel and Call Home (Same Figure 3: Activation of Base DOTS Signal Channel and Call Home (Same
DMS Provider) DMS Provider)
Call Home Base Signal Channel 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 Figure 4). Nevertheless, the DOTS signal channel Call Home
requires the DMS provider to be on the default forwarding path of the
outbound traffic from a given network.
DOTS Signal Channel Base DOTS
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
Figure 3: Activation of Base DOTS Signal Channel and Call Home Figure 4: Activation of Base DOTS Signal Channel and Call Home
(Distinct DMS Providers) (Distinct DMS Providers)
Figures 4 and 5 depict examples where the same node embeds both DOTS Figures 5 and 6 depict examples where the same node embeds both base
client and server instances. DOTS and DOTS Call Home agents. For example, a 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 Figure 5) or a
DOTS client and a Call Home DOTS server may be enabled on the same
device within a source network (e.g., Node #j with Network #D shown
in Figure 6) .
Call Home Base Signal Channel Whether the same or distinct nodes are used to host base DOTS and
DOTS Call Home agents is specific to each domain.
DOTS Signal Channel Base DOTS
Call Home Signal Channel
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
: +----------------------+ : : +----------------------+ :
: | Node #i | : : | Node #i | :
: | +------+ :: +------+ | : : | +------+ +------+ | :
: | | 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 #C Network #C
Figure 4: Example of the Same Node Embedding both DOTS Client and Figure 5: An Example of the Same Node Embedding both a Call Home DOTS
Server Instances at the Network Provider's Side Client and a DOTS Server at the Network Provider's Side
Call Home Base Signal Channel DOTS Signal Channel Base DOTS
Call Home Signal Channel
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
: +----------------------+ : : +----------------------+ :
: | Node #k | : : | Node #k | :
: | +------+ :: +------+ | : : | +------+ +------+ | :
: | | 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| | :
: | +------+ :: +------+ | : : | +------+ +------+ | :
: | Node #j | : : | Node #j | :
: +----------------------+ : : +----------------------+ :
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
Network #D Network #D
Figure 5: Another Example where the Same Node Embeds both DOTS Client Figure 6: Another Example where the Same Node Embeds both a DOTS
and Server Instances Client and a Call Home DOTS Server
Appendix A elaborates on the considerations to unambiguously Appendix A elaborates on the considerations to unambiguously
distinguish DOTS messages which belong to each of these channels. distinguish DOTS messages which belong to each of these channels.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The reader should be familiar with the terms defined in [RFC8612]. The reader should be familiar with the terms defined in [RFC8612].
'Base DOTS signal channel' refers to [I-D.ietf-dots-signal-channel].
The meaning of the symbols in YANG tree diagrams is defined in The meaning of the symbols in YANG tree diagrams is defined in
[RFC8340]. [RFC8340].
(D)TLS is used for statements that apply to both Transport Layer (D)TLS is used for statements that apply to both Transport Layer
Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS) Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS)
[RFC6347]. Specific terms are used for any statement that applies to [RFC6347]. Specific terms are used for any statement that applies to
either protocol alone. either protocol alone.
3. DOTS Signal Channel Call Home 3. DOTS Signal Channel Call Home
3.1. Procedure 3.1. Procedure
The DOTS signal channel Call Home extension preserves all but one of The DOTS signal channel Call Home preserves all but one of the DOTS
the DOTS client/server roles in the DOTS protocol stack, as compared client/server roles in the DOTS protocol stack, as compared to DOTS
to DOTS client-initiated DOTS signal channel protocol client-initiated DOTS signal channel protocol
[I-D.ietf-dots-signal-channel]. The role reversal that occurs is at [I-D.ietf-dots-signal-channel]. The role reversal that occurs is at
the (D)TLS layer; that is, (1) the DOTS server acts as a DTLS client the (D)TLS layer; that is, (1) the Call Home DOTS server acts as a
and the DOTS client acts as a DTLS server or (2) the DOTS server acts DTLS client and the Call Home DOTS client acts as a DTLS server or
as a TLS client initiating the underlying TCP connection and the DOTS (2) the Call Home DOTS server acts as a TLS client initiating the
client acts as a TLS server. The DOTS server initiates (D)TLS underlying TCP connection and the Call Home DOTS client acts as a TLS
handshake to the DOTS client. server. The Call Home DOTS server initiates (D)TLS handshake to the
Call Home DOTS client.
For example, a home network element (e.g., home router) co-located For example, a home network element (e.g., home router) co-located
with a DOTS server (likely, a client-domain DOTS gateway) is the with a Call Home DOTS server is the (D)TLS server. However, when
(D)TLS server. However, when calling home, the DOTS server initially calling home, the DOTS server initially assumes the role of the
assumes the role of the (D)TLS client, but the network element's role (D)TLS client, but the network element's role as a DOTS server
as a DOTS server remains the same. Furthermore, existing certificate remains the same. Furthermore, existing certificate chains and
chains and mutual authentication mechanisms between the DOTS agents mutual authentication mechanisms between the DOTS agents are
are unaffected by the Call Home function. This Call Home function unaffected by the Call Home function. This Call Home function
enables the DOTS server co-located with a network element (possibly enables the DOTS server co-located with a network element (possibly
behind NATs and firewalls) reachable by only the intended DOTS client behind NATs and firewalls) reachable by only the intended Call Home
and hence the DOTS server cannot be subjected to DDoS attacks. DOTS client and hence the Call Home DOTS server cannot be subjected
to these DDoS attacks.
Figure 6 illustrates a sample Call Home flow exchange: Figure 7 illustrates a sample DOTS Call Home flow exchange:
+--------+ +--------+ +-----------+ +-----------+
| DOTS | | DOTS | | Call Home | | Call Home |
| server | | client | | DOTS | | DOTS |
+---+----+ +----+---+ | 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 |
|<-----------------------------------| |<-----------------------------------|
| ... | | ... |
Figure 6: DOTS Signal Channel Call Home Sequence Diagram Figure 7: DOTS Signal Channel Call Home Sequence Diagram
The DOTS signal channel Call Home procedure is as follows: The DOTS signal channel Call Home procedure is as follows:
1. If UDP transport is used, the DOTS server begins by initiating a 1. If UDP transport is used, the Call Home DOTS server begins by
DTLS connection to the DOTS client. initiating a DTLS connection to the Call Home DOTS client.
If TCP is used, the DOTS server begins by initiating a TCP If TCP is used, the Call Home DOTS server begins by initiating a
connection to the DOTS client. Using this TCP connection, the TCP connection to the Call Home DOTS client. Using this TCP
DOTS server initiates a TLS connection to the DOTS client. connection, the Call Home DOTS server initiates a TLS connection
to the Call Home DOTS client.
In some cases, a DOTS client and server may have mutual agreement In some cases, peer DOTS agents may have mutual agreement to use
to use a specific port number, such as by explicit configuration a specific port number, such as by explicit configuration or
or dynamic discovery [I-D.ietf-dots-server-discovery]. Absent dynamic discovery [I-D.ietf-dots-server-discovery]. Absent such
such mutual agreement, the DOTS signal channel call home MUST run mutual agreement, the DOTS signal channel Call Home MUST run over
over port number TBD (that is, DOTS clients must support port number TBD (that is, Call Home DOTS clients must support
accepting DTLS (or TCP) connections on TBD) as defined in accepting DTLS (or TCP) connections on TBD) as defined in
Section 4.1, for both UDP and TCP. The interaction between the Section 4.1, for both UDP and TCP. The interaction between the
base DOTS signal channel and the call home is discussed in base DOTS signal channel and the Call Home is discussed in
Appendix A. Appendix A.
The Happy Eyeballs mechanism explained in Section 4.3 of The Happy Eyeballs mechanism explained in Section 4.3 of
[I-D.ietf-dots-signal-channel] can be used for initiating (D)TLS [I-D.ietf-dots-signal-channel] is used for initiating (D)TLS
connections. connections.
2. Using this (D)TLS connection, the DOTS client may request, 2. Using this (D)TLS connection, the Call Home DOTS client may
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 of new attributes defined in Section 3.3.1.
3.2. Heartbeat Mechanism The Heartbeat mechanism used for the DOTS Call Home deviates from
the one defined in Section 4.7 of [I-D.ietf-dots-signal-channel].
Section 3.2 specifies the behavior to be followed by Call Home
DOTS agents.
The Heartbeat mechanism used for the Call Home deviates from the one 3.2. Heartbeat Mechanism
defined in Section 4.7 of [I-D.ietf-dots-signal-channel]. This
section specifies the behavior to be followed by DOTS agents for the
Call Home.
Once the (D)TLS section is established between the DOTS agents, the Once the (D)TLS section is established between the DOTS agents, the
DOTS client contacts the DOTS server to retrieve the session Call Home DOTS client contacts the Call Home DOTS server to retrieve
configuration parameters (Section 4.5 of the session configuration parameters (Section 4.5 of
[I-D.ietf-dots-signal-channel]). The DOTS server adjusts the [I-D.ietf-dots-signal-channel]). The Call Home DOTS server adjusts
'heartbeat-interval' to accommodate binding timers used by on-path the 'heartbeat-interval' to accommodate binding timers used by on-
NATs and firewalls. Heartbeats will be then exchanged by the DOTS path NATs and firewalls. Heartbeats will be then exchanged by the
agents following the instructions retrieved using the signal channel DOTS agents following the instructions retrieved using the signal
session configuration exchange. channel session configuration exchange.
It is the responsibility of DOTS servers to ensure that on-path It is the responsibility of Call Home DOTS servers to ensure that on-
translators/firewalls are maintaining a binding so that the same path translators/firewalls are maintaining a binding so that the same
external IP address and/or port number is retained for the DOTS external IP address and/or port number is retained for the DOTS
signal channel session. A DOTS client MAY trigger their heartbeat signal channel session. A Call Home DOTS client MAY trigger their
requests immediately after receiving heartbeat probes from its peer heartbeat requests immediately after receiving heartbeat probes from
DOTS server. its peer Call Home DOTS server.
When an outgoing attack that saturates the outgoing link from the When an outgoing attack that saturates the outgoing link from the
DOTS server is detected and reported by a DOTS client, the latter Call Home DOTS server is detected and reported by a Call Home DOTS
MUST continue to use the signal channel even if no traffic is client, the latter MUST continue to use the DOTS signal channel even
received from the DOTS server. if no traffic is received from the Call Home DOTS server.
If the DOTS server receives traffic from the DOTS client, the DOTS If the Call Home DOTS server receives traffic from the Call Home DOTS
server MUST continue to use the signal channel even if the missing client, the Call Home DOTS server MUST continue to use the DOTS
heartbeat allowed threshold is reached. signal channel even if the missing heartbeats allowed threshold
('missing-hb-allowed') is reached.
If the DOTS server does not receive any traffic from the peer DOTS If the Call Home DOTS server does not receive any traffic from the
client, the DOTS server sends heartbeat requests to the DOTS client peer Call Home DOTS client during the time span required to exhaust
and after maximum 'missing-hb-allowed' threshold is reached, the DOTS the maximum 'missing-hb-allowed' threshold, the Call Home DOTS server
server concludes the session is disconnected. Then, the DOTS server concludes the session is disconnected. Then, the Call Home DOTS
MUST try to resume the (D)TLS session. server MUST try to resume the (D)TLS session.
3.3. DOTS Signal Channel Extension 3.3. DOTS Signal Channel Extension
3.3.1. Mitigation Request 3.3.1. Mitigation Request
This specification extends the mitigation request defined in This specification extends the mitigation request defined in
Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the attack
attacker source prefixes and source port numbers. The DOTS client source information (e.g., source prefixes, source port numbers). The
conveys the following new parameters in the CBOR body of the DOTS client conveys the following new parameters in the CBOR body of
mitigation request: the mitigation request:
source-prefix: A list of attacker prefixes used to attack the source-prefix: A list of attacker prefixes used to attack the
target. Prefixes are represented using Classless Inter-Domain target. Prefixes are represented using Classless Inter-Domain
Routing (CIDR) notation [RFC4632]. Routing (CIDR) notation [RFC4632].
As a reminder, the prefix length MUST be less than or equal to 32 As a reminder, the prefix length MUST be less than or equal to 32
(or 128) for IPv4 (or IPv6). (or 128) for IPv4 (or IPv6).
The prefix list MUST NOT include broadcast, loopback, or multicast The prefix list MUST NOT include broadcast, loopback, or multicast
addresses. These addresses are considered as invalid values. In addresses. These addresses are considered as invalid values. In
addition, the DOTS client MUST validate that attacker prefixes are addition, the DOTS client MUST validate that attacker prefixes are
within the scope of the DOTS server domain. within the scope of the DOTS server domain.
This is an optional attribute for the base DOTS signal channel This is an optional attribute for the base DOTS signal channel
operations [I-D.ietf-dots-signal-channel]. operations.
source-port-range: A list of port numbers used by the attack traffic source-port-range: A list of port numbers used by the attack traffic
flows. flows.
A port range is defined by two bounds, a lower port number (lower- A port range is defined by two bounds, a lower port number (lower-
port) and an upper port number (upper-port). When only 'lower- port) and an upper port number (upper-port). When only 'lower-
port' is present, it represents a single port number. port' is present, it represents a single port number.
For TCP, UDP, Stream Control Transmission Protocol (SCTP) For TCP, UDP, Stream Control Transmission Protocol (SCTP)
[RFC4960], or Datagram Congestion Control Protocol (DCCP) [RFC4960], or Datagram Congestion Control Protocol (DCCP)
[RFC4340], a range of ports can be any subrange of 0-65535, for [RFC4340], a range of ports can be any subrange of 0-65535, for
example, 0-1023, 1024-65535, or 1024-49151. example, 0-1023, 1024-65535, or 1024-49151.
This is an optional attribute for the base DOTS signal channel This is an optional attribute for the base DOTS signal channel
operations [I-D.ietf-dots-signal-channel]. operations.
source-icmp-type-range: A list of ICMP types used by the attack source-icmp-type-range: A list of ICMP types used by the attack
traffic flows. An ICMP type range is defined by two bounds, a traffic flows. An ICMP type range is defined by two bounds, a
lower ICMP type (lower-type) and an upper ICMP type (upper-type). lower ICMP type (lower-type) and an upper ICMP type (upper-type).
When only 'lower-type' is present, it represents a single ICMP When only 'lower-type' is present, it represents a single ICMP
type. type.
This is an optional attribute for the base DOTS signal channel This is an optional attribute for the base DOTS signal channel
operations [I-D.ietf-dots-signal-channel]. operations.
The 'source-prefix' parameter is a mandatory attribute when the The 'source-prefix' parameter is a mandatory attribute when the
attack traffic information is signaled by a DOTS client in the Call attack traffic information is signaled by a Call Home DOTS client
Home scenario (depicted in Figure 6). The 'target-uri' or 'target- (i.e., the Call Home scenario depicted in Figure 7). The 'target-
fqdn' parameters can be included in a mitigation request for uri' or 'target-fqdn' parameters can be included in a mitigation
diagnostic purposes to notify the DOTS server domain administrator, request for diagnostic purposes to notify the Call Home DOTS server
but SHOULD NOT be used to determine the target IP addresses. Note domain administrator, but SHOULD NOT be used to determine the target
that 'target-prefix' becomes a mandatory attribute in the mitigation IP addresses. Note that 'target-prefix' becomes a mandatory
request signaling the attack information because 'target-uri' and attribute in the mitigation request signaling the attack information
'target-fqdn' are optional attributes and 'alias-name' will not be because 'target-uri' and 'target-fqdn' are optional attributes and
conveyed in a mitigation request. 'alias-name' will not be conveyed in a mitigation request.
In order to help attack source identification by a DOTS server, the In order to help attack source identification by a Call Home DOTS
DOTS client SHOULD include in its mitigation request additional server, the Call Home DOTS client SHOULD include in its mitigation
information such as 'source-port-range' or 'source-icmp-type-range'. request additional information such as 'source-port-range' or
The DOTS client may not include such information if 'source-prefix' 'source-icmp-type-range'. The Call Home DOTS client may not include
conveys an IPv6 address/prefix. such information if 'source-prefix' conveys an IPv6 address/prefix.
Address sharing implications on the setting of source information
('source-prefix', 'source-port-range') are discussed in
Section 3.3.2.
Only immediate mitigation requests (i.e., 'trigger-mitigation' set to Only immediate mitigation requests (i.e., 'trigger-mitigation' set to
'true') are allowed; DOTS clients MUST NOT send requests with 'true') are allowed; Call Home DOTS clients MUST NOT send requests
'trigger-mitigation' set to 'false'. Such requests MUST be discarded with 'trigger-mitigation' set to 'false'. Such requests MUST be
by the DOTS server with a 4.00 (Bad Request). discarded by the Call Home DOTS server with a 4.00 (Bad Request).
The DOTS server MUST check that the 'source-prefix' is within the An example of a mitigation request sent by a Call Home DOTS client is
scope of the DOTS server domain in the Call Home scenario. Note that shown in Figure 8.
in such scenario, the DOTS server considers, by default, that any
routeable IP prefix enclosed in 'target-prefix' is within the scope
of the DOTS client. Invalid mitigation requests are handled as per
Section 4.4.1 of [I-D.ietf-dots-signal-channel].
The DOTS server domain administrator consent MAY be required to block Header: PUT (Code=0.03)
the traffic from the compromised device to the attack target. An Uri-Path: ".well-known"
implementation MAY have a configuration knob to block the traffic Uri-Path: "dots"
from the compromised device to the attack target with or without DOTS Uri-Path: "mitigate"
server domain administrator consent. If the attack traffic is Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
blocked, the DOTS server informs the DOTS client that the attack is Uri-Path: "mid=56"
being mitigated. Content-Format: "application/dots+cbor"
If the attack traffic information is identified by the DOTS server or {
the DOTS server domain administrator as legitimate traffic, the "ietf-dots-signal-channel:mitigation-scope": {
mitigation request is rejected, and 4.09 (Conflict) is returned to "scope": [
the DOTS client. The conflict-clause (defined in Section 4.4.1 of {
[I-D.ietf-dots-signal-channel]) indicates the cause of the conflict. "target-prefix": [
The following new value is defined: "2001:db8:c000::/128"
],
"ietf-dots-call-home:source-prefix": [
"2001:db8:123::/128"
],
"lifetime": 3600
}
]
}
}
Figure 8: An Example of Mitigation Request Issued by a Call Home DOTS
Client
The Call Home DOTS server MUST check that the 'source-prefix' is
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
default, that any routeable IP prefix enclosed in 'target-prefix' is
within the scope of the Call Home DOTS client. Invalid mitigation
requests are handled as per Section 4.4.1 of
[I-D.ietf-dots-signal-channel].
Note: These validation checks do not apply when the source
information is included as a hint in the context of the base DOTS
signal channel.
The Call Home DOTS server domain administrator consent MAY be
required to block the traffic from the compromised device to the
attack target. An implementation MAY have a configuration knob to
block the traffic from the compromised device to the attack target
with or without DOTS server domain administrator consent. If the
attack traffic is blocked, the Call Home DOTS server informs the Call
Home DOTS client that the attack is being mitigated.
If the attack traffic information is identified by the Call Home DOTS
server or the Call Home DOTS server domain administrator as
legitimate traffic, the mitigation request is rejected, and 4.09
(Conflict) is returned to the Call Home DOTS client. The conflict-
clause (defined in Section 4.4.1 of [I-D.ietf-dots-signal-channel])
indicates the cause of the conflict. The following new value is
defined:
4: Mitigation request rejected. This code is returned by the DOTS 4: Mitigation request rejected. This code is returned 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. legitimate traffic.
Once the request is validated by the DOTS server, appropriate actions Once the request is validated by the Call Home DOTS server,
are enforced to block the attack traffic within the source network. appropriate actions are enforced to block the attack traffic within
The DOTS client is informed about the progress of the attack the source network. The Call Home DOTS client is informed about the
mitigation following the rules in [I-D.ietf-dots-signal-channel]. progress of the attack mitigation following the rules in
For example, if the DOTS server is embedded in a CPE, it can program [I-D.ietf-dots-signal-channel]. For example, if the Call Home DOTS
the packet processor to punt all the traffic from the compromised server is embedded in a CPE, it can program the packet processor to
device to the target to slow path. The CPE inspects the punted slow punt all the traffic from the compromised device to the target to
path traffic to detect and block the outgoing DDoS attack traffic or slow path. The CPE inspects the punted slow path traffic to detect
quarantine the device (e.g., using MAC level filtering) until it is and block the outgoing DDoS attack traffic or quarantine the device
remediated, and notifies the CPE administrator about the compromised (e.g., using MAC level filtering) until it is remediated, and
device. notifies the CPE administrator about the compromised device.
The DOTS agents follow the same procedures specified in
[I-D.ietf-dots-signal-channel] for managing a mitigation request.
3.3.2. Address Sharing Considerations 3.3.2. Address Sharing Considerations
If a Carrier Grade NAT (CGN, including NAT64) is located between the If a Carrier Grade NAT (CGN, including NAT64) is located between the
DOTS client domain and DOTS server domain, communicating an external DOTS client domain and DOTS server domain, communicating an external
IP address in a mitigation request is likely to be discarded by the IP address in a mitigation request is likely to be discarded by the
DOTS server because the external IP address is not visible locally to Call Home DOTS server because the external IP address is not visible
the DOTS server (see Figure 7). The DOTS server is only aware of the locally to the Call Home DOTS server (see Figure 9). The Call Home
internal IP addresses/prefixes bound to its domain. Thus, the DOTS DOTS server is only aware of the internal IP addresses/prefixes bound
client MUST NOT include the external IP address and/or port number to its domain. Thus, the Call Home DOTS client MUST NOT include the
identifying the suspect attack source, but MUST include the internal external IP address and/or port number identifying the suspect attack
IP address and/or port number. To that aim, the DOTS client SHOULD source, but MUST include the internal IP address and/or port number.
rely on mechanisms, such as [RFC8512] or [RFC8513], to retrieve the To that aim, the Call Home DOTS client SHOULD rely on mechanisms,
internal IP address and port number which are mapped to an external such as [RFC8512] or [RFC8513], to retrieve the internal IP address
IP address and port number. and port number which are mapped to an external IP address and port
number.
N | .-------------------. N | .-------------------.
E | ( )-. E | ( )-.
T | .' ' T | .' '
W | ( ) 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
V |..............| |...................... V |..............| |......................
I | | | Internal Realm I | | | Internal Realm
D | +---+---+ D | +---+---+
E | | E | |
R | | R | |
--- | --- |
.---------+---------. .---------+---------.
( )-. ( )-.
.' Source Network ' .' Source Network '
( ) ( )
( DOTS server -' ( Call Home -'
'-( ) '-( DOTS server )
'------+------------' '------+------------'
| |
+-----+-------+ +-----+-------+
|Attack Source| |Attack Source|
+-------------+ +-------------+
Figure 7: Example of a CGN between DOTS Domains Figure 9: Example of a CGN between DOTS Domains
If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in the
provider's domain to service its customers, the identification of an provider's domain to service its customers, the identification of an
attack source bound to an IPv4 address/prefix MUST also rely on attack source bound to an IPv4 address/prefix MUST also rely on
source port numbers because the same IPv4 address is assigned to source port numbers because the same IPv4 address is assigned to
multiple customers. The port information is required to multiple customers. The port information is required to
unambiguously identify the source of an attack. unambiguously identify the source of an attack.
If a translator is enabled on the boundaries of the domain hosting If a translator is enabled on the boundaries of the domain hosting
the DOTS server (e.g., a CPE with NAT enabled as shown in Figures 8 the Call Home DOTS server (e.g., a CPE with NAT enabled as shown in
and 9), the DOTS server uses the attack traffic information conveyed Figures 10 and 11), the Call Home DOTS server uses the attack traffic
in a mitigation request to find the internal source IP address of the information conveyed in a mitigation request to find the internal
compromised device and blocks the traffic from the compromised device source IP address of the compromised device and blocks the traffic
traffic to the attack target until the mitigation request is from the compromised device traffic to the attack target until the
withdrawn. Doing so allows to isolate the suspicious device while mitigation request is withdrawn. Doing so allows to isolate the
avoiding to disturb other services. suspicious device while avoiding to disturb other services.
.-------------------. .-------------------.
( )-. ( )-.
.' Network Provider ' .' Network Provider (DMS)'
( (DMS) ) ( )
( DOTS client -' ( Call Home -'
'-( ) '-( DOTS client )
'------+------------' '-------+-----------'
| |
| --- +---+---+
--- +--+----+ S | | CPE | External Realm
S | | CPE | External Realm O |..............| |................
O |..............| |................ U | | NAT | Internal Realm
U | | NAT | Internal Realm R | +---+---+
R | +-------+ C | |
C | | E | .---------+---------.
E | .--------+----------. | ( )-.
| ( )-. N | .' '
N | .' ' E | ( Call Home )
E | ( ) T | ( DOTS server -'
T | ( DOTS server -' W | '-( )
W | '-( ) O | '-------+-----------'
O | '------+------------' R | |
R | | K | +------+------+
K | +-----+-------+ | |Attack Source|
| |Attack Source| +-------------+
+-------------+
Figure 8: Example of a DOTS Server Domain with a NAT Embedded in a Figure 10: Example of a DOTS Server Domain with a NAT Embedded in a
CPE CPE
.-------------------. .-------------------.
( )-. ( )-.
.' Network Provider ' .' Network Provider (DMS) '
( (DMS) ) ( )
( DOTS client -' ( Call Home -'
'-( ) '-( DOTS client )
'---------+---------' '---------+---------'
| |
| --- +-----+-----+
--- +-----+-----+ S | | CPE/NAT | External Realm
S | | CPE/NAT | External Realm O |..............| |................
O |..............| |................ U | | Call Home | Internal Realm
U | |DOTS server| Internal Realm R | |DOTS server|
R | +-----------+ C | +-----+-----+
C | | E | |
E | .--------+----------. | .-----------+-------.
| ( )-. | ( )-.
N | .' ' N | .' '
E | ( Local Area Network ) E | ( Local Area Network )
T | ( -' T | ( -'
W | '-( ) W | '-( )
O | '------+------------' O | '--------+----------'
R | | R | |
K | +-----+-------+ K | +------+------+
| |Attack Source| | |Attack Source|
+-------------+ +-------------+
Figure 9: Example of a DOTS Server and a NAT Embedded in a CPE Figure 11: Example of a Call Home DOTS Server and a NAT Embedded in a
CPE
3.3.3. DOTS Signal Call Home YANG Module 3.3.3. DOTS Signal Call Home YANG Module
3.3.3.1. Tree Structure 3.3.3.1. Tree Structure
This document augments the "dots-signal-channel" DOTS signal YANG This document augments the "ietf-dots-signal-channel" DOTS signal
module defined in [I-D.ietf-dots-signal-channel] for signaling the YANG module defined in [I-D.ietf-dots-signal-channel] for signaling
attack traffic information. This document defines the YANG module the attack traffic information. This document defines the YANG
"ietf-dots-call-home", which has the following tree structure: module "ietf-dots-call-home", which has the following tree structure:
module: ietf-dots-call-home module: ietf-dots-call-home
augment /ietf-signal:dots-signal/ietf-signal:message-type augment /ietf-signal:dots-signal/ietf-signal:message-type
/ietf-signal:mitigation-scope/ietf-signal:scope: /ietf-signal:mitigation-scope/ietf-signal:scope:
+--rw source-prefix* inet:ip-prefix {source-signaling}? +--rw source-prefix* inet:ip-prefix {source-signaling}?
+--rw source-port-range* [lower-port] {source-signaling}? +--rw source-port-range* [lower-port] {source-signaling}?
| +--rw lower-port inet:port-number | +--rw lower-port inet:port-number
| +--rw upper-port? inet:port-number | +--rw upper-port? inet:port-number
+--rw source-icmp-type-range* +--rw source-icmp-type-range*
| [lower-type] {source-signaling}? | [lower-type] {source-signaling}?
skipping to change at page 22, line 31 skipping to change at page 24, line 31
Reference: RFC XXXX Reference: RFC XXXX
The assignment of port number 4647 is strongly suggested (DOTS signal The assignment of port number 4647 is strongly suggested (DOTS signal
channel uses port number 4646). channel uses port number 4646).
4.2. DOTS Signal Channel CBOR Mappings Registry 4.2. DOTS Signal Channel CBOR Mappings Registry
This specification registers the 'source-prefix', 'source-port- This specification registers the 'source-prefix', 'source-port-
range', and 'source-icmp-type-range' parameters in the IANA "DOTS range', and 'source-icmp-type-range' parameters in the IANA "DOTS
Signal Channel CBOR Key Values" registry established by Signal Channel CBOR Key Values" registry established by
[I-D.ietf-dots-signal-channel] (Figure 10). [I-D.ietf-dots-signal-channel] (Figure 12).
The 'source-prefix', 'source-port-range', and 'source-icmp-type- The 'source-prefix', 'source-port-range', and 'source-icmp-type-
range' are comprehension-optional parameters. range' are comprehension-optional parameters.
o Note to the RFC Editor: Please delete (TBD1)-(TBD5) once CBOR keys o Note to the RFC Editor: Please delete (TBD1)-(TBD5) once CBOR keys
are assigned from the 0x8000 - 0xBFFF range. are assigned from the 0x8000 - 0xBFFF range.
+-------------------+------------+--------+---------------+--------+ +-------------------+------------+--------+---------------+--------+
| Parameter Name | YANG | CBOR | CBOR Major | JSON | | Parameter Name | YANG | CBOR | CBOR Major | JSON |
| | Type | Key | Type & | Type | | | Type | Key | Type & | Type |
skipping to change at page 23, line 23 skipping to change at page 25, line 23
| source-port-range | list | 0x8001 | 4 array | Array | | source-port-range | list | 0x8001 | 4 array | Array |
| | | (TBD2) | | | | | | (TBD2) | | |
| source-icmp-type- | list | 0x8002 | 4 array | Array | | source-icmp-type- | list | 0x8002 | 4 array | Array |
| range | | (TBD3) | | | | range | | (TBD3) | | |
| lower-type | uint8 | 0x8003 | 0 unsigned | Number | | lower-type | uint8 | 0x8003 | 0 unsigned | Number |
| | | (TBD4) | | | | | | (TBD4) | | |
| upper-type | uint8 | 0x8004 | 0 unsigned | Number | | upper-type | uint8 | 0x8004 | 0 unsigned | Number |
| | | (TBD5) | | | | | | (TBD5) | | |
+-------------------+------------+--------+---------------+--------+ +-------------------+------------+--------+---------------+--------+
Figure 10: Assigned DOTS Signal Channel CBOR Key Values Figure 12: Assigned DOTS Signal Channel CBOR Key Values
4.3. New DOTS Conflict Cause 4.3. New DOTS Conflict Cause
This document requests IANA to assign a new code from the "DOTS This document requests IANA to assign a new code from the "DOTS
Signal Channel Conflict Cause Codes" registry: Signal Channel Conflict Cause Codes" registry:
+-----+-----------------------------------+-------------+-----------+ +-----+-----------------------------------+-------------+-----------+
| Cod | Label | Description | Reference | | Cod | Label | Description | Reference |
| e | | | | | e | | | |
+-----+-----------------------------------+-------------+-----------+ +-----+-----------------------------------+-------------+-----------+
skipping to change at page 24, line 18 skipping to change at page 26, line 18
subregistry within the "IETF XML Registry" [RFC3688]: subregistry within the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home URI: urn:ietf:params:xml:ns:yang:ietf-dots-call-home
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG module in This document requests IANA to register the following YANG module in
the "YANG Module Names" subregistry [RFC7950] within the "YANG the "YANG Module Names" subregistry [RFC7950] within the "YANG
Parameters" registry: Parameters" registry:
name: ietf-call-home name: ietf-dots-call-home
namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home namespace: urn:ietf:params:xml:ns:yang:ietf-dots-call-home
maintained by IANA: N maintained by IANA: N
prefix: call-home prefix: call-home
reference: RFC XXXX reference: RFC XXXX
5. Security Considerations 5. Security Considerations
This document deviates from classic DOTS signal channel usage by 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. DOTS signal
channel related security considerations discussed in Section 10 of channel related security considerations discussed in Section 10 of
skipping to change at page 24, line 42 skipping to change at page 26, line 42
An attacker may launch a DoS attack on the DOTS client by having it An attacker may launch a DoS attack on the DOTS client by having it
perform computationally expensive operations, before deducing that perform computationally expensive operations, before deducing that
the attacker doesn't possess a valid key. For instance, in TLS 1.3 the attacker doesn't possess a valid key. For instance, in TLS 1.3
[RFC8446], the ServerHello message contains a Key Share value based [RFC8446], the ServerHello message contains a Key Share value based
on an expensive asymmetric key operation for key establishment. on an expensive asymmetric key operation for key establishment.
Common precautions mitigating DoS attacks are recommended, such as Common precautions mitigating DoS attacks are recommended, such as
temporarily blacklisting the source address after a set number of temporarily blacklisting the source address after a set number of
unsuccessful authentication attempts. unsuccessful authentication attempts.
DOTS servers may not blindly trust mitigation requests from DOTS Call Home DOTS servers may not blindly trust mitigation requests from
clients. For example, DOTS servers can use the attack flow Call Home DOTS clients. For example, DOTS servers can use the attack
information in a mitigation request to enable full-fledged packet flow information in a mitigation request to enable full-fledged
inspection function to inspect all the traffic from the compromised packet inspection function to inspect all the traffic from the
device to the target or to re-direct the traffic from the compromised compromised device to the target or to re-direct the traffic from the
device to the target to a DDoS mitigation system to scrub the compromised device to the target to a DDoS mitigation system to scrub
suspicious traffic. DOTS servers can also seek the consent of DOTS the suspicious traffic. Call Home DOTS servers can also seek the
server domain administrator to block the traffic from the compromised consent of DOTS server domain administrator to block the traffic from
device to the target (see Section 3.3.1). the compromised device to the target (see Section 3.3.1).
6. Privacy Considerations 6. Privacy Considerations
The considerations discussed in [RFC6973] were taken into account to The considerations discussed in [RFC6973] were taken into account to
assess whether the DOTS Call Home extension introduces privacy assess whether the DOTS Call Home introduces privacy threats.
threats.
Concretely, the protocol does not leak any new information that can Concretely, the protocol does not leak any new information that can
be used to ease surveillance. In particular, the DOTS server is not be used to ease surveillance. In particular, the Call Home DOTS
required to share information that is local to its network (e.g., server is not required to share information that is local to its
internal identifiers of an attack source) with the DOTS client. network (e.g., internal identifiers of an attack source) with the
Call Home DOTS client.
The DOTS Call Home extension does not preclude the validation of The DOTS Call Home does not preclude the validation of mitigation
mitigation requests received from a DOTS client. For example, a requests received from a Call Home DOTS client. For example, a
security service running on the CPE may require administrator's security service running on the CPE may require administrator's
consent before the CPE acts upon the mitigation request indicated by consent before the CPE acts upon the mitigation request indicated by
the DOTS client. How the consent is obtained is out of scope of this the Call Home DOTS client. How the consent is obtained is out of
document. scope of this document.
Note that a DOTS server can seek for an administrator's consent, Note that a Call Home DOTS server can seek for an administrator's
validate the request by inspecting the traffic, or proceed with both. consent, validate the request by inspecting the traffic, or proceed
with both.
The DOTS Call Home extension is only advisory in nature. Concretely, The DOTS Call Home is only advisory in nature. Concretely, the DOTS
the DOTS Call Home extension does not impose any action to be Call Home does not impose any action to be enforced within the
enforced within the home network; it is up to the DOTS server (and/or network hosting an attack source; it is up to the Call Home DOTS
network administrator) to decide whether and which actions are server (and/or network administrator) to decide whether and which
required. actions are required.
Moreover, the DOTS Call Home extension avoids misattribution by Moreover, the DOTS Call Home avoids misattribution by appropriately
appropriately identifying the network to which a suspect attack identifying the network to which a suspect attack source belongs to
source belongs to (e.g., address sharing issues discussed in (e.g., address sharing issues discussed in Section 3.3.1).
Section 3.3.1).
Triggers to send a DOTS mitigation request to a DOTS server are Triggers to send a DOTS mitigation request to a Call Home DOTS server
deployment-specific. For example, a DOTS client may rely on the are deployment-specific. For example, a Call Home DOTS client may
output of some DDoS detection systems deployed within the DOTS client rely on the output of some DDoS detection systems deployed within the
domain to detect potential outbound DDoS attacks or on abuse claims DOTS client domain to detect potential outbound DDoS attacks or on
received from remote victim networks. Such DDoS detection and abuse claims received from remote victim networks. Such DDoS
mitigation techniques are not meant to track the activity of users, detection and mitigation techniques are not meant to track the
but to protect the Internet and avoid altering the IP reputation of activity of users, but to protect the Internet and avoid altering the
the DOTS client domain. IP reputation of the DOTS client domain.
7. Contributors 7. Contributors
The following individuals have contributed to this document: The following individuals have contributed to this document:
Joshi Harsha Joshi Harsha
McAfee, Inc. McAfee, Inc.
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore, Karnataka 560071 Bangalore, Karnataka 560071
India India
skipping to change at page 27, line 37 skipping to change at page 29, line 37
Open Threat Signaling (DOTS) Server Discovery", draft- Open Threat Signaling (DOTS) Server Discovery", draft-
ietf-dots-server-discovery-04 (work in progress), June ietf-dots-server-discovery-04 (work in progress), June
2019. 2019.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
Open Threat Signaling", draft-ietf-dots-use-cases-18 (work Open Threat Signaling", draft-ietf-dots-use-cases-18 (work
in progress), July 2019. in progress), July 2019.
[I-D.ietf-i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-08 (work in
progress), July 2019.
[I-D.ietf-idr-flow-spec-v6]
McPherson, D., Raszuk, R., Pithawala, B.,
akarch@cisco.com, a., and S. Hares, "Dissemination of Flow
Specification Rules for IPv6", draft-ietf-idr-flow-spec-
v6-09 (work in progress), November 2017.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999,
<https://www.rfc-editor.org/info/rfc2663>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006, DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>. <https://www.rfc-editor.org/info/rfc4340>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <https://www.rfc-editor.org/info/rfc4632>. 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
Denial-of-Service Considerations", RFC 4732, Denial-of-Service Considerations", RFC 4732,
DOI 10.17487/RFC4732, December 2006, DOI 10.17487/RFC4732, December 2006,
<https://www.rfc-editor.org/info/rfc4732>. <https://www.rfc-editor.org/info/rfc4732>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<https://www.rfc-editor.org/info/rfc5575>. <https://www.rfc-editor.org/info/rfc5575>.
[RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and
Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October
2011, <https://www.rfc-editor.org/info/rfc6398>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the Dual- Farrer, "Lightweight 4over6: An Extension to the Dual-
Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
July 2015, <https://www.rfc-editor.org/info/rfc7596>. July 2015, <https://www.rfc-editor.org/info/rfc7596>.
skipping to change at page 29, line 21 skipping to change at page 31, line 40
[RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of
Things (IoT) Security: State of the Art and Challenges", Things (IoT) Security: State of the Art and Challenges",
RFC 8576, DOI 10.17487/RFC8576, April 2019, RFC 8576, DOI 10.17487/RFC8576, April 2019,
<https://www.rfc-editor.org/info/rfc8576>. <https://www.rfc-editor.org/info/rfc8576>.
[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
Threat Signaling (DOTS) Requirements", RFC 8612, Threat Signaling (DOTS) Requirements", RFC 8612,
DOI 10.17487/RFC8612, May 2019, DOI 10.17487/RFC8612, May 2019,
<https://www.rfc-editor.org/info/rfc8612>. <https://www.rfc-editor.org/info/rfc8612>.
Appendix A. Disambiguate Base DOTS Signal vs. Call Home [Sec] UK Department for Digital Culture, Media & Sport, "Secure
by Design: Improving the cyber security of consumer
Internet of Things Report", March 2018,
<https://www.gov.uk/government/publications/
secure-by-design-report>.
Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home
With the DOTS signal channel Call Home, there is a chance that two
DOTS agents can simultaneously establish two DOTS signal channels
with different directions (base DOTS signal channel and DOTS signal
channel Call Home). Here is one example drawn from the home network.
With the call home extension, there is a chance that two DOTS agents
can simultaneously establish two DOTS signal channels with different
directions (base DOTS signal channel and DOTS signal channel 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. networks, but applies to any DOTS Call Home scenario.
In the call home scenario, the DOTS server in, for example, the home In the Call Home scenario, the DOTS server in, for example, the home
network can mitigate the DDoS attacks launched by the compromised network can mitigate the DDoS attacks launched by the compromised
device in its domain by receiving the mitigation request sent by the device in its domain by receiving the mitigation request sent by the
DOTS client in the ISP environment. In addition, the DOTS client in Call Home DOTS client in the ISP environment. In addition, the DOTS
the home network can initiate a mitigation request to the DOTS server client in the home network can initiate a mitigation request to the
in the ISP environment to ask for help when the home network is under DOTS server in the ISP environment to ask for help when the home
a DDoS attack. Such DOTS server and DOTS client in the home network network is under a DDoS attack. Such DOTS server and DOTS client in
can co-locate in the same home network element (e.g., the Customer the home network can co-locate in the same home network element
Premises Equipment). In this case, with the same peer at the same (e.g., the Customer Premises Equipment). In this case, with the same
time the home network element will have the basic DOTS signal channel peer at the same time the home network element will have the base
defined in [I-D.ietf-dots-signal-channel] and the call home DOTS DOTS signal channel and the DOTS signal channel Call Home defined in
signal channel defined in this specification. Thus these two signal this specification. Thus, these two signal channels need to be
channels need to be distinguished when they are both supported. Two distinguished when they are both supported. Two approaches have been
approaches have been considered for distinguishing the two DOTS considered for distinguishing the two DOTS signal channels, but only
signal channels, but only the one that using the dedicated port the one that using the dedicated port number has been chosen as the
number has been chosen as the best choice. best choice.
By using a dedicated port number for each, these two signal channels By using a dedicated port number for each, these two signal channels
can be separated unambiguously and easily. For example, the CPE uses can be separated unambiguously and easily. For example, the CPE uses
the port number 4646 defined in [I-D.ietf-dots-signal-channel] to the port number 4646 allocated in [I-D.ietf-dots-signal-channel] to
initiate the basic signal channel to the ISP when it acts as the DOTS initiate the basic signal channel to the ISP when it acts as the DOTS
client, and uses the port number TBD to initiate the call home signal client, and uses the port number TBD to initiate the signal channel
channel. Based on the different ports, the ISP can directly decide Call Home. Based on the different port numbers, the ISP can directly
which kind of procedures should follow immediately after it receives decide which kind of procedures should follow immediately after it
the DOTS messages. This approach just requires two (D)TLS sessions receives the DOTS messages. This approach just requires two (D)TLS
to be established respectively for the basic signal channel and call sessions to be established respectively for the basic signal channel
home signal channel. and signal channel Call Home.
The other approach is signaling the role of each DOTS agent (e.g., by The other approach is signaling the role of each DOTS agent (e.g., by
using the DOTS data channel). For example, the DOTS agent in the using the DOTS data channel). For example, the DOTS agent in the
home network first initiates a DOTS data channel to the peer DOTS home network first initiates a DOTS data channel to the peer DOTS
agent in the ISP environment, at this time the DOTS agent in the home agent in the ISP environment, at this time the DOTS agent in the home
network is the DOTS client and the peer DOTS agent in the ISP 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 environment is the DOTS server. After that, the DOTS agent in the
home network retrieves the DOTS call home capability of the peer DOTS home network retrieves the DOTS Call Home capability of the peer DOTS
agent. If the peer supports the call home extension, the DOTS agent agent. If the peer supports the DOTS Call Home, the DOTS agent needs
needs to subscribe to the peer to use this extension. Then the to subscribe to the peer to use this extension. Then, the reversal
reversal of DOTS role can be recognized as done by both DOTS agents. of DOTS role can be recognized as done by both DOTS agents. When the
When the DOTS agent in the ISP environment, which now is the DOTS DOTS agent in the ISP environment, which now is the DOTS client,
client, wants to filter the attackers' traffic, it requests the DOTS wants to filter the attackers' traffic, it requests the DOTS agent in
agent in the home network, which now is the DOTS server, for help. the home network, which now is the DOTS server, for help.
Signaling the role will complicate the DOTS protocol, and this Signaling the role will complicate the DOTS protocol, and this
complexity is not required in context where call home extension is complexity is not required in context where the DOTS Call Home is not
not required or only when call home extension is needed. Besides, required or only when the DOTS Call Home is needed. Besides, the
the DOTS data channel may not work during attack time. Even if DOTS data channel may not work during attack time. Even if changing
changing the above example from using the DOTS data channel to the the above example from using the DOTS data channel to the DOTS signal
DOTS signal channel, the more procedures will still reduce the channel, the more procedures will still reduce the efficiency. Using
efficiency. Using the dedicated port number is much easier and more the dedicated port number is much easier and more concise compared to
concise compared to the second approach, and its cost that the second approach, and its cost that establishing two (D)TLS
establishing two (D)TLS sessions is much less. So, using a dedicated sessions is much less. So, using a dedicated port number for the
port number for the call home extension is chosen in this DOTS Call Home is chosen in this specification.
specification.
Authors' Addresses Authors' Addresses
Tirumaleswar Reddy Tirumaleswar Reddy
McAfee, Inc. McAfee, Inc.
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore, Karnataka 560071 Bangalore, Karnataka 560071
India India
Email: kondtir@gmail.com Email: kondtir@gmail.com
 End of changes. 106 change blocks. 
464 lines changed or deleted 603 lines changed or added

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