rfc9133.original   rfc9133.txt 
DOTS K. Nishizuka Internet Engineering Task Force (IETF) K. Nishizuka
Internet-Draft NTT Communications Request for Comments: 9133 NTT Communications
Intended status: Standards Track M. Boucadair Category: Standards Track M. Boucadair
Expires: December 27, 2020 Orange ISSN: 2070-1721 Orange
T. Reddy T. Reddy.K
McAfee Akamai
T. Nagata T. Nagata
Lepidum Lepidum
June 25, 2020 September 2021
Controlling Filtering Rules Using Distributed Denial-of-Service Open Controlling Filtering Rules Using Distributed Denial-of-Service Open
Threat Signaling (DOTS) Signal Channel Threat Signaling (DOTS) Signal Channel
draft-ietf-dots-signal-filter-control-07
Abstract Abstract
This document specifies an extension to the Distributed Denial-of- This document specifies an extension to the Distributed Denial-of-
Service Open Threat Signaling (DOTS) signal channel protocol so that Service Open Threat Signaling (DOTS) signal channel protocol so that
DOTS clients can control their filtering rules when an attack DOTS clients can control their filtering rules when an attack
mitigation is active. mitigation is active.
Particularly, this extension allows a DOTS client to activate or de- Particularly, this extension allows a DOTS client to activate or
activate existing filtering rules during a DDoS attack. The deactivate existing filtering rules during a Distributed Denial-of-
characterization of these filtering rules is conveyed by a DOTS Service (DDoS) attack. The characterization of these filtering rules
client during an idle time (i.e., no mitigation is active) by means is conveyed by a DOTS client during an 'idle' time (i.e., no
of the DOTS data channel protocol. mitigation is active) by means of the DOTS data channel protocol.
Editorial Note (To be removed by RFC Editor)
Please update these statements within the document with the RFC
number to be assigned to this document:
o "This version of this YANG module is part of RFC XXXX;"
o "RFC XXXX: Controlling Filtering Rules Using Distributed Denial-
of-Service Open Threat Signaling (DOTS) Signal Channel";
o reference: RFC XXXX
o [RFCXXXX]
Please update the "revision" date of the YANG module.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on December 27, 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9133.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Problem
1.2. Controlling Filtering Rules Using DOTS Signal Channel . . 4 1.2. Controlling Filtering Rules Using DOTS Signal Channel
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology
3. Controlling Filtering Rules of a DOTS Client . . . . . . . . 5 3. Controlling Filtering Rules of a DOTS Client
3.1. Binding DOTS Data and Signal Channels . . . . . . . . . . 5 3.1. Binding DOTS Data and Signal Channels
3.2. DOTS Signal Channel Extension . . . . . . . . . . . . . . 6 3.2. DOTS Signal Channel Extension
3.2.1. Parameters and Behaviors . . . . . . . . . . . . . . 6 3.2.1. Parameters and Behaviors
3.2.2. DOTS Signal Filtering Control Module . . . . . . . . 9 3.2.2. DOTS Signal Filtering Control Module
3.2.2.1. Tree Structure . . . . . . . . . . . . . . . . . 10 3.2.2.1. Tree Structure
3.2.2.2. YANG Module . . . . . . . . . . . . . . . . . . . 10 3.2.2.2. YANG Module
4. Some Examples . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Some Examples
4.1. Conflict Handling . . . . . . . . . . . . . . . . . . . . 12 4.1. Conflict Handling
4.2. On-Demand Activation of an Accept-List Filter . . . . . . 17 4.2. On-Demand Activation of an Accept-List Filter
4.3. DOTS Servers/Mitigators Lacking Capacity . . . . . . . . 18 4.3. DOTS Servers/Mitigators Lacking Capacity
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations
5.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 22 5.1. DOTS Signal Channel CBOR Key Values Subregistry
5.2. DOTS Signal Filtering Control YANG Module . . . . . . . . 23 5.2. A New YANG Module
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 7. References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Normative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 24 7.2. Informative References
8.2. Informative References . . . . . . . . . . . . . . . . . 25 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses
1. Introduction 1. Introduction
1.1. The Problem 1.1. The Problem
In the Distributed Denial-of-Service Open Threat Signaling (DOTS) In the Distributed Denial-of-Service Open Threat Signaling (DOTS)
architecture [I-D.ietf-dots-architecture], DOTS clients and servers architecture [RFC8811], DOTS clients and servers communicate using
communicate using both a signal channel protocol [RFC8782] and a data both a signal channel protocol [RFC9132] and a data channel protocol
channel protocol [RFC8783]. [RFC8783].
The DOTS data channel protocol [RFC8783] is used for bulk data The DOTS data channel protocol [RFC8783] is used for bulk data
exchange between DOTS agents to improve the coordination of parties exchange between DOTS agents to improve the coordination of parties
involved in the response to a Distributed Denial-of-Service (DDoS) involved in the response to a Distributed Denial-of-Service (DDoS)
attack. Filter management is one of its tasks which enables a DOTS attack. Filter management, which is one of the tasks of the DOTS
client to retrieve the filtering capabilities of a DOTS server and to data channel protocol, enables a DOTS client to retrieve the
manage filtering rules. Typically, these filtering rules are used filtering capabilities of a DOTS server and to manage filtering
for dropping or rate-limiting unwanted traffic, and permitting rules. Typically, these filtering rules are used for dropping or
accept-listed traffic. rate-limiting unwanted traffic, and permitting accept-listed traffic.
The DOTS signal channel protocol [RFC8782] is designed to be The DOTS signal channel protocol [RFC9132] is designed to be
resilient under extremely hostile network conditions and provides resilient under extremely hostile network conditions and provides
continued contact between DOTS agents even as DDoS attack traffic continued contact between DOTS agents even as DDoS attack traffic
saturates the link. The DOTS signal channel can be established saturates the link. The DOTS signal channel can be established
between two DOTS agents prior to or during an attack. At any time, between two DOTS agents prior to or during an attack. At any time,
the DOTS client may send mitigation requests (as per Section 4.4 of the DOTS client may send mitigation requests (as per Section 4.4 of
[RFC8782]) to a DOTS server over the active signal channel. While [RFC9132]) to a DOTS server over the active signal channel. While
mitigation is active, the DOTS server periodically sends status mitigation is active, the DOTS server periodically sends status
messages to the DOTS client, including basic mitigation feedback messages to the DOTS client, including basic mitigation feedback
details. In case of a massive DDoS attack that saturates the details. In case of a massive DDoS attack that saturates the
incoming link(s) to the DOTS client, all traffic from the DOTS server incoming link(s) to the DOTS client, all traffic from the DOTS server
to the DOTS client will likely be dropped. However, the DOTS server to the DOTS client will likely be dropped. However, the DOTS server
may still receive DOTS messages sent from the DOTS client over the may still receive DOTS messages sent from the DOTS client over the
signalling channel thanks to the heartbeat requests keeping the signaling channel thanks to the heartbeat requests keeping the
channel active (as described in Section 4.7 of [RFC8782]). channel active (as described in Section 4.7 of [RFC9132]).
Unlike the DOTS signal channel protocol, the DOTS data channel Unlike the DOTS signal channel protocol, the DOTS data channel
protocol is not expected to deal with attack conditions. As such, an protocol is not expected to deal with attack conditions. As such, an
issue that might be encountered in some deployments is when filters issue that might be encountered in some deployments is when filters
installed by means of the DOTS data channel protocol may not function installed by means of the DOTS data channel protocol may not function
as expected during DDoS attacks or, worse, exacerbate an ongoing DDoS as expected during DDoS attacks or, worse, exacerbate an ongoing DDoS
attack. In such conditions the DOTS data channel protocol cannot be attack. In such conditions, the DOTS data channel protocol cannot be
used to change these filters, which may complicate DDoS mitigation used to change these filters, which may complicate DDoS mitigation
operations [Interop]. operations [INTEROP].
A typical case is a conflict between filtering rules installed by a A typical case is a conflict between filtering rules installed by a
DOTS client and the mitigation actions of a DDoS mitigator. DOTS client and the mitigation actions of a DDoS mitigator.
Consider, for instance, a DOTS client that configures during 'idle' Consider, for instance, a DOTS client that configures during 'idle'
time (i.e., no mitigation is active) some filtering rules using the time (i.e., no mitigation is active) some filtering rules using the
DOTS data channel protocol to permit traffic from accept-listed DOTS data channel protocol to permit traffic from accept-listed
sources. However, during a volumetric DDoS attack the DDoS mitigator sources. However, during a volumetric DDoS attack, the DDoS
identifies the source addresses/prefixes in the accept-listed mitigator identifies the source addresses/prefixes in the accept-
filtering rules are attacking the target. For example, an attacker listed filtering rules are attacking the target. For example, an
can spoof the IP addresses of accept-listed sources to generate attacker can spoof the IP addresses of accept-listed sources to
attack traffic or the attacker can compromise the accept-listed generate attack traffic, or the attacker can compromise the accept-
sources and program them to launch a DDoS attack. listed sources and program them to launch a DDoS attack.
[RFC8782] is designed so that the DDoS server notifies the above [RFC9132] is designed so that the DDoS server notifies the above
conflict to the DOTS client (that is, 'conflict-cause' parameter set conflict to the DOTS client (that is, the 'conflict-cause' parameter
to 2 (Conflicts with an existing accept list)), but the DOTS client is set to 2 (conflict-with-acceptlist)), but the DOTS client may not
may not be able to withdraw the accept-list rules during the attack be able to withdraw the accept-list rules during the attack period
period due to the high-volume attack traffic saturating the inbound due to the high-volume attack traffic saturating the inbound link to
link to the DOTS client domain. In other words, the DOTS client the DOTS client domain. In other words, the DOTS client cannot use
cannot use the DOTS data channel protocol to withdraw the accept-list the DOTS data channel protocol to withdraw the accept-list filters
filters when a DDoS attack is in progress. when a DDoS attack is in progress.
1.2. Controlling Filtering Rules Using DOTS Signal Channel 1.2. Controlling Filtering Rules Using DOTS Signal Channel
This specification addresses the problems discussed in Section 1.1 by This specification addresses the problems discussed in Section 1.1 by
adding a capability for managing filtering rules using the DOTS adding a capability for managing filtering rules using the DOTS
signal channel protocol, which enables a DOTS client to request the signal channel protocol, which enables a DOTS client to request the
activation (or deactivation) of filtering rules during a DDoS attack. activation (or deactivation) of filtering rules during a DDoS attack.
Note that creating these filtering rules is still the responsibility Note that creating these filtering rules is still the responsibility
of the DOTS data channel [RFC8783]. of the DOTS data channel [RFC8783].
The DOTS signal channel protocol is designed to enable a DOTS client The DOTS signal channel protocol is designed to enable a DOTS client
to contact a DOTS server for help even under severe network to contact a DOTS server for help even under severe network
congestion conditions. Therefore, extending the DOTS signal channel congestion conditions. Therefore, extending the DOTS signal channel
protocol to manage the filtering rules during an attack will enhance protocol to manage the filtering rules during an attack will enhance
the protection capability offered by DOTS protocols. the protection capability offered by DOTS protocols.
Note: The experiment at the IETF103 hackathon [Interop] showed | Note: The experiment at the IETF 103 hackathon [INTEROP] showed
that even when the inbound link is saturated by DDoS attack | that even when the inbound link is saturated by DDoS attack
traffic, the DOTS client can signal mitigation requests using the | traffic, the DOTS client can signal mitigation requests using
DOTS signal channel over the saturated link. | the DOTS signal channel over the saturated link.
Conflicts that are induced by filters installed by other DOTS clients Conflicts that are induced by filters installed by other DOTS clients
of the same domain are not discussed in this specification. of the same domain are not discussed in this specification.
An augmentation to the DOTS signal channel YANG module is defined in An augmentation to the DOTS signal channel YANG module is defined in
Section 3.2.2. Section 3.2.2.
Sample examples are provided in Section 4, in particular: Sample examples are provided in Section 4, in particular:
o Section 4.1 illustrates how the filter control extension is used * Section 4.1 illustrates how the filter control extension is used
when conflicts with Access Control Lists (ACLs) are detected and when conflicts with Access Control Lists (ACLs) are detected and
reported by a DOTS server. reported by a DOTS server.
o Section 4.2 shows how a DOTS client can instruct a DOTS server to * Section 4.2 shows how a DOTS client can instruct a DOTS server to
safely forward some specific traffic in 'attack' time. safely forward some specific traffic in 'attack' time.
o Section 4.3 shows how a DOTS client can react if the DDoS traffic * Section 4.3 shows how a DOTS client can react if the DDoS traffic
is still being forwarded to the DOTS client domain even if is still being forwarded to the DOTS client domain even if
mitigation requests were sent to a DOTS server. mitigation requests were sent to a DOTS server.
The JavaScript Object Notation (JSON) encoding of YANG-modeled data The JavaScript Object Notation (JSON) encoding of YANG-modeled data
[RFC7951] is used to illustrate the examples. [RFC7951] is used to illustrate the examples.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The reader should be familiar with the terms defined in [RFC8612]. The reader should be familiar with the terms defined in [RFC8612].
The terminology for describing YANG modules is defined in [RFC7950]. The terminology for describing YANG modules is defined in [RFC7950].
The meaning of the symbols in the tree diagram is defined in The meaning of the symbols in the tree diagram is defined in
[RFC8340]. [RFC8340] and [RFC8791].
3. Controlling Filtering Rules of a DOTS Client 3. Controlling Filtering Rules of a DOTS Client
3.1. Binding DOTS Data and Signal Channels 3.1. Binding DOTS Data and Signal Channels
The filtering rules eventually managed using the DOTS signal channel The filtering rules eventually managed using the DOTS signal channel
protocol are created a priori by the same DOTS client using the DOTS protocol are created a priori by the same DOTS client using the DOTS
data channel protocol. Managing conflicts with filters installed by data channel protocol. Managing conflicts with filters installed by
other DOTS clients of the same domain is out of scope. other DOTS clients of the same domain is out of scope.
As discussed in Section 4.4.1 of [RFC8782], a DOTS client must use As discussed in Section 4.4.1 of [RFC9132], a DOTS client must use
the same 'cuid' for both the DOTS signal and data channels. This the same 'cuid' for both the DOTS signal and data channels. This
requirement is meant to facilitate binding DOTS channels used by the requirement is meant to facilitate binding DOTS channels used by the
same DOTS client. same DOTS client.
The DOTS signal and data channels from a DOTS client may or may not 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 use the same DOTS server. Nevertheless, the scope of the mitigation
request, alias, and filtering rules are not restricted to the DOTS request, alias, and filtering rules are not restricted to the DOTS
server but to the DOTS server domain. To that aim, DOTS servers server but to the DOTS server domain. To that aim, DOTS servers
within a domain are assumed to have a mechanism to coordinate the within a domain are assumed to have a mechanism to coordinate the
mitigation requests, aliases, and filtering rules to coordinate their mitigation requests, aliases, and filtering rules to coordinate their
decisions for better mitigation operation efficiency. The exact decisions for better mitigation operation efficiency. The exact
details about such mechanism is out of the scope of this document. details about such a mechanism is out of the scope of this document.
A filtering rule controlled by the DOTS signal channel is identified A filtering rule controlled by the DOTS signal channel is identified
by its ACL name (Section 4.3 of [RFC8782]). Note that an ACL name by its ACL name (Section 4.3 of [RFC8783]). Note that an ACL name
unambiguously identifies an ACL bound to a DOTS client, but the same unambiguously identifies an ACL bound to a DOTS client, but the same
name may be used by distinct DOTS clients. name may be used by distinct DOTS clients.
The activation or deactivation of an ACL by the DOTS signal channel The activation or deactivation of an ACL by the DOTS signal channel
overrides the 'activation-type' (defined in Section 4.3 of [RFC8783]) overrides the 'activation-type' (defined in Section 4.3 of [RFC8783])
a priori conveyed with the filtering rules using the DOTS data a priori conveyed with the filtering rules using the DOTS data
channel protocol. channel protocol.
Once the attack is mitigated, the DOTS client may use the data Once the attack is mitigated, the DOTS client may use the data
channel to control the 'activation-type' (e.g., revert to a default channel to control the 'activation-type' (e.g., revert to a default
value) of some of the filtering rules controlled by the DOTS signal value) of some of the filtering rules controlled by the DOTS signal
channel or delete some of these filters. This behavior is deployment channel or delete some of these filters. This behavior is deployment
specific. specific.
3.2. DOTS Signal Channel Extension 3.2. DOTS Signal Channel Extension
3.2.1. Parameters and Behaviors 3.2.1. Parameters and Behaviors
This specification extends the mitigation request defined in This specification extends the mitigation request defined in
Section 4.4.1 of [RFC8782] to convey the intended control of Section 4.4.1 of [RFC9132] to convey the intended control of
configured filtering rules. Concretely, the DOTS client conveys configured filtering rules. Concretely, the DOTS client conveys the
'acl-list' attribute with the following sub-attributes in the CBOR 'acl-list' attribute with the following sub-attributes in the Concise
body of a mitigation request (see the YANG structure in Binary Object Representation (CBOR) body of a mitigation request (see
Section 3.2.2.1): the YANG structure in Section 3.2.2.1):
acl-name: A name of an access list defined using the DOTS data acl-name: A name of an access list defined using the DOTS data
channel (Section 4.3 of [RFC8783]) that is associated with the channel (Section 4.3 of [RFC8783]) that is associated with the
DOTS client. DOTS client.
As a reminder, an ACL is an ordered list of Access Control Entries As a reminder, an ACL is an ordered list of Access Control Entries
(ACE). Each ACE has a list of match criteria and a list of (ACEs). Each ACE has a list of match criteria and a list of
actions [RFC8783]. The list of configured ACLs can be retrieved actions [RFC8783]. The list of configured ACLs can be retrieved
using the DOTS data channel during 'idle' time. using the DOTS data channel during 'idle' time.
This is a mandatory attribute when 'acl-list' is included. This is a mandatory attribute when 'acl-list' is included.
activation-type: Indicates the activation type of an ACL overriding activation-type: An attribute indicating the activation type of an
the existing 'activation-type' installed by the DOTS client using ACL overriding the existing 'activation-type' installed by the
the DOTS data channel. DOTS client using the DOTS data channel.
As a reminder, this attribute can be set to 'deactivate', As a reminder, this attribute can be set to 'deactivate',
'immediate', or 'activate-when-mitigating' as defined in 'immediate', or 'activate-when-mitigating' as defined in
[RFC8783]. [RFC8783].
Note that both 'immediate' and 'activate-when-mitigating' have an Note that both 'immediate' and 'activate-when-mitigating' have an
immediate effect when a mitigation request is being processed by immediate effect when a mitigation request is being processed by
the DOTS server. the DOTS server.
This is an optional attribute. This is an optional attribute.
By default, ACL-related operations are achieved using the DOTS data By default, ACL-related operations are achieved using the DOTS data
channel protocol when no attack is ongoing. DOTS clients MUST NOT channel protocol when no attack is ongoing. DOTS clients MUST NOT
use the filtering control over DOTS signal channel in 'idle' time; use the filtering control over the DOTS signal channel in 'idle'
such requests MUST be discarded by DOTS servers with 4.00 (Bad time; such requests MUST be discarded by DOTS servers with 4.00 (Bad
Request). Request).
During an attack time, DOTS clients may include 'acl-list', 'acl- During an attack time, DOTS clients may include 'acl-list', 'acl-
name', and 'activation-type' attributes in a mitigation request. name', and 'activation-type' attributes in a mitigation request.
This request may be the initial mitigation request for a given This request may be the initial mitigation request for a given
mitigation scope or a new one overriding an existing request. In mitigation scope or a new one overriding an existing request. In
both cases, a new 'mid' MUST be used. Nevertheless, it is NOT both cases, a new 'mid' MUST be used. Nevertheless, it is NOT
RECOMMENDED to include ACL attributes in an initial mitigation RECOMMENDED to include ACL attributes in an initial mitigation
request for a given mitigation scope or in a mitigation request request for a given mitigation scope or in a mitigation request
adjusting the mitigation scope. This recommendation is meant to adjusting the mitigation scope. This recommendation is meant to
avoid delaying attack mitigations because of failures to process ACL avoid delaying attack mitigations because of failures to process ACL
attributes. attributes.
As the attack evolves, DOTS clients can adjust the 'activation-type' As the attack evolves, DOTS clients can adjust the 'activation-type'
of an ACL conveyed in a mitigation request or control other filters of an ACL conveyed in a mitigation request or control other filters
as necessary. This can be achieved by sending a PUT request with a as necessary. This can be achieved by sending a PUT request with a
new 'mid' value. new 'mid' value.
It is RECOMMENDED for a DOTS client to subscribe to asynchronous It is RECOMMENDED for a DOTS client to subscribe to asynchronous
notifications of the attack mitigation, as detailed in notifications of the attack mitigation, as detailed in
Section 4.4.2.1 of [RFC8782]. If not, the polling mechanism in Section 4.4.2.1 of [RFC9132]. If not, the polling mechanism in
Section 4.4.2.2 of [RFC8782] has to be followed by the DOTS client. Section 4.4.2.2 of [RFC9132] has to be followed by the DOTS client.
A DOTS client relies on the information received from the DOTS server A DOTS client relies on the information received from the DOTS server
and/or local information to the DOTS client domain to trigger a and/or local information to the DOTS client domain to trigger a
filter control request. Only filters that are pertinent for an filter control request. Only filters that are pertinent for an
ongoing mitigation should be controlled by a DOTS client using the ongoing mitigation should be controlled by a DOTS client using the
DOTS signal channel. DOTS signal channel.
'acl-list', 'acl-name', and 'activation-type' are defined as 'acl-list', 'acl-name', and 'activation-type' are defined as
comprehension-required parameters. Following the rules in Section 6 comprehension-required parameters. Following the rules in Section 6
of [RFC8782], if the DOTS server does not understand the 'acl-list' of [RFC9132], if the DOTS server does not understand the 'acl-list',
or 'acl-name' or 'activation-type' attributes, it responds with a 'acl-name', or 'activation-type' attributes, it responds with a 4.00
"4.00 (Bad Request)" error response code. (Bad Request) error response code.
If the DOTS server does not find the ACL name ('acl-name') conveyed If the DOTS server does not find the ACL name ('acl-name') conveyed
in the mitigation request for this DOTS client, it MUST respond with in the mitigation request for this DOTS client, it MUST respond with
4.04 (Not Found) error response code. a 4.04 (Not Found) error response code.
If the DOTS server finds the ACL name for this DOTS client, and If the DOTS server finds the ACL name for this DOTS client, and
assuming the request passed the validation checks in Section 4.4.1 of assuming the request passed the validation checks in Section 4.4.1 of
[RFC8782], the DOTS server MUST proceed with the 'activation-type' [RFC9132], the DOTS server MUST proceed with the 'activation-type'
update. The update is immediately enforced by the DOTS server and update. The update is immediately enforced by the DOTS server and
will be maintained as the new activation type for the ACL name even will be maintained as the new activation type for the ACL name even
after the termination of the mitigation request. In addition, the after the termination of the mitigation request. In addition, the
DOTS server MUST update the lifetime of the corresponding ACL similar DOTS server MUST update the lifetime of the corresponding ACL similar
to the update when a refresh request is received using the DOTS data to the update when a refresh request is received using the DOTS data
channel (Section 7.2 of [RFC8783]). If, for some reason, the DOTS channel (Section 7.2 of [RFC8783]). If, for some reason, the DOTS
server fails to apply the filter update, it MUST respond with 5.03 server fails to apply the filter update, it MUST respond with a 5.03
(Service Unavailable) error response code and include the failed ACL (Service Unavailable) error response code and include the failed ACL
update in the diagnostic payload of the response (an example is shown update in the diagnostic payload of the response (an example is shown
in Figure 1). Else, the DOTS server replies with the appropriate in Figure 1). Else, the DOTS server replies with the appropriate
response code defined in Section 4.4.1 of [RFC8782]. response code defined in Section 4.4.1 of [RFC9132].
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"mid": 123, "mid": 123,
"ietf-dots-signal-control:acl-list": [ "ietf-dots-signal-control:acl-list": [
{ {
"acl-name": "an-accept-list", "acl-name": "an-accept-list",
"activation-type": "deactivate" "activation-type": "deactivate"
skipping to change at page 8, line 50 skipping to change at line 357
] ]
} }
] ]
} }
} }
Figure 1: Example of a Diagnostic Payload Including Failed ACL Update Figure 1: Example of a Diagnostic Payload Including Failed ACL Update
The JSON/YANG mappings for DOTS filter control attributes are shown The JSON/YANG mappings for DOTS filter control attributes are shown
in Table 1. As a reminder, the mapping for 'acl-name' is defined in in Table 1. As a reminder, the mapping for 'acl-name' is defined in
Table 5 of [RFC8782]. Table 5 of [RFC9132].
+-------------------+------------+--------+---------------+--------+ +===================+=============+======+=================+========+
| Parameter Name | YANG | CBOR | CBOR Major | JSON | | Parameter Name | YANG Type | CBOR | CBOR Major Type | JSON |
| | Type | Key | Type & | Type | | | | Key | & Information | Type |
| | | | Information | | +===================+=============+======+=================+========+
+===================+============+========+===============+========+ | activation-type | enumeration | 52 | 0 unsigned | String |
| activation-type | enumeration| TBA1 | 0 unsigned | String | +-------------------+-------------+------+-----------------+--------+
+-------------------+------------+--------+---------------+--------+ | ietf-dots- | list | 53 | 4 array | Array |
| ietf-dots-signal- | | | | | | signal- | | | | |
| control:acl-list | list | TBA2 | 4 array | Array | | control:acl-list | | | | |
+-------------------+------------+--------+---------------+--------+ +-------------------+-------------+------+-----------------+--------+
| acl-name | leafref | 23 | 3 text string | String | | acl-name | leafref | 23 | 3 text string | String |
+-------------------+------------+--------+---------------+--------+ +-------------------+-------------+------+-----------------+--------+
Table 1: JSON/YANG Mapping to CBOR for Filter Control Attributes
Table 1: JSON/YANG Mapping to CBOR for Filter Control Attributes
If the DOTS client receives a 5.03 (Service Unavailable) with a If the DOTS client receives a 5.03 (Service Unavailable) with a
diagnostic payload indicating a failed ACL update as a response to an diagnostic payload indicating a failed ACL update as a response to an
initial mitigation or a mitigation with adjusted scope, the DOTS initial mitigation or a mitigation with adjusted scope, the DOTS
client MUST immediately send a new request which repeats all the client MUST immediately send a new request that repeats all the
parameters as sent in the failed mitigation request but without parameters as sent in the failed mitigation request but without
including the ACL attributes. After the expiry of Max-Age returned including the ACL attributes. After the expiry of Max-Age returned
in the 5.03 (Service Unavailable) response, the DOTS client retries in the 5.03 (Service Unavailable) response, the DOTS client retries
with a new mitigation request (i.e., a new 'mid') that repeats all with a new mitigation request (i.e., a new 'mid') that repeats all
the parameters as sent in the failed mitigation request (i.e., the the parameters as sent in the failed mitigation request (i.e., the
one including the ACL attributes). one including the ACL attributes).
If, during an active mitigation, the 'activation-type' is changed at 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 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 of bound to a DOTS client, the DOTS server notifies that DOTS client of
the change by including the corresponding ACL parameters in an the change by including the corresponding ACL parameters in an
asynchronous notification (the DOTS client is observing the active asynchronous notification (the DOTS client is observing the active
mitigation) or in a response to a polling request (Section 4.4.2.2 of mitigation) or in a response to a polling request (Section 4.4.2.2 of
[RFC8782]). [RFC9132]).
If the DOTS signal and data channels of a DOTS client are not If the DOTS signal and data channels of a DOTS client are not
established with the same DOTS server of a DOTS server domain, the established with the same DOTS server of a DOTS server domain, the
above request processing operations are undertaken using the above request processing operations are undertaken using the
coordination mechanism discussed in Section 3.1. coordination mechanism discussed in Section 3.1.
This specification does not require any modification to the efficacy This specification does not require any modification to the efficacy
update and the withdrawal procedures defined in [RFC8782]. In update and the withdrawal procedures defined in [RFC9132]. In
particular, ACL-related clauses are not included in a PUT request particular, ACL-related clauses are not included in a PUT request
used to send an efficacy update and DELETE requests. used to send an efficacy update and DELETE requests.
3.2.2. DOTS Signal Filtering Control Module 3.2.2. DOTS Signal Filtering Control Module
3.2.2.1. Tree Structure 3.2.2.1. Tree Structure
This document augments the "ietf-dots-signal-channel" YANG module This document augments the "ietf-dots-signal-channel" YANG module
defined in [RFC8782] for managing filtering rules. defined in [RFC9132] for managing filtering rules.
This document defines the YANG module "ietf-dots-signal-control", This document defines the YANG module "ietf-dots-signal-control",
which has the following tree structure: which has the following tree structure:
module: ietf-dots-signal-control module: ietf-dots-signal-control
augment /ietf-signal:dots-signal/ietf-signal:message-type augment-structure /dots-signal:dots-signal/dots-signal:message-type
/ietf-signal:mitigation-scope/ietf-signal:scope: /dots-signal:mitigation-scope/dots-signal:scope:
+--rw acl-list* [acl-name] {control-filtering}? +-- acl-list* [acl-name]
+--rw acl-name +-- acl-name
| -> /ietf-data:dots-data/dots-client/acls/acl/name | -> /data-channel:dots-data/dots-client/acls/acl/name
+--rw activation-type? ietf-data:activation-type +-- activation-type? data-channel:activation-type
3.2.2.2. YANG Module 3.2.2.2. YANG Module
This YANG module is not intended to be used via NETCONF/RESTCONF for This YANG module is not intended to be used via NETCONF/RESTCONF for
DOTS server management purposes; such module is out of the scope of DOTS server management purposes; such a module is out of the scope of
this document. It serves only to provide a data model and encoding, this document. It serves only to provide a data model and encoding,
but not a management data model. but not a management data model.
This module uses types defined in [RFC8783]. This module uses types defined in [RFC8783].
<CODE BEGINS> file "ietf-dots-signal-control@2019-05-13.yang" <CODE BEGINS> file "ietf-dots-signal-control@2021-09-01.yang"
module ietf-dots-signal-control { module ietf-dots-signal-control {
yang-version 1.1; yang-version 1.1;
namespace namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control";
"urn:ietf:params:xml:ns:yang:ietf-dots-signal-control";
prefix dots-control; prefix dots-control;
import ietf-dots-signal-channel { import ietf-dots-signal-channel {
prefix ietf-signal; prefix dots-signal;
reference reference
"RFC 8782: Distributed Denial-of-Service Open Threat "RFC 9132: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification"; Signaling (DOTS) Signal Channel Specification";
} }
import ietf-yang-structure-ext {
prefix sx;
reference
"RFC 8791: YANG Data Structure Extensions";
}
import ietf-dots-data-channel { import ietf-dots-data-channel {
prefix ietf-data; prefix data-channel;
reference reference
"RFC 8783: Distributed Denial-of-Service Open Threat "RFC 8783: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Data Channel Specification"; Signaling (DOTS) Data Channel Specification";
} }
organization organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group"; "IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/dots/> "WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org> WG List: <mailto:dots@ietf.org>
Author: Kaname Nishizuka Author: Kaname Nishizuka
<mailto:kaname@nttv6.jp> <mailto:kaname@nttv6.jp>
Author: Mohamed Boucadair Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com> <mailto:mohamed.boucadair@orange.com>
Author: Konda, Tirumaleswar Reddy Author: Tirumaleswar Reddy.K
<mailto:TirumaleswarReddy_Konda@McAfee.com> <mailto:kondtir@gmail.com>
Author: Takahiko Nagata Author: Takahiko Nagata
<mailto:nagata@lepidum.co.jp>"; <mailto:nagata@lepidum.co.jp>";
description description
"This module contains YANG definition for the signaling "This module contains YANG definition for the signaling
messages exchanged between a DOTS client and a DOTS server messages exchanged between a DOTS client and a DOTS server
to control, by means of the DOTS signal channel, filtering to control, by means of the DOTS signal channel, filtering
rules configured using the DOTS data channel. rules configured using the DOTS data channel.
Copyright (c) 2020 IETF Trust and the persons identified as Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 9133; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2019-05-13 { revision 2021-09-01 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Controlling Filtering Rules Using Distributed "RFC 9133: Controlling Filtering Rules Using Distributed
Denial-of-Service Open Threat Signaling (DOTS) Denial-of-Service Open Threat Signaling (DOTS)
Signal Channel"; Signal Channel";
} }
feature control-filtering { sx:augment-structure "/dots-signal:dots-signal"
description + "/dots-signal:message-type"
"This feature means that the DOTS signal channel is able + "/dots-signal:mitigation-scope"
to manage the filtering rules created by the same DOTS + "/dots-signal:scope" {
client using the DOTS data channel.";
}
augment "/ietf-signal:dots-signal/ietf-signal:message-type"
+ "/ietf-signal:mitigation-scope/ietf-signal:scope" {
if-feature control-filtering;
description "ACL name and activation type."; description
"ACL name and activation type.";
list acl-list { list acl-list {
key "acl-name"; key "acl-name";
description description
"List of ACLs as defined using the DOTS data "List of ACLs as defined using the DOTS data
channel. ACLs bound to a DOTS client are uniquely channel. ACLs bound to a DOTS client are uniquely
identified by a name."; identified by a name.";
leaf acl-name { leaf acl-name {
type leafref { type leafref {
path "/ietf-data:dots-data/ietf-data:dots-client" path "/data-channel:dots-data/data-channel:dots-client"
+ "/ietf-data:acls/ietf-data:acl/ietf-data:name"; + "/data-channel:acls/data-channel:acl"
+ "/data-channel:name";
}
description
"Reference to the ACL name bound to a DOTS client.";
} }
description leaf activation-type {
"Reference to the ACL name bound to a DOTS client."; type data-channel:activation-type;
} default "activate-when-mitigating";
leaf activation-type { description
type ietf-data:activation-type; "Sets the activation type of an ACL.";
default "activate-when-mitigating";
description
"Sets the activation type of an ACL.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
4. Some Examples 4. Some Examples
This section provides some examples to illustrate the behavior This section provides some examples to illustrate the behavior
specified in Section 3.2.1. These examples are provided for specified in Section 3.2.1. These examples are provided for
illustration purposes; they should not be considered as deployment illustration purposes; they should not be considered as deployment
recommendations. recommendations.
4.1. Conflict Handling 4.1. Conflict Handling
Let's consider a DOTS client which contacts its DOTS server during Let's consider a DOTS client that contacts its DOTS server during
'idle' time to install an accept-list allowing for UDP traffic issued '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 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 forwarded to 2001:db8:6401::2/127. It does so by sending, for
example, a PUT request shown in Figure 2. example, a PUT request as shown in Figure 2.
PUT /restconf/data/ietf-dots-data-channel:dots-data\ PUT /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\ /dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
/acl=an-accept-list HTTP/1.1 /acl=an-accept-list HTTP/1.1
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [ "acl": [
skipping to change at page 13, line 47 skipping to change at line 591
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
} }
] ]
} }
} }
Figure 2: DOTS Data Channel Request to Create a Filter Figure 2: DOTS Data Channel Request to Create a Filter
Sometime later, consider that a DDoS attack is detected by the DOTS Sometime later, consider that a DDoS attack is detected by the DOTS
client on 2001:db8:6401::2/127. Consequently, the DOTS client sends client on 2001:db8:6401::2/127. Consequently, the DOTS client sends
a mitigation request to its DOTS server as shown in Figure 3. a mitigation request to its DOTS server as shown in Figure 3.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA" Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA"
skipping to change at page 14, line 29 skipping to change at line 621
], ],
"target-protocol": [ "target-protocol": [
17 17
], ],
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
Figure 3: DOTS Signal Channel Mitigation Request Figure 3: DOTS Signal Channel Mitigation Request
The DOTS server accepts immediately the request by replying with 2.01 The DOTS server immediately accepts the request by replying with 2.01
(Created) (Figure 4 depicts the message body of the response). (Created) (Figure 4 depicts the message body of the response).
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"mid": 123, "mid": 123,
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
Figure 4: Status Response (Message Body) Figure 4: Status Response (Message Body)
Assuming the DOTS client subscribed to asynchronous notifications, Assuming the DOTS client subscribed to asynchronous notifications,
when the DOTS server concludes that some of the attack sources belong when the DOTS server concludes that some of the attack sources belong
to 2001:db8:1234::/48, it sends a notification message with 'status' to 2001:db8:1234::/48, it sends a notification message with 'status'
code set to '1 (Attack mitigation is in progress)' and 'conflict- code set to 1 (attack-mitigation-in-progress) and 'conflict-cause'
cause' set to '2' (conflict-with-acceptlist) to the DOTS client to set to 2 (conflict-with-acceptlist) to the DOTS client to indicate
indicate that this mitigation request is in progress, but a conflict that this mitigation request is in progress, but a conflict is
is detected. detected.
Upon receipt of the notification message from the DOTS server, the Upon receipt of the notification message from the DOTS server, the
DOTS client sends a PUT request to deactivate the "an-accept-list" DOTS client sends a PUT request to deactivate the "an-accept-list"
ACL as shown in Figure 5. ACL as shown in Figure 5.
The DOTS client can also decide to send a PUT request to deactivate 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 the "an-accept-list" ACL if suspect traffic is received from an
accept-listed source (2001:db8:1234::/48). The structure of that PUT accept-listed source (2001:db8:1234::/48). The structure of that PUT
is the same as the one shown in Figure 5. is the same as the one shown in Figure 5.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA" Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA"
Uri-Path: "mid=124" Uri-Path: "mid=124"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
skipping to change at page 15, line 48 skipping to change at line 688
} }
], ],
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
Figure 5: PUT for Deactivating a Conflicting Filter Figure 5: PUT for Deactivating a Conflicting Filter
Then, the DOTS server deactivates "an-accept-list" ACL and replies Then, the DOTS server deactivates the "an-accept-list" ACL and
with 2.04 (Changed) response to the DOTS client to confirm the replies with a 2.04 (Changed) response to the DOTS client to confirm
successful operation. The message body is similar to the one the successful operation. The message body is similar to the one
depicted in Figure 4. depicted in Figure 4.
Once the attack is mitigated, the DOTS client may use the data Once the attack is mitigated, the DOTS client may use the data
channel to retrieve its ACLs maintained by the DOTS server. As shown channel to retrieve its ACLs maintained by the DOTS server. As shown
in Figure 6, the activation type is set to 'deactivate' as set by the in Figure 6, the activation type is set to 'deactivate' as set by the
DOTS signal channel (Figure 5) instead of the type initially set DOTS signal channel (Figure 5) instead of the type initially set
using the DOTS data channel (Figure 2). using the DOTS data channel (Figure 2).
{ {
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
skipping to change at page 16, line 46 skipping to change at line 734
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
} }
] ]
} }
} }
Figure 6: DOTS Data Channel GET Response after Mitigation (Message Figure 6: DOTS Data Channel GET Response after Mitigation
Body) (Message Body)
4.2. On-Demand Activation of an Accept-List Filter 4.2. On-Demand Activation of an Accept-List Filter
Let's consider a DOTS client which contacts its DOTS server during Let's consider a DOTS client that contacts its DOTS server during
'idle' time to install an accept-list allowing for UDP traffic issued '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 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 Figure 7. does so by sending, for example, a PUT request shown in Figure 7.
The DOTS server installs this filter with a "deactivated" state. The DOTS server installs this filter with a "deactivated" state.
PUT /restconf/data/ietf-dots-data-channel:dots-data\ PUT /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=ioiuLoZqo4SLv64TLPXrxA/acls\ /dots-client=ioiuLoZqo4SLv64TLPXrxA/acls\
/acl=my-accept-list HTTP/1.1 /acl=my-accept-list HTTP/1.1
Host: example.com Host: example.com
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
skipping to change at page 17, line 52 skipping to change at line 784
} }
} }
] ]
} }
} }
Figure 7: DOTS Data Channel Request to Create an Accept-List Filter Figure 7: DOTS Data Channel Request to Create an Accept-List Filter
Sometime later, consider that a UDP DDoS attack is detected by the 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 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 the traffic from 2001:db8:1234::/48 be accept-listed to the DOTS
client domain. Consequently, the DOTS client sends a mitigation client domain. Consequently, the DOTS client sends a mitigation
request to its DOTS server as shown in Figure 8. request to its DOTS server as shown in Figure 8.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=ioiuLoZqo4SLv64TLPXrxA" Uri-Path: "cuid=ioiuLoZqo4SLv64TLPXrxA"
Uri-Path: "mid=4879" Uri-Path: "mid=4879"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
skipping to change at page 18, line 37 skipping to change at line 818
"acl-name": "my-accept-list", "acl-name": "my-accept-list",
"activation-type": "immediate" "activation-type": "immediate"
} }
], ],
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
Figure 8: DOTS Signal Channel Mitigation Request with a Filter Figure 8: DOTS Signal Channel Mitigation Request with a Filter
Control Control
The DOTS server activates "my-accept-list" ACL and replies with 2.01 The DOTS server activates the "my-accept-list" ACL and replies with a
(Created) response to the DOTS client to confirm the successful 2.01 (Created) response to the DOTS client to confirm the successful
operation. operation.
4.3. DOTS Servers/Mitigators Lacking Capacity 4.3. DOTS Servers/Mitigators Lacking Capacity
This section describes a scenario in which a DOTS client activates a This section describes a scenario in which a DOTS client activates a
drop-list or a rate-limit filter during an attack. drop-list or a rate-limit filter during an attack.
Consider a DOTS client that contacts its DOTS server during 'idle' Consider a DOTS client that contacts its DOTS server during 'idle'
time to install an accept-list that rate-limits all (or a part 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 thereof) traffic to be forwarded to 2001:db8:123::/48 as a last
skipping to change at page 20, line 30 skipping to change at line 903
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
Figure 10: DOTS Signal Channel Mitigation Request Figure 10: DOTS Signal Channel Mitigation Request
For some reason (e.g., the DOTS server, or the mitigator, is lacking For some reason (e.g., the DOTS server, or the mitigator, is lacking
a capability or capacity), the DOTS client is still receiving attack a capability or capacity), the DOTS client is still receiving attack
traffic which saturates available links. To soften the problem, the traffic, which saturates available links. To soften the problem, the
DOTS client decides to activate the filter that rate-limits the DOTS client decides to activate the filter that rate-limits the
traffic destined to the DOTS client domain. To that aim, the DOTS traffic destined to the DOTS client domain. To that aim, the DOTS
client sends the mitigation request to its DOTS server shown in client sends the mitigation request to its DOTS server shown in
Figure 11. Figure 11.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
skipping to change at page 21, line 32 skipping to change at line 936
"acl-name": "my-ratelimit-list", "acl-name": "my-ratelimit-list",
"activation-type": "immediate" "activation-type": "immediate"
} }
], ],
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
Figure 11: DOTS Signal Channel Mitigation Request to Activate a Rate- Figure 11: DOTS Signal Channel Mitigation Request to Activate a
Limit Filter Rate-Limit Filter
Then, the DOTS server activates "my-ratelimit-list" ACL and replies Then, the DOTS server activates the "my-ratelimit-list" ACL and
with 2.04 (Changed) response to the DOTS client to confirm the replies with a 2.04 (Changed) response to the DOTS client to confirm
successful operation. the successful operation.
As the attack mitigation evolves, the DOTS client may decide to As the attack mitigation evolves, the DOTS client may decide to
deactivate the rate-limit policy (e.g., upon receipt of notification deactivate the rate-limit policy (e.g., upon receipt of a
status change from 'attack-exceeded-capability' to 'attack- notification status change from 'attack-exceeded-capability' to
mitigation-in-progress'). Based on the mitigation status conveyed by 'attack-mitigation-in-progress'). Based on the mitigation status
the DOTS server, the DOTS client can de-activate the rate-limit conveyed by the DOTS server, the DOTS client can deactivate the rate-
action. It does so by sending the request shown in Figure 12. limit action. It does so by sending the request shown in Figure 12.
Header: PUT (Code=0.03) Header: PUT (Code=0.03)
Uri-Path: ".well-known" Uri-Path: ".well-known"
Uri-Path: "dots" Uri-Path: "dots"
Uri-Path: "mitigate" Uri-Path: "mitigate"
Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA" Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
Uri-Path: "mid=87" Uri-Path: "mid=87"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
skipping to change at page 22, line 37 skipping to change at line 982
} }
] ]
} }
} }
Figure 12: DOTS Signal Channel Mitigation Request to Deactivate a Figure 12: DOTS Signal Channel Mitigation Request to Deactivate a
Rate-Limit Filter Rate-Limit Filter
5. IANA Considerations 5. IANA Considerations
5.1. DOTS Signal Channel CBOR Mappings Registry 5.1. DOTS Signal Channel CBOR Key Values Subregistry
This specification registers the following parameters in the IANA Per this specification, IANA has registered the following parameters
"DOTS Signal Channel CBOR Key Values" registry [Key-Map]. in the "DOTS Signal Channel CBOR Key Values" subregistry within the
"Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
Channel" registry [Key-Map].
o Note to the RFC Editor: Please delete (TBA1-TBA2) once the CBOR +==================+==========+=======+============+===============+
keys are assigned from the 1-16383 range. Please update Table 1 | Parameter Name | CBOR Key | CBOR | Change | Specification |
accordingly. | | Value | Major | Controller | Document(s) |
| | | Type | | |
+==================+==========+=======+============+===============+
| activation-type | 52 | 0 | IESG | RFC 9133 |
+------------------+----------+-------+------------+---------------+
| ietf-dots- | 53 | 4 | IESG | RFC 9133 |
| signal- | | | | |
| control:acl-list | | | | |
+------------------+----------+-------+------------+---------------+
+--------------------+--------+-------+------------+---------------+ Table 2
| Parameter Name | CBOR | CBOR | Change | Specification |
| | Key | Major | Controller | Document(s) |
| | Value | Type | | |
+====================+========+=======+============+===============+
| activation-type | 52 | | | |
| | (TBA1) | 0 | IESG | [RFCXXXX] |
+--------------------+--------+-------+------------+---------------+
| ietf-dots-signal- | 53 | | | |
| control:acl-list | (TBA2) | 4 | IESG | [RFCXXXX] |
+--------------------+--------+-------+------------+---------------+
5.2. DOTS Signal Filtering Control YANG Module 5.2. A New YANG Module
This document requests IANA to register the following URI in the "ns" IANA has registered the following URI in the "ns" subregistry within
subregistry within the "IETF XML Registry" [RFC3688]: the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG module in IANA has registered the following YANG module in the "YANG Module
the "YANG Module Names" subregistry [RFC7950] within the "YANG Names" subregistry [RFC6020] within the "YANG Parameters" registry.
Parameters" registry.
Name: ietf-dots-signal-control Name: ietf-dots-signal-control
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control
Maintained by IANA: N Maintained by IANA: N
Prefix: dots-control Prefix: dots-control
Reference: RFC XXXX Reference: RFC 9133
6. Security Considerations 6. Security Considerations
The security considerations for the DOTS signal channel protocol are The security considerations for the DOTS signal channel protocol are
discussed in Section 10 of [RFC8782], while those for the DOTS data discussed in Section 11 of [RFC9132], while those for the DOTS data
channel protocol are discussed in Section 10 of [RFC8783]. The channel protocol are discussed in Section 10 of [RFC8783]. The
following discusses the security considerations that are specific to following discusses the security considerations that are specific to
the DOTS signal channel extension defined in this document. the DOTS signal channel extension defined in this document.
This specification does not allow to create new filtering rules, This specification does not allow the creation of new filtering
which is the responsibility of the DOTS data channel. DOTS client rules, which is the responsibility of the DOTS data channel. DOTS
domains should be adequately prepared prior to an attack, e.g., by client domains should be adequately prepared prior to an attack,
creating filters that will be activated on demand when an attack is e.g., by creating filters that will be activated on demand when an
detected. attack is detected.
A DOTS client is entitled to access only the resources it creates. A DOTS client is entitled to access only the resources it creates.
In particular, a DOTS client can not tweak filtering rules created by In particular, a DOTS client can not tweak filtering rules created by
other DOTS clients of the same DOTS client domain. As a reminder, other DOTS clients of the same DOTS client domain. As a reminder,
DOTS servers must associate filtering rules with the DOTS client that DOTS servers must associate filtering rules with the DOTS client that
created these resources. Failure to ensure such association by a created these resources. Failure to ensure such association by a
DOTS server will have severe impact on DOTS client domains. DOTS server will have severe impact on DOTS client domains.
A compromised DOTS client can use the filtering control capability to A compromised DOTS client can use the filtering control capability to
exacerbate an ongoing attack. Likewise, such a compromised DOTS exacerbate an ongoing attack. Likewise, such a compromised DOTS
client may abstain from reacting to an ACL conflict notification client may abstain from reacting to an ACL conflict notification
received from the DOTS server during attacks. These are not new received from the DOTS server during attacks. These are not new
attack vectors, but variations of threats discussed in [RFC8782] and attack vectors, but variations of threats discussed in [RFC9132] and
[RFC8783]. DOTS operators should carefully monitor and audit DOTS [RFC8783]. DOTS operators should carefully monitor and audit DOTS
agents to detect misbehaviors and to deter misuses. agents to detect misbehaviors and deter misuses.
7. Acknowledgements
Many thanks to Wei Pan, Xia Liang, Jon Shallow, Dan Wing, Christer
Holmberg, Shawn Emery, Tim Chown, Murray Kucherawy, Roman Danyliw,
Erik Kline, and Eric Vyncke for the comments.
Thanks to Benjamin Kaduk for the AD review.
8. References 7. References
8.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P.,
Mortensen, A., and N. Teague, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel
Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020,
<https://www.rfc-editor.org/info/rfc8782>.
[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed
Denial-of-Service Open Threat Signaling (DOTS) Data Denial-of-Service Open Threat Signaling (DOTS) Data
Channel Specification", RFC 8783, DOI 10.17487/RFC8783, Channel Specification", RFC 8783, DOI 10.17487/RFC8783,
May 2020, <https://www.rfc-editor.org/info/rfc8783>. May 2020, <https://www.rfc-editor.org/info/rfc8783>.
8.2. Informative References [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data
Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
June 2020, <https://www.rfc-editor.org/info/rfc8791>.
[I-D.ietf-dots-architecture] [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
Mortensen, A., Reddy.K, T., Andreasen, F., Teague, N., and "Distributed Denial-of-Service Open Threat Signaling
R. Compton, "Distributed-Denial-of-Service Open Threat (DOTS) Signal Channel Specification", RFC 9132,
Signaling (DOTS) Architecture", draft-ietf-dots- DOI 10.17487/RFC9132, September 2021,
architecture-18 (work in progress), March 2020. <https://www.rfc-editor.org/info/rfc9132>.
[Interop] Nishizuka, K., Shallow, J., and L. Xia , "DOTS Interop 7.2. Informative References
test report, IETF 103 Hackathon", November 2018,
[INTEROP] Nishizuka, K., Shallow, J., and L. Xia, "DOTS Interop test
report, IETF 103 Hackathon", November 2018,
<https://datatracker.ietf.org/meeting/103/materials/ <https://datatracker.ietf.org/meeting/103/materials/
slides-103-dots-interop-report-from-ietf-103-hackathon- slides-103-dots-interop-report-from-ietf-103-hackathon-
00>. 00>.
[Key-Map] IANA, "DOTS Signal Channel CBOR Key Values", [Key-Map] IANA, "Distributed Denial-of-Service Open Threat Signaling
<https://www.iana.org/assignments/dots/dots.xhtml#dots- (DOTS) Signal Channel",
signal-channel-cbor-key-values>. <https://www.iana.org/assignments/dots>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016, RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>. <https://www.rfc-editor.org/info/rfc7951>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
Threat Signaling (DOTS) Requirements", RFC 8612, Threat Signaling (DOTS) Requirements", RFC 8612,
DOI 10.17487/RFC8612, May 2019, DOI 10.17487/RFC8612, May 2019,
<https://www.rfc-editor.org/info/rfc8612>. <https://www.rfc-editor.org/info/rfc8612>.
[RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F.,
Teague, N., and R. Compton, "DDoS Open Threat Signaling
(DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811,
August 2020, <https://www.rfc-editor.org/info/rfc8811>.
Acknowledgements
Many thanks to Wei Pan, Xia Liang, Jon Shallow, Dan Wing, Christer
Holmberg, Shawn Emery, Tim Chown, Murray Kucherawy, Roman Danyliw,
Erik Kline, and Éric Vyncke for the comments.
Thanks to Benjamin Kaduk for the AD review.
Authors' Addresses Authors' Addresses
Kaname Nishizuka Kaname Nishizuka
NTT Communications NTT Communications
GranPark 16F 3-4-1 Shibaura, Minato-ku GranPark 16F 3-4-1 Shibaura, Minato-ku, Tokyo
Tokyo 108-8118 108-8118
Japan Japan
Email: kaname@nttv6.jp Email: kaname@nttv6.jp
Mohamed Boucadair Mohamed Boucadair
Orange Orange
Rennes 35000 35000 Rennes
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Tirumaleswar Reddy Tirumaleswar Reddy.K
McAfee, Inc. Akamai
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore, Karnataka 560071 Bangalore 560071
Karnataka
India India
Email: kondtir@gmail.com Email: kondtir@gmail.com
Takahiko Nagata Takahiko Nagata
Lepidum Lepidum
Japan Japan
Email: nagata@lepidum.co.jp Email: nagata@lepidum.co.jp
 End of changes. 108 change blocks. 
292 lines changed or deleted 284 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/