RFC 8811

DDoS Open Threat Signaling (DOTS) Architecture

📅 published August 2020, from ietf

RFC 8811: DDoS Open Threat Signaling (DOTS) Architecture 🛡️✨

okay bestie, so this one is the architecture doc for DOTS 🦋. It's Informational, not a Standards Track spec, which means it's a big-picture map of how everything fits, not a rulebook with protocol details. Published August 2020 by a squad from Forcepoint, McAfee, Cisco, Iron Mountain and Charter, with A. Mortensen and T. Reddy.K as editors 💜. It is an IETF product that went through public review and IESG approval 🎀. It doesn't obsolete or update anything, so it's a clean fresh start 🌸.

Here's the vibe in one line: DOTS is how networks ask each other for help when a DDoS attack hits, and this doc explains the roles and the relationships 💅.

Abstract

This document describes an architecture for establishing and maintaining Distributed Denial-of-Service (DDoS) Open Threat Signaling (DOTS) within and between domains. It doesn't specify protocols or protocol extensions. Instead, it focuses on defining the architectural relationships, components, and concepts used in a DOTS deployment 🧚.

Status of This Memo

Okay so, this is not a Standards Track spec. It's published for informational purposes 📚.

It's an IETF product 💖, meaning it reflects the consensus of the IETF community. It got public review and was approved by the Internet Engineering Steering Group (IESG). Not everything the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🙈.

For the current status, errata, and a place to send feedback, head to https://www.rfc-editor.org/info/rfc8811 ✨.

Copyright (c) 2020 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) in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions 📜. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💜.

Table of Contents

1.  Context and Motivation
  1.1.  Terminology
    1.1.1.  Key Words
    1.1.2.  Definition of Terms
  1.2.  Scope
  1.3.  Assumptions
2.  DOTS Architecture
  2.1.  DOTS Operations
  2.2.  Components
    2.2.1.  DOTS Client
    2.2.2.  DOTS Server
    2.2.3.  DOTS Gateway
  2.3.  DOTS Agent Relationships
    2.3.1.  Gatewayed Signaling
3.  Concepts
  3.1.  DOTS Sessions
    3.1.1.  Preconditions
    3.1.2.  Establishing the DOTS Session
    3.1.3.  Maintaining the DOTS Session
  3.2.  Modes of Signaling
    3.2.1.  Direct Signaling
    3.2.2.  Redirected Signaling
    3.2.3.  Recursive Signaling
    3.2.4.  Anycast Signaling
    3.2.5.  Signaling Considerations for Network Address
            Translation
  3.3.  Triggering Requests for Mitigation
    3.3.1.  Manual Mitigation Request
    3.3.2.  Automated Conditional Mitigation Request
    3.3.3.  Automated Mitigation on Loss of Signal
4.  IANA Considerations
5.  Security Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgments
Contributors
Authors' Addresses

1. Context and Motivation ✨

Okay, big picture. When you're under an active DDoS attack, you need a shared understanding of who does what, so everyone can coordinate a defense 🛡️. DOTS is the signaling layer plus the extra messaging that makes that happen 💅. It's designed so willing peers can coordinate defenses to mitigate attacks quickly and efficiently 🚀. That means a hybrid response: handling it locally at or near the target, or anywhere along the path between the attackers and the target 🦋. Sample use cases are covered in [DOTS-USE-CASES] 📖.

This document describes the architecture used to set up, maintain, or tear down a DOTS relationship, whether it's inside one domain or between domains 🌈.

1.1. Terminology

1.1.1. Key Words

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 🎀.

1.1.2. Definition of Terms

This document uses the terms defined in [RFC8612] 📚.

1.2. Scope

So here's the scope 👑. DOTS clients and servers talk to each other using the DOTS signal channel [RFC8782] and data channel [RFC8783] protocols 💬.

The architecture works across network administrative domains, like between an enterprise domain and a third-party attack mitigation service. It also works within a single administrative domain 🧚. DOTS is generally most effective when it's coordinating attack response between two or more participating networks, but single-domain setups are valuable too, like when you're rolling up intra-domain DOTS client signals for an inter-domain coordinated response 🫶.

This document doesn't cover any administrative or business agreements between the DOTS parties, since those are out of scope 🙈. Regardless, it assumes that necessary authentication and authorization mechanisms are in place, so only authorized clients can invoke the DOTS service 🔐.

A detailed set of DOTS requirements is discussed in [RFC8612], and the DOTS architecture is designed to follow those requirements 💖. Only new behavioral requirements are described in this document ✨.

1.3. Assumptions

Okay, here are the assumptions this doc makes 🧠:

  • All domains where DOTS is deployed are assumed to offer the required connectivity between DOTS agents and any intermediary network elements. The architecture doesn't add any extra limits on the form of that connectivity 🔌.
  • Congestion and resource exhaustion are intended outcomes of a DDoS attack [RFC4732] 💀. Some operators may use non-impacted paths or networks for DOTS. But in general, conditions should be assumed to be hostile, and DOTS must be able to function in all circumstances, including when the signaling path is significantly impaired 😭. Congestion control requirements are discussed in Section 3 of [RFC8612] 📖. The DOTS signal channel defined in [RFC8782] is designed to be extremely resilient under extremely hostile network conditions, and it keeps DOTS agents in contact even while DDoS attack traffic saturates the link 🔥.
  • There's no universal DDoS attack scale threshold that triggers a coordinated response across administrative domains 🙅. A network domain administrator, or a service or application owner, may arbitrarily set attack scale threshold triggers or manually send requests for mitigation 🍓.
  • Mitigation requests may be sent to one or more upstream DOTS servers, based on criteria set by DOTS client administrators and the underlying network configuration. The number of DOTS servers a given DOTS client has communications with is determined by local policy and is deployment specific. For example, a DOTS client on a multihomed network may support built-in policies to establish DOTS relationships with DOTS servers located upstream of each interconnection link 🌸.
  • The mitigation capacity and/or capability of domains receiving coordinated attack response requests is opaque to the domains sending the request 🫣. The domain receiving the DOTS client signal may or may not have enough capacity or capability to filter any or all DDoS attack traffic aimed at a target. Either way, the upstream DOTS server may redirect a request to another DOTS server. Redirection may stay local to the redirecting server's domain, or it may involve a third-party domain 🦋.
  • DOTS client and server signals, plus messages sent through the data channel, travel across any transit networks with the same probability of delivery as any other traffic between the DOTS client domain and the DOTS server domain. Any encapsulation needed for successful delivery is left untouched by transit network elements. DOTS servers and DOTS clients can't assume any preferential treatment of DOTS signals. Some deployments (like intra-domain scenarios) may offer that preferential treatment, and the DOTS architecture doesn't rule it out when it's available. However, DOTS itself doesn't say how that's done 🤷‍♀️.
  • The architecture allows for, but doesn't assume, Quality-of-Service (QoS) policy agreements between DOTS-enabled peer networks, or local QoS prioritization meant to make sure DOTS messages get delivered between DOTS agents. QoS is just an operational consideration, not a functional part of the DOTS architecture 💅.
  • The signal and data channels are loosely coupled and might not terminate on the same DOTS server. How DOTS servers synchronize the DOTS configuration is out of scope for this specification 🎀.

(This is part 1 of 8. More parts are coming, so stay tuned bestie 💜🌈)

2. DOTS Architecture ✨

okay bestie, let's get into the basic DOTS architecture 🦋 here's the picture:

       +-----------+            +-------------+
       | Mitigator | ~~~~~~~~~~ | DOTS Server |
       +-----------+            +-------------+
                                       |
                                       |
                                       |
       +---------------+        +-------------+
       | Attack Target | ~~~~~~ | DOTS Client |
       +---------------+        +-------------+

Figure 1: Basic DOTS Architecture

so a simple example would be an enterprise as the attack target for a volumetric DDoS attack, with an upstream DDoS mitigation service as the mitigator 💅 the service the mitigator provides is called "DDoS mitigation service". the enterprise is connected to the Internet through a link that is getting saturated, and the enterprise suspects it's under DDoS attack. the enterprise has a DOTS client, which gets info about the DDoS attack and signals the DOTS server for help mitigating it. then the DOTS server invokes one or more mitigators, which are the ones actually tasked with handling the DDoS attack. they aim to suppress the attack traffic while still letting valid traffic reach the attack target. it's giving teamwork 🫶

the scope of the DOTS specifications is the interfaces between the DOTS client and DOTS server. the interfaces to the attack target and the mitigator are out of scope, and so is the operation of both the attack target and the mitigator 🙈 so DOTS doesn't specify how an attack target decides it's under DDoS attack, and it doesn't specify how a mitigator actually mitigates the attack either. a DOTS client's request for mitigation is advisory in nature 💜 it might not lead to any mitigation at all, depending on the DOTS server domain's capacity and willingness to mitigate on behalf of the DOTS client domain.

the DOTS client may be given a list of DOTS servers, each associated with one or more IP addresses. these addresses may or may not be of the same address family. the DOTS client sets up one or more sessions by connecting to the provided DOTS server addresses ✨

as shown in Figure 2, there are two interfaces between a DOTS server and a DOTS client: a signal channel and (optionally) a data channel 🎀

  +---------------+                                 +---------------+
  |               | <------- Signal Channel ------> |               |
  |  DOTS Client  |                                 |  DOTS Server  |
  |               | <=======  Data Channel  ======> |               |
  +---------------+                                 +---------------+

Figure 2: DOTS Interfaces

the main job of the signal channel is for a DOTS client to ask a DOTS server for help mitigating an attack, and for the DOTS server to keep the DOTS client posted on how that mitigation is going 📡 the DOTS client does this by sending a client signal that has info about the attack target(s). the client signal can also include telemetry about the attack, if the DOTS client has it. then the DOTS server sends a server signal to tell the DOTS client whether it will honor the mitigation request. if it will, the DOTS server starts attack mitigation and periodically updates the DOTS client on the status 🔥 it goes both ways, too: the DOTS client periodically tells the DOTS server about the client's status. at a minimum that's client (attack target) health info, and it should also include efficacy information about the attack mitigation as it is now seen by the client. at some point the DOTS client might decide to end the server-side attack mitigation, and it tells the DOTS server over the signal channel. a mitigation can also end if a DOTS client-specified mitigation lifetime is exceeded ⏳ one important detail: the signal channel may need to work over a link that's experiencing a DDoS attack, so it can be subject to severe packet loss and high latency 💀

the signal channel can request mitigation all by itself, but adding the DOTS data channel unlocks extra, more efficient capabilities 🍓 the main purpose of the data channel is to support DOTS-related configuration and policy information exchange between the DOTS client and the DOTS server. examples of that info include, but are not limited to:

  • Creating identifiers: names or aliases for resources that might get mitigation requests. these identifiers can then be used in later signal channel exchanges to refer more efficiently to the resources under attack.
  • Drop-list management: lets a DOTS client tell the DOTS server about sources to suppress.
  • Accept-list management: lets a DOTS client tell the DOTS server about sources that traffic is always accepted from.
  • Filter management: lets a DOTS client install or remove traffic filters that drop or rate-limit unwanted traffic.
  • DOTS client provisioning.
⚠️ here's the important bit: it's possible to exchange all of the above before, during, or after a DDoS attack. but DOTS requires reliable delivery of this info, and it doesn't offer any special means for making sure it arrives on time during an attack. so in practice, DOTS deployments should rely on this info being exchanged only under normal traffic conditions 🌸

2.1. DOTS Operations

DOTS doesn't prescribe any specific deployment models 🧚 but it's designed with some specific requirements around the different DOTS agents and how they relate to each other.

first of all, a DOTS agent belongs to a domain that has an identity which can be authenticated and authorized. DOTS agents talk to each other over a mutually authenticated signal channel and (optionally) data channel. before they can do that, though, a service relationship has to be set up between them. the details and means of doing that are outside the scope of DOTS. an example would be an enterprise A (DOTS client) signing up for DDoS service from provider B (DOTS server). that creates a (service) relationship between the two, which lets enterprise A's DOTS client set up a signal channel with provider B's DOTS server. A and B authenticate each other, and B can verify that A is authorized for its service 🫶

from an operational and design point of view, DOTS assumes that the above relationship is set up before any request for DDoS attack mitigation. in particular, it's assumed that bidirectional communication is possible at that point between the DOTS client and DOTS server. it's also assumed that additional service provisioning, configuration, and information exchange can be done over the data channel if operationally required. the mitigation service isn't available for use until this point ✨

once the mutually authenticated signal channel is set up, it stays active. this is done to increase the likelihood that the DOTS client can signal the DOTS server for help when the attack target is being flooded. it also raises the probability that DOTS server signals reach the client regardless of inbound link congestion 💖 this doesn't necessarily mean the attack target and the DOTS client have to be co-located in the same administrative domain, but that's expected to be a common scenario.

DDoS mitigation with the help of an upstream mitigator may involve some form of traffic redirection, where traffic destined for the attack target gets steered toward the mitigator. common mechanisms for this redirection depend on BGP [RFC4271] and DNS [RFC1035] 🌈 then the mitigator inspects and scrubs the traffic and forwards the resulting (hopefully non-attack) traffic to the attack target. so when a DOTS server gets an attack mitigation request from a DOTS client, you can think of it as a way of causing traffic redirection for the attack target that was indicated 👑

DOTS relies on mutual authentication and the pre-established service relationship between the DOTS client domain and the DOTS server domain to provide authorization. the DOTS server should enforce authorization mechanisms that restrict the mitigation scope a DOTS client can request, but those authorization mechanisms are deployment specific 🔐

co-location of the DOTS server and mitigator within the same domain is expected to be a common deployment model. still, it's assumed that operators may need alternative models, and nothing in this document rules those alternatives out 🦋

2.2. Components

2.2.1. DOTS Client

a DOTS client is a DOTS agent that requests help coordinating an attack response. those requests may be in response to an active, ongoing attack against a target in the DOTS client domain, but no active attack is required for a DOTS client to ask for help 🍓 operators may want upstream mitigators in the network path for an indefinite period, and the only limits on the duration and scope of requested mitigation are business relationships 💅

the DOTS client requests attack response coordination from a DOTS server over the signal channel. in the request, it includes the DOTS client's desired mitigation scoping, as described in [RFC8612] (SIG-008). the actual mitigation scope and countermeasures used in response to the attack are up to the DOTS server and mitigator operators, since the DOTS client may have a narrow perspective on the ongoing attack 👀 so the DOTS client's request for mitigation should be considered advisory. guarantees of DOTS server availability or mitigation capacity count as Service Level Agreements (SLAs), and those are out of scope for this document 💀

the DOTS client adjusts mitigation scope and provides available mitigation feedback (e.g., mitigation efficacy) at the direction of its local administrator ✨ that direction might involve manual or automated adjustments in response to updates from the DOTS server.

to give a metric of signal health and tell an idle signal channel apart from a disconnected or defunct session, the DOTS client sends a heartbeat over the signal channel to keep its half of the channel alive 💖 the DOTS client similarly expects a heartbeat from the DOTS server, and it may consider a session terminated if the DOTS server heartbeat is absent for an extended period 🥺

2.2.2. DOTS Server ✨

okay so, a DOTS server is a DOTS agent that can receive, process, and maybe act on requests for help coordinating attack responses from DOTS clients 🛡️ 💖 It's the one that checks who's asking (see Section 3.1), keeps track of session state, tracks mitigation requests, reports on how active mitigations are doing, and ends sessions when a client has been silent for way too long or a session times out 💀

Assuming the preconditions we'll talk about below are all good, a DOTS client with an active session can reasonably expect some level of mitigation when it asks for coordinated attack response 🎀 ✨

Next up, the DOTS server needs to be able to tell whether a given resource is inside a particular DOTS client domain 🧚 For example, this could look like associating a set of IP addresses and/or prefixes with each DOTS client domain 🍓 The DOTS server enforces authorization for mitigation signals, filtering rules, and aliases for resources coming from DOTS clients 💅 The enforcement mechanism is not in scope for this document, but it's expected to restrict mitigation requests, filtering rules, aliases for addresses and prefixes, and/or services owned by the DOTS client domain. The goal is that a DOTS client from one domain is not able to influence the network path to another domain 😭 🚫

A DOTS server MUST reject mitigation requests, filtering rules, and aliases for resources not owned by the requesting DOTS client's administrative domain. 🙅‍♀️ The exact way the DOTS servers check that resources are within the scope of the DOTS client domain is deployment specific 🌸

For example, if the DOTS client domain uses Provider-Aggregatable prefixes for its resources and uses the DDoS mitigation service of the Internet Transit Provider (ITP), the ITP already knows the prefixes, because the ITP assigned them itself 🦋 But if the DDoS mitigation is offered by a third-party DDoS mitigation service provider, that provider does not know which resources the DOTS client domain owns 🥺 In that case, the DDoS mitigation service provider and the DOTS client domain can opt to use the identifier validation challenges discussed in [RFC8555] and [RFC8738] to figure out whether the DOTS client domain actually controls the resources 🔍 The challenges for validating control of resources must be performed when no attack traffic is present, and they only work for "dns" and "ip" identifier types ⚠️ Also, if the DOTS client lies about which resources it owns, the DDoS mitigation service provider can impose penalties for violating the SLA 😤 💸

A DOTS server MAY also refuse a DOTS client's mitigation request for arbitrary reasons, within any limits imposed by business or SLAs between client and server domains. 🫶 And if a DOTS server does refuse a DOTS client's request for mitigation, the DOTS server MUST include the refusal reason in the server signal sent to the client. 📣 💜

A DOTS server is in regular contact with one or more mitigators 🤝 If a DOTS server accepts a DOTS client's request for help, it forwards a translated form of that request to the mitigator(s) responsible for scrubbing attack traffic ✨ The form of the translated request passed from the DOTS server to the mitigator is not in scope. It might be as simple as an alert to mitigator operators, or it could be highly automated using vendor or open application programming interfaces supported by the mitigator 🤖 The DOTS server MUST report the actual scope of any mitigation enabled on behalf of a client. 📏

The DOTS server SHOULD retrieve available metrics for any mitigations activated on behalf of a DOTS client and SHOULD include them in server signals sent to the DOTS client originating the request for mitigation. 📊🌈

To give a metric of signal health and tell an idle signal channel apart from a disconnected or defunct one, the DOTS server MUST send a heartbeat over the signal channel to maintain its half of the channel. 💓 The DOTS server also expects a heartbeat from the DOTS client, and MAY consider a session terminated in the extended absence of a DOTS client heartbeat. 🥀 👀

2.2.3. DOTS Gateway 🌉

Traditional client/server relationships can be expanded by chaining DOTS sessions 🔗 This chaining works through "logical concatenation" of a DOTS server and a DOTS client, which gives you something analogous to the Session Initiation Protocol (SIP) [RFC3261] logical entity of a Back-to-Back User Agent (B2BUA) [RFC7092] 💅 The term "DOTS gateway" is used here in the descriptions of selected scenarios involving this application 🎀

A DOTS gateway may be deployed client side, server side, or both 🌍 It may terminate multiple discrete client connections and aggregate them into a single DOTS session or multiple DOTS sessions 🧩

The DOTS gateway will appear as a server to its downstream agents and as a client to its upstream agents, a functional concatenation of the DOTS client and server roles, as shown in Figure 3 🪞✨

                     +-------------+
                     |    | D |    |
     +----+          |    | O |    |         +----+
     | c1 |----------| s1 | T | c2 |---------| s2 |
     +----+          |    | S |    |         +----+
                     |    | G |    |
                     +-------------+

                       Figure 3: DOTS Gateway

The DOTS gateway MUST perform full stack DOTS session termination and reorigination between its client and server side. The details of how this is achieved are implementation specific 🛠️ 🌷

2.3. DOTS Agent Relationships 🧸

So far we've only looked at a pretty simple setup with a single DOTS client linked to a single DOTS server, but DOTS supports way more advanced relationships 🌈 💫

A DOTS server may be associated with one or more DOTS clients, and those clients may belong to different domains 👯‍♀️ An example is a mitigation provider serving multiple attack targets (Figure 4) 🏰

  DOTS clients       DOTS server
  +---+
  | c |-----------
  +---+           \
  c1.example.org   \
                    \
  +---+              \ +---+
  | c |----------------| S |
  +---+              / +---+
  c1.example.com    /  dots1.example.net
                   /
  +---+           /
  | c |-----------
  +---+
  c2.example.com

            Figure 4: DOTS Server with Multiple Clients

A DOTS client may be associated with one or more DOTS servers, and those servers may belong to different domains 🌐 This can be for high availability, or to coordinate mitigation with more than one directly connected ISP 💖 An example is an enterprise getting DDoS mitigation service from multiple providers, as shown in Figure 5 🏢

  DOTS client        DOTS servers
                      +---+
           -----------| S |
          /           +---+
         /            dots1.example.net
        /
  +---+/              +---+
  | c |---------------| S |
  +---+\              +---+
        \             dots.example.org
         \
          \           +---+
           -----------| S |
                      +---+
  c.example.com       dots2.example.net

                  Figure 5: Multihomed DOTS Client

Deploying a multihomed client takes extra care and planning 🧠 The DOTS servers a multihomed client talks to might not be affiliated with each other, so if the client asks for mitigation from every server it has signal channels with at the same time, it might accidentally cause network chaos for the very resources it's trying to protect 😬 In one of the worst cases, a multihomed DOTS client could cause a permanent routing loop for traffic headed to its protected services, because the uncoordinated mitigators all keep trying to divert that traffic to their own scrubbing centers 🌀💀

The DOTS protocol itself has no fool-proof way to prevent these self-inflicted harms when you deploy multihomed DOTS clients 🙈 If DOTS client implementations include support for multihoming anyway, they are expected to be aware of the risks and to include measures that reduce the likelihood of bad outcomes 🫧 Simple measures might include:

  • Requesting mitigation serially, so only one mitigation request for a given address space is active at any given time 🕐
  • Dividing the protected resources among the DOTS servers, so no two mitigators are trying to divert and scrub the same traffic 🍰
  • Restricting multihoming to deployments where all DOTS servers coordinate management of a shared pool of mitigation resources 🤝💜

2.3.1. Gatewayed Signaling ✨

okay so, remember from Section 2.2.3 that a DOTS gateway is basically a logical function that chains DOTS sessions together by stacking a DOTS server and a DOTS client back to back 🔗

Here's the main scenario, shown in Figure 6 and Figure 7. Picture an enterprise with a bunch of DOTS-capable devices that can signal inside their own domain over TCP [RFC0793] on links that aren't congested. Those devices talk to a DOTS gateway, and the gateway can switch things to UDP [RFC0768] for the trip between domains, which is where connection-oriented transports can start to struggle 😤 This only applies to the signal channel though, because the data channel needs a connection-oriented transport. And the initial clients don't get to see what's going on between the gateway and its upstream agents. It's a whole mystery box 🎁

         +---+
         | c |\
         +---+ \              +---+
                \-----TCP-----| D |               +---+
         +---+                | O |               |   |
         | c |--------TCP-----| T |------UDP------| S |
         +---+                | S |               |   |
                /-----TCP-----| G |               +---+
         +---+ /              +---+
         | c |/
         +---+
         example.com       example.com           example.net
         DOTS clients      DOTS gateway (DOTSG)  DOTS server

               Figure 6: Client-Side Gateway with Aggregation
         +---+
         | c |\
         +---+ \              +---+
                \-----TCP-----| D |------UDP------+---+
         +---+                | O |               |   |
         | c |--------TCP-----| T |------UDP------| S |
         +---+                | S |               |   |
                /-----TCP-----| G |------UDP------+---+
         +---+ /              +---+
         | c |/
         +---+
         example.com       example.com           example.net
         DOTS clients      DOTS gateway (DOTSG)  DOTS server

             Figure 7: Client-Side Gateway without Aggregation

This setup can also be flipped 🙃 where the gateway lives on the server-side domain instead. In that case it can terminate and/or aggregate multiple clients onto a single transport, as shown in Figure 8 and Figure 9.

         +---+
         | c |\
         +---+ \              +---+
                \-----UDP-----| D |               +---+
         +---+                | O |               |   |
         | c |--------TCP-----| T |------TCP------| S |
         +---+                | S |               |   |
                /-----TCP-----| G |               +---+
         +---+ /              +---+
         | c |/
         +---+
         example.com       example.net           example.net
         DOTS clients      DOTS gateway (DOTSG)  DOTS server

               Figure 8: Server-Side Gateway with Aggregation
         +---+
         | c |\
         +---+ \              +---+
                \-----UDP-----| D |------TCP------+---+
         +---+                | O |               |   |
         | c |--------TCP-----| T |------TCP------| S |
         +---+                | S |               |   |
                /-----UDP-----| G |------TCP------+---+
         +---+ /              +---+
         | c |/
         +---+
         example.com       example.net           example.net
         DOTS clients      DOTS gateway (DOTSG)  DOTS server

             Figure 9: Server-Side Gateway without Aggregation

This document also lines up with scenarios that involve multiple DOTS gateways 🌸 For example, one DOTS gateway sits on the network client's side and another sits on the server side. The first gateway can live at Customer Premises Equipment (CPE), where it aggregates requests from multiple DOTS clients enabled in an enterprise network. The second DOTS gateway is deployed on the provider side. Honestly, this whole setup can be seen as a combo of the client-side and server-side scenarios, and it's giving layers 🧅

3. Concepts 💖

3.1. DOTS Sessions 🎀

Okay, so for DOTS to actually work as a way to send DDoS mitigation requests, one or more DOTS clients have to set up ongoing communication with one or more DOTS servers. There can also be business relationships, SLAs, or other formal or informal understandings between network operators that come into play before DOTS gets enabled in or among network domains. Those kinds of considerations are out of scope for this document though, so we're not getting into them here 🙅‍♀️

A DOTS session is set up to support a two-way exchange of data between an associated DOTS client and a DOTS server. In the DOTS architecture, data goes back and forth between DOTS agents over signal and data channels. So a DOTS session can be a DOTS signal channel session, a DOTS data channel session, or both. The DOTS server ties the DOTS signal and data channel sessions together using the DOTS client identity. The DOTS session is explained in more detail in the DOTS signal channel protocol defined in [RFC8782] and the DOTS data channel protocol defined in [RFC8783] 📖

A DOTS agent can maintain one or more DOTS sessions. Easy 💅

A DOTS signal channel session is tied to a single transport connection (a TCP connection or a UDP session) and a security association (a TLS or DTLS session). In the same way, a DOTS data channel session is tied to a single TCP connection and a TLS security association 🔐

Here's the tea: mitigation requests created using the DOTS signal channel are not bound to the DOTS signal channel session. Instead, they're associated with a DOTS client, and they can be managed using different DOTS signal channel sessions. Main character energy for those requests ✨

3.1.1. Preconditions 🧾

Before a DOTS session can get going between agents, the owners of the networks, domains, services or applications involved are assumed to have agreed on the terms of their relationship. Those agreements are out of scope for this document, but they must be in place for a functional DOTS architecture.

It's assumed that, as part of any DOTS service agreement, the DOTS client gets all the data and metadata it needs to talk to the DOTS server. That includes any cryptographic information needed to meet the message confidentiality, integrity, and authenticity requirement (SEC-002) in [RFC8612]. It might also include the pool of DOTS server addresses and ports the DOTS client should use for signal and data channel messaging 🗝️

3.1.2. Establishing the DOTS Session 🚀

Once the business agreements are in place, the DOTS client starts a DOTS session by contacting its DOTS server(s) over the signal channel and (possibly) the data channel. For flexibility, neither the order of contact nor the time gap between channel creations is specified. A DOTS client MAY establish the signal channel first and then the data channel, or do it the other way around 🙌

The document doesn't prescribe how a DOTS client gets the address and associated service details of the DOTS server. For example, a DOTS client can be directly configured to use a specific DOTS server IP address and port. It can also be given directly any data it needs to satisfy the Peer Mutual Authentication requirement (SEC-001) in [RFC8612], such as symmetric or asymmetric keys, usernames, passwords, and so on. In this scenario, all configuration and authentication information is provided out of band by the domain operating the DOTS server 📦

On the flip side, the architecture in this document also allows for a form of DOTS client auto-provisioning 🪄 For example, the domain operating the DOTS server or servers might give the client domain only symmetric or asymmetric keys to authenticate the provisioned DOTS clients. Only those keys would be directly configured on the DOTS clients. The rest of the configuration needed to provision the DOTS clients could be learned through mechanisms similar to DNS SRV [RFC2782] or DNS Service Discovery [RFC6763].

The DOTS client SHOULD successfully authenticate and exchange messages with the DOTS server over both the signal and (if used) data channel as soon as possible. That's how it confirms both channels are operational 🫶

As described in [RFC8612] (DM-008), the DOTS client can configure preferred values for acceptable signal loss, mitigation lifetime, and heartbeat intervals when it establishes the DOTS signal channel session. A DOTS signal channel session isn't active until DOTS agents have agreed on the values for these DOTS session parameters, and that agreement is a process defined by the protocol 🤝

Once the DOTS client starts receiving DOTS server signals, the DOTS session is active 🟢 At any time during the DOTS session, the DOTS client may use the data channel to manage aliases, manage drop- and accept-listed prefixes or addresses, leverage vendor-specific extensions, and so on. Note that, unlike the signal channel, there's no requirement that the data channel stays operational in attack conditions. (See "Data Channel Requirements" Section 2.3 of [RFC8612].) Not the signal channel being the MVP here 🥲

3.1.3. Maintaining the DOTS Session 💜

DOTS clients and servers send heartbeats to each other periodically over the signal channel, which is covered in [RFC8612] (SIG-004). DOTS agent operators SHOULD configure the heartbeat interval so that the frequency doesn't cause accidental denials of service from the overwhelming number of heartbeats a DOTS agent has to field. Don't let your heartbeats become the attack, bestie 😭

Either DOTS agent may consider a DOTS signal channel session terminated after an extended absence of heartbeats from its peer agent. The period of that absence will be established in the protocol definition ⏳

3.2. Modes of Signaling 🦋

This section looks at the modes of signaling between agents in a DOTS architecture.

3.2.1. Direct Signaling 🎯

A DOTS session may take the form of direct signaling between the DOTS clients and servers, as shown in Figure 10.

        +-------------+                            +-------------+
        | DOTS client |<------signal session------>| DOTS server |
        +-------------+                            +-------------+

                     Figure 10: Direct Signaling

In a direct DOTS session, the DOTS client and server talk to each other directly. Direct signaling can exist inter- or intra-domain. The DOTS session is abstracted away from the underlying networks or network elements the signals travel through. With direct signaling, the DOTS client and server are logically adjacent, which is very much a 1-on-1 vibe 👯‍♀️

3.2.2. Redirected Signaling ✨

okay so sometimes a DOTS server needs to send a DOTS client over to a different DOTS server for its DOTS signal channel session 💅 and there are a bunch of reasons this can happen, like:

  • the server has already hit its maximum number of DOTS signal channel sessions with clients 🫠
  • the mitigator that this server talks to is running out of mitigation capacity 😬
  • the mitigator is down, or it's getting scheduled maintenance 🛠️
  • the DOTS server itself is getting scheduled maintenance 🛠️
  • there are scheduled changes to the network path between the DOTS server and the DOTS client 🛣️

the basic redirected setup looks like this, shown in Figure 11 🦋

        +-------------+                            +---------------+
        |             |<-(1)--- DOTS signal ------>|               |
        |             |      channel session 1     |               |
        |             |<=(2)== redirect to B ======|               |
        | DOTS client |                            | DOTS server A |
        |             |X-(4)--- DOTS signal ------X|               |
        |             |      channel session 1     |               |
        |             |                            |               |
        +-------------+                            +---------------+
               ^
               |
              (3) DOTS signal channel
               |      session 2
               v
        +---------------+
        | DOTS server B |
        +---------------+

                   Figure 11: Redirected Signaling

here's how it plays out, step by step 🎀

  1. first, DOTS signal channel session 1 is already up between a DOTS client and DOTS server A 🤝
  2. DOTS server A sends a server signal that redirects the client over to DOTS server B 📨
  3. if the DOTS client doesn't already have a separate DOTS signal channel session with the redirection target, it starts up and establishes DOTS signal channel session 2 with DOTS server B 🧚
  4. once the client has been redirected, DOTS server A stops sending server signals, and the DOTS client also stops sending client signals to DOTS server A. DOTS signal channel session 1 gets terminated 👋

3.2.3. Recursive Signaling 🌈

okay, the whole point of DOTS is making the response to DDoS attacks faster and more efficient 🚀 and one scenario we haven't talked about yet is coordination between federated domains that each run DOTS servers and mitigators 👑

in normal DOTS operations, a DOTS client tells a DOTS server that it needs mitigation, and that server starts mitigation on a mitigator it has an established service relationship with 🛡️ the operator of that mitigator might keep an eye on mitigation performance and capacity too, because the attack could get more severe than what their domain can handle 😵‍💫

the mitigator operator doesn't have a ton of options if a requested mitigation is getting totally overwhelmed by the attack 😭 out-of-scope business arrangements or SLAs might let the mitigating domain just drop the mitigation and let the attack traffic flow through to the target, but that only encourages the attackers to escalate 📈 and if the mitigating domain is also the upstream service provider for the attack target, its other services and users can keep suffering the side effects of the attack 💀

a recursive signaling model, shown in Figure 12, is a cute alternative 💖 in a variation of the use case "Upstream DDoS Mitigation by an Upstream Internet Transit Provider" described in [DOTS-USE-CASES], a domain running a DOTS server and mitigator also runs a DOTS client 🍓 that DOTS client has an established DOTS session with a DOTS server that belongs to a separate administrative domain 🫶

so with those preconditions in place, the operator of the struggling mitigator can request mitigation for the attack target from that separate DOTS-aware domain 🙏 this request recurses the original mitigation request over to the secondary DOTS server, hoping to build up a cumulative mitigation against the attack 💪

                    example.net domain
                    . . . . . . . . . . . . . . . . .
                    .    Gn                         .
      +----+    1   .  +----+       +-----------+   .
      | Cc |<--------->| Sn |~~~~~~~| Mitigator |   .
      +----+        .  +====+       |     Mn    |   .
                    .  | Cn |       +-----------+   .
    example.com     .  +----+                       .
       client       .    ^                          .
                    . . .|. . . . . . . . . . . . . .
                         |
                       2 |
                         |
                    . . .|. . . . . . . . . . . . . .
                    .    v                          .
                    .  +----+       +-----------+   .
                    .  | So |~~~~~~~| Mitigator |   .
                    .  +----+       |     Mo    |   .
                    .               +-----------+   .
                    .                               .
                    . . . . . . . . . . . . . . . . .
                    example.org domain

                   Figure 12: Recursive Signaling

in Figure 12, client Cc sends a request for mitigation over inter-domain DOTS session 1 to DOTS server Sn in the example.net domain 📡 DOTS server Sn turns on mitigation at mitigator Mn 🔛 Sn is half of DOTS gateway Gn, and it's set up logically back to back with DOTS client Cn 🧩 Cn already has inter-domain DOTS session 2 with DOTS server So in the example.org domain 🌸 at any point, DOTS server Sn MAY recurse an ongoing mitigation request through DOTS client Cn to DOTS server So 🦄 the idea is that mitigator Mo gets activated to help defend the attack target 🛡️

recursive signaling is opaque to the DOTS client, and that's kinda the tea 🫖 still, to give the DOTS client as much visibility into mitigation as possible, the recursing domain SHOULD send recursed mitigation feedback in signals that report mitigation status to the DOTS client 👀 for example, the recursing domain's DOTS server should fold in available metrics, like dropped packet or byte counts from the recursed domain's DOTS server, into its mitigation status messages 📊

DOTS clients involved in recursive signaling MUST be able to withdraw mitigation requests without warning or justification, per SIG-006 in [RFC8612] 🚪

operators that recurse mitigation requests MAY keep the recursed mitigation going for a brief protocol-defined period if the originating DOTS client withdraws its request for help 🕰️ this is covered in the discussion of managing mitigation toggling in SIG-006 of [RFC8612] 🔁

deploying recursive signaling can lead to traffic redirection, examination, and mitigation reaching beyond the first one-on-one relationship between the DOTS client and DOTS server 🌍 which means the client might have less control over the network path its mitigated traffic takes 😬 DOTS client operators SHOULD be aware of any privacy concerns and work with the DOTS server operators who use recursive signaling so that shared sensitive material stays properly protected 🔐 usually there's a contractual SLA negotiated among the DOTS client domain, the recursed domain, and the recursing domain 📝 it covers the privacy requirements of the DOTS client domain and gives the recursing domain authorization to request mitigation for resources controlled by the DOTS client domain 🎀

3.2.4. Anycast Signaling 🌷

the DOTS architecture doesn't assume anycast is available within a DOTS deployment, but it doesn't rule it out either 🤷‍♀️ domains running DOTS servers MAY deploy DOTS servers with an anycast Service Address, as described in BCP 126 [RFC4786] 💫 in that kind of deployment, DOTS clients connecting to the DOTS Service Address might end up talking to different DOTS servers, depending on the network configuration at the moment they connect 🗺️ anycast signaling has some perks, including:

  • simpler DOTS client configuration, including service discovery through the methods described in [RFC7094] ⚙️ in this setup, the "instance discovery" message is just a DOTS client starting a DOTS session to the DOTS server anycast Service Address, and the DOTS server replies with a redirection to the unicast address the client should use for DOTS 🧭
  • region- or customer-specific deployments, where the DOTS Service Addresses route to different DOTS servers depending on the client's region or the customer network the DOTS client lives in 🌏
  • operational resiliency, which spreads DOTS signaling traffic across the DOTS server domain's networks and also reduces the potential attack surface, as described in BCP 126 [RFC4786] 🛡️✨

3.2.4.1. Anycast Signaling Considerations

okay so as long as the network config stays stable, anycast DOTS signaling looks exactly like direct signaling to the individual DOTS client 👀✨ but bestie, the operational challenges with anycast are literally not nothing 😭 DOTS server operators need to weigh the risks against the benefits really carefully before they deploy 💅

the DOTS signal channel mainly runs over UDP per SIG-001 in [RFC8612] 🦋 but the signal channel also needs mutual authentication between DOTS agents, with security state stored on both ends 🔐

network instability is a big deal with anycast signaling 🌪️ because DOTS signal channels are supposed to be long lived, and they might be running under congested conditions caused by a volumetric DDoS attack. so yeah, not great 💀

for example, if a network config change alters the route to the DOTS server during active anycast signaling, the DOTS client might start sending messages to a different DOTS server than the one it first set up its signaling session with. that second server might not have the security state of the existing session, so the DOTS client ends up having to initialize a brand new DOTS session 😤 this could be partly mitigated by using resumption via a pre-shared key (PSK) in TLS 1.3 [RFC8446] and DTLS 1.3 [DTLS-PROTOCOL] (session resumption in TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347]), but the keying material then has to be available to all DOTS servers sharing the anycast Service Address, which comes with its own operational challenges 🙃

while the DOTS client tries to set up a new DOTS session with the DOTS server now acting as the anycast DOTS Service Address, the link between the DOTS client and server might be congested with attack traffic 🚧 which makes session establishment hard. in that scenario, anycast Service Address instability turns into a sort of signal session flapping, and that has obvious negative consequences for the DOTS deployment 😩

anycast signaling deployments also have to think about active mitigations 🛡️ active mitigations started through a DOTS session might involve diverting traffic to a scrubbing center. if the DOTS session flaps because of anycast changes like we just talked about, the mitigation may flap too, since the DOTS servers sharing the anycast DOTS service address toggle mitigation when they detect DOTS session loss. whether that happens depends on whether the client has configured mitigation on loss of signal (Section 3.3.3) 🎀

3.2.5. Signaling Considerations for Network Address Translation

network address translators (NATs) are expected to be a super common feature of DOTS deployments 🌸 the middlebox traversal guidelines in [RFC8085] include general NAT considerations that apply to DOTS deployments when the signal channel is set up over UDP 🫶

there are also DOTS-specific considerations when NATs are part of the DOTS architecture 👑 for example, DDoS attack detection behind a NAT will detect attacks against internal addresses. a DOTS client later asked to request mitigation for that attacked scope of addresses can't reasonably do the job, because the mitigation scope has no externally routable addresses in it 😵‍💫

the following considerations don't cover every possible scenario 🙈 they're more about highlighting the common issues people anticipate when signaling through NATs.

3.2.5.1. Direct Provisioning of Internal-to-External Address Mappings

operators can dodge the problem of translating internal addresses or prefixes into externally routable mitigation scopes by directly provisioning the mappings of external addresses to internal protected resources on the DOTS client 🧚 when the operator asks for mitigation scoped to internal addresses (directly or through automated means), the DOTS client looks up the matching external addresses or prefixes and issues a mitigation request scoped to that externally routable info. so clean ✨

when you directly provision the address mappings, operators need to keep them up to date, or they risk losing the ability to request accurate mitigation scopes 😬 to help with that, the DOTS client can rely on mechanisms like [RFC8512] or [RFC7658] to retrieve static explicit mappings. this document doesn't prescribe how the mappings get maintained once they're provisioned on the DOTS client, so that part is up to you 💖

3.2.5.2. Resolving Public Mitigation Scope with Port Control Protocol (PCP)

Port Control Protocol (PCP) [RFC6887] can be used to retrieve the external addresses/prefixes and/or port numbers if the NAT function embeds a PCP server 🌈

a DOTS client can use the info it gets from PCP to feed the DOTS protocol messages that get sent to a DOTS server 💌 those messages convey the external addresses/prefixes as set by the NAT.

PCP also enables discovery and configuration of the lifetime of port mappings set up in intermediate NAT devices ⏳ discovering those mapping lifetimes can reduce how much we depend on heartbeat messages to keep mappings alive, which means less load on DOTS servers and the network. big brain move 🧠✨

3.2.5.3. Resolving Public Mitigation Scope with Session Traversal Utilities (STUN)

an internal resource, e.g., a web server, can discover its reflexive transport address through a STUN Binding request/response transaction, as described in [RFC8489] 🔍 after it learns that reflexive transport address from the STUN server, the internal resource can export its reflexive transport address and its internal transport address to the DOTS client. that lets the DOTS client request mitigation with the correct external scope, as shown in Figure 13 🦋 how the reflexive transport address and internal transport address get handed to the DOTS client is unspecified in this document, so that's a mystery for another day 🤷‍♀️

to stop an attacker from messing with the STUN messages in transit, the STUN client and server must use the message-integrity mechanism discussed in Section 9 of [RFC8489], or use STUN over DTLS [RFC7350] or STUN over TLS 🔒 if the STUN client is behind a NAT that does Endpoint-Dependent Mapping [RFC5128], the internal service can't give the DOTS client the reflexive transport address it found with STUN 😭 you might be able to figure out how a NAT between the STUN client and STUN server behaves using the experimental techniques in [RFC5780], but there's currently no standardized way for a STUN client to reliably tell whether it's behind a NAT that does Endpoint-Dependent Mapping. yikes, I know 🙃

               Binding         Binding
   +--------+  request  +---+  request  +--------+
   |  STUN  |<----------| N |<----------|  STUN  |
   | server |           | A |           | client |
   |        |---------->| T |---------->|        |
   +--------+  Binding  +---+ Binding   +--------+
               response       response    |
                                          | reflexive transport address
                                          | & internal transport address
                                          v
                                        +--------+
                                        |  DOTS  |
                                        | client |
                                        +--------+

              Figure 13: Resolving Mitigation Scope with STUN

3.2.5.4. Resolving Requested Mitigation Scope with DNS

DOTS supports mitigation scoped to DNS names 🍓 as discussed in [RFC3235], using DNS names instead of IP addresses can potentially dodge the address translation problem, as long as the same domain name is resolvable both internally and externally. for example, a detected attack's internal target address can be mapped to a DNS name through a reverse lookup 🔁 the DNS name returned by that reverse lookup can then be handed to the DOTS client as the external scope for mitigation. for the reverse DNS lookup, DNS Security Extensions (DNSSEC) [RFC4033] must be used where the authenticity of the response is critical 🔐 (so don't skip it when it matters!)

3.3. Triggering Requests for Mitigation

[RFC8612] places no limit on the circumstances in which a DOTS client operator may request mitigation 💅 and it doesn't demand justification for any mitigation request either. that leaves operational control over DDoS defense with the domain requesting mitigation, which is honestly very on-brand for them 👑 this architecture doesn't prescribe the network conditions and mechanisms that trigger a mitigation request from a DOTS client, either.

that said, looking at some selected possible mitigation triggers from an architectural perspective gives us a model for alternative or unanticipated triggers in DOTS deployments 🧩 in every case, which network conditions merit a mitigation request is entirely at the discretion of the DOTS client operator 🫶

the mitigation request itself is defined by DOTS 📦 but the interfaces needed to trigger that request in the following scenarios are implementation specific 🛠️

3.3.1. Manual Mitigation Request

a DOTS client operator can manually prepare a request for mitigation, including scope and duration, and then manually tell the DOTS client to send it to the DOTS server 🙌 in context, a manual request is one the operator issues directly, with no automated decision making done by a device interacting with the DOTS client. manual requests can be sent in a few ways, like an operator typing a command into a text interface or directly clicking through a graphical interface to send it 🖱️

an operator might do this, for example, after getting notice of an attack from attack detection equipment or software, when the alerting detector doesn't have interfaces (or isn't set up to use the available ones) to turn the alert into a mitigation request automatically 🚨

in a variation on that scenario, the operator may have preconfigured mitigation requests on the DOTS client for various resources in their domain 🗂️ when notified of an attack, the operator manually tells the DOTS client to send the relevant preconfigured mitigation request for the resources under attack. so efficient, I'm obsessed 😍

there's also a further variant that involves recursive signaling, as described in Section 3.2.3 🪆 here the DOTS client is the second half of a DOTS gateway (a back-to-back DOTS server and client). just like the previous scenario, the scope and duration of the mitigation request are preexisting, but in this case they're derived from the mitigation request the DOTS server received from a downstream DOTS client 💜 as long as the preconditions required by Section 3.2.3 are in place, the DOTS gateway operator can manually request mitigation from an upstream DOTS server at any time, sending a mitigation request derived from the downstream DOTS client's request ✨

the motivations for a DOTS client operator to request mitigation manually aren't prescribed by this architecture 🤷‍♀️ but they're expected to include some of the following:

  • Notice of an attack delivered via email or alternative messaging 📧
  • Notice of an attack delivered via phone call 📞
  • Notice of an attack delivered through the interface(s) of networking monitoring software deployed in the operator's domain 📊
  • Manual monitoring of network behavior through network monitoring software 👀

3.3.2. Automated Conditional Mitigation Request

Okay so bestie, manual mitigation requests depend totally on the DOTS client operator being fast and accurate enough to react to every attack they detect or could detect 😭💅. Automated conditional mitigation requests are the glow-up 🦋. They cut down the operator's workload AND shrink the time between attack detection and the start of mitigation ✨. Lowkey iconic.

So here's how it goes: mitigation requests get triggered by network conditions that the operator sets up 🎀. How attack detection works is up to each deployment, and this architecture doesn't put any limits on it 🧚. The exact conditions are the operator's call too, but these are the common ones that deserve mitigation 💜:

  • Detected attack exceeding a rate in packets per second (pps).
  • Detected attack exceeding a rate in bytes per second (bps).
  • Detected resource exhaustion in an attack target.
  • Detected resource exhaustion in the local domain's mitigator.
  • Number of open connections to an attack target.
  • Number of attack sources in a given attack.
  • Number of active attacks against targets in the operator's domain.
  • Conditional detection developed through arbitrary statistical analysis or deep learning techniques.
  • Any combination of the above.

When automated conditional mitigation requests are turned on, any violation of the conditions above, or any extra conditions the operator defines, will trigger a mitigation request from the DOTS client to the DOTS server 🌈. The interfaces between the app that spots the condition violation and the DOTS client are implementation specific 🫶.

3.3.3. Automated Mitigation on Loss of Signal

Okay, this one is giving "keep the lights on" energy 💡. To keep a DOTS signal channel session alive, the DOTS client and the DOTS server swap regular but infrequent messages across the signal channel 💖. When there's no attack, the chance of message loss in the signaling channel should be extremely low 🌸. Under attack conditions though, some signal loss may be expected, since attack traffic can congest the link depending on the attack type 😭.

[RFC8612] says the DOTS protocol should be robust when signaling under attack conditions, and it does 💅. BUT there are still situations where the DOTS signal gets lost even with the protocol doing its best 💀. So to handle those, a DOTS operator may request one or more mitigations, and those only kick in when the DOTS server stops receiving DOTS client heartbeats beyond the miss count or interval the protocol allows 🔥.

Be careful before turning this on, no cap 🙈. The impact of mitigating due to loss of signal in either direction MUST be considered carefully before enabling it. Attack traffic congesting links is not the only reason signal could be lost, so mitigation requests triggered by signal channel degradation in either direction may rack up unnecessary costs from scrubbing traffic, and hurt network performance and operational expense alike 💸.

4. IANA Considerations ✨

This document has no IANA actions 🌸.

5. Security Considerations 🔐

Okay, this section is the serious one, so let's go 😤. It describes the security considerations we've identified for the DOTS architecture 💜.

Security considerations and security requirements discussed in [RFC8612] need to be taken into account 🫶.

DOTS is at risk from three main attack vectors: agent impersonation, traffic injection, and signal blocking 💀. An attacker can use these individually or together to confuse, disable, pull information from, or otherwise inhibit DOTS agents 😭.

Any attacker who can impersonate a legit DOTS client or server, or inject false messages into the stream, could potentially trigger or withdraw traffic redirection, trigger or cancel mitigation activities, or subvert drop-/accept-lists 🙈. From an architectural standpoint, operators MUST ensure conformance to the security requirements defined in Section 2.4 of [RFC8612] to secure data in transit 🔒. Similarly, since the received data may contain network topology, telemetry, and threat and mitigation information that could be sensitive in certain environments, it SHOULD be protected at rest per required local policy 🎀.

DOTS agents MUST perform mutual authentication to make sure they're authentic to each other, and DOTS servers MUST verify that the requesting DOTS client is authorized to request mitigation for specific target resources (see Section 2.2.2) 💅.

A man-in-the-middle (MITM) attacker can intercept and drop packets, stopping the DOTS peers from receiving some or all of the DOTS messages 😱. Automated mitigation on loss of signal can be used as a countermeasure, but it comes with the risks discussed in Section 3.3.3 ⚠️.

An attacker controlling a DOTS client can mess with network traffic by requesting and withdrawing mitigation for particular prefixes, which can lead to route or DNS flapping 🌀. DOTS operators should carefully monitor and audit DOTS clients to detect misbehavior and deter misuse 👀.

Any attack on the availability of DOTS servers may disrupt the system's ability to receive and process DOTS signals, resulting in a failure to fulfill a mitigation request 😭. DOTS servers MUST be given adequate protections in accordance with best current practices for network and host security 🛡️.

6. References 📚

6.1. Normative References

[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>.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.

[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <https://www.rfc-editor.org/info/rfc4786>.

[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <https://www.rfc-editor.org/info/rfc6887>.

[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>.

[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>.

6.2. Informative References 📚✨

okay so these are the informative refs, the "read this if you want the backstory" list 💅 nothing here is required to implement RFC 8811, but it's lowkey iconic reading material. Here's the full lineup:

Acknowledgments 🫶

big thank-yous to Matt Richardson, Roman Danyliw, Frank Xialiang, Roland Dobbins, Wei Pan, Kaname Nishizuka, Jon Shallow, Paul Kyzivat, Warren Kumari, Benjamin Kaduk, and Mohamed Boucadair for their comments and suggestions 💖 and a special shoutout to Roman Danyliw for the AD review 👑

Contributors 💅

  • Mohamed Boucadair
    • Orange
    • mohamed.boucadair@orange.com
  • Cristopher Gray
    • Christopher_Gray3@cable.comcast.com

Authors' Addresses 🦋

  • Andrew Mortensen (editor)
    • Forcepoint
    • United States of America
    • Email: andrewmortensen@gmail.com
  • Tirumaleswar Reddy.K (editor)
    • McAfee, Inc.
    • Embassy Golf Link Business Park
    • Bangalore 560071
    • Karnataka
    • India
    • Email: kondtir@gmail.com
  • Flemming Andreasen
    • Cisco
    • United States of America
    • Email: fandreas@cisco.com
  • Nik Teague
    • Iron Mountain
    • United States of America
    • Email: nteague@ironmountain.co.uk
  • Rich Compton
    • Charter
    • Email: Rich.Compton@charter.com
📦 where this page comes from