Controlling Filtering Rules
Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
ChannelNTT CommunicationsGranPark 16F 3-4-1 Shibaura, Minato-kuTokyo108-8118Japankaname@nttv6.jpOrangeRennes35000Francemohamed.boucadair@orange.comMcAfee, Inc.Embassy Golf Link Business ParkBangaloreKarnataka560071Indiakondtir@gmail.comLepidumJapannagata@lepidum.co.jpDOTSMitigationAutomationFilteringThis document specifies an extension to the DOTS signal channel so
that DOTS clients can control their filtering rules when an attack
mitigation is active.Particularly, this extension allows a DOTS client to activate or
de-activate existing filtering rules during a DDoS attack. The
characterization of these filtering rules is supposed to be conveyed by
a DOTS client during an idle time by means of the DOTS data channel
protocol.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: Controlling Filtering Rules Using Distributed
Denial-of-Service Open Threat Signaling (DOTS) Signal Channel";reference: RFC XXXX[RFCXXXX]Please update these statements with the RFC number to be
assigned to the following documents:"RFC SSSS: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification" (used to be )"RFC DDDD: Distributed Denial-of-Service Open Threat Signaling
(DOTS) Data Channel Specification" (used to be )Please update the "revision" date of the YANG module.The DOTS data channel protocol is used for bulk data
exchange between DOTS agents to improve the coordination of all the
parties involved in the response to the DDoS attack. Filter management
is one of its tasks which enables a DOTS client to retrieve the
filtering capabilities of a DOTS server and to manage filtering rules.
These Filtering rules are used for dropping or rate-limiting unwanted
traffic, and permitting accept-listed traffic.Unlike the DOTS signal channel , the DOTS data channel
is not expected to deal with attack conditions. As such, an issue that
might be encountered in some deployments is when filters installed by
means of DOTS data channel protocol may not function as expected
during DDoS attacks or exacerbate an ongoing DDoS attack. The DOTS
data channel cannot be used then to change these filters, which may
complicate DDoS mitigation operations .A typical case is a DOTS client which configures during 'idle' time
(i.e., no mitigation is active) some filtering rules using DOTS data
channel to permit traffic from accept-listed sources, but during a
volumetric DDoS attack the DDoS mitigator identifies the source
addresses/prefixes in the accept-listed filtering rules are attacking
the target. For example, an attacker can spoof the IP addresses of
accept-listed sources to generate attack traffic or the attacker can
compromise the accept-listed sources and program them to launch a DDoS
attack. is designed so
that the DDoS server notifies the conflict to the DOTS client (that
is, 'conflict-cause' parameter set to 2 (Conflicts with an existing
accept list)), but the DOTS client may not be able to withdraw the
accept-list rules during the attack period due to the high-volume
attack traffic saturating the inbound link. In other words, the DOTS
client cannot use the DOTS data channel to withdraw the accept-list
filters when the DDoS attack is in progress. This assumes that this
DOTS client is the owner of the filtering rule.This specification addresses the problems discussed in by adding the capability of managing
filtering rules using the DOTS signal channel, which enables a DOTS
client to request the activation or deactivation of filtering rules
during a DDoS attack.The DOTS signal channel protocol is designed to enable a
DOTS client to contact a DOTS server for help even under severe
network congestion conditions. Therefore, extending the DOTS signal
channel protocol to manage the filtering rules during a attack will
enhance the protection capability offered by DOTS protocols.Note: The experiment at the IETF103 hackathon showed that even when the incoming link
is saturated by DDoS attack traffic, the DOTS client can signal
mitigation requests using the DOTS signal channel over the
saturated link.Conflicts that are induced by filters installed by other DOTS
clients of the same domain are not discussed in this
specification.Sample examples are provided in , in
particular: illustrates how the filter
control extension is used when conflicts with ACLs are detected by
a DOTS server. shows how a DOTS client can
instruct a DOTS server to safely forward some specific traffic in
'attack' time. shows how a DOTS client can
react if DDoS traffic is still being forwarded to the DOTS client
domain even if mitigation requests were sent to a DOTS server.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 tree diagrams is defined in .The filtering rules eventually managed using the DOTS signal
channel are created a priori by the same DOTS client using the DOTS
data channel. Managing conflicts with filters installed by other DOTS
clients of the same domain is out of scope.As discussed in Section 4.4.1 of , a DOTS client must use
the same 'cuid' for both the signal and data channels. This
requirement is meant to facilitate binding DOTS channels used by the
same DOTS client.The DOTS signal and data channels from a DOTS client may or may not
use the same DOTS server. Nevertheless, the scope of the mitigation
request, alias, and filtering rules are not restricted to the DOTS
server but to the DOTS server domain. To that aim, DOTS servers within
a domain are assumed to have a mechanism to coordinate the mitigation
requests, aliases, and filtering rules to coordinate their decisions
for better mitigation operation efficiency. The exact details about
such mechanism is out of scope of this document.A filtering rule controlled by the DOTS signal channel is
identified by its Access Control List (ACL) name (Section 7.2 of ). Note that an ACL name
unambiguously identifies an ACL bound to a DOTS client, but the same
name may be used by distinct DOTS clients.The activation or deactivation of an ACL by the signal channel
overrides the 'activation-type' (defined in Section 7.2 of ) a priori conveyed with
the filtering rules using the DOTS data channel.This specification extends the mitigation request defined in
Section 4.4.1 of
to convey the intended control of the configured filtering rules.
Concretely, the DOTS client conveys the following parameters in the
CBOR body of a mitigation request:A name of an access list defined using
the DOTS data channel (Section 7.2 of ) that is associated
with the DOTS client.As a reminder, an
ACL is an ordered list of Access Control Entries (ACE). Each
Access Control Entry has a list of match criteria and a list of
actions . The
list of configured ACLs can be retrieved using the DOTS data
channel during 'idle' time. This is an
optional attribute.Indicates the activation type of
an ACL overriding the existing 'activation-type' installed by
the DOTS client using the DOTS data channel. As a reminder, this attribute can be set to
'deactivate', 'immediate', or 'activate-when-mitigating' as
defined in .
Note that both 'immediate' and
'activate-when-mitigating' have an immediate effect when a
mitigation request is being processed by the DOTS server.
This is an optional attribute.The JSON/YANG mapping to CBOR for
'activation-type' is shown in Table 1.A DOTS client may include acl-* attributes in a mitigation
request having a new or an existing 'mid'. When acl-* attributes are
to be included in a mitigation request with an existing 'mid', the
DOTS client MUST repeat all the other parameters as sent in the
original mitigation request (i.e., having that 'mid') apart from a
possible change to the lifetime parameter value.It is RECOMMENDED for a DOTS client to subscribe to asynchronous
notifications of the attack mitigation, as detailed in Section
4.4.2.1 of . If
not, the polling mechanism in Section 4.4.2.2 of has to be followed by
the DOTS client.A DOTS client MUST NOT use the filtering control over DOTS signal
channel in 'idle' time; such requests MUST be discarded by the DOTS
server with 4.00 (Bad Request). By default, ACL-related operations
are achieved using the DOTS data channel when no attack is
ongoing.A DOTS client relies on the information received from the DOTS
server and/or local information to the DOTS client domain to trigger
a filter control request. Only filters that are pertinent for an
ongoing mitigation should be controlled by a DOTS client using the
DOTS signal channel.If the DOTS server does not find the ACL name conveyed in the
mitigation request in its configuration data for this DOTS client,
it MUST respond with a "4.04 (Not Found)" error response code.If the DOTS server finds the ACL name for this DOTS client, and
assuming the request passed the validation checks in , the DOTS server MUST
proceed with the 'activation-type' update. The update is immediately
enforced by the DOTS server and will be maintained as the new
activation type for the ACL name even after the termination of the
mitigation request. In addition, the DOTS server MUST update the
lifetime of the corresponding ACL similar to the update when a
refresh request is received using the DOTS data channel.If, during an active mitigation, the 'activation-type' is changed
at the DOTS server (e.g., as a result of an external action) for an
ACL bound to a DOTS client, the DOTS server notifies that DOTS
client with the change by including the corresponding acl-*
parameters in an asynchronous notification (the DOTS client is
observing the active mitigation) or in a response to a polling
request (Section 4.4.2.2 of ).This specification does not require any modification to the
efficacy update and the withdrawal procedures defined in . In particular,
ACL-related clauses are not included in a PUT request used to send
an efficacy update and DELETE requests.This document augments the "ietf-dots-signal-channel" DOTS
signal YANG module defined in for managing
filtering rules.This document defines the YANG module
"ietf-dots-signal-control", which has the following tree
structure:This section provides sample examples to illustrate the behavior
specified in . These examples are
provided for illustration purposes; they should not be considered as
deployment recommendations.Let's consider a DOTS client which contacts its DOTS server during
'idle' time to install an accept-list allowing for UDP traffic issued
from 2001:db8:1234::/48 with a destination port number 443 to be
forwarded to 2001:db8:6401::2/127. It does so by sending, for example,
a PUT request shown in .Some time later, consider that a DDoS attack is detected by the
DOTS client on 2001:db8:6401::2/127. Consequently, the DOTS client
sends a mitigation request to its DOTS server as shown in .The DOTS server accepts immediately the request by replying with
2.01 (Created) ().Assuming the DOTS client subscribed to asynchronous notifications,
when the DOTS server concludes that some of the attack sources belong
to 2001:db8:1234::/48, it sends a notification message with 'status'
code set to '1 (Attack mitigation is in progress)' and
'conflict-cause' set to '2' (conflict-with-acceptlist) to the DOTS
client to indicate that this mitigation request is in progress, but a
conflict is detected.Upon receipt of the notification message from the DOTS server, the
DOTS client sends a PUT request to deactivate the "an-accept-list" ACL
as shown in .The DOTS client can also decide to send a PUT request to deactivate
the "an-accept-list" ACL, if suspect traffic is received from an
accept-listed source (2001:db8:1234::/48). The structure of that PUT
is the same as the one shown in .Then, the DOTS server deactivates "an-accept-list" ACL and replies
with 2.04 (Changed) response to the DOTS client to confirm the
successful operation. The message body is similar to the one depicted
in .Once the attack is mitigated, the DOTS client may use the data
channel to retrieve its ACLs maintained by the DOTS server. As shown
in , the activation type is set to
'deactivate' as set by the signal channel () instead of the type initially set using the
data channel ().Let's consider a DOTS client which contacts its DOTS server during
'idle' time to install an accept-list allowing for UDP traffic issued
from 2001:db8:1234::/48 to be forwarded to 2001:db8:6401::2/127. It
does so by sending, for example, a PUT request shown in . The DOTS server installs this filter with a
"deactivated" state.Sometime later, consider that a UDP DDoS attack is detected by the
DOTS client on 2001:db8:6401::2/127 but the DOTS client wants to let
the traffic from 2001:db8:1234::/48 to be accept-listed to the DOTS
client domain. Consequently, the DOTS client sends a mitigation
request to its DOTS server as shown in .The DOTS server activates "my-accept-list" ACL and replies with
2.01 (Created) response to the DOTS client to confirm the successful
operation.This section describes a scenario in which a DOTS client activates
a drop-list or a rate-limit filter during an attack.Consider a DOTS client that contacts its DOTS server during 'idle'
time to install an accept-list that rate-limits all (or a part
thereof) traffic to be forwarded to 2001:db8:123::/48 as a last resort
countermeasure whenever required. It does so by sending, for example,
a PUT request shown in . The DOTS server
installs this filter with a "deactivated" state.Consider now that a DDoS attack is detected by the DOTS client on
2001:db8:123::/48. Consequently, the DOTS client sends a mitigation
request to its DOTS server ().For some reason (e.g., the DOTS server, or the mitigator, is
lacking a capability or capacity), the DOTS client is still receiving
the attack trafic which saturates available links. To soften the
problem, the DOTS client decides to activate the filter that
rate-limits the traffic destined to the DOTS client domain. To that
aim, the DOTS client sends the mitigation request to its DOTS server
shown in .Then, the DOTS server activates "my-ratelimit-list" ACL and replies
with 2.04 (Changed) response to the DOTS client to confirm the
successful operation.This specification registers the 'activation-type' parameter in the
IANA "DOTS Signal Channel CBOR Key Values" registry established by
.The 'activation-type' is a comprehension-required parameter. The
'acl-list' and 'acl-name' parameters are defined as
comprehension-required parameters in Table 6 in . Following the rules in
, if the DOTS
server does not understand the 'acl-list' or 'acl-name' or
'activation-type' attributes, it responds with a "4.00 (Bad Request)"
error response code.Note to the RFC Editor: Please delete (TBD1) once the CBOR key
is assigned from the (0x0001 - 0x3FFF) range.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 .The security considerations discussed in and need to be taken into
account.A compromised DOTS client can use the filtering control capability to
exacerbate an ongoing attack. Likewise, such compromised DOTS client may
abstain from reacting to an ACL conflict notification received from the
DOTS server during attacks. These are not new attack vectors, but
variations of threats discussed in and . DOTS operators should
carefully monitor and audit DOTS agents to detect misbehavior and to
deter misuse.Thank you to Takahiko Nagata, Wei Pan, Xia Liang, Jon Shollow, and
Dan Wing for the comments.DOTS Interop test report, IETF 103 HackathonNTT CommunicationsGranPark 16F 3-4-1 Shibaura, Minato-kuTokyo108-8118Japankaname@nttv6.jpJ.NCC GroupHuawe