RFC 9133
Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
RFC 9133 🎀 Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
Bestie, this is RFC 9133 💖, and it's on the Standards Track 🔥, which means it's a real spec that implementers actually build against. It came out in September 2021 📅 and has ISSN 2070-1721 ✨.
The authors are K. Nishizuka (NTT Communications) 🧚, M. Boucadair (Orange) 🦋, T. Reddy.K (Akamai) 💜, and T. Nagata (Lepidum) 🌈. The title block doesn't say it obsoletes or updates any other RFC, so it's standing on its own 💅.
Abstract
Okay so this doc adds a new power-up to the DOTS signal channel protocol 🦋. It lets DOTS clients control their filtering rules while an attack mitigation is active 🔥.
The big deal is that a DOTS client can activate or deactivate existing filtering rules during a Distributed Denial-of-Service (DDoS) attack 💅. The rules themselves get described during an 'idle' time (i.e., no mitigation is active) over the DOTS data channel protocol 🌸.
Status of This Memo
This is an Internet Standards Track document. 🎀
It's a product of the Internet Engineering Task Force (IETF) ✨, and it represents the consensus of the IETF community 🫶. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 👑. For more on Internet Standards, check Section 2 of RFC 7841 💜.
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9133 🍓.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication 📜. Please read these carefully, because they describe your rights and restrictions for this document 🙈. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 💅.
Table of Contents
1. Introduction
1.1. The Problem
1.2. Controlling Filtering Rules Using DOTS Signal Channel
2. Terminology
3. Controlling Filtering Rules of a DOTS Client
3.1. Binding DOTS Data and Signal Channels
3.2. DOTS Signal Channel Extension
3.2.1. Parameters and Behaviors
3.2.2. DOTS Signal Filtering Control Module
3.2.2.1. Tree Structure
3.2.2.2. YANG Module
4. Some Examples
4.1. Conflict Handling
4.2. On-Demand Activation of an Accept-List Filter
4.3. DOTS Servers/Mitigators Lacking Capacity
5. IANA Considerations
5.1. DOTS Signal Channel CBOR Key Values Subregistry
5.2. A New YANG Module
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction 🌸
1.1. The Problem
Okay so, in the Distributed Denial-of-Service Open Threat Signaling (DOTS) architecture [RFC8811] 🧚, DOTS clients and servers talk to each other using both a signal channel protocol [RFC9132] and a data channel protocol [RFC8783] 💬.
The DOTS data channel protocol [RFC8783] is used for bulk data exchange between DOTS agents, which helps the parties involved in responding to a Distributed Denial-of-Service (DDoS) attack coordinate better 🤝. Filter management is one of its tasks. It lets a DOTS client retrieve the filtering capabilities of a DOTS server and manage filtering rules 🛠️. These rules are usually for dropping or rate-limiting unwanted traffic, and for permitting accept-listed traffic ✨.
The DOTS signal channel protocol [RFC9132] is built to stay resilient under extremely hostile network conditions 💪. It keeps DOTS agents in contact even when DDoS attack traffic saturates the link 🫶. The signal channel can be set up between two DOTS agents before or during an attack ⭐. At any time, the DOTS client may send mitigation requests (as per Section 4.4 of [RFC9132]) to a DOTS server over the active signal channel 📨. While mitigation is active, the DOTS server periodically sends status messages to the DOTS client, including basic mitigation feedback details 📊. In case of a massive DDoS attack that saturates the incoming link(s) to the DOTS client, all traffic from the DOTS server to the DOTS client will likely be dropped 😭. Even so, the DOTS server may still receive DOTS messages sent from the DOTS client over the signaling channel, thanks to the heartbeat requests that keep the channel active (as described in Section 4.7 of [RFC9132]) 💖.
Unlike the signal channel protocol, the DOTS data channel protocol is not expected to deal with attack conditions 🙃. So here's the issue: in some deployments, filters installed through the DOTS data channel protocol might not work as expected during DDoS attacks, or they might even make an ongoing attack worse 💀. In those conditions, the DOTS data channel protocol can't be used to change these filters, and that can complicate DDoS mitigation operations [INTEROP] 😤.
A typical case is a conflict between filtering rules installed by a DOTS client and the mitigation actions of a DDoS mitigator 🥊. Picture this: during 'idle' time (i.e., no mitigation is active), a DOTS client sets up some filtering rules with the DOTS data channel protocol to permit traffic from accept-listed sources 📝. Then, during a volumetric DDoS attack, the DDoS mitigator spots that the source addresses/prefixes in those accept-listed rules are attacking the target 🚨. For example, an attacker can spoof the IP addresses of accept-listed sources to generate attack traffic, or the attacker can compromise the accept-listed sources and program them to launch a DDoS attack 👀.
[RFC9132] is designed so that the DDoS server notifies the DOTS client about this conflict (that is, the conflict-cause parameter is set to 2 (conflict-with-acceptlist)) 📣. The catch is that the DOTS client may not be able to withdraw the accept-list rules during the attack period, because high-volume attack traffic is saturating the inbound link to the DOTS client domain 🌊. In other words, the DOTS client cannot use the DOTS data channel protocol to withdraw the accept-list filters while a DDoS attack is in progress 😩.
1.2. Controlling Filtering Rules Using DOTS Signal Channel
This specification tackles the problems from Section 1.1 by adding a way to manage filtering rules through the DOTS signal channel protocol 🦋. That lets a DOTS client request the activation (or deactivation) of filtering rules during a DDoS attack 🔥. Just note that creating these filtering rules is still the job of the DOTS data channel [RFC8783] 📌.
The DOTS signal channel protocol is designed to let a DOTS client reach a DOTS server for help even under severe network congestion 🆘. So extending it to manage filtering rules during an attack will boost the protection that DOTS protocols offer 💅✨.
🧪 Note: The experiment at the IETF 103 hackathon [INTEROP] showed that even when the inbound link is saturated by DDoS attack traffic, the DOTS client can signal mitigation requests using the DOTS signal channel over the saturated link. Iconic. 🙌
Conflicts caused by filters installed by other DOTS clients of the same domain are not discussed in this specification 🙅♀️.
An augmentation to the DOTS signal channel YANG module is defined in Section 3.2.2 📦.
Sample examples are in Section 4, and here's the highlight reel 🎬:
- Section 4.1 shows how the filter control extension is used when conflicts with Access Control Lists (ACLs) are detected and reported by a DOTS server 🚫.
- Section 4.2 shows how a DOTS client can instruct a DOTS server to safely forward some specific traffic in 'attack' time 🛡️.
- Section 4.3 shows how a DOTS client can react if DDoS traffic is still being forwarded to the DOTS client domain even after mitigation requests were sent to a DOTS server 😤.
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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🎀
The reader should be familiar with the terms defined in [RFC8612] 🧠.
The terminology for describing YANG modules is defined in [RFC7950]. The meaning of the symbols in the tree diagram is defined in [RFC8340] and [RFC8791] 🌳.
3. Controlling Filtering Rules of a DOTS Client 👑
3.1. Binding DOTS Data and Signal Channels
The filtering rules that eventually get managed through the DOTS signal channel protocol are created a priori by the same DOTS client, using the DOTS data channel protocol 🧩. Managing conflicts with filters installed by other DOTS clients of the same domain is out of scope 🚫.
As discussed in Section 4.4.1 of [RFC9132], a DOTS client must use the same 'cuid' for both the DOTS signal and data channels 🆔. This requirement is there to make it easier to bind the DOTS channels used by the same DOTS client 🔗.
The DOTS signal and data channels from a DOTS client may or may not use the same DOTS server 🤷♀️. Still, the scope of the mitigation request, alias, and filtering rules isn't limited to one DOTS server. It covers the whole DOTS server domain 🌍. To make that work, DOTS servers within a domain are assumed to have a mechanism for coordinating mitigation requests, aliases, and filtering rules, so their decisions line up and mitigation runs more efficiently ⚡. The exact details of such a mechanism are out of scope for this document 🙃.
A filtering rule controlled by the DOTS signal channel is identified by its ACL name (Section 4.3 of [RFC8783]) 🏷️. An ACL name unambiguously identifies an ACL bound to a DOTS client, but the same name may be used by distinct DOTS clients 👯.
Activating or deactivating an ACL through the DOTS signal channel overrides the 'activation-type' (defined in Section 4.3 of [RFC8783]) that was a priori conveyed with the filtering rules over the DOTS data channel protocol 🔄.
Once the attack is mitigated, the DOTS client may use the data channel to control the 'activation-type' (e.g., revert to a default value) of some filtering rules controlled by the DOTS signal channel, or delete some of those filters 🧹. How this behaves is deployment specific 🏗️.
3.2. DOTS Signal Channel Extension
3.2.1. Parameters and Behaviors ✨
okay bestie, this is where the signal channel gets its filter-control glow-up 💅 This spec extends the mitigation request from Section 4.4.1 of [RFC9132] so the DOTS client can convey the intended control of configured filtering rules. Concretely, the client adds an acl-list attribute with the sub-attributes below to the CBOR body of a mitigation request (see the YANG structure in Section 3.2.2.1) 🎀
acl-name: a name of an access list defined using the DOTS data channel (Section 4.3 of [RFC8783]) that is associated with the DOTS client.
As a reminder, an ACL is an ordered list of Access Control Entries (ACEs). Each ACE has a list of match criteria and a list of actions [RFC8783]. The list of configured ACLs can be retrieved using the DOTS data channel during 'idle' time 🌸
This is a mandatory attribute when acl-list is included.
activation-type: an attribute indicating the activation type of an ACL, overriding the existingactivation-typeinstalled by the DOTS client using the DOTS data channel 🦋
As a reminder, this attribute can be set to deactivate, immediate, or activate-when-mitigating as defined in [RFC8783].
Note that both immediate and activate-when-mitigating have an immediate effect when a mitigation request is being processed by the DOTS server. ⚡
This is an optional attribute.
By default, ACL-related operations happen over the DOTS data channel protocol when no attack is ongoing. DOTS clients MUST NOT use the filtering control over the DOTS signal channel in 'idle' time, and such requests MUST be discarded by DOTS servers with 4.00 (Bad Request). not me being strict, but this is literally the rule 🙈
During 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. The reason is that this recommendation is meant to avoid delaying attack mitigations because of failures to process ACL attributes 🧚
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. They can do this by sending a PUT request with a new mid value. main character energy 👑
It is RECOMMENDED for a DOTS client to subscribe to asynchronous notifications of the attack mitigation, as detailed in Section 4.4.2.1 of [RFC9132]. If not, the polling mechanism in 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 and/or local information to the DOTS client domain to trigger a filter control request. Only filters that are pertinent for an ongoing mitigation should be controlled by a DOTS client using the DOTS signal channel. don't go poking at random filters, iykyk 🫶
acl-list, acl-name, and activation-type are defined as comprehension-required parameters. Following the rules in Section 6 of [RFC9132], if the DOTS server does not understand the acl-list, 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 a 4.04 (Not Found) error response code. ngl that's a whole vibe check 💀
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 [RFC9132], the DOTS server MUST proceed with the activation-type update. The update is immediately enforced by the DOTS server and will be maintained as the new activation type for the ACL name even after the termination of the mitigation request. On top of that, the DOTS server MUST update the lifetime of the corresponding ACL, similar to the update when a refresh request is received using the DOTS data channel (Section 7.2 of [RFC8783]). If, for some reason, the DOTS server fails to apply the filter update, it MUST respond with a 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 [RFC9132]. 🔥
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"mid": 123,
"ietf-dots-signal-control:acl-list": [
{
"acl-name": "an-accept-list",
"activation-type": "deactivate"
}
]
}
]
}
}Figure 1: Example of a Diagnostic Payload Including Failed ACL Update
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 Table 5 of [RFC9132]. 🍓
+===================+=============+======+=================+========+
| Parameter Name | YANG Type | CBOR | CBOR Major Type | JSON |
| | | Key | & Information | Type |
+===================+=============+======+=================+========+
| activation-type | enumeration | 52 | 0 unsigned | String |
+-------------------+-------------+------+-----------------+--------+
| ietf-dots- | list | 53 | 4 array | Array |
| signal- | | | | |
| control:acl-list | | | | |
+-------------------+-------------+------+-----------------+--------+
| acl-name | leafref | 23 | 3 text string | String |
+-------------------+-------------+------+-----------------+--------+Table 1: JSON/YANG Mapping to CBOR for Filter Control Attributes
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 that 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 (i.e., the one including the ACL attributes). so the client gets a fallback first, then a retry 🌈
If, during an active mitigation, the activation-type is changed at the DOTS server (e.g., as a result of an external action) for an ACL bound to a DOTS client, the DOTS server notifies that DOTS client of the change. It does this by including the corresponding ACL parameters in an asynchronous notification (the DOTS client is observing the active mitigation) or in a response to a polling request (Section 4.4.2.2 of [RFC9132]). 🧚♀️
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 update and the withdrawal procedures defined in [RFC9132]. In particular, ACL-related clauses are not included in a PUT request used to send an efficacy update, and DELETE requests. no extra ACL drama there ✨
3.2.2. DOTS Signal Filtering Control Module 🎀
3.2.2.1. Tree Structure
This document augments the "ietf-dots-signal-channel" YANG module defined in [RFC9132] for managing filtering rules. 💖
This document defines the YANG module "ietf-dots-signal-control", which has the following tree structure:
module: ietf-dots-signal-control
augment-structure /dots-signal:dots-signal/dots-signal:message-type
/dots-signal:mitigation-scope/dots-signal:scope:
+-- acl-list* [acl-name]
+-- acl-name
| -> /data-channel:dots-data/dots-client/acls/acl/name
+-- activation-type? data-channel:activation-type3.2.2.2. YANG Module ✨
okay so bestie, this YANG module is NOT meant for managing the DOTS server through NETCONF/RESTCONF 🙅♀️ that stuff is out of scope for this doc. It's only here to give us a data model and encoding, not a management data model. 🧚
It uses types from [RFC8783] 💖
<CODE BEGINS> file "ietf-dots-signal-control@2021-09-02.yang"
module ietf-dots-signal-control {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control";
prefix dots-control;
import ietf-dots-signal-channel {
prefix dots-signal;
reference
"RFC 9132: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification";
}
import ietf-yang-structure-ext {
prefix sx;
reference
"RFC 8791: YANG Data Structure Extensions";
}
import ietf-dots-data-channel {
prefix data-channel;
reference
"RFC 8783: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Data Channel Specification";
}
organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org>
Author: Kaname Nishizuka
<mailto:kaname@nttv6.jp>
Author: Mohamed Boucadair
<mailto:mohamed.boucadair@orange.com>
Author: Tirumaleswar Reddy.K
<mailto:kondtir@gmail.com>
Author: Takahiko Nagata
<mailto:nagata@lepidum.co.jp>";
description
"This module contains YANG definition for the signaling
messages exchanged between a DOTS client and a DOTS server
to control, by means of the DOTS signal channel, filtering
rules configured using the DOTS data channel.
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9133; see
the RFC itself for full legal notices.";
revision 2021-09-02 {
description
"Initial revision.";
reference
"RFC 9133: Controlling Filtering Rules Using Distributed
Denial-of-Service Open Threat Signaling (DOTS)
Signal Channel";
}
sx:augment-structure "/dots-signal:dots-signal"
+ "/dots-signal:message-type"
+ "/dots-signal:mitigation-scope"
+ "/dots-signal:scope" {
description
"ACL name and activation type.";
list acl-list {
key "acl-name";
description
"List of ACLs as defined using the DOTS data
channel. ACLs bound to a DOTS client are uniquely
identified by a name.";
leaf acl-name {
type leafref {
path "/data-channel:dots-data/data-channel:dots-client"
+ "/data-channel:acls/data-channel:acl"
+ "/data-channel:name";
}
description
"Reference to the ACL name bound to a DOTS client.";
}
leaf activation-type {
type data-channel:activation-type;
default "activate-when-mitigating";
description
"Sets the activation type of an ACL.";
}
}
}
}
<CODE ENDS>4. Some Examples 🎀
this section is all about examples that show off the behavior from Section 3.2.1 🦋 these are just for illustration, so they should not be considered as deployment recommendations, okay? 🙈
4.1. Conflict Handling 💅
so picture this: a DOTS client checks in with its DOTS server during 'idle' time to install an accept-list 🫶 the list lets UDP traffic from 2001:db8:1234::/48 with destination port 443 get forwarded to 2001:db8:6401::2/127. it does this by sending a PUT request, like the one in Figure 2 ✨
PUT /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=paL8p4Zqo4SLv64TLPXrxA/acls\
/acl=an-accept-list HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{
"ietf-dots-data-channel:acls": {
"acl": [
{
"name": "an-accept-list",
"type": "ipv6-acl-type",
"activation-type": "activate-when-mitigating",
"aces": {
"ace": [
{
"name": "test-ace-ipv6-udp",
"matches": {
"ipv6": {
"destination-ipv6-network": "2001:db8:6401::2/127",
"source-ipv6-network": "2001:db8:1234::/48"
},
"udp": {
"destination-port-range-or-operator": {
"operator": "eq",
"port": 443
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
}
]
}
}
Figure 2: DOTS Data Channel Request to Create a Filterlater on, the DOTS client detects a DDoS attack on 2001:db8:6401::2/127 😱 so it sends a mitigation request to its DOTS server, as in Figure 3 🔥
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA"
Uri-Path: "mid=123"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:6401::2/127"
],
"target-protocol": [
17
],
"lifetime": 3600
}
]
}
}
Figure 3: DOTS Signal Channel Mitigation Requestthe DOTS server instantly says yes ✅ with a 2.01 (Created) reply. Figure 4 shows the message body of that response 💖
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"mid": 123,
"lifetime": 3600
}
]
}
}
Figure 4: Status Response (Message Body)now, if the DOTS client subscribed to asynchronous notifications 👀 and the DOTS server works out that some attack sources belong to 2001:db8:1234::/48, the server sends a notification with 'status' set to 1 (attack-mitigation-in-progress) and 'conflict-cause' set to 2 (conflict-with-acceptlist) 🚨 that basically means the mitigation is in progress, but there's a conflict.
once the client gets that notification, it sends a PUT to deactivate the "an-accept-list" ACL, as in Figure 5 🙅♀️ the client can also choose to send that same PUT if suspect traffic shows up from the accept-listed source (2001:db8:1234::/48). it has the same structure as the one in Figure 5 🫶
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=paL8p4Zqo4SLv64TLPXrxA"
Uri-Path: "mid=124"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:6401::2/127"
],
"target-protocol": [
17
],
"ietf-dots-signal-control:acl-list": [
{
"acl-name": "an-accept-list",
"activation-type": "deactivate"
}
],
"lifetime": 3600
}
]
}
}
Figure 5: PUT for Deactivating a Conflicting Filterthen the DOTS server deactivates "an-accept-list" and replies with a 2.04 (Changed) response to confirm it worked ✨ the message body looks a lot like Figure 4 💅
once the attack is mitigated, the DOTS client can use the data channel to grab its ACLs from the DOTS server 🧚 as Figure 6 shows, the activation type is now 'deactivate', because the signal channel changed it (Figure 5), not the original value from the data channel (Figure 2) 🦋
{
"ietf-dots-data-channel:acls": {
"acl": [
{
"name": "an-accept-list",
"type": "ipv6-acl-type",
"activation-type": "deactivate",
"pending-lifetime": 10021,
"aces": {
"ace": [
{
"name": "test-ace-ipv6-udp",
"matches": {
"ipv6": {
"destination-ipv6-network": "2001:db8:6401::2/127",
"source-ipv6-network": "2001:db8:1234::/48"
},
"udp": {
"destination-port-range-or-operator": {
"operator": "eq",
"port": 443
}
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
}
]
}
}
Figure 6: DOTS Data Channel GET Response after Mitigation
(Message Body)the whole chain is giving full main character energy 🌈👑
4.2. On-Demand Activation of an Accept-List Filter ✨
Okay bestie, picture a DOTS client checking in with its DOTS server during 'idle' time to install an accept-list. The filter lets UDP traffic from 2001:db8:1234::/48 get forwarded to 2001:db8:6401::2/127. It does this with a PUT request, like the one in Figure 7. The DOTS server installs the filter in a "deactivated" state, so it just sits there chilling until it's needed 💤
PUT /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=ioiuLoZqo4SLv64TLPXrxA/acls\
/acl=my-accept-list HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{
"ietf-dots-data-channel:acls": {
"acl": [
{
"name": "my-accept-list",
"type": "ipv6-acl-type",
"activation-type": "deactivate",
"aces": {
"ace": [
{
"name": "an-ace",
"matches": {
"ipv6": {
"destination-ipv6-network": "2001:db8:6401::2/127",
"source-ipv6-network": "2001:db8:1234::/48",
"protocol": 17
}
},
"actions": {
"forwarding": "accept"
}
}
]
}
}
]
}
}Figure 7: DOTS Data Channel Request to Create an Accept-List Filter
Fast forward a bit. A UDP DDoS attack gets detected by the DOTS client on 2001:db8:6401::2/127, but the DOTS client still wants traffic from 2001:db8:1234::/48 to be accept-listed to the DOTS client domain. So it sends a mitigation request to its DOTS server, as shown in Figure 8. 🫶
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=ioiuLoZqo4SLv64TLPXrxA"
Uri-Path: "mid=4879"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:6401::2/127"
],
"target-protocol": [
17
],
"ietf-dots-signal-control:acl-list": [
{
"acl-name": "my-accept-list",
"activation-type": "immediate"
}
],
"lifetime": 3600
}
]
}
}Figure 8: DOTS Signal Channel Mitigation Request with a Filter Control
The DOTS server activates the my-accept-list ACL and replies with a 2.01 (Created) response to the DOTS client to confirm the successful operation. Iconic teamwork 👑
4.3. DOTS Servers/Mitigators Lacking Capacity 💪
This section is about a DOTS client that activates a drop-list or a rate-limit filter during an attack. Let's get into it.
Here's the setup. A DOTS client checks in with its DOTS server during 'idle' time to install an accept-list that rate-limits all (or a part thereof) traffic to be forwarded to 2001:db8:123::/48. This is a last resort countermeasure, to be used whenever required. The PUT request in Figure 9 does the job, and the DOTS server installs the filter with a "deactivated" state.
PUT /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=OopPisZqo4SLv64TLPXrxA/acls\
/acl=my-ratelimit-list HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{
"ietf-dots-data-channel:acls": {
"acl": [
{
"name": "my-ratelimit-list",
"type": "ipv6-acl-type",
"activation-type": "deactivate",
"aces": {
"ace": [
{
"name": "my-ace",
"matches": {
"ipv6": {
"destination-ipv6-network": "2001:db8:123::/48"
}
},
"actions": {
"forwarding": "accept",
"rate-limit": "20000.00"
}
}
]
}
}
]
}
}Figure 9: DOTS Data Channel Request to Create a Rate-Limit Filter
Now a DDoS attack is detected by the DOTS client on 2001:db8:123::/48. So the DOTS client sends a mitigation request to its DOTS server, shown in Figure 10. 🚨
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
Uri-Path: "mid=85"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:123::/48"
],
"lifetime": 3600
}
]
}
}Figure 10: DOTS Signal Channel Mitigation Request
Here's where it gets messy. For some reason (e.g., the DOTS server, or the mitigator, is lacking a capability or capacity), the DOTS client is still receiving attack traffic, and it's saturating the available links 😭 To soften the problem, the DOTS client decides to activate the filter that rate-limits the traffic destined to the DOTS client domain. The mitigation request it sends to its DOTS server is shown in Figure 11.
Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=OopPisZqo4SLv64TLPXrxA"
Uri-Path: "mid=86"
Content-Format: "application/dots+cbor"
{
"ietf-dots-signal-channel:mitigation-scope": {
"scope": [
{
"target-prefix": [
"2001:db8:123::/48"
],
"ietf-dots-signal-control:acl-list": [
{
"acl-name": "my-ratelimit-list",
"activation-type": "immediate"
}
],
"lifetime": 3600
}
]
}
}Figure 11: DOTS Signal Channel Mitigation Request to Activate a Rate-Limit Filter
Then the DOTS server activates the my-ratelimit-list ACL and replies with a 2.04 (Changed) response to the DOTS client to confirm the successful operation. 🎉
As the attack mitigation evolves, the DOTS client may decide to deactivate the rate-limit policy. For example, it might do so upon receipt of a 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 deactivate the rate-limit action. It does so by sending the request shown in Figure 12. Very calm, very in control. 🦋
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": [
{
"acl-name": "my-ratelimit-list",
"activation-type": "deactivate"
}
],
"lifetime": 3600
}
]
}
}Figure 12: DOTS Signal Channel Mitigation Request to Deactivate a Rate-Limit Filter
5. IANA Considerations 🌈
5.1. DOTS Signal Channel CBOR Key Values Subregistry
Per this specification, IANA has registered the following parameters in the "DOTS Signal Channel CBOR Key Values" subregistry within the "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel" registry [Key-Map]. Registry paperwork, but make it cute 🎀
+==================+==========+=======+============+===============+
| Parameter Name | CBOR Key | CBOR | Change | Specification |
| | 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
5.2. A New YANG Module
IANA has registered the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.IANA has also registered the following YANG module in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. ✨
Name: ietf-dots-signal-control
Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-signal-control
Maintained by IANA: N
Prefix: dots-control
Reference: RFC 91336. Security Considerations 🔒
The security considerations for the DOTS signal channel protocol are discussed in Section 11 of [RFC9132], while those for the DOTS data channel protocol are discussed in Section 10 of [RFC8783]. The following discusses the security considerations that are specific to the DOTS signal channel extension defined in this document.
This specification does not allow the creation of new filtering rules, which is the responsibility of the DOTS data channel. DOTS client domains should be adequately prepared prior to an attack, e.g., by creating filters that will be activated on demand when an attack is detected. Prep before the storm, always. 🌧️
A DOTS client is entitled to access only the resources it creates. In particular, a DOTS client can not tweak filtering rules created by other DOTS clients of the same DOTS client domain. As a reminder, DOTS servers must associate filtering rules with the DOTS client that created these resources. Failure to ensure such association by a DOTS server will have severe impact on DOTS client domains. 🚫
A compromised DOTS client can use the filtering control capability to exacerbate an ongoing attack. Likewise, such a compromised DOTS client may abstain from reacting to an ACL conflict notification received from the DOTS server during attacks. These are not new attack vectors, but variations of threats discussed in [RFC9132] and [RFC8783]. DOTS operators should carefully monitor and audit DOTS agents to detect misbehaviors and deter misuses. This one is serious, bestie 💀
7. References 📚
7.1. Normative References 📚
okay bestie, these are the normative refs, aka the reading you genuinely can't skip if you want the spec to make sense 🎀 every single one is load-bearing ✨
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<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",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed
Denial-of-Service Open Threat Signaling (DOTS) Data
Channel Specification", RFC 8783, DOI 10.17487/RFC8783,
May 2020, <https://www.rfc-editor.org/info/rfc8783>.
[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>.
[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
"Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification", RFC 9132,
DOI 10.17487/RFC9132, September 2021,
<https://www.rfc-editor.org/info/rfc9132>.7.2. Informative References 🧠
these ones are the bonus reading 💅 nice to have, great for context, and they're all right here
[INTEROP] Nishizuka, K., Shallow, J., and L. Xia, "DOTS Interop test
report, IETF 103 Hackathon", November 2018,
<https://datatracker.ietf.org/meeting/103/materials/
slides-103-dots-interop-report-from-ietf-103-hackathon-
00>.
[Key-Map] IANA, "Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel",
<https://www.iana.org/assignments/dots>.
[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",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
Threat Signaling (DOTS) Requirements", RFC 8612,
DOI 10.17487/RFC8612, May 2019,
<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 🫶
huge thank yous 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 all the comments 💖 the whole squad showed up.
and a special shoutout to Benjamin Kaduk for the AD review 👑
Authors' Addresses 💌
these are the people who wrote it, and where to find them 🦋
Kaname Nishizuka
NTT Communications
GranPark 16F 3-4-1 Shibaura, Minato-ku, Tokyo
108-8118
Japan
Email: kaname@nttv6.jp
Mohamed Boucadair
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com
Tirumaleswar Reddy.K
Akamai
Embassy Golf Link Business Park
Bangalore 560071
Karnataka
India
Email: kondtir@gmail.com
Takahiko Nagata
Lepidum
Japan
Email: nagata@lepidum.co.jp📦 where this page comes from
- ietf: rfc9133 2021-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms