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.comDOTSAutomationAnti-DDoS AutomationDDoS MitigationCollaborative NetworkingProtective NetworkingSecurityScrubbingThis document specifies the DOTS signal channel Call Home, which
enables a Call Home DOTS server to initiate a secure connection to a
Call Home DOTS client, and to receive attack traffic information from
the Call Home DOTS client. The Call Home DOTS server in turn uses the
attack traffic information to identify compromised devices launching
outgoing DDoS attacks and take appropriate mitigation action(s).The DOTS signal channel Call Home is not specific to home networks;
the solution targets any deployment in which it is required to block
DDoS attack traffic closer to the source(s) of a DDoS attack.Please update these statements within the document with the RFC
number to be assigned to this document:"This version of this YANG module is part of RFC XXXX;""RFC XXXX: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Call Home";"| [RFCXXXX] |"reference: RFC XXXXPlease update this statement with the RFC number to be assigned to
the following documents:"RFC YYYY: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification" (used to be
I-D.ietf-dots-rfc8782-bis)Please update TBD/TBA statements with the assignments made by IANA to
DOTS Signal Channel Call Home.Also, please update the "revision" date of the YANG module.The Distributed Denial-of-Service Open Threat Signaling (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 .However, only covers
how to mitigate when being attacked (i.e., protect a network from
inbound DDoS attacks). It does not cover how to control the attacks
close to their source(s) that are misusing network resources (i.e.,
outbound DDoS attacks). In particular, the DOTS signal protocol does not
discuss cooperative DDoS mitigation between the network hosting an
attack source and the Internet Service Provider (ISP) to suppress the
outbound DDoS attack traffic originating from that network. As a
reminder, the base basic DOTS architecture is depicted in (Section 2 of ). details why the rise of Internet of
Things (IoT) compounds the possibility of these being used as malicious
actors which need to be controlled. Similar issues can be encountered in
enterprise networks, data centers, etc. The ISP offering a 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 transit provider to filter, block, or
rate-limit DDoS attack traffic originating from the ISP's subscribers to
a downstream target. Nevertheless, the DOTS signal channel does not
provide means for the ISP to request blocking such attacks close to the
sources without altering legitimate traffic. This document fills that
void by specifying an extension to the DOTS signal channel: DOTS signal
channel Call Home.Note: Another design approach would be to extend the DOTS signal
channel with a new attribute to explicitly indicate whether a
mitigation request is about an outbound DDoS attack. In such an
approach, it is assumed that a DOTS server is deployed within the
domain that is hosting the attack source(s), while a DOTS client is
enabled within an upstream network (e.g., access network). However,
initiating a DOTS signal channel from an upstream network to a
source network is complicated because of the presence of translators
and firewalls. Moreover, the use of the same signal channel to
handle both inbound and outbound attacks complicates both the
heartbeat and redirection mechanisms that are executed as a function
of the attack direction (see Sections and ). Also, the DOTS server will be subject to
fingerprinting (e.g., using scanning tools) and DoS attacks (e.g.,
by having the DOTS server to perform computationally expensive
operations). Various management and deployment considerations that
motivate the Call Home functionality are listed in Section 1.1 of
.'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers
to a DOTS signal channel established at the initiative of a DOTS server
thanks to a role reversal at the (D)TLS layer (). That is, the DOTS server initiates a secure
connection to a DOTS client, and uses that connection to receive the
attack traffic information (e.g., attack sources) from the DOTS
client.A high-level DOTS Call Home functional architecture is shown in . Attack source(s) are within the DOTS server
domain.DOTS agents involved in the DOTS Call Home otherwise adhere to the
DOTS roles as defined in . For clarity,
this document uses "Call Home DOTS client" (or "Call Home DOTS server")
to refer to a DOTS client (or DOTS server) deployed in a Call Home
scenario (). DOTS Call Home agents may (or not)
be co-located with DOTS agents that are compliant with (see for more details).A Call Home DOTS client relies upon a variety of triggers to make use
of the Call Home function (e.g., scrubbing the traffic from the attack
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 Call
Home DOTS client.In a typical deployment scenario, the Call Home DOTS server is
enabled on a Customer Premises Equipment (CPE), which is aligned with
recent trends to enrich the CPE with advanced security features. For
example, the DOTS Call Home service can be part of services supported by
an ISP-managed CPE or a managed security service subscribed by the user.
Unlike classic DOTS deployments , a Call Home DOTS server
maintains a single DOTS signal channel session for each DOTS-capable
upstream provisioning domain .For instance, the Call Home DOTS server in the home network initiates
the signal channel Call Home in 'idle' time and then subsequently the
Call Home 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 Call Home 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). For example, 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.This document assumes that Call Home DOTS servers are provisioned
with a way to know how to reach the upstream Call Home DOTS client(s),
which could occur by a variety of means (e.g., ). The specification of such means are out of
scope of this document.More information about the applicability scope of the DOTS signal
channel Call Home is provided in .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 Section 1.2
of .DDoS Mitigation System (DMS) refers to a system that performs DDoS
mitigation.'Base DOTS signal channel' refers to .The meaning of the symbols in YANG tree diagrams are defined in and .(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 problems discussed in may be
encountered in many deployments (e.g., home networks, enterprise
networks, transit networks, data centers). 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. That is, attacks that are
issued, e.g., from within an enterprise network or a data center, will
thus be blocked before exiting these networks.An instantiation of the Call Home functional architecture is depicted
in .It is out of the scope of this document to identify an exhaustive
list of such deployments.Call Home DOTS agent relationships are similar to those discussed in
Section 2.3 of . For example, multiple
Call Home DOTS servers of the same domain can be associated with the
same Call Home DOTS client. A Call Home DOTS client may decide to
contact these Call Home DOTS servers sequentially, fork a mitigation
request to all of them, or select one Call Home DOTS server to place a
mitigation request. Such decision is implementation-specific.For some mitigations, a feedback may be required from an
administrator to confirm a filtering action. Means to seek for an
administrator's consent are deployment-specific. Indeed, a variety of
implementation options can be considered as a function of the Call Home
DOTS deployment: push notifications using a dedicated application,
Syslog, etc. It is out of the scope of this document to make
recommendations about how such interactions are implemented (see ).The Call Home DOTS server can be enabled on a border router or a
dedicated appliance. For the particular case of home networks, the Call
Home DOTS server functionality can be enabled on a managed CPE or be
bundled with a CPE management application that is provided by an ISP to
its subscribers. These managed services are likely to be designed to
hide the complexity of managing (including configuring) the CPE. For
example, managed CPEs support means to notify the user when a new device
is detected in order to seek a confirmation whether access should be
granted or not to the device. These means can be upgraded to interface
with the Call Home DOTS server. Customized settings can be configured by
users to control the notifications (e.g., triggers, type) and default
actions.The DOTS signal channel Call Home does not require nor preclude the
activation of the base DOTS signal channel . Some sample deployment
schemes are discussed in this section for illustration purposes.The network that hosts an attack source may also be subject to
inbound DDoS attacks. In that case, both the base DOTS signal channel
and DOTS signal channel Call Home may be enabled as shown in (Same DMS provider) or (Distinct DMS providers).Note that a DMS provider may not be on the default forwarding path of
an inbound DDoS attack traffic targeting a network (e.g., Network #B in
). Nevertheless, the DOTS signal channel
Call Home requires the DMS provider to be on the default forwarding path
of the outbound traffic from a given network.Figures and depict examples where the same
node embeds both base DOTS and DOTS Call Home agents. For example, a
DOTS server and a Call Home DOTS client may be enabled on the same
device within the infrastructure of a DMS provider (e.g., Node #i in
) or a DOTS client and a Call Home DOTS
server may be enabled on the same device within a source network (e.g.,
Node #j with Network #D shown in ) .Whether the same or distinct nodes are used to host base DOTS and
DOTS Call Home agents is specific to each domain. elaborates on the considerations
to unambiguously distinguish DOTS messages which belong to each of these
channels.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-initiated DOTS signal channel protocol . The role reversal that
occurs is at the (D)TLS layer; that is, (1) the Call Home DOTS server
acts as a DTLS client and the Call Home DOTS client acts as a DTLS
server or (2) the 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. The Call Home DOTS server initiates (D)TLS
handshake to the Call Home DOTS client.For example, a home network element (e.g., home router) co-located
with a Call Home DOTS server is the (D)TLS client. That is, the Call
Home DOTS server assumes the role of the (D)TLS client, but the
network element's role as a DOTS server remains the same.Existing certificate chains and mutual authentication mechanisms
between the DOTS agents are unaffected by the Call Home function. From
a deployment standpoint, and given the scale of Call Home DOTS servers
that may be involved, enabling means for automating the provisioning
of credentials on Call Home DOTS servers to authenticate to the Call
Home DOTS client is encouraged. It is out of the scope of this
document to elaborate on these means. illustrates a sample DOTS Call Home
flow exchange:The DOTS signal channel Call Home procedure is as follows:If UDP transport is used, the Call Home DOTS server begins by
initiating a DTLS connection to the Call Home DOTS client.If TCP is used, the Call Home DOTS server begins
by initiating a TCP connection to the Call Home DOTS client. Once
connected, the Call Home DOTS server continues to initiate a TLS
connection to the Call Home DOTS client.Peer DOTS agents may have mutual agreement to use
a specific port number, such as by explicit configuration or
dynamic discovery . The interaction
between the base DOTS signal channel and the Call Home is
discussed in .The Happy Eyeballs mechanism explained in Section
4.3 of is used
for initiating (D)TLS connections.Using this (D)TLS connection, the Call Home DOTS client may
request, withdraw, or retrieve the status of mitigation requests.
The Call Home DOTS client supplies the source information by means
of new attributes defined in .
The Heartbeat mechanism used for the DOTS
Call Home deviates from the one defined in Section 4.7 of . specifies the behavior to be followed by Call
Home DOTS agents.Once the (D)TLS section is established between the DOTS agents,
the Call Home DOTS client contacts the Call Home DOTS server to
retrieve the session configuration parameters (Section 4.5 of ). The Call Home 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 Call Home 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 Call Home DOTS client MAY trigger their
heartbeat requests immediately after receiving heartbeat probes from
its peer Call Home DOTS server.When an outgoing attack that saturates the outgoing link from the
Call Home DOTS server is detected and reported by a Call Home DOTS
client, the latter MUST continue to use the DOTS signal channel even
if no traffic is received from the Call Home DOTS server.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
signal channel even if the missing heartbeats allowed threshold
('missing-hb-allowed') is reached.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 the maximum 'missing-hb-allowed' threshold, the Call Home
DOTS server concludes the session is disconnected. Then, the Call
Home DOTS server MUST try to establish a new DOTS signal channel
session, preferably by resuming the (D)TLS session.A Call Home DOTS server MUST NOT support the Redirected Signaling
mechanism as specified in Section 4.6 of (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 MUST silently
discard such message as only a Call Home DOTS server can initiate a
new (D)TLS connection.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 request to the predefined resource
“.well-known/dots/redirect” with the following
attributes in the body of the PUT request:The FQDN of an alternate Call Home
DOTS client. It is also presented as reference identifier for
authentication purposes.This is a
mandatory attribute for DOTS signal Call Home. It MUST NOT be
used for base DOTS signal channel operations.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.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 with a 2.01 (Created), closes this connection and
establishes a connection with the new Call Home DOTS client. The
processing of the TTL is defined in Section 4.6 of . If the Call Home DOTS
server cannot service the PUT request, the response is rejected with
a 4.00 (Bad Request). shows a PUT request example to
convey the alternate Call 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 this
alternate Call Home DOTS client is 10 minutes.This specification extends the mitigation request defined in
Section 4.4.1 of to
convey the attack source information (e.g., source prefixes, source
port numbers). The DOTS client conveys the following new parameters
in the CBOR body of the mitigation request:A list of attacker IP prefixes used
to attack the target. Prefixes are represented using Classless
Inter-Domain Routing (CIDR) notation BCP
122 . As a reminder, the prefix
length MUST be less than or equal to 32 (or 128) for IPv4 (or
IPv6).The prefix list MUST NOT include
broadcast, loopback, or multicast addresses. These addresses are
considered as invalid values. Note that link-local addresses are
allowed. The Call Home DOTS client MUST validate that attacker
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 operations.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 any subrange
of 0-65535, for example, 0-1023, 1024-65535, or 1024-49151.
This is an optional attribute for the
base DOTS signal channel operations.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. Both ICMP and ICMPv6 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
operations.The 'source-prefix' parameter is a mandatory attribute when the
attack traffic information is signaled by a Call Home DOTS client
(i.e., the Call Home scenario depicted in ). The 'target-prefix' attribute MUST be
included in the mitigation request signaling the attack information
to a Call Home DOTS server. The 'target-uri' or 'target-fqdn'
parameters can be included in a mitigation request for diagnostic
purposes to notify the Call Home DOTS server domain administrator,
but SHOULD NOT be used to determine the target IP addresses.
'alias-name' is unlikely to be conveyed in a Call Home mitigation
request given that a target may be any IP resource and that there is
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
server, the Call Home DOTS client SHOULD include in its mitigation
request additional information such as 'source-port-range' or
'source-icmp-type-range' to disambiguate nodes sharing the same
'source-prefix'. IPv6 addresses/prefixes are sufficient to uniquely
identify a network endpoint, without need for port numbers or ICMP
type information. While this is also possible for IPv4, it is much
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 .Only immediate mitigation requests (i.e., 'trigger-mitigation'
set to 'true') are allowed; Call Home DOTS clients MUST NOT send
requests with 'trigger-mitigation' set to 'false'. Such requests
MUST be 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 shown in .The Call Home DOTS server MUST check that the 'source-prefix' is
within the scope of the Call Home DOTS server domain. Note that in a
DOTS Call Home scenario, the Call Home DOTS server considers, by
default, that any routeable IP prefix enclosed in 'target-prefix' is
within the scope of the Call Home DOTS client. Invalid mitigation
requests are handled as per Section 4.4.1 of .Note: These validation checks do not apply when the source
information is included as a hint in the context of the base
DOTS signal channel.The Call Home DOTS server domain administrator consent MAY be
required to block the traffic from the compromised device to the
attack target. An implementation MAY have a configuration knob to
block the traffic from the compromised device to the attack target
with or without DOTS server domain administrator consent.If 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 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 attack traffic information is identified by the Call Home
DOTS server or the Call Home DOTS server domain administrator as
legitimate traffic, the mitigation request is rejected with a 4.09
(Conflict) (e.g., when no consent is required from an administrator)
or a notification message with the 'conflict-clause' (Section 4.4.1
of ) set to the
following new value: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 Call Home DOTS server,
appropriate actions are enforced to block the attack traffic within
the source network. For example, if the Call Home DOTS server is
embedded in a CPE, it can program the packet processor to punt all
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. Note that the Call
Home DOTS client is informed about the progress of the attack
mitigation following the rules in Section 4.4.2 of .The DOTS agents follow the same procedures specified in for managing a mitigation
request. depicts an example of a network
provider that hosts a Call Home DOTS client and deploys a Carrier
Grade NAT (CGN) between the DOTS client domain and DOTS server
domain. In such cases, communicating an external IP address in a
mitigation request by a Call Home DOTS client is likely to be
discarded by the Call Home DOTS server because the external IP
address is not visible locally to the Call Home DOTS server (). The Call Home DOTS server is only aware of
the internal IP addresses/prefixes bound to its domain (i.e., those
used in the Internal Realm shown in ).
Thus, Call Home DOTS clients that are aware of the presence of
on-path CGNs MUST NOT include the external IP address and/or port
number identifying the suspect attack source (i.e., those used in
the External Realm shown in ), 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 or , 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 , if the target address is an
IPv4 address, the IPv4-converted IPv6 address of this target address
SHOULD be used.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.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 Figures and
), the Call Home 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. The
Call Home DOTS server proceeds with a NAT mapping table lookup using
the attack information (or a subset thereof) as a key. The lookup
can be local () or via a dedicated
administration interface that is offered by the CPE (). This identification allows the suspicious
device to be isolated while avoiding disturbances of other
services.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 (network provider) and
Figures and (source network).This document augments the "ietf-dots-signal-channel" (dots-signal)
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:The YANG/JSON mapping parameters to CBOR are listed in Table
1.Note: Implementers must check that the mapping output provided
by their YANG-to-CBOR encoding schemes is aligned with the content
of Table 1.The YANG/JSON mappings to CBOR for 'lower-port' and 'upper-port'
are already defined in Table 5 of .This module uses the common YANG types defined in and the data structure extension defined in
.This specification registers the following comprehension-optional
parameters (Table 2) in the IANA "DOTS Signal Channel CBOR Key Values"
registry .Note to the RFC Editor: Please delete TBA1-TBA8 once CBOR keys
are assigned from the 32768-49151 range.This document requests IANA to assign a new code from the "DOTS
Signal Channel Conflict Cause Codes" registry .CodeLabelDescriptionReference4 (TBA9)request-rejected-legitimate-trafficMitigation 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
"ns" subregistry within the "IETF XML Registry" : This document requests IANA to register the following YANG
module in the "YANG Module Names" subregistry within the "YANG Parameters" 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 11 of MUST be considered. DOTS
agents MUST authenticate each other using (D)TLS before a DOTS signal
channel 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. These filters can be automatically installed by
a Call Home DOTS server based on the configured or discovered peer Call
Home DOTS client(s).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 adding to a drop-list the source
address after a set number of unsuccessful authentication attempts.The DOTS Call Home signal channel can be misused by a misbehaving
Call Home DOTS client by arbitrarily signalling legitimate traffic as
being attack traffic or falsifying mitigation signals so that some
sources are disconnected or some traffic is rate-limited. Such
misbehaving Call Home DOTS clients may include sources identified by IP
addresses that are used for internal use only (that is, these addresses
are not visible outside a Call Home DOTS server domain). Absent explicit
policy (e.g., the Call Home DOTS client and server are managed by the
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 ). Means to
seek the consent are implementation-specific.Call Home DOTS agents may interact with on-path address sharing
functions to retrieve an internal IP addresss/external IP address
mapping () 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 or
Section 4 of ).The considerations discussed in were
taken into account to assess whether the DOTS Call Home introduces
privacy threats.Concretely, the protocol does not leak any new information that can
be used to ease surveillance. In particular, the Call Home DOTS server
is not required to share information that is local to its network (e.g.,
internal identifiers of an attack source) with the 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
requests received from a Call Home DOTS client. For example, a security
service running on the CPE may require an administrator's consent before
the CPE acts upon the mitigation request indicated by the Call Home DOTS
client. How the consent is obtained is out of scope of this
document.Note that a Call Home DOTS server can seek an administrator's
consent, validate the request by inspecting the relevant traffic for
attack signatures, or proceed with both courses of action.The DOTS Call Home is only advisory in nature. Concretely, the DOTS
Call Home does not impose any action to be enforced within the network
hosting an attack source; it is up to the Call Home DOTS server (and/or
network administrator) to decide whether and which actions are
required.Moreover, the DOTS Call Home 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 Call Home DOTS server
are deployment-specific. For example, a Call Home DOTS client may rely
on the output of some DDoS detection systems (flow exports or similar
functions) deployed within the DOTS client domain to detect potential
outbound DDoS attacks or on abuse claims received from remote victim
networks. These systems may be misused to track users and infer their
activities. Such misuses are not required to achieve 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 .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.Benjamin Kaduk's AD review is valuable. Many thanks to him for the
detailed review.Thanks to Radia Perlman and David Schinazi for the directorate
reviews.Thanks to Ebben Aries for the yangdoctors review.Thanks to Éric Vyncke, Roman Danyliw, Barry Leiba, Robert
Wilton, and Erik Kline for the IESG review.Secure by Design: Improving the cyber security of consumer
Internet of Things ReportUK Department for Digital Culture, Media &
SportDOTS Signal Channel CBOR Key ValuesDOTS Signal Channel Conflict Cause CodesSlowloris HTTP DoSInternet of Things (IoT) devices are becoming more and more
prevalent, in particular in home networks. With compute and memory
becoming cheaper and cheaper, various types of IoT devices become
available in the consumer market at affordable prices. But on the
downside, there is a corresponding threat since most of these IoT
devices are bought off-the-shelf and most manufacturers haven't
considered security in the product design (e.g., ). IoT devices deployed in home networks
can be easily compromised, they often do not have an easy mechanism to
upgrade, and even when upgradable, IoT manufacturers may cease
manufacture and/or discontinue patching vulnerabilities on IoT devices
(Sections 5.4 and 5.5 of ). 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. Such misbehaviors can
cause collateral damage that will affect end users, and can also harm
the reputation of an Internet Service Provider (ISP) for being a source
of attack traffic.Nowadays, network devices in a home network can offer network
security functions (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. It is natural to seek to provide DDoS defense in these
devices as well, and 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 within the
ISP's network.Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris
, and Transport Layer Security (TLS)
renegotiation are difficult to detect on a home network device without
adversely affecting its performance. The reason is that 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. The reader may refer to Section
2 of for a brief definition of slow and
fast paths.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 because of the
memory and CPU limitations of the home routers. Furthermore, for certain
DDoS attacks the logic needed to distinguish legitimate traffic from
attack traffic on a per-packet basis is complex. This complexity is
because that the packet itself may look "legitimate" and no attack
signature can be identified. The anomaly can be identified only after
detailed statistical analysis. In addition, network security services in
home networks may not be able to detect all types of DDoS attacks using
DPI. ISPs offering DDoS mitigation services have a DDoS detection
capability that relies upon anomaly detection to identify zero day DDoS
attacks and to detect DDoS attacks that cannot be detected using
signatures and rate-limit techniques.ISPs can detect some DDoS attacks originating from a home network
(e.g., Section 2.6 of ), but the ISP
usually does not have a mechanism to detect which device in the home
network is generating the DDoS attack traffic. The primary reason for
this is that devices in an IPv4 home network are typically behind a
Network Address Translation (NAT) border .
Even in case of an IPv6 home network, although the ISP can identify the
infected device in the home network launching the DDoS traffic by
tracking its unique IPv6 address, the infected device can easily change
its IPv6 address to evade remediation. 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.With the DOTS signal channel Call Home, there is a chance that two
DOTS agents can simultaneously establish two DOTS signal channels with
different directions (base DOTS signal channel and DOTS signal channel
Call Home). Here is one example drawn from the home network.
Nevertheless, the outcome of the discussion is not specific to these
networks, but applies to any DOTS Call Home scenario.In the Call Home scenario, the Call Home DOTS server in, for example,
the home network can mitigate the DDoS attacks launched by the
compromised device in its domain by receiving the mitigation request
sent by the Call Home DOTS client in the ISP environment. In addition,
the DOTS client in the home network can initiate a mitigation request to
the DOTS server in the ISP environment to ask for help when the home
network is under a DDoS attack. Such Call Home DOTS server and DOTS
client in the home network can co-locate in the same home network
element (e.g., the Customer Premises Equipment). In this case, with the
same peer at the same time the home network element will have the base
DOTS signal channel defined in and the DOTS signal channel
Call Home defined in this specification. Thus, these two signal channels
need to be distinguished when they are both supported. Two approaches
have been considered for distinguishing the two DOTS signal channels,
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
can be separated unambiguously and easily. For example, the CPE uses the
port number 4646 allocated in to initiate the basic signal
channel to the ISP when it acts as the DOTS client, and uses another
port number to initiate the signal channel Call Home. Based on the
different port numbers, the ISP can directly decide which kind of
procedures should follow immediately after it receives the DOTS
messages. This approach just requires two (D)TLS sessions to be
established respectively for the basic signal channel and signal channel
Call Home.The other approach is signaling the role of each DOTS agent (e.g., by
using the DOTS data channel as depicted in ).
For example, the DOTS agent in the home network first initiates a DOTS
data channel to the peer DOTS agent in the ISP environment, at this time
the DOTS agent in the home network is the DOTS client and the peer DOTS
agent in the ISP environment is the DOTS server. After that, the DOTS
agent in the home network retrieves the DOTS Call Home capability of the
peer DOTS agent. If the peer supports the DOTS Call Home, the DOTS agent
needs to subscribe to the peer to use this extension. Then, the reversal
of DOTS role can be recognized as done by both DOTS agents. When the
DOTS agent in the ISP environment, which now is the DOTS client, wants
to filter the attackers' traffic, it requests the DOTS agent in the home
network, which now is the DOTS server, for help.Signaling the role will complicate the DOTS protocols, and this
complexity is not required in context where the DOTS Call Home is not
required or only when the DOTS Call Home is needed. Besides, the DOTS
data channel may not work during attack time. Even if changing the above
example from using the DOTS data channel to the DOTS signal channel, the
more procedures will still reduce the efficiency. Using the dedicated
port number is much easier and more concise compared to the second
approach, and its cost that establishing two (D)TLS sessions is much
less. So, using a dedicated port number for the DOTS Call Home is
recommended in this specification. The dedicated port number can be
configured locally or discovered using means such as .