Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Call HomeMcAfee, Inc.Embassy Golf Link Business ParkBangaloreKarnataka560071Indiakondtir@gmail.comMcAfee, Inc.Embassy Golf Link Business ParkBangaloreKarnataka560071Indiaharsha_joshi@mcafee.comOrangeRennes35000Francemohamed.boucadair@orange.comNCC GroupUKsupjps-ietf@jpshallow.comDOTSThis document presents 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.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 .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 are 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
easy mechanism to upgrade, and IoT manufactures may cease manufacture
and/or discontinue patching vulnerabilities on IoT devices. However,
these vulnerable and compromised devices will continue 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 on the victim
while the owner/administrator of the home network is not aware about
such misbehaviors. Similar to other DDoS attack, 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,
for instance, firewall/IPS service on a home router or gateway to
protect the devices connected to the home network from 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 (for
example, using BGP flowspec ) from
downstream service provider to filter, block, or rate-limit DDoS
attack traffic originating from the ISP's subscribers to the
downstream target.Some of the DDoS attacks like spoofed RST or FIN packets,
Slowloris, and TLS re-negotiation are difficult to detect on the home
network devices without adversely affecting its performance. The
reason is typically 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
originates from the fact 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 the DDoS attack originating
from a home network, 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 a IPv4 Home network
are typically behind a 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 the IP 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 do not discuss cooperative DDoS mitigation between the
home network and ISP to the suppress the outbound DDoS attack traffic
originating from the home network.This specification addresses the problems discussed in and presents 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. The DOTS server uses
the DDoS attack traffic information to identify the compromised device
in its domain launching the DDoS attack, notifies the network
administrator, and takes appropriate mitigation action. The mitigation
action can be to quarantine the compromised device or block its
traffic to the attack target until the mitigation request is
withdrawn.For instance, the DOTS server in the home network initiates the
Call Home during peace time and then subsequently the DOTS client in
the ISP environment can initiate mitigation requests whenever the ISP
detects there is an attack from a compromised device in the DOTS
server's domain.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 .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-initiated DOTS signal channel protocol. The one and only role
reversal that occurs are at the TCP/TLS or DTLS layers; that is, the
DOTS server acts as a DTLS client and the DOTS client acts as a DTLS
server or the DOTS server acts as a TCP/TLS client and the DOTS client
acts as a TCP/TLS server. The DOTS server initiates TCP/TLS handshake
or DTLS 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
TCP/TLS server and DTLS server. However, when calling home, the DOTS
server initially assumes the role of the TCP/TLS client and DTLS
client, but the network element's role as a DOTS server remains the
same. Further, existing certificate chains and mutual authentication
mechanisms between the DOTS agents are unaffected by 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. Other motivations for introducing Call Home
are discussed in Section 1.1 of . illustrates sample Call Home flow
exchange:This diagram makes the following points: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 defined in
, but MAY be configured to listen to a
different port. 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
defined in , but MAY be configured to
listen to a different port. Using this TCP connection, the DOTS
server initiates an TLS connection to the DOTS client. The happy
eyeballs mechanism explained in Section 4.3 of can be used for
initiation of both TCP and UDP sessions.Using this (D)TLS connection, the DOTS client requests,
withdraws, or retrieves the status of mitigation requests.This specification extends the mitigation request defined in
to convey the
attacker source prefixes and source port numbers. The DOTS client in
the mitigation request 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's 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 the DOTS client in the
call home scenario. The 'target-uri' or 'target-fqdn' parameters can
be included in the mitigation request for diagnostic purpose 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 the
mitigation request.In order to help attack source identification by the 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. When a translator is on-path, the DOTS server uses the attack
traffic information 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. 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.If the DOTS server is co-located with a home router, it can
program the packet processor to punt all the traffic from the
compromised device to the target to slow path. The home router
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 home
administrator about the compromised device.TBD:a) Do we also want to convey Attack Name/type or ID (the home
router may not be capable of detecting new emerging/sophisticated
attacks) ?b) Is DOTS data channel Call Home service required (if required,
can RESTCONF Call Home defined in RFC8071 be used) ?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-signal-call-home", which has the following tree
structure: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.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.[ThisDoc]This document requests IANA to register the following URIs in the
"IETF XML Registry" : This document requests IANA to register the following YANG
modules in the "YANG Module Names" registry .This document deviates from standard DOTS signal channel usage by
having the DOTS server initiate the TCP/TLS or DTLS 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.TBC.