draft-ietf-dots-signal-filter-control-00.txt   draft-ietf-dots-signal-filter-control-01.txt 
DOTS K. Nishizuka DOTS K. Nishizuka
Internet-Draft NTT Communications Internet-Draft NTT Communications
Intended status: Standards Track M. Boucadair Intended status: Standards Track M. Boucadair
Expires: October 25, 2019 Orange Expires: November 25, 2019 Orange
T. Reddy T. Reddy
McAfee McAfee
T. Nagata T. Nagata
Lepidum Lepidum
April 23, 2019 May 24, 2019
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-00 draft-ietf-dots-signal-filter-control-01
Abstract Abstract
This document specifies an extension to the DOTS signal channel so This document specifies an extension to the DOTS signal channel
that DOTS clients can control their filtering rules when an attack protocol so that DOTS clients can control their filtering rules when
mitigation is active. an attack mitigation is active.
Particularly, this extension allows a DOTS client to activate or de- Particularly, this extension allows a DOTS client to activate or de-
activate existing filtering rules during a DDoS attack. The activate existing filtering rules during a DDoS attack. The
characterization of these filtering rules is supposed to be conveyed characterization of these filtering rules is supposed to be conveyed
by a DOTS client during an idle time by means of the DOTS data by a DOTS client during an idle time by means of the DOTS data
channel protocol. channel protocol.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Please update these statements within the document with the RFC Please update these statements within the document with the RFC
skipping to change at page 2, line 26 skipping to change at page 2, line 26
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 25, 2019. This Internet-Draft will expire on November 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 48 skipping to change at page 2, line 48
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4 1.2. The Solution . . . . . . . . . . . . . . . . . . . . . . 4
2. Notational Conventions and Terminology . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Controlling Filtering Rules of a DOTS Client . . . . . . . . 5 3. Controlling Filtering Rules of a DOTS Client . . . . . . . . 5
3.1. Binding the Data and Signal Channels . . . . . . . . . . 5 3.1. Binding DOTS Data and Signal Channels . . . . . . . . . . 5
3.2. DOTS Signal Channel Extension . . . . . . . . . . . . . . 6 3.2. DOTS Signal Channel Extension . . . . . . . . . . . . . . 6
3.2.1. Parameters & Behaviors . . . . . . . . . . . . . . . 6 3.2.1. Parameters and Behaviors . . . . . . . . . . . . . . 6
3.2.2. DOTS Signal Filtering Control Module . . . . . . . . 8 3.2.2. DOTS Signal Filtering Control Module . . . . . . . . 9
3.2.2.1. Tree Structure . . . . . . . . . . . . . . . . . 8 3.2.2.1. Tree Structure . . . . . . . . . . . . . . . . . 9
3.2.2.2. YANG Module . . . . . . . . . . . . . . . . . . . 8 3.2.2.2. YANG Module . . . . . . . . . . . . . . . . . . . 10
4. Sample Examples . . . . . . . . . . . . . . . . . . . . . . . 11 4. Sample Examples . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Conflict Handling . . . . . . . . . . . . . . . . . . . . 11 4.1. Conflict Handling . . . . . . . . . . . . . . . . . . . . 12
4.2. On-Demand Activation of an Accept-List Filter . . . . . . 15 4.2. On-Demand Activation of an Accept-List Filter . . . . . . 16
4.3. DOTS Servers/Mitigators Lacking Capacity . . . . . . . . 17 4.3. DOTS Servers/Mitigators Lacking Capacity . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
5.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 20 5.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 22
5.2. DOTS Signal Filtering Control YANG Module . . . . . . . . 21 5.2. DOTS Signal Filtering Control YANG Module . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
1.1. The Problem 1.1. The Problem
The DOTS data channel protocol [I-D.ietf-dots-data-channel] is used The DOTS data channel protocol [I-D.ietf-dots-data-channel] is used
for bulk data exchange between DOTS agents to improve the for bulk data exchange between DOTS agents to improve the
coordination of all the parties involved in the response to the DDoS coordination of parties involved in the response to the Distributed
attack. Filter management is one of its tasks which enables a DOTS Denial-of-Service (DDoS) attack. Filter management is one of its
client to retrieve the filtering capabilities of a DOTS server and to tasks which enables a DOTS client to retrieve the filtering
manage filtering rules. These Filtering rules are used for dropping capabilities of a DOTS server and to manage filtering rules.
or rate-limiting unwanted traffic, and permitting accept-listed Typically, these Filtering rules are used for dropping or rate-
traffic. limiting unwanted traffic, and permitting accept-listed traffic.
Unlike the DOTS signal channel [I-D.ietf-dots-signal-channel], the Unlike the DOTS signal channel protocol
DOTS data channel is not expected to deal with attack conditions. As [I-D.ietf-dots-signal-channel], the DOTS data channel protocol is not
such, an issue that might be encountered in some deployments is when expected to deal with attack conditions. As such, an issue that
filters installed by means of DOTS data channel protocol may not might be encountered in some deployments is when filters installed by
function as expected during DDoS attacks or exacerbate an ongoing means of the DOTS data channel protocol may not function as expected
DDoS attack. The DOTS data channel cannot be used then to change during DDoS attacks or, worse, exacerbate an ongoing DDoS attack.
these filters, which may complicate DDoS mitigation operations The DOTS data channel protocol cannot be used then to change these
[Interop]. filters, which may complicate DDoS mitigation operations [Interop].
A typical case is a DOTS client which configures during 'idle' time A typical case is a DOTS client which configures during 'idle' time
(i.e., no mitigation is active) some filtering rules using DOTS data (i.e., no mitigation is active) some filtering rules using the DOTS
channel to permit traffic from accept-listed sources, but during a data channel protocol to permit traffic from accept-listed sources,
volumetric DDoS attack the DDoS mitigator identifies the source but during a volumetric DDoS attack the DDoS mitigator identifies the
addresses/prefixes in the accept-listed filtering rules are attacking source addresses/prefixes in the accept-listed filtering rules are
the target. For example, an attacker can spoof the IP addresses of attacking the target. For example, an attacker can spoof the IP
accept-listed sources to generate attack traffic or the attacker can addresses of accept-listed sources to generate attack traffic or the
compromise the accept-listed sources and program them to launch a attacker can compromise the accept-listed sources and program them to
DDoS attack. launch a DDoS attack.
[I-D.ietf-dots-signal-channel] is designed so that the DDoS server [I-D.ietf-dots-signal-channel] is designed so that the DDoS server
notifies the conflict to the DOTS client (that is, 'conflict-cause' notifies the conflict to the DOTS client (that is, 'conflict-cause'
parameter set to 2 (Conflicts with an existing accept list)), but the 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 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 attack period due to the high-volume attack traffic saturating
the inbound link. In other words, the DOTS client cannot use the the inbound link to the DOTS client domain. In other words, the DOTS
DOTS data channel to withdraw the accept-list filters when the DDoS client cannot use the DOTS data channel protocol to withdraw the
attack is in progress. This assumes that this DOTS client is the accept-list filters when a DDoS attack is in progress. This assumes
owner of the filtering rule. that this DOTS client is the owner of the filtering rule.
1.2. The Solution 1.2. The Solution
This specification addresses the problems discussed in Section 1.1 by This specification addresses the problems discussed in Section 1.1 by
adding the capability of managing filtering rules using the DOTS adding the capability of managing filtering rules using the DOTS
signal channel, which enables a DOTS client to request the activation signal channel protocol, which enables a DOTS client to request the
or deactivation of filtering rules during a DDoS attack. activation (or deactivation) of filtering rules during a DDoS attack.
The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is The DOTS signal channel protocol is designed to enable a DOTS client
designed to enable a DOTS client to contact a DOTS server for help to contact a DOTS server for help even under severe network
even under severe network congestion conditions. Therefore, congestion conditions. Therefore, extending the DOTS signal channel
extending the DOTS signal channel protocol to manage the filtering protocol to manage the filtering rules during an attack will enhance
rules during a attack will enhance the protection capability offered the protection capability offered by DOTS protocols.
by DOTS protocols.
Note: The experiment at the IETF103 hackathon [Interop] showed Note: The experiment at the IETF103 hackathon [Interop] showed
that even when the incoming 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 the
DOTS signal channel over the saturated link. 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 augment to the DOTS signal channel YANG module is defined in
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 o Section 4.1 illustrates how the filter control extension is used
when conflicts with ACLs are detected by a DOTS server. when conflicts with Access Control List (ACLs) are detected and
reported by a DOTS server.
o Section 4.2 shows how a DOTS client can instruct a DOTS server to o 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 DDoS traffic is o Section 4.3 shows how a DOTS client can react if the DDoS traffic
still being forwarded to the DOTS client domain even if mitigation is still being forwarded to the DOTS client domain even if
requests were sent to a DOTS server. mitigation requests were sent to a DOTS server.
2. Notational Conventions and Terminology The JavaScript Object Notation (JSON) encoding of YANG-modeled data
[RFC7951] is used to illustrate the examples.
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 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 The reader should be familiar with the terms defined in
[I-D.ietf-dots-requirements]. [I-D.ietf-dots-requirements].
The meaning of the symbols in tree diagrams is defined in [RFC8340]. The terminology for describing YANG modules is defined in [RFC7950].
The meaning of the symbols in the tree diagram is defined in
[RFC8340].
3. Controlling Filtering Rules of a DOTS Client 3. Controlling Filtering Rules of a DOTS Client
3.1. Binding the 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
are created a priori by the same DOTS client using the DOTS data protocol are created a priori by the same DOTS client using the DOTS
channel. Managing conflicts with filters installed by other DOTS data channel protocol. Managing conflicts with filters installed by
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 [I-D.ietf-dots-signal-channel], a As discussed in Section 4.4.1 of [I-D.ietf-dots-signal-channel], a
DOTS client must use the same 'cuid' for both the signal and data DOTS client must use the same 'cuid' for both the DOTS signal and
channels. This requirement is meant to facilitate binding DOTS data channels. This requirement is meant to facilitate binding DOTS
channels used by the same DOTS client. channels used by the 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 scope of this document. details about such 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 Access Control List (ACL) name (Section 7.2 of by its ACL name (Section 7.2 of [I-D.ietf-dots-data-channel]). Note
[I-D.ietf-dots-data-channel]). Note that an ACL name unambiguously that an ACL name unambiguously identifies an ACL bound to a DOTS
identifies an ACL bound to a DOTS client, but the same name may be client, but the same name may be used by distinct DOTS clients.
used by distinct DOTS clients.
The activation or deactivation of an ACL by the signal channel The activation or deactivation of an ACL by the DOTS signal channel
overrides the 'activation-type' (defined in Section 7.2 of overrides the 'activation-type' (defined in Section 7.2 of
[I-D.ietf-dots-data-channel]) a priori conveyed with the filtering [I-D.ietf-dots-data-channel]) a priori conveyed with the filtering
rules using the DOTS data channel. rules using the DOTS data channel protocol.
3.2. DOTS Signal Channel Extension 3.2. DOTS Signal Channel Extension
3.2.1. Parameters & 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 [I-D.ietf-dots-signal-channel] to convey the Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the
intended control of the configured filtering rules. Concretely, the intended control of configured filtering rules. Concretely, the DOTS
DOTS client conveys the following parameters in the CBOR body of a client conveys 'acl-list' attribute with the following sub-attributes
mitigation request: in the CBOR body of a mitigation request (see the YANG-encoded
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 7.2 of [I-D.ietf-dots-data-channel]) that is channel (Section 7.2 of [I-D.ietf-dots-data-channel]) that is
associated with the DOTS client. associated with the 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 Access Control Entry has a list of match criteria and (ACE). Each Access Control Entry has a list of match criteria and
a list of actions [I-D.ietf-dots-data-channel]. The list of a list of actions [I-D.ietf-dots-data-channel]. The list of
configured ACLs can be retrieved using the DOTS data channel configured ACLs can be retrieved using the DOTS data channel
during 'idle' time. during 'idle' time.
skipping to change at page 7, line 16 skipping to change at page 7, line 16
| Parameter Name | YANG | CBOR | CBOR Major | JSON | | Parameter Name | YANG | CBOR | CBOR Major | JSON |
| | Type | Key | Type & | Type | | | Type | Key | Type & | Type |
| | | | Information | | | | | | Information | |
+-------------------+------------+--------+---------------+--------+ +-------------------+------------+--------+---------------+--------+
| activation-type | enumeration| 0x0031 | 0 unsigned | String | | activation-type | enumeration| 0x0031 | 0 unsigned | String |
| | | (TBD1) | | | | | | (TBD1) | | |
+-------------------+------------+--------+---------------+--------+ +-------------------+------------+--------+---------------+--------+
Table 1: JSON/YANG mapping to CBOR for 'activation-type' Table 1: JSON/YANG mapping to CBOR for 'activation-type'
A DOTS client may include acl-* attributes in a mitigation request By default, ACL-related operations are achieved using the DOTS data
having a new or an existing 'mid'. When acl-* attributes are to be channel protocol when no attack is ongoing. DOTS clients MUST NOT
included in a mitigation request with an existing 'mid', the DOTS use the filtering control over DOTS signal channel in 'idle' time;
client MUST repeat all the other parameters as sent in the original such requests MUST be discarded by DOTS servers with 4.00 (Bad
mitigation request (i.e., having that 'mid') apart from a possible Request).
change to the lifetime parameter value.
During an attack time, DOTS clients may include 'acl-list', 'acl-
name', and 'activation-type' attributes in a mitigation request.
This request may be the initial mitigation request for a given
mitigation scope or a new one overriding an existing request. In
both cases, a new 'mid' MUST be used. Nevertheless, it is NOT
RECOMMENDED to include ACL attributes in an initial mitigation
request for a given mitigation scope or in a mitigation request
adjusting the mitigation scope.
As the attack evolves, DOTS clients can adjust the 'activation-type'
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
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 [I-D.ietf-dots-signal-channel]. If not, the Section 4.4.2.1 of [I-D.ietf-dots-signal-channel]. If not, the
polling mechanism in Section 4.4.2.2 of polling mechanism in Section 4.4.2.2 of
[I-D.ietf-dots-signal-channel] has to be followed by the DOTS client. [I-D.ietf-dots-signal-channel] 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 [I-D.ietf-dots-data-channel]
when no attack is ongoing.
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.
If the DOTS server does not find the ACL name conveyed in the As a reminder, the 'acl-list' and 'acl-name' parameters are defined
mitigation request in its configuration data for this DOTS client, it as comprehension-required parameters in Table 6 of
MUST respond with a "4.04 (Not Found)" error response code. [I-D.ietf-dots-signal-channel]. Also, the 'activation-type' is
defined as a comprehension-required parameter (Section 5.1).
Following the rules in Section 6 of [I-D.ietf-dots-signal-channel],
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.
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
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 assuming the request passed the validation checks in Section 4.4.1 of
[I-D.ietf-dots-signal-channel], the DOTS server MUST proceed with the [I-D.ietf-dots-signal-channel], the DOTS server MUST proceed with the
'activation-type' update. The update is immediately enforced by the 'activation-type' update. The update is immediately enforced by the
DOTS server and will be maintained as the new activation type for 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 ACL name even after the termination of the mitigation request. In
addition, the DOTS server MUST update the lifetime of the addition, the DOTS server MUST update the lifetime of the
corresponding ACL similar to the update when a refresh request is corresponding ACL similar to the update when a refresh request is
received using the DOTS data channel. received using the DOTS data channel (Section 7.2 of
[I-D.ietf-dots-data-channel]). If, for some reason, the DOTS server
fails to apply the filter update, it MUST respond with 5.03 (Service
Unavailable) error response code and include the failed ACL update in
the diagnostic payload of the response (an example is shown in
Figure 1). Else, the DOTS server replies with the appropriate
response code defined in Section 4.4.1 of
[I-D.ietf-dots-signal-channel].
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"mid": 123,
"ietf-dots-signal-control:acl-list": [
{
"ietf-dots-signal-control:acl-name": "an-accept-list",
"ietf-dots-signal-control:activation-type": "deactivate"
}
]
}
]
}
}
Figure 1: Example of a Diagnostic Payload Including Failed ACL Update
If the DOTS client receives a 5.03 (Service Unavailable) with a
diagnostic payload indicating a failed ACL update as a response to an
initial mitigation or a mitigation with adjusted scope, the DOTS
client MUST immediately send a new request which repeats all the
parameters as sent in the failed mitigation request but without
including the ACL attributes. After the expiry of Max-Age returned
in the 5.03 (Service Unavailable) response, the DOTS client retries
with a new mitigation request (i.e., a new 'mid') that repeats all
the parameters as sent in the failed mitigation request.
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 bound to a DOTS client, the DOTS server notifies that DOTS client
with the change by including the corresponding acl-* parameters in an with 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
[I-D.ietf-dots-signal-channel]). [I-D.ietf-dots-signal-channel]).
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
above request processing operations are undertaken using the
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 update and the withdrawal procedures defined in
[I-D.ietf-dots-signal-channel]. In particular, ACL-related clauses [I-D.ietf-dots-signal-channel]. In particular, ACL-related clauses
are not included in a PUT request used to send an efficacy update and are not included in a PUT request used to send an efficacy update and
DELETE requests. 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" DOTS signal This document augments the "ietf-dots-signal-channel" DOTS signal
YANG module defined in [I-D.ietf-dots-signal-channel] for managing YANG module defined in [I-D.ietf-dots-signal-channel] for managing
filtering rules. 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 /ietf-signal:dots-signal/ietf-signal:message-type
/ietf-signal:mitigation-scope/ietf-signal:scope: /ietf-signal:mitigation-scope/ietf-signal:scope:
+--rw acl-list* [acl-name] {control-filtering}? +--rw acl-list* [acl-name] {control-filtering}?
+--rw acl-name +--rw acl-name
| -> /ietf-data:dots-data/dots-client/acls/acl/name | -> /ietf-data:dots-data/dots-client/acls/acl/name
+--rw activation-type? ietf-data:activation-type +--rw activation-type? ietf-data:activation-type
3.2.2.2. YANG Module 3.2.2.2. YANG Module
<CODE BEGINS> file "ietf-dots-signal-control@2019-04-01.yang" This module uses types defined in [I-D.ietf-dots-data-channel].
<CODE BEGINS> file "ietf-dots-signal-control@2019-05-13.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 signal-control; prefix signal-control;
import ietf-dots-signal-channel { import ietf-dots-signal-channel {
prefix ietf-signal; prefix ietf-signal;
reference reference
skipping to change at page 10, line 5 skipping to change at page 11, line 18
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). (http://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 XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2019-04-01 { revision 2019-05-13 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Controlling Filtering Rules Using Distributed "RFC XXXX: 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 { feature control-filtering {
description description
skipping to change at page 10, line 30 skipping to change at page 11, line 43
augment "/ietf-signal:dots-signal/ietf-signal:message-type" augment "/ietf-signal:dots-signal/ietf-signal:message-type"
+ "/ietf-signal:mitigation-scope/ietf-signal:scope" { + "/ietf-signal:mitigation-scope/ietf-signal:scope" {
if-feature control-filtering; 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 in the DOTS data "List of ACLs as defined using the DOTS data
channel. These ACLs are uniquely defined by channel. ACLs bound to a DOTS client are uniquely
cuid and 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 "/ietf-data:dots-data/ietf-data:dots-client"
+ "/ietf-data:acls/ietf-data:acl/ietf-data:name"; + "/ietf-data:acls/ietf-data:acl/ietf-data:name";
} }
description description
"Reference to the ACL name bound to a DOTS client."; "Reference to the ACL name bound to a DOTS client.";
} }
leaf activation-type { leaf activation-type {
type ietf-data:activation-type; type ietf-data:activation-type;
default "activate-when-mitigating"; default "activate-when-mitigating";
description description
"Set the activation type of an ACL."; "Sets the activation type of an ACL.";
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
4. Sample Examples 4. Sample Examples
This section provides sample examples to illustrate the behavior This section provides sample 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 which 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 1. example, a PUT request 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: {host}:{port} Host: {host}:{port}
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [ "acl": [
{ {
"name": "an-accept-list", "name": "an-accept-list",
"type": "ipv6-acl-type", "type": "ipv6-acl-type",
"activation-type": "activate-when-mitigating", "activation-type": "activate-when-mitigating",
"aces": { "aces": {
"ace": [ "ace": [
{ {
skipping to change at page 12, line 44 skipping to change at page 13, line 45
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
} }
] ]
} }
} }
Figure 1: DOTS Data Channel Request to Create a Filtering Figure 2: DOTS Data Channel Request to Create a Filtering
Some time later, consider that a DDoS attack is detected by the DOTS 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 client on 2001:db8:6401::2/127. Consequently, the DOTS client sends
a mitigation request to its DOTS server as shown in Figure 2. 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"
Uri-Path: "mid=123" Uri-Path: "mid=123"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"target-prefix": [ "target-prefix": [
"2001:db8:6401::2/127" "2001:db8:6401::2/127"
], ],
"target-protocol": [ "target-protocol": [
17 17
], ],
skipping to change at page 13, line 28 skipping to change at page 14, line 29
], ],
"target-protocol": [ "target-protocol": [
17 17
], ],
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
Figure 2: 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 accepts immediately the request by replying with 2.01
(Created) (Figure 3). (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 3: 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 is in progress)' and 'conflict-
cause' set to '2' (conflict-with-acceptlist) to the DOTS client to cause' set to '2' (conflict-with-acceptlist) to the DOTS client to
indicate that this mitigation request is in progress, but a conflict indicate that this mitigation request is in progress, but a conflict
is detected. is 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 4. 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 4. 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=123" Uri-Path: "mid=124"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": { {
"scope": [ "ietf-dots-signal-channel:mitigation-scope": {
{ "scope": [
"target-prefix": [ {
"2001:db8:6401::2/127" "target-prefix": [
], "2001:db8:6401::2/127"
"target-protocol": [ ],
17 "target-protocol": [
], 17
"acl-list": [ ],
{ "ietf-dots-signal-control:acl-list": [
"acl-name": "an-accept-list", {
"activation-type": "deactivate" "ietf-dots-signal-control:acl-name": "an-accept-list",
} "ietf-dots-signal-control:activation-type": "deactivate"
] }
"lifetime": 3600 ]
} "lifetime": 3600
] }
} ]
} }
}
Figure 4: 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 "an-accept-list" ACL and replies
with 2.04 (Changed) response to the DOTS client to confirm the with 2.04 (Changed) response to the DOTS client to confirm the
successful operation. The message body is similar to the one successful operation. The message body is similar to the one
depicted in Figure 3. 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 5, 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
signal channel (Figure 4) instead of the type initially set using the signal channel (Figure 5) instead of the type initially set using the
data channel (Figure 1). data channel (Figure 2).
{ {
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [ "acl": [
{ {
"name": "an-accept-list", "name": "an-accept-list",
"type": "ipv6-acl-type", "type": "ipv6-acl-type",
"activation-type": "deactivate", "activation-type": "deactivate",
"pending-lifetime": 10021, "pending-lifetime": 10021,
"aces": { "aces": {
skipping to change at page 15, line 42 skipping to change at page 16, line 46
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
} }
] ]
} }
} }
Figure 5: DOTS Data Channel GET Response after Mitigation Figure 6: DOTS Data Channel GET Response after Mitigation
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 which 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 6. 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: {host}:{port} Host: {host}:{port}
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [ "acl": [
{ {
"name": "my-accept-list", "name": "my-accept-list",
"type": "ipv6-acl-type", "type": "ipv6-acl-type",
"activation-type": "deactivate", "activation-type": "deactivate",
"aces": { "aces": {
"ace": [ "ace": [
{ {
skipping to change at page 16, line 39 skipping to change at page 17, line 42
"forwarding": "accept" "forwarding": "accept"
} }
} }
] ]
} }
} }
] ]
} }
} }
Figure 6: 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 to 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 7. 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"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:6401::2/127"
],
"target-protocol": [
17
],
"acl-list": [
{
"acl-name": "my-accept-list",
"activation-type": "immediate"
}
"lifetime": 3600
}
]
}
}
Figure 7: DOTS Signal Channel Mitigation Request with a Filter {
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:6401::2/127"
],
"target-protocol": [
17
],
"ietf-dots-signal-control:acl-list": [
{
"ietf-dots-signal-control:acl-name": "my-accept-list",
"ietf-dots-signal-control:activation-type": "immediate"
}
"lifetime": 3600
}
]
}
}
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 "my-accept-list" ACL and replies with 2.01
(Created) response to the DOTS client to confirm the successful (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
resort countermeasure whenever required. It does so by sending, for resort countermeasure whenever required. It does so by sending, for
example, a PUT request shown in Figure 8. The DOTS server installs example, a PUT request shown in Figure 9. The DOTS server installs
this filter with a "deactivated" state. 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=OopPisZqo4SLv64TLPXrxA/acls\ /dots-client=OopPisZqo4SLv64TLPXrxA/acls\
/acl=my-ratelimit-list HTTP/1.1 /acl=my-ratelimit-list HTTP/1.1
Host: {host}:{port} Host: {host}:{port}
Content-Type: application/yang-data+json Content-Type: application/yang-data+json
{ {
"ietf-dots-data-channel:acls": { "ietf-dots-data-channel:acls": {
"acl": [ "acl": [
{ {
"name": "my-ratelimit-list", "name": "my-ratelimit-list",
"type": "ipv6-acl-type", "type": "ipv6-acl-type",
"activation-type": "deactivate", "activation-type": "deactivate",
"aces": { "aces": {
"ace": [ "ace": [
{ {
skipping to change at page 18, line 38 skipping to change at page 19, line 39
"rate-limit": "20.00" "rate-limit": "20.00"
} }
} }
] ]
} }
} }
] ]
} }
} }
Figure 8: DOTS Data Channel Request to Create a Rate-Limit Filter Figure 9: DOTS Data Channel Request to Create a Rate-Limit Filter
Consider now that a DDoS attack is detected by the DOTS client on Consider now that a DDoS attack is detected by the DOTS client on
2001:db8:123::/48. Consequently, the DOTS client sends a mitigation 2001:db8:123::/48. Consequently, the DOTS client sends a mitigation
request to its DOTS server (Figure 9). request to its DOTS server (Figure 10).
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=85" Uri-Path: "mid=85"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{ {
"ietf-dots-signal-channel:mitigation-scope": { "ietf-dots-signal-channel:mitigation-scope": {
"scope": [ "scope": [
{ {
"target-prefix": [ "target-prefix": [
"2001:db8:123::/48" "2001:db8:123::/48"
], ],
"lifetime": 3600 "lifetime": 3600
} }
] ]
skipping to change at page 19, line 25 skipping to change at page 20, line 26
{ {
"target-prefix": [ "target-prefix": [
"2001:db8:123::/48" "2001:db8:123::/48"
], ],
"lifetime": 3600 "lifetime": 3600
} }
] ]
} }
} }
Figure 9: DOTS Signal Channel Mitigation Request to Activate a Rate- Figure 10: DOTS Signal Channel Mitigation Request to Activate a Rate-
Limit Filter Limit Filter
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 the a capability or capacity), the DOTS client is still receiving the
attack trafic which saturates available links. To soften the attack trafic which saturates available links. To soften the
problem, the DOTS client decides to activate the filter that rate- problem, the DOTS client decides to activate the filter that rate-
limits the traffic destined to the DOTS client domain. To that aim, limits the traffic destined to the DOTS client domain. To that aim,
the DOTS client sends the mitigation request to its DOTS server shown the DOTS client sends the mitigation request to its DOTS server shown
in Figure 10. in 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"
Uri-Path: "mid=85" Uri-Path: "mid=86"
Content-Format: "application/dots+cbor" Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:123::/48"
],
"acl-list": [
{
"acl-name": "my-ratelimit-list",
"activation-type": "activate"
}
]
"lifetime": 3600
}
]
}
}
Figure 10: DOTS Signal Channel Mitigation Request to Activate a Rate- {
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:123::/48"
],
"ietf-dots-signal-control:acl-list": [
{
"ietf-dots-signal-control:acl-name": "my-ratelimit-list",
"ietf-dots-signal-control:activation-type": "immediate"
}
]
"lifetime": 3600
}
]
}
}
Figure 11: DOTS Signal Channel Mitigation Request to Activate a Rate-
Limit Filter Limit Filter
Then, the DOTS server activates "my-ratelimit-list" ACL and replies Then, the DOTS server activates "my-ratelimit-list" ACL and replies
with 2.04 (Changed) response to the DOTS client to confirm the with 2.04 (Changed) response to the DOTS client to confirm the
successful operation. successful operation.
As the attack mitigation evolves, the DOTS client may decide to
deactivate the rate-limit policy (e.g., upon receipt of notification
status change from 'attack-exceeded-capability' to 'attack-
mitigation-in-progress'). Based on the mitigation status conveyed by
the DOTS server, the DOTS client can de-activate the rate-limit
action. ). It does so by sending the request shown in Figure 12.
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
Uri-Path: "mid=87"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:123::/48"
],
"ietf-dots-signal-control:acl-list": [
{
"ietf-dots-signal-control:acl-name": "my-ratelimit-list",
"ietf-dots-signal-control:activation-type": "deactivate"
}
]
"lifetime": 3600
}
]
}
}
Figure 12: DOTS Signal Channel Mitigation Request to Deactivate a
Rate-Limit Filter
5. IANA Considerations 5. IANA Considerations
5.1. DOTS Signal Channel CBOR Mappings Registry 5.1. DOTS Signal Channel CBOR Mappings Registry
This specification registers the 'activation-type' parameter in the This specification registers the 'activation-type' parameter in the
IANA "DOTS Signal Channel CBOR Key Values" registry established by IANA "DOTS Signal Channel CBOR Key Values" registry established by
[I-D.ietf-dots-signal-channel]. [I-D.ietf-dots-signal-channel].
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 [I-D.ietf-dots-signal-channel].
Following the rules in [I-D.ietf-dots-signal-channel], 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.
o Note to the RFC Editor: Please delete (TBD1) once the CBOR key is o Note to the RFC Editor: Please delete (TBD1) once the CBOR key is
assigned from the (0x0001 - 0x3FFF) range. assigned from the (0x0001 - 0x3FFF) range.
+--------------------+--------+-------+------------+---------------+ +--------------------+--------+-------+------------+---------------+
| Parameter Name | CBOR | CBOR | Change | Specification | | Parameter Name | CBOR | CBOR | Change | Specification |
| | Key | Major | Controller | Document(s) | | | Key | Major | Controller | Document(s) |
| | Value | Type | | | | | Value | Type | | |
+--------------------+--------+-------+------------+---------------+ +--------------------+--------+-------+------------+---------------+
| activation-type | 0x0031 | 0 | IESG | [RFCXXXX] | | activation-type | 0x0031 | 0 | IESG | [RFCXXXX] |
| | (TBD1) | | | | | | (TBD1) | | | |
skipping to change at page 21, line 41 skipping to change at page 23, line 38
Maintained by IANA: N Maintained by IANA: N
Prefix: signal-control Prefix: signal-control
Reference: RFC XXXX Reference: RFC XXXX
6. Security Considerations 6. Security Considerations
The security considerations discussed in The security considerations discussed in
[I-D.ietf-dots-signal-channel] and [I-D.ietf-dots-data-channel] need [I-D.ietf-dots-signal-channel] and [I-D.ietf-dots-data-channel] need
to be taken into account. to be taken into account.
A DOTS client is entitled to access only to resources it creates. In
particular, a DOTS client can not tweak filtering rules created by
other DOTS clients of the same DOTS client domain.
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 compromised DOTS client exacerbate an ongoing attack. Likewise, such compromised DOTS client
may abstain from reacting to an ACL conflict notification received may abstain from reacting to an ACL conflict notification received
from the DOTS server during attacks. These are not new attack from the DOTS server during attacks. These are not new attack
vectors, but variations of threats discussed in vectors, but variations of threats discussed in
[I-D.ietf-dots-signal-channel] and [I-D.ietf-dots-data-channel]. [I-D.ietf-dots-signal-channel] and [I-D.ietf-dots-data-channel].
DOTS operators should carefully monitor and audit DOTS agents to DOTS operators should carefully monitor and audit DOTS agents to
detect misbehavior and to deter misuse. detect misbehaviors and to deter misuses.
7. Acknowledgements 7. Acknowledgements
Thank you to Takahiko Nagata, Wei Pan, Xia Liang, Jon Shollow, and Many thanks to Takahiko Nagata, Wei Pan, Xia Liang, Jon Shallow, and
Dan Wing for the comments. Dan Wing for the comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-dots-data-channel] [I-D.ietf-dots-data-channel]
Boucadair, M. and R. K, "Distributed Denial-of-Service Boucadair, M. and R. K, "Distributed Denial-of-Service
Open Threat Signaling (DOTS) Data Channel Specification", Open Threat Signaling (DOTS) Data Channel Specification",
draft-ietf-dots-data-channel-28 (work in progress), March draft-ietf-dots-data-channel-29 (work in progress), May
2019. 2019.
[I-D.ietf-dots-signal-channel] [I-D.ietf-dots-signal-channel]
K, R., Boucadair, M., Patil, P., Mortensen, A., and N. K, R., Boucadair, M., Patil, P., Mortensen, A., and N.
Teague, "Distributed Denial-of-Service Open Threat Teague, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification", draft- Signaling (DOTS) Signal Channel Specification", draft-
ietf-dots-signal-channel-31 (work in progress), March ietf-dots-signal-channel-34 (work in progress), May 2019.
2019.
[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>.
skipping to change at page 23, line 11 skipping to change at page 25, line 11
Denial of Service (DDoS) Open Threat Signaling Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-22 (work in Requirements", draft-ietf-dots-requirements-22 (work in
progress), March 2019. progress), March 2019.
[Interop] Nishizuka, K., Shallow, J., and L. Xia , "DOTS Interop [Interop] Nishizuka, K., Shallow, J., and L. Xia , "DOTS Interop
test report, IETF 103 Hackathon", November 2018, 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>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016,
<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>.
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 108-8118 Tokyo 108-8118
 End of changes. 82 change blocks. 
225 lines changed or deleted 337 lines changed or added

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