Distributed Denial-of-Service Open
Threat Signaling (DOTS) Signal Channel Call HomeMcAfee, Inc.Embassy Golf Link Business ParkBangaloreKarnataka560071Indiakondtir@gmail.comOrangeRennes35000Francemohamed.boucadair@orange.comUKsupjps-ietf@jpshallow.comDOTSThis document specifies the DOTS signal channel Call Home service,
which enables a DOTS server to initiate a secure connection to a DOTS
client, and to receive the attack traffic information from the DOTS
client. The DOTS server in turn uses the attack traffic information to
identify the compromised devices launching the outgoing DDoS attack and
takes appropriate mitigation action(s).The DOTS Call Home service is not specific to the home networks; the
solution targets any deployment which requires to block DDoS attack
traffic closer to the source(s) of a DDoS attack.The DOTS signal channel protocol is used to carry
information about a network resource or a network (or a part thereof)
that is under a Distributed Denial of Service (DDoS) attack. Such
information is sent by a DOTS client to one or multiple DOTS servers
so that appropriate mitigation actions are undertaken on traffic
deemed suspicious. Various use cases are discussed in .Internet of Things (IoT) devices are becoming more and more
prevalent in home networks, and with compute and memory becoming
cheaper and cheaper, various types of IoT devices become available in
the consumer market at affordable price. But on the downside, the main
threat being most of these IoT devices are bought off-the-shelf and
most manufacturers haven't considered security in the product design.
IoT devices deployed in home networks can be easily compromised, they
do not have an easy mechanism to upgrade, and IoT manufactures may
cease manufacture and/or discontinue patching vulnerabilities on IoT
devices (Sections 5.4 and 5.5 of ).
However, these vulnerable and compromised devices will continue to be
used for a long period of time in the home, and the end-user does not
know that IoT devices in his/her home are compromised. The compromised
IoT devices are typically used for launching DDoS attacks (Section 3
of ) on victims while the
owner/administrator of the home network is not aware about such
misbehaviors. Similar to other DDoS attacks, the victim in this attack
can be an application server, a host, a router, a firewall, or an
entire network.Nowadays, network devices in a home network offer network security
(e.g., firewall or Intrusion Protection System (IPS) service on a home
router) to protect the devices connected to the home network from both
external and internal attacks. Over the years several techniques have
been identified to detect DDoS attacks, some of these techniques can
be enabled on home network devices but most of them are used in the
Internet Service Provider (ISP)'s network. The ISP offering DDoS
mitigation service can detect outgoing DDoS attack traffic originating
from its subscribers or the ISP may receive filtering rules (e.g.,
using BGP flowspec ) 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, and Transport Layer Security (TLS) re-negotiation are
difficult to detect on a home network device without adversely
affecting its performance. The reason is typically home devices such
as home routers have fast path to boost the throughput. For every new
TCP/UDP flow, only the first few packets are punted through the slow
path. Hence, it is not possible to detect various DDoS attacks in the
slow path, since the attack payload is sent to the target server after
the flow is switched to fast path. 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 detect these type of DDoS attacks is
functionally or operationally not possible for all the devices
attached to the home network owing to the memory and CPU limitations
of the home routers. Further, for certain DDoS attacks the ability to
distinguish legitimate traffic from attacker traffic on a per packet
basis is complex. This complexity is due to that the packet itself may
look "legitimate" and no attack signature can be identified. The
anomaly can be identified only after detailed statistical
analysis.The ISP on the other hand can detect some DDoS attacks originating
from a home network (e.g., Section 2.6 of ), but the ISP does not have a mechanism to
detect which device in the home network is generating the DDoS attack
traffic. The primary reason being that devices in an IPv4 home network
are typically behind a Network Address Translation (NAT) border. Even
in case of a IPv6 home network, although the ISP can identify the
infected device in the home network launching the DDoS traffic by
tracking its unique IPv6 address, the infected device can easily
change its IPv6 address to evade remediation.Existing approaches are still suffering from misused access network
resources by abusing devices; the support of means for blocking such
attacks close to the sources are missing. In particular, the DOTS
signal protocol does not discuss cooperative DDoS mitigation between
the network hosting an attack source and the ISP to the suppress the
outbound DDoS attack traffic originating from that network.This specification addresses the problems discussed in and presents the DOTS signal channel Call
Home extension, which enables the DOTS server to initiate a secure
connection to the DOTS client, and the DOTS client then conveys the
attack traffic information to the DOTS server.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
source, receiving an alert from an attack target, a peer DDoS
Mitigation System (DMS), or a transit provider). The definition of
these triggers is deployment-specific. It is therefore out of the
scope of this document to elaborate on how these triggers are made
available to a DOTS client.In a typical deployment scenario, the DOTS server is enabled on a
Customer Premises Equipment (CPE), which is aligned with recent trends
to enrich the CPE with advanced security features. Unlike classic DOTS
deployments , such DOTS
server maintains a single DOTS signal channel session for each
DOTS-capable upstream provisioning domain .For instance, the DOTS server in the home network initiates the
Call Home in 'idle' time and then subsequently the DOTS client in the
ISP environment can initiate a mitigation request whenever the ISP
detects there is an attack from a compromised device in the DOTS
server domain (i.e., from within the home network).The DOTS server uses the DDoS attack traffic information to
identify the compromised device in its domain that is responsible for
launching the DDoS attack, optionally notifies a network
administrator, and takes appropriate mitigation action(s). A
mitigation action can be to quarantine the compromised device or block
its traffic to the attack target(s) until the mitigation request is
withdrawn.Other motivations for introducing the Call Home function are
discussed in Section 1.1 of .This document assumes that DOTS servers are provisioned with a way
to know how to reach the upstream DOTS client(s), which could occur by
a variety of means (e.g., ). The specification of
such means are out of scope of this document.The aforementioned problems may be encountered in other deployments
than those discussed in (e.g., data
centers, enterprise networks). The solution specified in this document
can be used for those deployments to block DDoS attack traffic closer
to the source(s) of the attack. The Call Home reference architecture
is shown in .It is out of the scope of this document to identify an exhaustive
list of such deployments.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
when, and
only when, they appear in all capitals, as shown here.The reader should be familiar with the terms defined in .The meaning of the symbols in YANG tree diagrams is defined in .(D)TLS is used for statements that apply to both Transport Layer
Security (TLS) and Datagram Transport
Layer Security (DTLS) . Specific terms are
used for any statement that applies to either protocol alone.The DOTS signal channel Call Home extension preserves all but one
of the DOTS client/server roles in the DOTS protocol stack, as
compared to DOTS client-initiated DOTS signal channel protocol . The role reversal that
occurs is at the (D)TLS layer; that is, (1) the DOTS server acts as a
DTLS client and the DOTS client acts as a DTLS server or (2) the DOTS
server acts as a TLS client initiating the underlying TCP connection
and the DOTS client acts as a TLS server. The DOTS server initiates
(D)TLS handshake to the DOTS client.For example, a home network element (e.g., home router) co-located
with a DOTS server (likely, a client-domain DOTS gateway) is the
(D)TLS server. However, when calling home, the DOTS server initially
assumes the role of the (D)TLS client, but the network element's role
as a DOTS server remains the same. Furthermore, existing certificate
chains and mutual authentication mechanisms between the DOTS agents
are unaffected by the Call Home function. This Call Home function
enables the DOTS server co-located with a network element (possibly
behind NATs and firewalls) reachable by only the intended DOTS client
and hence the DOTS server cannot be subjected to DDoS attacks. illustrates a sample Call Home flow
exchange:The DOTS signal channel Call Home procedure is as follows:If UDP transport is used, the DOTS server begins by initiating
a DTLS connection to the DOTS client. The DOTS client MUST support
accepting DTLS connection on the IANA-assigned port number defined
in , but MAY be configured to listen to
a different port number. If TCP is used,
the DOTS server begins by initiating a TCP connection to the DOTS
client. The DOTS client MUST support accepting TCP connections on
the IANA-assigned port number defined in , but MAY be configured to listen to a
different port number. Using this TCP connection, the DOTS server
initiates a TLS connection to the DOTS client. The Happy Eyeballs mechanism explained in Section
4.3 of can be
used for initiating (D)TLS connections.Using this (D)TLS connection, the DOTS client may request,
withdraw, or retrieve the status of mitigation requests.The Heartbeat mechanism used for the Call Home deviates from the
one defined in Section 4.7 of . This section specifies
the behavior to be followed by DOTS agents for the Call Home.Once the (D)TLS section is established between the DOTS agents, the
DOTS client contacts the DOTS server to retrieve the session
configuration parameters (Section 4.5 of ). The DOTS server
adjusts the 'heartbeat-interval' to accommodate binding timers used by
on-path NATs and firewalls. Heartbeats will be then exchanged by the
DOTS agents following the instructions retrieved using the signal
channel session configuration exchange.It is the responsibility of DOTS servers to ensure that on-path
translators/firewalls are maintaining a binding so that the same
external IP address and/or port number is retained for the DOTS signal
channel session. A DOTS client MAY trigger their heartbeat requests
immediately after receiving heartbeat probes from its peer DOTS
server.When an outgoing attack that saturates the outgoing link from the
DOTS server is detected and reported by a DOTS client, the latter MUST
continue to use the signal channel even if no traffic is received from
the DOTS server. It is most likely that the outgoing traffic is
exceeding the DOTS server domain capacity. As a reminder, the DOTS
client cannot initiate a (D)TLS connection.If the DOTS server receives traffic from the DOTS client, the DOTS
server MUST continue to use the signal channel even if the missing
heartbeat allowed threshold is reached.If the DOTS server does not receive any traffic from the peer DOTS
client, the DOTS server sends heartbeat requests to the DOTS client
and after maximum 'missing-hb-allowed' threshold is reached, the DOTS
server concludes the session is disconnected. Then, the DOTS server
MUST try to resume the (D)TLS session.This specification extends the mitigation request defined in
Section 4.4.1 of
to convey the attacker source prefixes and source port numbers. The
DOTS client conveys the following new parameters in the CBOR body of
the mitigation request:A list of attacker prefixes used to
attack the target. Prefixes are represented using Classless
Inter-Domain Routing (CIDR) notation . As a
reminder, the prefix length MUST be less than or equal to 32
(resp. 128) for IPv4 (resp. IPv6).The
prefix list MUST NOT include broadcast, loopback, or multicast
addresses. These addresses are considered as invalid values. In
addition, the DOTS client MUST validate that attacker prefixes
are within the scope of the DOTS server domain.This is an optional attribute.A list of port numbers used by
the attack traffic flows. 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' is
present, it represents a single port number. For TCP, UDP, Stream Control Transmission
Protocol (SCTP) , or Datagram
Congestion Control Protocol (DCCP) , a range of ports can be, for example,
0-1023, 1024-65535, or 1024-49151. This
is an optional attribute.A list of ICMP types used by the
attack traffic flows. An ICMP type range is defined by two
bounds, a lower ICMP type (lower-type) and an upper ICMP type
(upper-type). When only 'lower-type' is present, it represents a
single ICMP type. This is an optional
attribute.The 'source-prefix' parameter is a mandatory attribute when the
attack traffic information is signaled by a DOTS client in the Call
Home scenario. The 'target-uri' or 'target-fqdn' parameters can be
included in a mitigation request for diagnostic purposes to notify
the DOTS server domain administrator, but SHOULD NOT be used to
determine the target IP addresses. Note that 'target-prefix' becomes
a mandatory attribute in the mitigation request signaling the attack
information because 'target-uri' and 'target-fqdn' are optional
attributes and 'alias-name' will not be conveyed in a mitigation
request.In order to help attack source identification by a DOTS server,
the DOTS client SHOULD include in its mitigation request additional
information such as 'source-port-range' or 'source-icmp-type-range'.
The DOTS client may not include such information if 'source-prefix'
conveys an IPv6 address/prefix.Only immediate mitigation requests (i.e., 'trigger-mitigation'
set to 'true') are allowed; DOTS clients MUST NOT send requests with
'trigger-mitigation' set to 'false'. Such requests MUST be discarded
by the DOTS server with a 4.00 (Bad Request).If a Carrier Grade NAT (CGN, including NAT64) is located between
the DOTS client domain and DOTS server domain, communicating an
external IP address in a mitigation request is likely to be
discarded by the DOTS server because the external IP address is not
visible locally to the DOTS server (see ).
The DOTS server is only aware of the internal IP addresses/prefixes
bound to its domain. Thus, the DOTS client MUST NOT include the
external IP address and/or port number identifying the suspect
attack source, but MUST include the internal IP address and/or port
number. To that aim, the DOTS client SHOULD rely on mechanisms, such
as or ,
to retrieve the internal IP address and port number which are mapped
to an external IP address and port number.If a MAP Border Relay or lwAFTR
is enabled in the provider's domain
to service its customers, the identification of an attack source
bound to an IPv4 address/prefix MUST also rely on source port
numbers because the same IPv4 address is assigned to multiple
customers. The port information is required to unambiguously
identify the source of an attack.The DOTS server MUST check that the 'source-prefix' is within the
scope of the DOTS server domain in the Call Home scenario. Note that
in such scenario, the DOTS server considers, by default, that any
routeable IP prefix enclosed in 'target-prefix' is within the scope
of the DOTS client. Invalid mitigation requests are handled as per
Section 4.4.1 of .If a translator is enabled on the boundaries of the domain
hosting the DOTS server (e.g., a CPE with NAT enabled as shown in
Figures and ), the DOTS server uses the
attack traffic information conveyed in a mitigation request to find
the internal source IP address of the compromised device and blocks
the traffic from the compromised device traffic to the attack target
until the mitigation request is withdrawn. Doing so allows to
isolate the suspicious device while avoiding to disturb other
services.The DOTS server domain administrator consent MAY be required to
block the traffic from the compromised device to the attack target.
An implementation MAY have a configuration knob to block the traffic
from the compromised device to the attack target with or without
DOTS server domain administrator consent. If the attack traffic is
blocked, the DOTS server informs the DOTS client that the attack is
being mitigated.If the attack traffic information is identified by the DOTS
server or the DOTS server domain administrator as legitimate
traffic, the mitigation request is rejected, and 4.09 (Conflict) is
returned to the DOTS client. The conflict-clause (defined in Section
4.4.1 of )
indicates the cause of the conflict. The following new value is
defined:Mitigation request rejected. This code is
returned by the DOTS server to indicate the attack traffic has
been classified as legitimate traffic.Once the request is validated by the DOTS server, appropriate
actions are enforced to block the attack traffic within the source
network. The DOTS client is informed about the progress of the
attack mitigation following the rules in . For example, if the
DOTS server is embedded in a CPE, it can program the packet
processor to punt all the traffic from the compromised device to the
target to slow path. The CPE inspects the punted slow path traffic
to detect and block the outgoing DDoS attack traffic or quarantine
the device (e.g., using MAC level filtering) until it is remediated,
and notifies the CPE administrator about the compromised device.This document augments the "dots-signal-channel" DOTS signal
YANG module defined in for signaling the
attack traffic information. This document defines the YANG module
"ietf-dots-call-home", which has the following tree
structure:This module uses the common YANG types defined in .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 Name
and Transport Protocol Port Number Registry" available at:
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml.The assignment of port number 4647 is strongly suggested (DOTS
signal channel uses port number 4646).This specification registers the 'source-prefix' and
'source-port-range' parameters in the IANA "DOTS Signal Channel CBOR
Mappings" registry established by .The 'source-prefix', 'source-port-range', and
‘source-icmp-type-range' are comprehension-optional
parameters.Note to the RFC Editor: Please delete (TBD1)-(TBD5) once CBOR
keys are assigned from the 0x8000 - 0xBFFF range.This document requests IANA to assign a new code from the "DOTS
Conflict Cause Codes" registry:CodeLabelDescriptionReference4request-rejectedMitigation request rejected. This code is returned by the DOTS
server to indicate the attack traffic has been classified as
legitimate traffic.[RFCXXXX]This document requests IANA to register the following URI in the
"IETF XML Registry" : This document requests IANA to register the following YANG
module in the "YANG Module Names" registry .This document deviates from classic DOTS signal channel usage by
having the DOTS server initiate the (D)TLS connection. DOTS signal
channel related security considerations discussed in Section 10 of MUST be considered. DOTS
agents MUST authenticate each other using (D)TLS before a DOTS signal
channel session is considered valid.An attacker may launch a DoS attack on the DOTS client by having it
perform computationally expensive operations, before deducing that the
attacker doesn't possess a valid key. For instance, in TLS 1.3 , the ServerHello message contains a Key Share
value based on an expensive asymmetric key operation for key
establishment. Common precautions mitigating DoS attacks are
recommended, such as temporarily blacklisting the source address after a
set number of unsuccessful authentication attempts.DOTS servers may not blindly trust mitigation requests from DOTS
clients. For example, DOTS servers can use the attack flow information
in a mitigation request to enable full-fledged packet inspection
function to inspect all the traffic from the compromised to the target
or to re-direct the traffic from the compromised device to the target to
a DDoS mitigation system to scrub the suspicious traffic. DOTS servers
can also seek the consent of DOTS server domain administrator to block
the traffic from the compromised device to the target (see ).The considerations discussed in were
taken into account to assess whether the DOTS Call Home extension
introduces privacy threats.Concretely, the protocol does not leak any new information that can
be used to ease surveillance. In particular, the DOTS server is not
required to share information that is local to its network (e.g.,
internal identifiers of an attack source) with the DOTS client.The DOTS Call Home extension does not preclude the validation of
mitigation requests received from a DOTS client. For example, a security
service running on the CPE may require administrator's consent before
the CPE acts upon the mitigation request indicated by the DOTS client.
How the consent is obtained is out of scope of this document.Note that a DOTS server can seek for an administrator's consent,
validate the request by inspecting the traffic, or proceed with
both.The DOTS Call Home extension is only advisory in nature. Concretely,
the DOTS Call Home extension does not impose any action to be enforced
within the home network; it is up to the DOTS server (and/or network
administrator) to decide whether and which actions are required.Moreover, the DOTS Call Home extension avoids misattribution by
appropriately identifying the network to which a suspect attack source
belongs to (e.g., address sharing issues discussed in ).Triggers to send a DOTS mitigation request to a DOTS server are
deployment-specific. For example, a DOTS client may rely on the output
of some DDoS detection systems deployed within the DOTS client domain to
detect potential outbound DDoS attacks or on abuse claims received from
remote victim networks. Such DDoS detection and mitigation techniques
are not meant to track the activity of users, but to protect the
Internet and avoid altering the IP reputation of the DOTS client
domain.The following individuals have contributed to this document:Thanks to Wei Pei, Xia Liang, Roman Danyliw, Dan Wing, Töma
Gavrichenkov, Daniel Migault, and Valery Smyslov for the comments.