draft-ietf-dots-signal-call-home-09.txt   draft-ietf-dots-signal-call-home-10.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: March 18, 2021 Orange Expires: April 25, 2021 Orange
J. Shallow J. Shallow
September 14, 2020 October 22, 2020
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-09 draft-ietf-dots-signal-call-home-10
Abstract Abstract
This document specifies the DOTS signal channel Call Home, which This document specifies the DOTS signal channel Call Home, which
enables a DOTS server to initiate a secure connection to a DOTS enables a Call Home DOTS server to initiate a secure connection to a
client, and to receive the attack traffic information from the DOTS Call Home DOTS client, and to receive attack traffic information from
client. The DOTS server in turn uses the attack traffic information the Call Home DOTS client. The Call Home DOTS server in turn uses
to identify the compromised devices launching the outgoing DDoS the attack traffic information to identify compromised devices
attack and takes appropriate mitigation action(s). launching outgoing DDoS attacks and take appropriate mitigation
action(s).
The DOTS signal channel Call Home is not specific to the home The DOTS signal channel Call Home is not specific to home networks;
networks; the solution targets any deployment which requires 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. 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
skipping to change at page 1, line 48 skipping to change at page 2, line 5
o reference: RFC XXXX o reference: RFC XXXX
Please update this statement with the RFC number to be assigned to Please update this statement with the RFC number to be assigned to
the following documents: the following documents:
o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification" (used to be I-D.ietf-dots- (DOTS) Signal Channel Specification" (used to be I-D.ietf-dots-
rfc8782-bis) rfc8782-bis)
Please update TBD statements with the assignment made by IANA to DOTS Please update TBD/TBA statements with the assignments made by IANA to
Signal Channel Call Home. DOTS Signal Channel Call Home.
Also, please update the "revision" date of the YANG module. Also, please update the "revision" date of the YANG module.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 18, 2021. This Internet-Draft will expire on April 25, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 44 skipping to change at page 2, line 47
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 Call Home Solution . . . . . . . . . . . . . . . . . 5 1.2. The Call Home Solution . . . . . . . . . . . . . . . . . 5
1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Co-existence of Base DOTS Signal Channel & DOTS Call Home 8 3. Applicability Scope . . . . . . . . . . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Co-existence of Base DOTS Signal Channel & DOTS Call Home . . 8
3. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 12 5. DOTS Signal Channel Call Home . . . . . . . . . . . . . . . . 12
3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. DOTS Signal Channel Variations . . . . . . . . . . . . . 13 5.2. DOTS Signal Channel Variations . . . . . . . . . . . . . 14
3.2.1. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 13 5.2.1. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 14
3.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 14 5.2.2. Redirected Signaling . . . . . . . . . . . . . . . . 15
3.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 15 5.3. DOTS Signal Channel Extension . . . . . . . . . . . . . . 16
3.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 15 5.3.1. Mitigation Request . . . . . . . . . . . . . . . . . 16
3.3.2. Address Sharing Considerations . . . . . . . . . . . 18 5.3.2. Address Sharing Considerations . . . . . . . . . . . 20
3.3.3. DOTS Signal Call Home YANG Module . . . . . . . . . . 21 6. DOTS Signal Call Home YANG Module . . . . . . . . . . . . . . 23
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 23
4.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 27 6.2. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . 24
4.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 27 6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25
4.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
4.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 29 7.1. DOTS Signal Channel Call Home UDP and TCP Port Number . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7.2. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 30
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 7.3. New DOTS Conflict Cause . . . . . . . . . . . . . . . . . 30
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 7.4. DOTS Signal Call Home YANG Module . . . . . . . . . . . . 31
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33
9.1. Normative References . . . . . . . . . . . . . . . . . . 31 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . 32 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home . . 35 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 12.1. Normative References . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Disambiguating Base DOTS Signal vs. DOTS Call Home . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
1.1. The Problem 1.1. The Problem
The DOTS signal channel protocol [I-D.ietf-dots-rfc8782-bis] is used The DOTS signal channel protocol [I-D.ietf-dots-rfc8782-bis] is used
to carry information about a network resource or a network (or a part to carry information about a network resource or a network (or a part
thereof) that is under a Distributed Denial of Service (DDoS) attack thereof) that is under a Distributed Denial of Service (DDoS) attack
[RFC4732]. Such information is sent by a DOTS client to one or [RFC4732]. Such information is sent by a DOTS client to one or
multiple DOTS servers so that appropriate mitigation actions are multiple DOTS servers so that appropriate mitigation actions are
undertaken on traffic deemed suspicious. Various use cases are undertaken on traffic deemed suspicious. Various use cases are
discussed in [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
in home networks, in particular. With compute and memory becoming prevalent, in particular in home networks. With compute and memory
cheaper and cheaper, various types of IoT devices become available in becoming cheaper and cheaper, various types of IoT devices become
the consumer market at affordable prices. But on the downside, the available in the consumer market at affordable prices. But on the
main threat being most of these IoT devices are bought off-the-shelf downside, there is a corresponding threat since most of these IoT
and most manufacturers haven't considered security in the product devices are bought off-the-shelf and most manufacturers haven't
design (e.g., [Sec]). IoT devices deployed in home networks can be considered security in the product design (e.g., [Sec-by-design]).
easily compromised, they do not have an easy mechanism to upgrade, IoT devices deployed in home networks can be easily compromised, they
and IoT manufactures may cease manufacture and/or discontinue often do not have an easy mechanism to upgrade, and even when
patching vulnerabilities on IoT devices (Sections 5.4 and 5.5 of upgradable, IoT manufacturers may cease manufacture and/or
[RFC8576]). These vulnerable and compromised devices will continue discontinue patching vulnerabilities on IoT devices (Sections 5.4 and
to be used for a long period of time in the home, and the end-user 5.5 of [RFC8576]). These vulnerable and compromised devices will
does not know that IoT devices in his/her home are compromised. The continue to be used for a long period of time in the home, and the
compromised IoT devices are typically used for launching DDoS attacks end-user does not know that IoT devices in his/her home are
(Section 3 of [RFC8576]) on victims while the owner/administrator of compromised. The compromised IoT devices are typically used for
the home network is not aware about such misbehaviors. Similar to launching DDoS attacks (Section 3 of [RFC8576]) on victims while the
other DDoS attacks, the victim in this attack can be an application owner/administrator of the home network is not aware about such
server, a host, a router, a firewall, or an entire network. Such misbehaviors. Similar to other DDoS attacks, the victim in this
misbehaviors will have a collateral damage that affects end users and attack can be an application server, a host, a router, a firewall, or
the reputation of an Internet Service Provider (ISP). an entire network. Such misbehaviors will have both a collateral
damage that affects end users, and can harm the reputation of an
Internet Service Provider (ISP) for being a source of attack traffic.
Nowadays, network devices in a home network offer network security Nowadays, network devices in a home network can offer network
(e.g., firewall [RFC4949] or Intrusion Protection System (IPS) security functions (e.g., firewall [RFC4949] or Intrusion Protection
service [I-D.ietf-i2nsf-terminology] on a home router) to protect the System (IPS) service [I-D.ietf-i2nsf-terminology] on a home router)
devices connected to the home network from both external and internal to protect the devices connected to the home network from both
attacks. Over the years several techniques have been identified to external and internal attacks. It is natural to seek to provide DDoS
detect DDoS attacks, some of these techniques can be enabled on home defense in these devices as well, and over the years several
network devices but most of them are used within the ISP's network. techniques have been identified to detect DDoS attacks; some of these
The ISP offering a DDoS mitigation service can detect outgoing DDoS techniques can be enabled on home network devices but most of them
attack traffic originating from its subscribers or the ISP may are used within the ISP's network. The ISP offering a DDoS
receive filtering rules (e.g., using BGP Flowspec mitigation service can detect outgoing DDoS attack traffic
[RFC5575][I-D.ietf-idr-flow-spec-v6]) from a downstream service originating from its subscribers or the ISP may receive filtering
provider to filter, block, or rate-limit DDoS attack traffic rules (e.g., using BGP Flowspec [RFC5575][I-D.ietf-idr-flow-spec-v6])
originating from the ISP's subscribers to a downstream target. from a downstream service provider to filter, block, or rate-limit
DDoS attack traffic 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) renegotiation 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 that 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. The reader may refer to after the flow is switched to fast path. The reader may refer to
Section 2 of [RFC6398] for a brief definition of slow and fast paths. Section 2 of [RFC6398] for a brief definition of slow and fast paths.
Deep Packet Inspection (DPI) of all the packets of a flow would be 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 detect these type of DDoS attacks is functionally or operationally
not possible for all the devices attached to the home network owing not possible for all the devices attached to the home network owing
to the memory and CPU limitations of the home routers. Furthermore, to the memory and CPU limitations of the home routers. Furthermore,
for certain DDoS attacks the ability to distinguish legitimate for certain DDoS attacks the logic needed to distinguish legitimate
traffic from attack traffic on a per packet basis is complex. This traffic from attack traffic on a per-packet basis is complex. This
complexity is due to that the packet itself may look "legitimate" and complexity is due to the fact that the packet itself may look
no attack signature can be identified. The anomaly can be identified "legitimate" and no attack signature can be identified. The anomaly
only after detailed statistical analysis. can be identified only after detailed statistical analysis.
ISPs can detect some DDoS attacks originating from a home network 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 (e.g., Section 2.6 of [RFC8517]), but the ISP usually does not have a
mechanism to detect which device in the home network is generating mechanism to detect which device in the home network is generating
the DDoS attack traffic. The primary reason being that devices in an the DDoS attack traffic. The primary reason for this is that devices
IPv4 home network are typically behind a Network Address Translation in an IPv4 home network are typically behind a Network Address
(NAT) border [RFC2663]. Even in case of an IPv6 home network, Translation (NAT) border [RFC2663]. Even in case of an IPv6 home
although the ISP can identify the infected device in the home network network, although the ISP can identify the infected device in the
launching the DDoS traffic by tracking its unique IPv6 address, the home network launching the DDoS traffic by tracking its unique IPv6
infected device can easily change its IPv6 address to evade address, the infected device can easily change its IPv6 address to
remediation. evade remediation. A security function on the local home network is
better positioned to track the compromised device across IPv6 address
(and potentially even MAC address) changes and thus ensure that
remediation remains in place across such events.
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 abusive 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 Call Home Solution 1.2. The Call Home Solution
This specification addresses the problems discussed in Section 1.1 This specification addresses the problems discussed in Section 1.1
and presents an extension to the DOTS signal channel: DOTS signal and presents an extension to the DOTS signal channel: DOTS signal
channel Call Home. channel Call Home.
'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers 'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers
to a DOTS signal channel established at the initiative of a DOTS to a DOTS signal channel established at the initiative of a DOTS
server. That is, the DOTS server initiates a secure connection to a server thanks to a role reversal at the (D)TLS layer (Section 5.1).
DOTS client, and uses that connection to receive the attack traffic That is, the DOTS server initiates a secure connection to a DOTS
information (e.g., attack sources) from the DOTS client. More client, and uses that connection to receive the attack traffic
details are provided in Section 3. information (e.g., attack sources) from the DOTS client.
DOTS agents involved in the DOTS Call Home adhere to the DOTS roles DOTS agents involved in the DOTS Call Home otherwise adhere to the
as defined in [RFC8612]. For clarity, this document uses "Call Home DOTS roles as defined in [RFC8612]. For clarity, this document uses
DOTS client" (or "Call Home DOTS server") to refer to a DOTS client "Call Home DOTS client" (or "Call Home DOTS server") to refer to a
(or DOTS server) deployed in a Call Home scenario (Figure 1). DOTS client (or DOTS server) deployed in a Call Home scenario
(Figure 1). DOTS Call Home agents may (or not) be co-located with
DOTS agents that are compliant with [I-D.ietf-dots-rfc8782-bis] (see
Section 4 for more details).
A high-level DOTS Call Home functional architecture is shown in A high-level DOTS Call Home functional architecture is shown in
Figure 1. Attack source(s) are within the DOTS server domain. Figure 1. Attack source(s) are within the DOTS server domain.
Scope Scope
+.-.-.-.-.-.-.-.-.-.-.-.+ +.-.-.-.-.-.-.-.-.-.-.-.+
+---------------+ : +-------------+ : +---------------+ : +-------------+ :
| Alert/DMS/ | ~~~:~~~ | Call Home | : | Alert | ~~~:~~~ | Call Home | :
| Peer DMS/... | : | DOTS client | : | | : | DOTS client | :
+---------------+ : +------+------+ : +---------------+ : +------+------+ :
: | : : | :
: | : : | :
: | : : | :
+---------------+ : +------+------+ : +---------------+ : +------+------+ :
| Attack | ~~~:~~~ | Call Home | : | Attack | ~~~:~~~ | Call Home | :
| Source(s) | : | DOTS server | : | Source(s) | : | DOTS server | :
+---------------+ : +-------------+ : +---------------+ : +-------------+ :
+.-.-.-.-.-.-.-.-.-.-.-.+ +.-.-.-.-.-.-.-.-.-.-.-.+
Figure 1: Basic DOTS Signal Channel Call Home Functional Architecture Figure 1: Basic DOTS Signal Channel Call Home Functional Architecture
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 A Call Home DOTS client relies upon a variety of triggers to make use
source, receiving an alert from an attack target, a peer DDoS 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 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 Call Home DOTS client. available to a Call Home DOTS client.
In a typical deployment scenario, the Call Home DOTS server is 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. recent trends to enrich the CPE with advanced security features.
Unlike classic DOTS deployments [I-D.ietf-dots-use-cases], such DOTS Unlike classic DOTS deployments [I-D.ietf-dots-use-cases], such DOTS
server maintains a single DOTS signal channel session for each DOTS- server maintains a single DOTS signal channel session for each DOTS-
skipping to change at page 6, line 44 skipping to change at page 7, line 15
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 Call Home DOTS servers are provisioned This document assumes that Call Home DOTS servers are provisioned
with a way to know how to reach the upstream Call Home DOTS 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., client(s), which could occur by a variety of means (e.g.,
[I-D.ietf-dots-server-discovery]). The specification of such means [I-D.ietf-dots-server-discovery]). The specification of such means
are out of scope of this document. are out of scope of this document.
More information about the applicability scope of the DOTS signal More information about the applicability scope of the DOTS signal
channel Call Home is provided in Section 1.3. channel Call Home is provided in Section 3.
1.3. Applicability Scope 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
The reader should be familiar with the terms defined in Section 1.2
of [RFC8612].
DDoS Mitigation System (DMS) refers to a system that performs DDoS
mitigation.
'Base DOTS signal channel' refers to [I-D.ietf-dots-rfc8782-bis].
The meaning of the symbols in YANG tree diagrams are defined in
[RFC8340] and [RFC8791].
(D)TLS is used for statements that apply to both Transport Layer
Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS)
[RFC6347]. Specific terms are used for any statement that applies to
either protocol alone.
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. source(s) of the attack.
An instantiation of the Call Home functional architecture is depicted An instantiation of the Call Home functional architecture is depicted
in Figure 2. in Figure 2.
skipping to change at page 8, line 5 skipping to change at page 8, line 43
| || | ||
+-----+-++----+ +-----+-++----+
|Attack Source| |Attack Source|
+-------------+ +-------------+
Figure 2: DOTS Signal Channel 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 4. Co-existence of Base DOTS Signal Channel & DOTS Call Home
The DOTS signal channel Call Home does not require nor preclude the The DOTS signal channel Call Home does not require nor preclude the
activation of the base DOTS signal channel activation of the base DOTS signal channel
[I-D.ietf-dots-rfc8782-bis]. Some sample deployment schemes are [I-D.ietf-dots-rfc8782-bis]. 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 signal channel Call Home may be enabled as shown in channel and DOTS signal channel Call Home may be enabled as shown in
Figure 3 (Same DMS provider) or Figure 4 (Distinct DMS providers). Figure 3 (Same DMS provider) or Figure 4 (Distinct DMS providers).
skipping to change at page 11, line 36 skipping to change at page 12, line 36
: +----------------------+ : : +----------------------+ :
+-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+ +-.-.-.-.-.-.-.-.-.-++-.-.-.-.-.-.-.-.-.-+
Network #D Network #D
Figure 6: Another Example where the Same Node Embeds both a DOTS Figure 6: Another Example where the Same Node Embeds both a DOTS
Client and a Call Home DOTS Server 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 5. DOTS Signal Channel Call Home
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
The reader should be familiar with the terms defined in [RFC8612].
'Base DOTS signal channel' refers to [I-D.ietf-dots-rfc8782-bis].
The meaning of the symbols in YANG tree diagrams are defined in
[RFC8340] and [RFC8791].
(D)TLS is used for statements that apply to both Transport Layer
Security (TLS) [RFC8446] and Datagram Transport Layer Security (DTLS)
[RFC6347]. Specific terms are used for any statement that applies to
either protocol alone.
3. DOTS Signal Channel Call Home
3.1. Procedure 5.1. Procedure
The DOTS signal channel Call Home preserves all but one of the DOTS 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 DOTS
client-initiated DOTS signal channel protocol client-initiated DOTS signal channel protocol
[I-D.ietf-dots-rfc8782-bis]. The role reversal that occurs is at the [I-D.ietf-dots-rfc8782-bis]. The role reversal that occurs is at the
(D)TLS layer; that is, (1) the Call Home DOTS server acts as a DTLS (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 server or (2) the client and the Call Home DOTS client acts as a DTLS server or (2) the
Call Home DOTS server acts as a TLS client initiating the underlying Call Home DOTS server acts as a TLS client initiating the underlying
TCP connection and the Call Home DOTS client acts as a TLS server. TCP connection and the Call Home DOTS client acts as a TLS server.
The Call Home DOTS server initiates (D)TLS handshake to the Call Home The Call Home DOTS server initiates (D)TLS handshake to the Call Home
DOTS client. 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 Call Home DOTS server is the (D)TLS server. However, when with a Call Home DOTS server is the (D)TLS client. That is, the Call
calling home, the DOTS server initially assumes the role of the Home DOTS server assumes the role of the (D)TLS client, but the
(D)TLS client, but the network element's role as a DOTS server network element's role as a DOTS server remains the same.
remains the same. Furthermore, existing certificate chains and
mutual authentication mechanisms between the DOTS agents are Existing certificate chains and mutual authentication mechanisms
unaffected by the Call Home function. This Call Home function between the DOTS agents are unaffected by the Call Home function.
enables the DOTS server co-located with a network element (possibly From a deployment standpoint, and given the scale of Call Home DOTS
behind NATs and firewalls) reachable by only the intended Call Home servers that may be involved, enabling means for automating the
DOTS client and hence the Call Home DOTS server cannot be subjected provisioning of credentials on Call Home DOTS servers to authenticate
to these DDoS attacks. to the Call Home DOTS client are encouraged. It is out of the scope
of this document to elaborate on these means.
Figure 7 illustrates a sample DOTS Call Home flow exchange: Figure 7 illustrates a sample DOTS Call Home flow exchange:
+-----------+ +-----------+ +-----------+ +-----------+
| 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
| | | |
skipping to change at page 13, line 21 skipping to change at page 13, line 51
TCP connection to the Call Home DOTS client. Once connected, the TCP connection to the Call Home DOTS client. Once connected, the
Call Home DOTS server continues to initiate a TLS connection to Call Home DOTS server continues to initiate a TLS connection to
the Call Home DOTS client. the Call Home DOTS client.
In some cases, peer DOTS agents may have mutual agreement to use In some cases, 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 [I-D.ietf-dots-server-discovery]. Absent such dynamic discovery [I-D.ietf-dots-server-discovery]. Absent such
mutual agreement, the DOTS signal channel Call Home MUST run over mutual agreement, the DOTS signal channel Call Home MUST run over
port number TBD (that is, Call Home 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 7.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-rfc8782-bis] is used for initiating (D)TLS [I-D.ietf-dots-rfc8782-bis] is used for initiating (D)TLS
connections. connections.
2. Using this (D)TLS connection, the Call Home DOTS client may 2. 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 The Call Home DOTS client supplies the source information by
means of new attributes defined in Section 3.3.1. means of new attributes defined in Section 5.3.1.
The Heartbeat mechanism used for the DOTS Call Home deviates from The Heartbeat mechanism used for the DOTS Call Home deviates from
the one defined in Section 4.7 of [I-D.ietf-dots-rfc8782-bis]. the one defined in Section 4.7 of [I-D.ietf-dots-rfc8782-bis].
Section 3.2.1 specifies the behavior to be followed by Call Home Section 5.2.1 specifies the behavior to be followed by Call Home
DOTS agents. DOTS agents.
3.2. DOTS Signal Channel Variations 5.2. DOTS Signal Channel Variations
3.2.1. Heartbeat Mechanism 5.2.1. Heartbeat Mechanism
Once the (D)TLS section is established between the DOTS agents, the Once the (D)TLS section is established between the DOTS agents, the
Call Home DOTS client contacts the Call Home DOTS server to retrieve Call Home DOTS client contacts the Call Home DOTS server to retrieve
the session configuration parameters (Section 4.5 of the session configuration parameters (Section 4.5 of
[I-D.ietf-dots-rfc8782-bis]). The Call Home DOTS server adjusts the [I-D.ietf-dots-rfc8782-bis]). The Call Home DOTS server adjusts the
'heartbeat-interval' to accommodate binding timers used by on-path 'heartbeat-interval' to accommodate binding timers used by on-path
NATs and firewalls. Heartbeats will be then exchanged by the DOTS NATs and firewalls. Heartbeats will be then exchanged by the DOTS
agents following the instructions retrieved using the signal channel agents following the instructions retrieved using the signal channel
session configuration exchange. session configuration exchange.
skipping to change at page 14, line 26 skipping to change at page 15, line 9
If the Call Home DOTS server receives traffic from the Call Home DOTS 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 client, the Call Home DOTS server MUST continue to use the DOTS
signal channel even if the missing heartbeats allowed threshold signal channel even if the missing heartbeats allowed threshold
('missing-hb-allowed') is reached. ('missing-hb-allowed') is reached.
If the Call Home DOTS server does not receive any traffic from the If the Call Home DOTS server does not receive any traffic from the
peer Call Home DOTS client during the time span required to exhaust peer Call Home DOTS client during the time span required to exhaust
the maximum 'missing-hb-allowed' threshold, the Call Home DOTS server the maximum 'missing-hb-allowed' threshold, the Call Home DOTS server
concludes the session is disconnected. Then, the Call Home DOTS concludes the session is disconnected. Then, the Call Home DOTS
server MUST try to resume the (D)TLS session. server MUST try to establish a new DOTS signal channel session,
preferably by resuming the (D)TLS session.
3.2.2. Redirected Signaling 5.2.2. Redirected Signaling
A Call Home DOTS server MUST NOT support the Redirected Signaling A Call Home DOTS server MUST NOT support the Redirected Signaling
mechanism as specified in Section 4.6 of [I-D.ietf-dots-rfc8782-bis] mechanism as specified in Section 4.6 of [I-D.ietf-dots-rfc8782-bis]
(i.e., a 5.03 response that conveys an alternate DOTS server's FQDN (i.e., a 5.03 response that conveys an alternate DOTS server's FQDN
or alternate DOTS server's IP address(es)). A Call Home DOTS client 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 MUST silently discard such message as only a Call Home DOTS server
can initiate a new (D)TLS connection. can initiate a new (D)TLS connection.
If a Call Home DOTS client wants to redirect a Call Home DOTS server If a Call Home DOTS client wants to redirect a Call Home DOTS server
to another Call Home DOTS client, it MUST send a Non-confirmable PUT to another Call Home DOTS client, it MUST send a Non-confirmable PUT
request to the predefined resource ".well-known/dots/redirect" with request to the predefined resource ".well-known/dots/redirect" with
the new Call Home DOTS client FQDN or IP address in the body of the the following attributes in the body of the PUT request:
PUT similar to what is described in Section 4.6 of
[I-D.ietf-dots-rfc8782-bis]. Furthermore, a new clause called 'ttl" alt-ch-client: The FQDN of an alternate Call Home DOTS client.
is defined to return the Time to live (TTL) of the alternate Call
Home DOTS client. This is a mandatory attribute for DOTS signal Call Home. It MUST
NOT be used for base DOTS signal channel operations.
alt-ch-client-record: 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 addresses of the
alternate Call Home DOTS client.
This is an optional attribute for DOTS signal Call Home. It MUST
NOT be used for base DOTS signal channel operations.
ttl: The Time to live (TTL) of the alternate Call Home DOTS client.
That is, the time interval that the alternate Call Home DOTS
client may be cached for use by a Call Home DOTS server.
This is an optional attribute for DOTS signal Call Home. It MUST
NOT be used for base DOTS signal channel operations.
On receipt of this PUT request, the Call Home DOTS server responds On receipt of this PUT request, the Call Home DOTS server responds
with a 2.01 (Created), closes this connection and establishes a with a 2.01 (Created), closes this connection and establishes a
connection with the new Call Home DOTS client. The processing of the connection with the new Call Home DOTS client. The processing of the
TTL is defined in Section 4.6 of [I-D.ietf-dots-rfc8782-bis]. If the TTL is defined in Section 4.6 of [I-D.ietf-dots-rfc8782-bis]. If the
Call Home DOTS server cannot service the PUT request, the response is Call Home DOTS server cannot service the PUT request, the response is
rejected with a 4.00 (bad Request). rejected with a 4.00 (Bad Request).
Figure 8 shows a PUT request example to convey the alternate Call Figure 8 shows a PUT request example to convey the alternate Call
Home DOTS client 'alt-call-home-client.example' together with its IP Home DOTS client 'alt-call-home-client.example' together with its IP
addresses 2001:db8:6401::1 and 2001:db8:6401::2. The validity of addresses 2001:db8:6401::1 and 2001:db8:6401::2. The validity of
this alternate Call Home DOTS client is 10 minutes. this alternate Call Home DOTS client is 10 minutes.
Header: PUT (Code=0.03) 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"
skipping to change at page 15, line 31 skipping to change at page 16, line 31
"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
} }
Figure 8: Example of a PUT Request for Redirected Signaling Figure 8: Example of a PUT Request for Redirected Signaling
3.3. DOTS Signal Channel Extension 5.3. DOTS Signal Channel Extension
3.3.1. Mitigation Request 5.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-rfc8782-bis] to convey the attack Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis] to convey the attack
source information (e.g., source prefixes, source port numbers). The source information (e.g., source prefixes, source port numbers). The
DOTS client conveys the following new parameters in the CBOR body of DOTS client conveys the following new parameters in the CBOR body of
the mitigation request: the mitigation request:
source-prefix: A list of attacker prefixes used to attack the source-prefix: A list of attacker IP 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 BCP 122 [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 Call Home DOTS client MUST validate that attacker
within the scope of the DOTS server domain. prefixes are within the scope of 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 contacting
Call Home DOTS servers that are not entitled to enforce actions on
specific prefixes.
This is an optional attribute for the base DOTS signal channel This is an optional attribute for the base DOTS signal channel
operations. 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.
skipping to change at page 16, line 27 skipping to change at page 17, line 30
[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. 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. Both ICMP [RFC0792] and ICMPv6 [RFC4443] types are
supported. Whether ICMP or ICMPv6 types are to be used is
determined by the address family of the 'target-prefix'.
This is an optional attribute for the base DOTS signal channel This is an optional attribute for the base DOTS signal channel
operations. 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 Call Home DOTS client attack traffic information is signaled by a Call Home DOTS client
(i.e., the Call Home scenario depicted in Figure 7). The 'target- (i.e., the Call Home scenario depicted in Figure 7). 'target-prefix'
uri' or 'target-fqdn' parameters can be included in a mitigation attribute MUST be included in the mitigation request signaling the
request for diagnostic purposes to notify the Call Home DOTS server attack information to a Call Home DOTS server. The 'target-uri' or
domain administrator, but SHOULD NOT be used to determine the target 'target-fqdn' parameters can be included in a mitigation request for
IP addresses. Note that 'target-prefix' becomes a mandatory diagnostic purposes to notify the Call Home DOTS server domain
attribute in the mitigation request signaling the attack information administrator, but SHOULD NOT be used to determine the target IP
because 'target-uri' and 'target-fqdn' are optional attributes and addresses. 'alias-name' is unlikely to be conveyed in a Call Home
'alias-name' will not be conveyed in a mitigation request. mitigation 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 a CPE) to maintain aliases.
In order to help attack source identification by a Call Home DOTS 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 SHOULD include in its mitigation
request additional information such as 'source-port-range' or request additional information such as 'source-port-range' or
'source-icmp-type-range'. The Call Home DOTS client may not include 'source-icmp-type-range' to disambiguate nodes sharing the same
such information if 'source-prefix' conveys an IPv6 address/prefix. 'source-prefix'. IPv6 addresses/prefixes are sufficient to uniquely
Address sharing implications on the setting of source information identify a network endpoint, without need for port numbers or ICMP
('source-prefix', 'source-port-range') are discussed in type information. While this is also possible for IPv4, it is much
Section 3.3.2. less often the case than for IPv6. More address sharing implications
on the setting of source information ('source-prefix', 'source-port-
range') are discussed in Section 5.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; Call Home DOTS clients MUST NOT send requests 'true') are allowed; Call Home DOTS clients MUST NOT send requests
with 'trigger-mitigation' set to 'false'. Such requests MUST be with 'trigger-mitigation' set to 'false'. Such requests MUST be
discarded by the Call Home DOTS server with a 4.00 (Bad Request). discarded by the Call Home DOTS server with a 4.00 (Bad Request).
An example of a mitigation request sent by a Call Home DOTS client is An example of a mitigation request sent by a Call Home DOTS client is
shown in Figure 9. shown in Figure 9.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
skipping to change at page 18, line 9 skipping to change at page 19, line 16
[I-D.ietf-dots-rfc8782-bis]. [I-D.ietf-dots-rfc8782-bis].
Note: These validation checks do not apply when the source Note: These validation checks do not apply when the source
information is included as a hint in the context of the base DOTS information is included as a hint in the context of the base DOTS
signal channel. signal channel.
The Call Home DOTS server domain administrator consent MAY be The Call Home DOTS server domain administrator consent MAY 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 MAY have a configuration 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. If the with or without DOTS server domain administrator consent.
attack traffic is blocked, the Call Home DOTS server informs the Call
Home DOTS client that the attack is being mitigated. If a consent from the Call Home DOTS server domain administrator is
required, the Call Home DOTS server replies with 2.01 (Created) and
'status' code set to 1 (attack-mitigation-in-progress). Then, the
mechanisms defined in Section 4.4.2 of [I-D.ietf-dots-rfc8782-bis]
are followed by the DOTS agents to update the mitigation status.
Particularly, if the attack 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 'status' code to 2 (attack-
successfully-mitigated)).
If the Call Home DOTS server rejects the mitigation request without
waiting for a consent from the Call Home DOTS server domain
administrator, the 'conflict-cause' set to '4' is returned in 4.09
(Conflict) sent back to the Call Home DOTS client.
If the attack traffic information is identified by the Call Home DOTS If the attack traffic information is identified by the Call Home DOTS
server or the Call Home DOTS server domain administrator as server or the Call Home DOTS server domain administrator as
legitimate traffic, the mitigation request is rejected, and 4.09 legitimate traffic, the mitigation request is rejected with a 4.09
(Conflict) is returned to the Call Home DOTS client. The conflict- (Conflict) or a notification message with the 'conflict-clause'
clause (defined in Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis]) (Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis]) set to the following
indicates the cause of the conflict. The following new value is new value:
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 Call Home DOTS server, 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. The Call Home DOTS client is informed about the the source network. For example, if the Call Home DOTS server is
progress of the attack mitigation following the rules in embedded in a CPE, it can program the packet processor to punt all
[I-D.ietf-dots-rfc8782-bis]. For example, if the Call Home DOTS the traffic from the compromised device to the target to slow path.
server is embedded in a CPE, it can program the packet processor to The CPE inspects the punted slow path traffic to detect and block the
punt all the traffic from the compromised device to the target to outgoing DDoS attack traffic or quarantine the device (e.g., using
slow path. The CPE inspects the punted slow path traffic to detect MAC level filtering) until it is remediated, and notifies the CPE
and block the outgoing DDoS attack traffic or quarantine the device administrator about the compromised device. Note that the Call Home
(e.g., using MAC level filtering) until it is remediated, and DOTS client is informed about the progress of the attack mitigation
notifies the CPE administrator about the compromised device. following the rules in Section 4.4.2 of [I-D.ietf-dots-rfc8782-bis].
The DOTS agents follow the same procedures specified in The DOTS agents follow the same procedures specified in
[I-D.ietf-dots-rfc8782-bis] for managing a mitigation request. [I-D.ietf-dots-rfc8782-bis] for managing a mitigation request.
3.3.2. Address Sharing Considerations 5.3.2. Address Sharing Considerations
If a Carrier Grade NAT (CGN, including NAT64) is located between the Figure 10 depictes an example of a network provider that hosts a Call
DOTS client domain and DOTS server domain, communicating an external Home DOTS client and deploys a Carrier Grade NAT (CGN) between the
IP address in a mitigation request is likely to be discarded by the DOTS client domain and DOTS server domain. In such case,
Call Home DOTS server because the external IP address is not visible communicating an external IP address in a mitigation request by a
locally to the Call Home DOTS server (see Figure 10). The Call Home Call Home DOTS client is likely to be discarded by the Call Home DOTS
DOTS server is only aware of the internal IP addresses/prefixes bound server because the external IP address is not visible locally to the
to its domain. Thus, the Call Home DOTS client MUST NOT include the Call Home DOTS server (Figure 10). The Call Home DOTS server is only
external IP address and/or port number identifying the suspect attack aware of the internal IP addresses/prefixes bound to its domain
source, but MUST include the internal IP address and/or port number. (i.e., those used in the Internal Realm shown in Figure 10). Thus,
To that aim, the Call Home DOTS client SHOULD rely on mechanisms, Call Home DOTS clients that are aware of the presence of on-path CGNs
such as [RFC8512] or [RFC8513], to retrieve the internal IP address MUST NOT include the external IP address and/or port number
and port number which are mapped to an external IP address and port identifying the suspect attack source (i.e., those used in the
number. External Realm shown in Figure 10), but MUST include the internal IP
address and/or port number. To that aim, the Call Home DOTS client
SHOULD rely on mechanisms, such as [RFC8512] or [RFC8513], to
retrieve the internal IP address and port number which are mapped to
an external IP address and port number. For the particular case of
NAT64 [RFC6146], if the target address is an IPv4 address, the
IPv4-converted IPv6 address of this target address [RFC6052] SHOULD
be used.
N | .-------------------. N | .-------------------.
E | ( )-. E | ( )-.
T | .' ' T | .' '
W | ( Call Home ) W | ( Call Home )
O | ( DOTS client -' O | ( DOTS client -'
R | '-( ) R | '-( )
K | '-------+-----------' K | '-------+-----------'
| | | |
P | | P | |
skipping to change at page 20, line 4 skipping to change at page 21, line 49
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 Call Home DOTS server (e.g., a CPE with NAT enabled as shown in the Call Home DOTS server (e.g., a CPE with NAT enabled as shown in
Figures 11 and 12), the Call Home DOTS server uses the attack traffic Figures 11 and 12), the Call Home DOTS server uses the attack traffic
information conveyed in a mitigation request to find the internal information conveyed in a mitigation request to find the internal
source IP address of the compromised device and blocks the traffic source IP address of the compromised device and blocks the traffic
from the compromised device traffic to the attack target until the from the compromised device traffic to the attack target until the
mitigation request is withdrawn. Doing so allows to isolate the mitigation request is withdrawn. The Call Home DOTS server proceeds
suspicious device while avoiding to disturb other services. with a NAT mapping table lookup using the attack information (or a
subset thereof) as a key. The lookup can be local (Figure 11) or via
a dedicated administration interface that is offered by the CPE
(Figure 12). This identification allows the suspicious device to be
isolated while avoiding disturbances of other services.
.-------------------. .-------------------.
( )-. ( )-.
.' Network Provider (DMS)' .' Network Provider (DMS)'
( ) ( )
( Call Home -' ( Call Home -'
'-( DOTS client ) '-( DOTS client )
'-------+-----------' '-------+-----------'
| |
--- +---+---+ --- +---+---+
skipping to change at page 21, line 35 skipping to change at page 23, line 35
W | '-( ) W | '-( )
O | '--------+----------' O | '--------+----------'
R | | R | |
K | +------+------+ K | +------+------+
| |Attack Source| | |Attack Source|
+-------------+ +-------------+
Figure 12: Example of a Call Home DOTS Server and a NAT Embedded in a Figure 12: Example of a Call Home DOTS Server and a NAT Embedded in a
CPE CPE
3.3.3. DOTS Signal Call Home YANG Module If for any reason address sharing is deployed in both source and
provider networks, both Call Home DOTS agents have to proceed with
address mapping lookups following the behavior specified in reference
to Figure 10 (network provider) and Figures 11 and 12 (source
network).
3.3.3.1. Tree Structure 6. DOTS Signal Call Home YANG Module
This document augments the "ietf-dots-signal-channel" DOTS signal 6.1. Tree Structure
YANG module defined in [I-D.ietf-dots-rfc8782-bis] for signaling the
attack traffic information. This document defines the YANG module This document augments the "ietf-dots-signal-channel" (dots-signal)
"ietf-dots-call-home", which has the following tree structure: DOTS signal YANG module defined in [I-D.ietf-dots-rfc8782-bis] for
signaling the attack traffic information. This document defines the
YANG module "ietf-dots-call-home", which has the following tree
structure:
module: ietf-dots-call-home module: ietf-dots-call-home
augment-structure /signal:dots-signal/signal:message-type augment-structure /dots-signal:dots-signal/dots-signal:message-type
/signal:mitigation-scope/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 /signal:dots-signal/signal:message-type augment-structure /dots-signal:dots-signal/dots-signal:message-type
/signal:redirected-signal: /dots-signal:redirected-signal:
+-- (type)? +-- (type)?
+--:(call-home-only) +--:(call-home-only)
+-- alt-ch-client? string +-- alt-ch-client string
+-- alt-ch-client-record* inet:ip-address +-- alt-ch-client-record* inet:ip-address
+-- ttl? uint32 +-- ttl? uint32
3.3.3.2. YANG/JSON Mapping Parameters to CBOR 6.2. YANG/JSON Mapping Parameters to CBOR
The YANG/JSON mapping parameters to CBOR are listed in Table 1. The YANG/JSON mapping parameters to CBOR are listed in Table 1.
o Note: Implementers must check that the mapping output provided by
their YANG-to-CBOR encoding schemes is aligned with the content of
Table 1.
+--------------------+------------+------+---------------+--------+ +--------------------+------------+------+---------------+--------+
| Parameter Name | YANG | CBOR | CBOR Major | JSON | | Parameter Name | YANG | CBOR | CBOR Major | JSON |
| | Type | Key | Type & | Type | | | Type | Key | Type & | Type |
| | | | Information | | | | | | Information | |
+====================+============+======+===============+========+ +====================+============+======+===============+========+
|ietf-dots-call-home:| leaf-list | | | | |ietf-dots-call-home:| leaf-list | | | |
| source-prefix | inet: | TBA1 | 4 array | Array | | source-prefix | inet: | TBA1 | 4 array | Array |
| | ip-prefix | | 3 text string | String | | | ip-prefix | | 3 text string | String |
+--------------------+------------+------+---------------+--------+ +--------------------+------------+------+---------------+--------+
|ietf-dots-call-home:| | | | | |ietf-dots-call-home:| | | | |
skipping to change at page 23, line 38 skipping to change at page 25, line 38
|ietf-dots-call-home:| leaf-list | TBA7 | 4 array | Array | |ietf-dots-call-home:| leaf-list | TBA7 | 4 array | Array |
| alt-ch-client- | inet: | | | | | alt-ch-client- | inet: | | | |
| record | ip-address| | 3 text string | String | | record | ip-address| | 3 text string | String |
+--------------------+------------+------+---------------+--------+ +--------------------+------------+------+---------------+--------+
|ietf-dots-call-home:| | | | | |ietf-dots-call-home:| | | | |
| ttl | uint32 | TBA8 | 0 unsigned | Number | | ttl | uint32 | TBA8 | 0 unsigned | Number |
+--------------------+------------+------+---------------+--------+ +--------------------+------------+------+---------------+--------+
Table 1: YANG/JSON Mapping Parameters to CBOR Table 1: YANG/JSON Mapping Parameters to CBOR
3.3.3.3. YANG Module The YANG/JSON mappings to CBOR for 'lower-port' and 'upper-port' are
already defined in Table 5 of [I-D.ietf-dots-rfc8782-bis].
6.3. YANG Module
This module uses the common YANG types defined in [RFC6991] and the This module uses the common YANG types defined in [RFC6991] and the
data structure defined in [RFC8791]. data structure extension defined in [RFC8791].
<CODE BEGINS> file "ietf-dots-call-home@2020-07-07.yang" <CODE BEGINS> file "ietf-dots-call-home@2020-10-15.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 signal; prefix dots-signal;
reference reference
"RFC YYYY: Distributed Denial-of-Service Open Threat "RFC YYYY: 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";
} }
skipping to change at page 24, line 50 skipping to change at page 27, line 5
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 XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2020-07-07 { revision 2020-10-15 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Distributed Denial-of-Service Open Threat "RFC XXXX: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Call Home"; Signaling (DOTS) Signal Channel Call Home";
} }
sx:augment-structure "/signal:dots-signal/signal:message-type/" sx:augment-structure "/dots-signal:dots-signal"
+ "signal:mitigation-scope/signal:scope" { + "/dots-signal:message-type"
+ "/dots-signal:mitigation-scope"
+ "/dots-signal:scope" {
description description
"Attacker source details."; "Attack source details.";
leaf-list source-prefix { leaf-list source-prefix {
type inet:ip-prefix; type inet:ip-prefix;
description description
"IPv4 or IPv6 prefix identifying the attacker(s)."; "IPv4 or IPv6 prefix identifying the attack source(s).";
} }
list source-port-range { list source-port-range {
key "lower-port"; key "lower-port";
description description
"Port range. When only lower-port is "Port range. When only lower-port is
present, it represents a single port number."; present, it represents a single port number.";
leaf lower-port { leaf lower-port {
type inet:port-number; type inet:port-number;
mandatory true; mandatory true;
description description
skipping to change at page 25, line 43 skipping to change at page 27, line 48
"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 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 type range. When only lower-type is "ICMP/ICMPv6 type range. When only lower-type is
present, it represents a single ICMP type."; present, it represents a single ICMP/ICMPv6 type.
The address family of the target-prefix is used
to determine whether ICMP or ICMPv6 are used.";
leaf lower-type { leaf lower-type {
type uint8; type uint8;
mandatory true; mandatory true;
description description
"Lower ICMP type of the ICMP type range."; "Lower ICMP/ICMPv6 type of the ICMP type range.";
reference
"RFC 792: Internet Control Message Protocol
RFC 4443: Internet Control Message Protocol (ICMPv6)
for Internet Protocol Version 6 (IPv6)
Specification.";
} }
leaf upper-type { leaf upper-type {
type uint8; type uint8;
must '. >= ../lower-type' { must '. >= ../lower-type' {
error-message error-message
"The upper ICMP type must be greater than "The upper ICMP/ICMPv6 type must be greater than
or equal to lower ICMP type."; or equal to lower ICMP type.";
} }
description description
"Upper type of the ICMP type range."; "Upper type of the ICMP type range.";
reference
"RFC 792: Internet Control Message Protocol
RFC 4443: Internet Control Message Protocol (ICMPv6)
for Internet Protocol Version 6 (IPv6)
Specification.";
} }
} }
} }
sx:augment-structure "/signal:dots-signal/signal:message-type/" sx:augment-structure "/dots-signal:dots-signal"
+ "signal:redirected-signal" { + "/dots-signal:message-type"
+ "/dots-signal:redirected-signal" {
description description
"The alternate Call Home DOTS client."; "Augments the redirected signal to communicate an
alternate Call Home DOTS client.";
choice type { choice type {
description description
"Indicates the type of the DOTS session."; "Indicates the type of the DOTS session (e.g., base
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 call home signal
channel message from the Call Home DOTS client channel message from a Call Home DOTS client
to the Call Home DOTS server."; to a Call Home DOTS server.";
leaf alt-ch-client { leaf alt-ch-client {
type string; type string;
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
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 records for the alternate Call Home "List of IP addresses for the alternate Call
DOTS client."; Home DOTS client.
If this data node is not present, a Call Home
DOTS server resolves the alt-ch-client into
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
"Section 4.6 of RFC YYYY";
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
4. IANA Considerations 7. IANA Considerations
4.1. DOTS Signal Channel Call Home UDP and TCP Port Number 7.1. DOTS Signal Channel Call Home UDP and TCP Port Number
IANA is requested to assign the port number TBD to the DOTS signal IANA is requested to assign the port number TBD to the DOTS signal
channel Call Home protocol for both UDP and TCP from the "Service channel Call Home protocol for both UDP and TCP from the "Service
Name and Transport Protocol Port Number Registry" [ServicePorts]. Name and Transport Protocol Port Number Registry" [ServicePorts].
Service Name: dots-call-home Service Name: dots-call-home
Port Number: TBD Port Number: TBD
Transport Protocol(s): TCP/UDP Transport Protocol(s): TCP/UDP
Description: DOTS Signal Channel Call Home Description: DOTS Signal Channel Call Home Protocol.
The service name is used to construct the
SRV service names "_dots-call-home._udp"
and "_dots-call-home._tcp" for discovering
Call Home DOTS clients used to establish
DOTS signal channel call home.
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org> Contact: IETF Chair <chair@ietf.org>
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 7.2. DOTS Signal Channel CBOR Mappings Registry
This specification registers the following comprehension-optional This specification registers the following comprehension-optional
parameters (Table 2) in the IANA "DOTS Signal Channel CBOR Key parameters (Table 2) in the IANA "DOTS Signal Channel CBOR Key
Values" registry [Key-Map]. Values" registry [Key-Map].
o Note to the RFC Editor: Please delete TBA1-TBA8 once CBOR keys are o Note to the RFC Editor: Please delete TBA1-TBA8 once CBOR keys are
assigned from the 32768-49151 range. assigned from the 32768-49151 range.
+--------------------+-------+-------+------------+---------------+ +--------------------+-------+-------+------------+---------------+
| Parameter Name | CBOR | CBOR | Change | Specification | | Parameter Name | CBOR | CBOR | Change | Specification |
skipping to change at page 28, line 36 skipping to change at page 30, line 48
+--------------------+-------+-------+------------+---------------+ +--------------------+-------+-------+------------+---------------+
|ietf-dots-call-home:| | | | | |ietf-dots-call-home:| | | | |
|alt-ch-client-record| TBA7 | 4 | IESG | [RFCXXXX] | |alt-ch-client-record| TBA7 | 4 | IESG | [RFCXXXX] |
+--------------------+-------+-------+------------+---------------+ +--------------------+-------+-------+------------+---------------+
|ietf-dots-call-home:| | | | | |ietf-dots-call-home:| | | | |
| ttl | TBA8 | 0 | IESG | [RFCXXXX] | | ttl | TBA8 | 0 | IESG | [RFCXXXX] |
+--------------------+-------+-------+------------+---------------+ +--------------------+-------+-------+------------+---------------+
Table 2: Assigned DOTS Signal Channel CBOR Key Values Table 2: Assigned DOTS Signal Channel CBOR Key Values
4.3. New DOTS Conflict Cause 7.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 [Cause]. Signal Channel Conflict Cause Codes" registry [Cause].
+-------+----------------------------------+------------+-----------+ +-------+----------------------------------+------------+-----------+
| Code | Label | Descriptio | Reference | | Code | Label | Descriptio | Reference |
| | | n | | | | | n | |
+-------+----------------------------------+------------+-----------+ +-------+----------------------------------+------------+-----------+
| 4 (TB | request-rejected-legitimate- | Mitigation | [RFCXXXX] | | 4 (TB | request-rejected-legitimate- | Mitigation | [RFCXXXX] |
| A9) | traffic | request | | | A9) | traffic | request | |
skipping to change at page 29, line 28 skipping to change at page 31, line 28
| | | indicate | | | | | indicate | |
| | | the attack | | | | | the attack | |
| | | traffic | | | | | traffic | |
| | | has been | | | | | has been | |
| | | classified | | | | | classified | |
| | | as | | | | | as | |
| | | legitimate | | | | | legitimate | |
| | | traffic. | | | | | traffic. | |
+-------+----------------------------------+------------+-----------+ +-------+----------------------------------+------------+-----------+
4.4. DOTS Signal Call Home YANG Module 7.4. DOTS Signal Call Home YANG Module
This document requests IANA to register the following URI in the "ns" This document requests IANA to register the following URI in the "ns"
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 [RFC6020] within the "YANG the "YANG Module Names" subregistry [RFC6020] within the "YANG
Parameters" registry: Parameters" registry:
name: ietf-dots-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: dots-call-home prefix: dots-call-home
reference: RFC XXXX reference: RFC XXXX
5. Security Considerations 8. 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 11 of channel related security considerations discussed in Section 11 of
[I-D.ietf-dots-rfc8782-bis] MUST be considered. DOTS agents MUST [I-D.ietf-dots-rfc8782-bis] MUST be considered. DOTS agents MUST
authenticate each other using (D)TLS before a DOTS signal channel authenticate each other using (D)TLS before a DOTS signal channel
session is considered valid. session is considered valid.
The Call Home function enables a Call Home DOTS server to be
reachable by only the intended Call Home DOTS client. Appropriate
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 communications from a trusted Call Home DOTS client to the
Call Home DOTS server are allowed.
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 adding to a drop-list the source address after a set
unsuccessful authentication attempts. number of unsuccessful authentication attempts.
Call Home DOTS servers may not blindly trust mitigation requests from The DOTS Call Home can be misused by a misbehaving Call Home DOTS
Call Home DOTS clients. For example, DOTS servers can use the attack client by arbitrarily signalling legitimate traffic as being attack
flow information in a mitigation request to enable full-fledged traffic or falsifying mitigation signals so that some sources are
packet inspection function to inspect all the traffic from the disconnected or some traffic is rate-limited. Such misbehaving Call
compromised device to the target or to re-direct the traffic from the Home DOTS clients may include sources identified by IP addresses that
compromised device to the target to a DDoS mitigation system to scrub are used for internal use only (that is, these addresses are not
the suspicious traffic. Call Home DOTS servers can also seek the visible outside a Call Home DOTS server domain). Absent explicit
consent of DOTS server domain administrator to block the traffic from policy (e.g., the Call Home DOTS client and server are managed by the
the compromised device to the target (see Section 3.3.1). same administrative entity), such requests should be discarded by the
Call Home DOTS server. More generally, Call Home DOTS servers should
not blindly trust mitigation requests from Call Home DOTS clients.
For example, Call Home DOTS servers could use the attack flow
information contained in a mitigation request to enable a full-
fledged packet inspection function to inspect all the traffic from
the compromised device to the target, or could re-direct the traffic
from the potentially compromised device to the target towards a DDoS
mitigation system that can scrub the suspicious traffic, without
blindly blocking all traffic from the indicated attack source to the
target. Call Home DOTS servers can also seek the consent of DOTS
server domain administrator to block the traffic from the potentially
compromised device to the target (see Section 5.3.1).
6. Privacy Considerations Call Home DOTS agents may interact with on-path address sharing
functions to retrieve an internal IP addresss/external IP address
mapping (Section 5.3.2) identifying an attack source. Blocking
access or manipulating the mapping information will complicate DDoS
attack mitigation close to an attack source. Additional security
considerations are specific to the actual mechanism used to access
that mapping (refer, e.g., to Section 4 of [RFC8512] or Section 4 of
[RFC8513]).
9. 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 introduces privacy threats. assess whether the DOTS Call Home introduces privacy 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 Call Home DOTS be used to ease surveillance. In particular, the Call Home DOTS
server is not required to share information that is local to its server is not required to share information that is local to its
network (e.g., internal identifiers of an attack source) with the network (e.g., internal identifiers of an attack source) with the
Call Home DOTS client. 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 learnt from the overall traffic flows that
exit the Call Home DOTS server domain. Furthermore, Call Home DOTS
clients do not publicly reveal attack identification information;
that information is encrypted and only shared with an authorized
entity in the domain to which the IP address/prefix is assigned, from
which an attack was issued.
The DOTS Call Home does not preclude the validation of mitigation The DOTS Call Home does not preclude the validation of mitigation
requests received from a Call Home 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 an 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 Call Home DOTS client. How the consent is obtained is out of the Call Home DOTS client. How the consent is obtained is out of
scope of this document. scope of this document.
Note that a Call Home DOTS server can seek for an administrator's Note that a Call Home DOTS server can seek an administrator's
consent, validate the request by inspecting the traffic, or proceed consent, validate the request by inspecting the relevant traffic for
with both. attack signatures, or proceed with both courses of action.
The DOTS Call Home is only advisory in nature. Concretely, the DOTS The DOTS Call Home is only advisory in nature. Concretely, the DOTS
Call Home does not impose any action to be enforced within the 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 network hosting an attack source; it is up to the Call Home DOTS
server (and/or network administrator) to decide whether and which server (and/or network administrator) to decide whether and which
actions are required. actions are required.
Moreover, the DOTS Call Home avoids misattribution by appropriately 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 to
(e.g., address sharing issues discussed in Section 3.3.1). (e.g., address sharing issues discussed in Section 5.3.1).
Triggers to send a DOTS mitigation request to a Call Home DOTS server Triggers to send a DOTS mitigation request to a Call Home DOTS server
are deployment-specific. For example, a Call Home DOTS client may are deployment-specific. For example, a Call Home DOTS client may
rely on the output of some DDoS detection systems deployed within the rely on the output of some DDoS detection systems (flow exports or
DOTS client domain to detect potential outbound DDoS attacks or on similar functions) deployed within the DOTS client domain to detect
abuse claims received from remote victim networks. Such DDoS potential outbound DDoS attacks or on abuse claims received from
detection and mitigation techniques are not meant to track the remote victim networks. These systems may be misused to track users
activity of users, but to protect the Internet and avoid altering the and infer their activities. Such misuses are not required to achieve
IP reputation of the DOTS client domain. the functionality defined in this document (that is, protect the
Internet and avoid altering the IP reputation of source networks).
It is out of the scope to identify privacy threats specific to a
given attack detection technology. The reader may refer, for
example, to Section 11.8 of [RFC7011].
7. Contributors 10. 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
Email: harsha_joshi@mcafee.com Email: harsha_joshi@mcafee.com
Wei Pan Wei Pan
Huawei Technologies Huawei Technologies
China China
Email: william.panwei@huawei.com Email: william.panwei@huawei.com
8. Acknowledgements 11. Acknowledgements
Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Toema
Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments. Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments.
9. References Benjamin Kaduk's AD review is valuable. Many thanks to him for the
detailed review.
9.1. Normative References 12. References
12.1. Normative References
[I-D.ietf-dots-rfc8782-bis] [I-D.ietf-dots-rfc8782-bis]
Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed
Denial-of-Service Open Threat Signaling (DOTS) Signal Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel Specification", draft-ietf-dots-rfc8782-bis-00 Channel Specification", draft-ietf-dots-rfc8782-bis-01
(work in progress), August 2020. (work in progress), September 2020.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010,
<https://www.rfc-editor.org/info/rfc6052>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data [RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data
Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
June 2020, <https://www.rfc-editor.org/info/rfc8791>. June 2020, <https://www.rfc-editor.org/info/rfc8791>.
9.2. Informative References 12.2. Informative References
[Cause] IANA, "DOTS Signal Channel Conflict Cause Codes", [Cause] IANA, "DOTS Signal Channel Conflict Cause Codes",
<https://www.iana.org/assignments/dots/dots.xhtml#dots- <https://www.iana.org/assignments/dots/dots.xhtml#dots-
signal-channel-conflict-cause-codes>. signal-channel-conflict-cause-codes>.
[I-D.ietf-dots-multihoming] [I-D.ietf-dots-multihoming]
Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing
Deployment Considerations for Distributed-Denial-of- Deployment Considerations for Distributed-Denial-of-
Service Open Threat Signaling (DOTS)", draft-ietf-dots- Service Open Threat Signaling (DOTS)", draft-ietf-dots-
multihoming-04 (work in progress), May 2020. multihoming-04 (work in progress), May 2020.
[I-D.ietf-dots-server-discovery] [I-D.ietf-dots-server-discovery]
Boucadair, M. and T. Reddy.K, "Distributed-Denial-of- Boucadair, M. and T. Reddy.K, "Distributed-Denial-of-
Service Open Threat Signaling (DOTS) Agent Discovery", Service Open Threat Signaling (DOTS) Agent Discovery",
draft-ietf-dots-server-discovery-10 (work in progress), draft-ietf-dots-server-discovery-12 (work in progress),
February 2020. October 2020.
[I-D.ietf-dots-use-cases] [I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
L., and K. Nishizuka, "Use cases for DDoS Open Threat L., and K. Nishizuka, "Use cases for DDoS Open Threat
Signaling", draft-ietf-dots-use-cases-25 (work in Signaling", draft-ietf-dots-use-cases-25 (work in
progress), July 2020. progress), July 2020.
[I-D.ietf-i2nsf-terminology] [I-D.ietf-i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
Birkholz, "Interface to Network Security Functions (I2NSF) Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-08 (work in Terminology", draft-ietf-i2nsf-terminology-08 (work in
progress), July 2019. progress), July 2019.
[I-D.ietf-idr-flow-spec-v6] [I-D.ietf-idr-flow-spec-v6]
Loibl, C., Raszuk, R., and S. Hares, "Dissemination of Loibl, C., Raszuk, R., and S. Hares, "Dissemination of
Flow Specification Rules for IPv6", draft-ietf-idr-flow- Flow Specification Rules for IPv6", draft-ietf-idr-flow-
spec-v6-14 (work in progress), August 2020. spec-v6-16 (work in progress), October 2020.
[Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", [Key-Map] IANA, "DOTS Signal Channel CBOR Key Values",
<https://www.iana.org/assignments/dots/dots.xhtml#dots- <https://www.iana.org/assignments/dots/dots.xhtml#dots-
signal-channel-cbor-key-values>. signal-channel-cbor-key-values>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999, RFC 2663, DOI 10.17487/RFC2663, August 1999,
<https://www.rfc-editor.org/info/rfc2663>. <https://www.rfc-editor.org/info/rfc2663>.
skipping to change at page 34, line 28 skipping to change at page 37, line 43
[RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and
Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October
2011, <https://www.rfc-editor.org/info/rfc6398>. 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>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[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>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597, Port with Encapsulation (MAP-E)", RFC 7597,
DOI 10.17487/RFC7597, July 2015, DOI 10.17487/RFC7597, July 2015,
<https://www.rfc-editor.org/info/rfc7597>. <https://www.rfc-editor.org/info/rfc7597>.
skipping to change at page 35, line 26 skipping to change at page 38, line 46
[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>.
[Sec] UK Department for Digital Culture, Media & Sport, "Secure [Sec-by-design]
UK Department for Digital Culture, Media & Sport, "Secure
by Design: Improving the cyber security of consumer by Design: Improving the cyber security of consumer
Internet of Things Report", March 2018, Internet of Things Report", March 2018,
<https://www.gov.uk/government/publications/secure-by- <https://www.gov.uk/government/publications/secure-by-
design-report>. design-report>.
[ServicePorts] [ServicePorts]
IANA, "Service Name and Transport Protocol Port Number IANA, "Service Name and Transport Protocol Port Number
Registry", <https://www.iana.org/assignments/service- Registry", <https://www.iana.org/assignments/service-
names-port-numbers/service-names-port-numbers.xhtml>. names-port-numbers/service-names-port-numbers.xhtml>.
Appendix A. Disambiguate Base DOTS Signal vs. DOTS Call Home Appendix A. Disambiguating Base DOTS Signal vs. DOTS Call Home
With the DOTS signal channel Call Home, there is a chance that two With the DOTS signal channel Call Home, there is a chance that two
DOTS agents can simultaneously establish two DOTS signal channels DOTS agents can simultaneously establish two DOTS signal channels
with different directions (base DOTS signal channel and DOTS signal with different directions (base DOTS signal channel and DOTS signal
channel Call Home). Here is one example drawn from the home network. 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 Call Home DOTS server in, for example,
network can mitigate the DDoS attacks launched by the compromised the home network can mitigate the DDoS attacks launched by the
device in its domain by receiving the mitigation request sent by the compromised device in its domain by receiving the mitigation request
Call Home DOTS client in the ISP environment. In addition, the DOTS sent by the Call Home DOTS client in the ISP environment. In
client in the home network can initiate a mitigation request to the addition, the DOTS client in the home network can initiate a
DOTS server in the ISP environment to ask for help when the home mitigation request to the DOTS server in the ISP environment to ask
network is under a DDoS attack. Such DOTS server and DOTS client in for help when the home network is under a DDoS attack. Such Call
the home network can co-locate in the same home network element Home DOTS server and DOTS client in the home network can co-locate in
(e.g., the Customer Premises Equipment). In this case, with the same the same home network element (e.g., the Customer Premises
peer at the same time the home network element will have the base Equipment). In this case, with the same peer at the same time the
DOTS signal channel and the DOTS signal channel Call Home defined in home network element will have the base DOTS signal channel defined
this specification. Thus, these two signal channels need to be in [I-D.ietf-dots-rfc8782-bis] and the DOTS signal channel Call Home
distinguished when they are both supported. Two approaches have been defined in this specification. Thus, these two signal channels need
considered for distinguishing the two DOTS signal channels, but only to be distinguished when they are both supported. Two approaches
the one that using the dedicated port number has been chosen as the have been considered for distinguishing the two DOTS signal channels,
best choice. but only the one that using the dedicated port number has been chosen
as the 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 allocated in [I-D.ietf-dots-rfc8782-bis] to the port number 4646 allocated in [I-D.ietf-dots-rfc8782-bis] 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 signal channel client, and uses the port number TBD to initiate the signal channel
Call Home. Based on the different port numbers, the ISP can directly Call Home. Based on the different port numbers, the ISP can directly
decide which kind of procedures should follow immediately after it decide which kind of procedures should follow immediately after it
receives the DOTS messages. This approach just requires two (D)TLS receives the DOTS messages. This approach just requires two (D)TLS
sessions to be established respectively for the basic signal channel sessions to be established respectively for the basic signal channel
and signal channel Call Home. 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 as depicted in Figure 13). For example,
home network first initiates a DOTS data channel to the peer DOTS the DOTS agent in the home network first initiates a DOTS data
agent in the ISP environment, at this time the DOTS agent in the home channel to the peer DOTS agent in the ISP environment, at this time
network is the DOTS client and the peer DOTS agent in the ISP the DOTS agent in the home network is the DOTS client and the peer
environment is the DOTS server. After that, the DOTS agent in the DOTS agent in the ISP environment is the DOTS server. After that,
home network retrieves the DOTS Call Home capability of the peer DOTS the DOTS agent in the home network retrieves the DOTS Call Home
agent. If the peer supports the DOTS Call Home, the DOTS agent needs capability of the peer DOTS agent. If the peer supports the DOTS
to subscribe to the peer to use this extension. Then, the reversal Call Home, the DOTS agent needs to subscribe to the peer to use this
of DOTS role can be recognized as done by both DOTS agents. When the extension. Then, the reversal of DOTS role can be recognized as done
DOTS agent in the ISP environment, which now is the DOTS client, by both DOTS agents. When the DOTS agent in the ISP environment,
wants to filter the attackers' traffic, it requests the DOTS agent in which now is the DOTS client, wants to filter the attackers' traffic,
the home network, which now is the DOTS server, for help. it requests the DOTS agent in the home network, which now is the DOTS
server, for help.
Signaling the role will complicate the DOTS protocol, and this augment /ietf-data:dots-data/ietf-data:capabilities:
+--ro call-home-support? boolean
augment /ietf-data:dots-data/ietf-data:dots-client:
+--rw call-home-enable? boolean
Figure 13: Example of DOTS Data Channel Augmentation
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 required or only when the DOTS Call Home is needed. Besides, the
DOTS data channel may not work during attack time. Even if changing DOTS data channel may not work during attack time. Even if changing
the above example from using the DOTS data channel to the DOTS signal the above example from using the DOTS data channel to the DOTS signal
channel, the more procedures will still reduce the efficiency. Using channel, the more procedures will still reduce the efficiency. Using
the dedicated port number is much easier and more concise compared to the dedicated port number is much easier and more concise compared to
the second approach, and its cost that establishing two (D)TLS the second approach, and its cost that establishing two (D)TLS
sessions is much less. So, using a dedicated port number for the sessions is much less. So, using a dedicated port number for the
DOTS Call Home is chosen in this specification. DOTS Call Home is chosen in this specification.
 End of changes. 111 change blocks. 
310 lines changed or deleted 505 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/