| RFC 8811 | DOTS Architecture | August 2020 |
| Mortensen, et al. | Informational | [Page] |
This document describes an architecture for establishing and maintaining Distributed Denial-of-Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components, and concepts used in a DOTS deployment.¶
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://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 of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to 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 are provided without warranty as described in the Simplified BSD License.¶
Signaling the need for help to defend against an active distributed denial-of-service (DDoS) attack requires a common understanding of mechanisms and roles among the parties coordinating a defensive response. The signaling layer and supplementary messaging are the focus of DDoS Open Threat Signaling (DOTS). DOTS defines a method of coordinating defensive measures among willing peers to mitigate attacks quickly and efficiently, enabling hybrid attack responses coordinated locally at or near the target of an active attack, or anywhere in path between attack sources and target. Sample DOTS use cases are elaborated in[DOTS-USE-CASES].¶
This document describes an architecture used in establishing, maintaining, or terminating a DOTS relationship within a domain or between domains.¶
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.¶
In this architecture, DOTS clients and servers communicate using DOTS signal channel[RFC8782] and data channel[RFC8783] protocols.¶
The DOTS architecture presented here is applicable across network administrative domains, for example, between an enterprise domain and the domain of a third-party attack mitigation service, as well as to a single administrative domain. DOTS is generally assumed to be most effective when aiding coordination of attack response between two or more participating networks, but single domain scenarios are valuable in their own right, as when aggregating intra-domain DOTS client signals for an inter-domain coordinated attack response.¶
This document does not address any administrative or business agreements that may be established between involved DOTS parties. Those considerations are out of scope. Regardless, this document assumes necessary authentication and authorization mechanisms are put in place so that only authorized clients can invoke the DOTS service.¶
A detailed set of DOTS requirements are discussed in[RFC8612], and the DOTS architecture is designed to follow those requirements. Only new behavioral requirements are described in this document.¶
This document makes the following assumptions:¶
The basic high-level DOTS architecture is illustrated inFigure 1:¶
+-----------+ +-------------+ | Mitigator | ~~~~~~~~~~ | DOTS Server | +-----------+ +-------------+ | | | +---------------+ +-------------+ | Attack Target | ~~~~~~ | DOTS Client | +---------------+ +-------------+
A simple example instantiation of the DOTS architecture could be an enterprise as the attack target for a volumetric DDoS attack and an upstream DDoS mitigation service as the mitigator. The service provided by the mitigator is called "DDoS mitigation service". The enterprise (attack target) is connected to the Internet via a link that is getting saturated, and the enterprise suspects it is under DDoS attack. The enterprise has a DOTS client, which obtains information about the DDoS attack and signals the DOTS server for help in mitigating the attack. In turn, the DOTS server invokes one or more mitigators, which are tasked with mitigating the actual DDoS attack and, hence, aim to suppress the attack traffic while allowing valid traffic to reach the attack target.¶
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 of DOTS. Similarly, the operation of both the attack target and the mitigator is out of scope of DOTS. Thus, DOTS specifies neither how an attack target decides it is under DDoS attack nor does DOTS specify how a mitigator may actually mitigate such an attack. A DOTS client's request for mitigation is advisory in nature and 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 provided with 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 establishes one or more sessions by connecting to the provided DOTS server addresses.¶
As illustrated inFigure 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 ======> | | +---------------+ +---------------+
The primary purpose of the signal channel is for a DOTS client to ask a DOTS server for help in mitigating an attack and for the DOTS server to inform the DOTS client about the status of such mitigation. The DOTS client does this by sending a client signal that contains information about the attack target(s). The client signal may also include telemetry information about the attack, if the DOTS client has such information available. In turn, the DOTS server sends a server signal to inform the DOTS client of whether it will honor the mitigation request. Assuming it will, the DOTS server initiates attack mitigation and periodically informs the DOTS client about the status of the mitigation. Similarly, the DOTS client periodically informs the DOTS server about the client's status, which, at a minimum, provides client (attack target) health information; it should also include efficacy information about the attack mitigation as it is now seen by the client. At some point, the DOTS client may decide to terminate the server-side attack mitigation, which it indicates to the DOTS server over the signal channel. A mitigation may also be terminated if a DOTS client-specified mitigation lifetime is exceeded. Note that the signal channel may need to operate over a link that is experiencing a DDoS attack and, hence, is subject to severe packet loss and high latency.¶
While DOTS is able to request mitigation with just the signal channel, the addition of the DOTS data channel provides for additional, more efficient capabilities. The primary 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 such information include, but are not limited to:¶
Note that, while it is possible to exchange the above information before, during, or after a DDoS attack, DOTS requires reliable delivery of this information and does not provide any special means for ensuring timely delivery of it during an attack. In practice, this means that DOTS deployments should rely on such information being exchanged only under normal traffic conditions.¶
DOTS does not prescribe any specific deployment models; however, DOTS is designed with some specific requirements around the different DOTS agents and their relationships.¶
First of all, a DOTS agent belongs to a domain that has an identity that can be authenticated and authorized. DOTS agents communicate with each other over a mutually authenticated signal channel and (optionally) data channel. However, before they can do so, a service relationship needs to be established between them. The details and means by which this is done is outside the scope of DOTS; however, an example would be for an enterprise A (DOTS client) to sign up for DDoS service from provider B (DOTS server). This would establish a (service) relationship between the two that enables enterprise A's DOTS client to establish a signal channel with provider B's DOTS server. A and B will 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 established prior to a request for DDoS attack mitigation. In particular, it is assumed that bidirectional communication is possible at this time between the DOTS client and DOTS server. Furthermore, it is assumed that additional service provisioning, configuration, and information exchange can be performed by use of the data channel if operationally required. It is not until this point that the mitigation service is available for use.¶
Once the mutually authenticated signal channel has been established, it will remain 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, and similarly raise the probability that DOTS server signals reach the client regardless of inbound link congestion. This does not necessarily imply that the attack target and the DOTS client have to be co-located in the same administrative domain, but it is expected to be a common scenario.¶
DDoS mitigation with the help of an upstream mitigator may involve some form of traffic redirection whereby traffic destined for the attack target is steered towards the mitigator. Common mechanisms to achieve this redirection depend on BGP[RFC4271] and DNS[RFC1035]. In turn, the mitigator inspects and scrubs the traffic and forwards the resulting (hopefully non-attack) traffic to the attack target. Thus, when a DOTS server receives an attack mitigation request from a DOTS client, it can be viewed as a way of causing traffic redirection for the attack target 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 to restrict the mitigation scope a DOTS client can request, but such authorization mechanisms are deployment specific.¶
Although co-location of DOTS server and mitigator within the same domain is expected to be a common deployment model, it is assumed that operators may require alternative models. Nothing in this document precludes such alternatives.¶
A DOTS client is a DOTS agent from which requests for help coordinating an attack response originate. The 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 request help. Operators may wish to have upstream mitigators in the network path for an indefinite period and are restricted only by business relationships when it comes to duration and scope of requested mitigation.¶
The DOTS client requests attack response coordination from a DOTS server over the signal channel, including in the request 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, as the DOTS client may have a narrow perspective on the ongoing attack. As such, the DOTS client's request for mitigation should be considered advisory: guarantees of DOTS server availability or mitigation capacity constitute Service Level Agreements (SLAs) and 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. Such direction may involve manual or automated adjustments in response to updates from the DOTS server.¶
To provide a metric of signal health and distinguish an idle signal channel from a disconnected or defunct session, the DOTS client sends a heartbeat over the signal channel to maintain its half of the channel. The DOTS client similarly expects a heartbeat from the DOTS server and may consider a session terminated in the extended absence of a DOTS server heartbeat.¶
A DOTS server is a DOTS agent capable of receiving, processing, and possibly acting on requests for help coordinating attack responses from DOTS clients. The DOTS server authenticates and authorizes DOTS clients as described inSection 3.1 and maintains session state, tracks requests for mitigation, reports on the status of active mitigations, and terminates sessions in the extended absence of a client heartbeat or when a session times out.¶
Assuming the preconditions discussed below exist, a DOTS client maintaining an active session with a DOTS server may reasonably expect some level of mitigation in response to a request for coordinated attack response.¶
For a given DOTS client (administrative) domain, the DOTS server needs to be able to determine whether a given resource is in that domain. For example, this could take the form of associating a set of IP addresses and/or prefixes per DOTS client domain. The DOTS server enforces authorization of signals for mitigation, filtering rules, and aliases for resources from DOTS clients. The mechanism of enforcement is not in scope for this document but is expected to restrict mitigation requests, filtering rules, aliases for addresses and prefixes, and/or services owned by the DOTS client domain, such that a DOTS client from one domain is not able to influence the network path to another domain. A DOTS serverMUST reject mitigation requests, filtering rules, and aliases for resources not owned by the requesting DOTS client's administrative domain. The exact mechanism for the DOTS servers to validate that the 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 leverages the DDoS mitigation service of the Internet Transit Provider (ITP); the ITP knows the prefixes assigned to the DOTS client domain because they are assigned by the ITP itself. However, if the DDoS Mitigation is offered by a third-party DDoS mitigation service provider; it does not know the resources owned by the DOTS client domain. The DDoS mitigation service provider and the DOTS client domain can opt to use the identifier validation challenges discussed in[RFC8555] and[RFC8738] to identify whether or not 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 works only for "dns" and "ip" identifier types. Further, if the DOTS client lies about the resources owned by the DOTS client domain, the DDoS mitigation service provider can impose penalties for violating the SLA. A DOTS serverMAY also refuse a DOTS client's mitigation request for arbitrary reasons, within any limits imposed by business or SLAs between client and server domains. If a DOTS server refuses a DOTS client's request for mitigation, the DOTS serverMUST 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, the DOTS server forwards a translated form of that request to the mitigator(s) responsible for scrubbing attack traffic. Note that the form of the translated request passed from the DOTS server to the mitigator is not in scope; it may be as simple as an alert to mitigator operators, or highly automated using vendor or open application programming interfaces supported by the mitigator. The DOTS serverMUST report the actual scope of any mitigation enabled on behalf of a client.¶
The DOTS serverSHOULD retrieve available metrics for any mitigations activated on behalf of a DOTS client andSHOULD include them in server signals sent to the DOTS client originating the request for mitigation.¶
To provide a metric of signal health and distinguish an idle signal channel from a disconnected or defunct channel, the DOTS serverMUST send a heartbeat over the signal channel to maintain its half of the channel. The DOTS server similarly expects a heartbeat from the DOTS client andMAY consider a session terminated in the extended absence of a DOTS client heartbeat.¶
Traditional client/server relationships may be expanded by chaining DOTS sessions. This chaining is enabled through "logical concatenation" of a DOTS server and a DOTS client, resulting in an application 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. The gateway may terminate multiple discrete client connections and may aggregate these into a single or multiple DOTS session(s).¶
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 depicted inFigure 3:¶
+-------------+ | | D | | +----+ | | O | | +----+ | c1 |----------| s1 | T | c2 |---------| s2 | +----+ | | S | | +----+ | | G | | +-------------+
The DOTS gatewayMUST perform full stack DOTS session termination and reorigination between its client and server side. The details of how this is achieved are implementation specific.¶
So far, we have only considered a relatively simple scenario of a single DOTS client associated with a single DOTS server; however, DOTS supports more advanced relationships.¶
A DOTS server may be associated with one or more DOTS clients, and those DOTSclients may belong to different domains. An example scenario is a mitigationprovider 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
A DOTS client may be associated with one or more DOTS servers, and those DOTSservers may belong to different domains. This may be to ensure highavailability or coordinate mitigation with more than one directly connectedISP. An example scenario is for an enterprise to have DDoS mitigation servicefrom multiple providers, as shown inFigure 5.¶
DOTS client DOTS servers +---+ -----------| S | / +---+ / dots1.example.net / +---+/ +---+ | c |---------------| S | +---+\ +---+ \ dots.example.org \ \ +---+ -----------| S | +---+ c.example.com dots2.example.net
Deploying a multihomed client requires extra care and planning, as the DOTSservers with which the multihomed client communicates might not be affiliated.Should the multihomed client simultaneously request for mitigation from allservers with which it has established signal channels, the client mayunintentionally inflict additional network disruption on the resources itintends to protect. In one of the worst cases, a multihomed DOTS client couldcause a permanent routing loop of traffic destined for the client'sprotected services, as the uncoordinated DOTS servers' mitigators all try todivert that traffic to their own scrubbing centers.¶
The DOTS protocol itself provides no fool-proof method to prevent suchself-inflicted harms as a result of deploying multihomed DOTS clients. IfDOTS client implementations nevertheless include support for multihoming, theyare expected to be aware of the risks, and consequently to include measuresaimed at reducing the likelihood of negative outcomes. Simple measures mightinclude:¶
As discussed inSection 2.2.3, a DOTS gateway is a logical function chaining DOTS sessions through concatenation of a DOTS server and DOTS client.¶
An example scenario, as shown inFigure 6 andFigure 7, is for an enterprise to have deployed multiple DOTS-capable devices that are able to signal intra-domain using TCP[RFC0793] on uncongested links to a DOTS gateway that may then transform these to a UDP[RFC0768] transport inter-domain where connection-oriented transports may degrade; this applies to the signal channel only, as the data channel requires a connection-oriented transport. The relationship between the gateway and its upstream agents is opaque to the initial clients.¶
+---+ | 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
+---+ | 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
This may similarly be deployed in the inverse scenario where the gateway residesin the server-side domain and may be used to terminate and/or aggregate multipleclients to a single transport as shown inFigure 8 andFigure 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
+---+ | 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
This document anticipates scenarios involving multiple DOTS gateways. An exampleis a DOTS gateway at the network client's side and another one at the serverside. The first gateway can be located at Customer Premises Equipment (CPE) to aggregate requests frommultiple DOTS clients enabled in an enterprise network. The second DOTS gatewayis deployed on the provider side. This scenario can be seen as a combination ofthe client-side and server-side scenarios.¶
In order for DOTS to be effective as a vehicle for DDoS mitigation requests, one or more DOTS clients must establish ongoing communication with one or more DOTS servers. While the preconditions for enabling DOTS in or among network domains may also involve business relationships, SLAs, or other formal or informal understandings between network operators, such considerations are out of scope for this document.¶
A DOTS session is established to support bilateral exchange of data between an associated DOTS client and a DOTS server. In the DOTS architecture, data is exchanged between DOTS agents over signal and data channels. As such, a DOTS session can be a DOTS signal channel session, a DOTS data channel session, or both. The DOTS server couples the DOTS signal and data channel sessions using the DOTS client identity. The DOTS session is further elaborated 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.¶
A DOTS signal channel session is associated with a single transport connection (TCP or UDP session) and a security association (a TLS or DTLS session). Similarly, a DOTS data channel session is associated with a single TCP connection and a TLS security association.¶
Mitigation requests created using the DOTS signal channel are not bound to the DOTS signal channel session. Instead, mitigation requests are associated with a DOTS client and can be managed using different DOTS signal channel sessions.¶
Prior to establishing a DOTS session between agents, the owners of the networks, domains, services or applications involved are assumed to have agreed upon the terms of the relationship involved. Such agreements are out of scope for this document but must be in place for a functional DOTS architecture.¶
It is assumed that, as part of any DOTS service agreement, the DOTS client is provided with all data and metadata required to establish communication with the DOTS server. Such data and metadata would include any cryptographic information necessary to meet the message confidentiality, integrity, and authenticity requirement (SEC-002) in[RFC8612] and might also include the pool of DOTS server addresses and ports the DOTS client should use for signal and data channel messaging.¶
With the required business agreements in place, the DOTS client initiates a DOTS session by contacting its DOTS server(s) over the signal channel and (possibly) the data channel. To allow for DOTS service flexibility, neither the order of contact nor the time interval between channel creations is specified. A DOTS clientMAY establish the signal channel first, and then the data channel, or vice versa.¶
The methods by which a DOTS client receives the address and associated service details of the DOTS server are not prescribed by this document. For example, a DOTS client may be directly configured to use a specific DOTS server IP address and port, and be directly provided with any data necessary to satisfy the Peer Mutual Authentication requirement (SEC-001) in[RFC8612], such as symmetric or asymmetric keys, usernames, passwords, etc. All configuration and authentication information in this scenario is provided out of band by the domain operating the DOTS server.¶
At the other extreme, the architecture in this document allows for a form of DOTS client auto-provisioning. For example, the domain operating the DOTS server or servers might provide the client domain only with symmetric or asymmetric keys to authenticate the provisioned DOTS clients. Only the keys would then be directly configured on DOTS clients, but the remaining configuration required to provision the DOTS clients could be learned through mechanisms similar to DNS SRV[RFC2782] or DNS Service Discovery[RFC6763].¶
The DOTS clientSHOULD successfully authenticate and exchange messages with the DOTS server over both the signal and (if used) data channel as soon as possible to confirm that 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 establishing the DOTS signal channel session. A DOTS signal channel session is not active until DOTS agents have agreed on the values for these DOTS session parameters, a process defined by the protocol.¶
Once the DOTS client begins 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 is no requirement that the data channel remains operational in attack conditions. (See "Data Channel Requirements"Section 2.3 of [RFC8612]).¶
DOTS clients and servers periodically send heartbeats to each other over the signal channel, discussed in[RFC8612] (SIG-004). DOTS agent operatorsSHOULD configure the heartbeat interval such that the frequency does not lead to accidental denials of service due to the overwhelming number of heartbeats a DOTS agent must field.¶
Either DOTS agent may consider a DOTS signal channel session terminated in the extended absence of a heartbeat from its peer agent. The period of that absence will be established in the protocol definition.¶
This section examines the modes of signaling between agents in a DOTSarchitecture.¶
A DOTS session may take the form of direct signaling between the DOTSclients and servers, as shown inFigure 10.¶
+-------------+ +-------------+ | DOTS client |<------signal session------>| DOTS server | +-------------+ +-------------+
In a direct DOTS session, the DOTS client and server are communicating directly. Direct signaling may exist inter- or intra-domain. The DOTS session is abstracted from the underlying networks or network elements the signals traverse; in direct signaling, the DOTS client and server are logically adjacent.¶
In certain circumstances, a DOTS server may want to redirect a DOTS client toan alternative DOTS server for a DOTS signal channel session. Suchcircumstances include but are not limited to:¶
A basic redirected DOTS signal channel session resembles the following, asshown inFigure 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 | +---------------+
DOTS is centered around improving the speed and efficiency of a coordinated response to DDoS attacks. One scenario not yet discussed involves coordination among federated domains operating DOTS servers and mitigators.¶
In the course of normal DOTS operations, a DOTS client communicates the need formitigation to a DOTS server, and that server initiates mitigation on amitigator with which the server has an established service relationship. Theoperator of the mitigator may in turn monitor mitigation performance andcapacity, as the attack being mitigated may grow in severity beyond themitigating domain's capabilities.¶
The operator of the mitigator has limited options in the event a DOTSclient-requested mitigation is being overwhelmed by the severity of the attack.Out-of-scope business or SLAs may permit the mitigatingdomain to drop the mitigation and let attack traffic flow unchecked to thetarget, but this only encourages attack escalation. In the case wherethe mitigating domain is the upstream service provider for the attack target,this may mean the mitigating domain and its other services and users continue tosuffer the incidental effects of the attack.¶
A recursive signaling model as shown inFigure 12 offersan alternative. In a variation of the use case "Upstream DDoS Mitigation by anUpstream Internet Transit Provider" described in[DOTS-USE-CASES], adomain operating a DOTS server and mitigator also operates a DOTS client. ThisDOTS client has an established DOTS session with a DOTS server belonging to aseparate administrative domain.¶
With these preconditions in place, the operator of the mitigator beingoverwhelmed or otherwise performing inadequately may request mitigation for theattack target from this separate DOTS-aware domain. Such a request recurses theoriginating mitigation request to the secondary DOTS server in the hope ofbuilding 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
InFigure 12, client Cc signals a request for mitigationacross inter-domain DOTS session 1 to the DOTS server Sn belonging to theexample.net domain. DOTS server Sn enables mitigation on mitigator Mn. DOTSserver Sn is half of DOTS gateway Gn, being deployed logically back to back withDOTS client Cn, which has preexisting inter-domain DOTS session 2 with the DOTSserver So belonging to the example.org domain. At any point, DOTS server SnMAYrecurse an ongoing mitigation request through DOTS client Cn to DOTS server So,in the expectation that mitigator Mo will be activated to aid in the defense ofthe attack target.¶
Recursive signaling is opaque to the DOTS client. To maximize mitigationvisibility to the DOTS client, however, the recursing domainSHOULD providerecursed mitigation feedback in signals reporting on mitigation status to theDOTS client. For example, the recursing domain's DOTS server should incorporateavailable metrics such as dropped packet or byte counts from the recurseddomain's DOTS server into mitigation status messages.¶
DOTS clients involved in recursive signaling must be able to withdraw requestsfor mitigation without warning or justification per SIG-006 in[RFC8612].¶
Operators recursing mitigation requestsMAY maintain the recursed mitigation for a brief protocol-defined period in the event the DOTS client originating the mitigation withdraws its request for help, as per the discussion of managing mitigation toggling in SIG-006 of[RFC8612].¶
Deployment of recursive signaling may result in traffic redirection, examination, and mitigation extending beyond the initial bilateral relationship between DOTS client and DOTS server. As such, client control over the network path of mitigated traffic may be reduced. DOTS client operators should be aware of any privacy concerns and work with DOTS server operators employing recursive signaling to ensure shared sensitive material is suitably protected. Typically, there is a contractual SLA negotiated among the DOTS client domain, the recursed domain, and the recursing domain to meet the privacy requirements of the DOTS client domain and authorization for the recursing domain to request mitigation for the resources controlled by the DOTS client domain.¶
The DOTS architecture does not assume the availability of anycast within a DOTS deployment, but neither does the architecture exclude it. Domains operating DOTS serversMAY deploy DOTS servers with an anycast Service Address as described in BCP 126[RFC4786]. In such a deployment, DOTS clients connecting to the DOTS Service Address may be communicating with distinct DOTS servers, depending on the network configuration at the time the DOTS clients connect. Among other benefits, anycast signaling potentially offers the following:¶
As long as network configuration remains stable, anycast DOTS signaling is to the individual DOTS client indistinct from direct signaling. However, the operational challenges inherent in anycast signaling are anything but negligible, and DOTS server operators must carefully weigh the risks against the benefits before deploying.¶
While the DOTS signal channel primarily operates over UDP per SIG-001 in[RFC8612], the signal channel also requires mutual authentication between DOTS agents, with associated security state on both ends.¶
Network instability is of particular concern with anycast signaling, as DOTS signal channels are expected to be long lived and potentially operating under congested network conditions caused by a volumetric DDoS attack.¶
For example, a network configuration altering the route to the DOTS server during active anycast signaling may cause the DOTS client to send messages to a DOTS server other than the one with which it initially established a signaling session. That second DOTS server might not have the security state of the existing session, forcing the DOTS client to initialize a new DOTS session. This challenge might in part be mitigated by use of 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 keying material must then be available to all DOTS servers sharing the anycast Service Address, which has operational challenges of its own.¶
While the DOTS client will try to establish a new DOTS session with the DOTS server now acting as the anycast DOTS Service Address, the link between DOTS client and server may be congested with attack traffic, making signal session establishment difficult. In such a scenario, anycast Service Address instability becomes a sort of signal session flapping, with obvious negative consequences for the DOTS deployment.¶
Anycast signaling deployments similarly must also take into account active mitigations. Active mitigations initiated through a DOTS session may involve diverting traffic to a scrubbing center. If the DOTS session flaps due to anycast changes as described above, mitigation may also flap as the DOTS servers sharing the anycast DOTS service address toggles mitigation on detecting DOTS session loss, depending on whether or not the client has configured mitigation on loss of signal (Section 3.3.3).¶
Network address translators (NATs) are expected to be a common feature of DOTS deployments. The middlebox traversal guidelines in[RFC8085] include general NAT considerations that are applicable to DOTS deployments when the signal channel is established over UDP.¶
Additional DOTS-specific considerations arise 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 subsequently asked to request mitigation for the attacked scope of addresses cannot reasonably perform the task, due to the lack of externally routable addresses in the mitigation scope.¶
The following considerations do not cover all possible scenarios but are meant rather to highlight anticipated common issues when signaling through NATs.¶
Operators may circumvent the problem of translating internal addresses or prefixes to externally routable mitigation scopes by directly provisioning the mappings of external addresses to internal protected resources on the DOTS client. When the operator requests mitigation scoped for 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 information.¶
When directly provisioning the address mappings, operators must ensure themappings remain up to date or they risk losing the ability to request accuratemitigation scopes. To that aim, the DOTS client can rely on mechanisms such as[RFC8512] or[RFC7658] to retrieve static explicit mappings. This document does notprescribe the method by which mappings are maintained once they are provisionedon the DOTS client.¶
Port Control Protocol (PCP)[RFC6887] may be used to retrieve the externaladdresses/prefixes and/or port numbers if the NAT function embeds a PCP server.¶
A DOTS client can use the information retrieved by means of PCP to feed the DOTSprotocol(s) messages that will be sent to a DOTS server. These messages willconvey the external addresses/prefixes as set by the NAT.¶
PCP also enables discovery and configuration of the lifetime of port mappingsinstantiated in intermediate NAT devices. Discovery of port mapping lifetimescan reduce the dependency on heartbeat messages to maintain mappings and,therefore, reduce the load on DOTS servers and the network.¶
An internal resource, e.g., a web server, can discover its reflexive transportaddress through a STUN Binding request/response transaction, as described in[RFC8489]. After learning its reflexive transport address from the STUN server,the internal resource can export its reflexive transport address and internaltransport address to the DOTS client, thereby enabling the DOTS client torequest mitigation with the correct external scope, as depicted inFigure 13. The mechanism for providing the DOTS client with the reflexivetransport address and internal transport address is unspecified in thisdocument.¶
In order to prevent an attacker from modifying the STUN messages in transit, theSTUN client and server must use the message-integrity mechanism discussed inSection 9 of [RFC8489] or use STUN over DTLS[RFC7350] or STUN over TLS.If the STUN client is behind a NAT that performs Endpoint-Dependent Mapping[RFC5128], the internal service cannot provide the DOTS client with thereflexive transport address discovered using STUN. The behavior of a NAT betweenthe STUN client and the STUN server could be discovered using the experimentaltechniques discussed in[RFC5780], but note that there is currently nostandardized way for a STUN client to reliably determine if it is behind a NATthat performs Endpoint-Dependent Mapping.¶
Binding Binding+--------+ request +---+ request +--------+| STUN |<----------| N |<----------| STUN || server | | A | | client || |---------->| T |---------->| |+--------+ Binding +---+ Binding +--------+ response response | | reflexive transport address | & internal transport address v +--------+ | DOTS | | client | +--------+
DOTS supports mitigation scoped to DNS names. As discussed in[RFC3235],using DNS names instead of IP addresses potentially avoids the addresstranslation problem, as long as the same domain name is internally and externally resolvable. For example, a detected attack's internal target address can be mapped to a DNS name through a reverse lookup. The DNS namereturned by the reverse lookup can then be provided to the DOTS client as theexternal scope for mitigation. For the reverse DNS lookup, DNS SecurityExtensions (DNSSEC)[RFC4033] must be used where the authenticity of responseis critical.¶
[RFC8612] places no limitation on the circumstances in which a DOTS clientoperator may request mitigation, nor does it demand justification for anymitigation request, thereby reserving operational control over DDoS defense forthe domain requesting mitigation. This architecture likewise does not prescribethe network conditions and mechanisms triggering a mitigation request from aDOTS client.¶
However, considering selected possible mitigation triggers from an architecturalperspective offers a model for alternative or unanticipated triggers for DOTSdeployments. In all cases, what network conditions merit a mitigation requestare at the discretion of the DOTS client operator.¶
The mitigation request itself is defined by DOTS; however, the interfacesrequired to trigger the mitigation request in the following scenarios areimplementation specific.¶
A DOTS client operator may manually prepare a request for mitigation, includingscope and duration, and manually instruct the DOTS client to send the mitigationrequest to the DOTS server. In context, a manual request is a request directlyissued by the operator without automated decision making performed by a deviceinteracting with the DOTS client. Modes of manual mitigation requests includean operator entering a command into a text interface, or directly interactingwith a graphical interface to send the request.¶
An operator might do this, for example, in response to notice of an attackdelivered by attack detection equipment or software, and the alerting detectorlacks interfaces or is not configured to use available interfaces to translatethe alert to a mitigation request automatically.¶
In a variation of the above scenario, the operator may have preconfigured on theDOTS client mitigation requests for various resources in the operator's domain.When notified of an attack, the DOTS client operator manually instructs the DOTSclient to send the relevant preconfigured mitigation request for the resourcesunder attack.¶
A further variant involves recursive signaling, as described inSection 3.2.3. The DOTS client in this case is the second half of aDOTS gateway (back-to-back DOTS server and client). As in the previous scenario,the scope and duration of the mitigation request are preexisting but, in thiscase, are derived from the mitigation request received from a downstream DOTSclient by the DOTS server. Assuming the preconditions required bySection 3.2.3 are in place, the DOTS gateway operator may at any timemanually request mitigation from an upstream DOTS server, sending a mitigationrequest derived from the downstream DOTS client's request.¶
The motivations for a DOTS client operator to request mitigation manually arenot prescribed by this architecture but are expected to include some of thefollowing:¶
Unlike manual mitigation requests, which depend entirely on the DOTS clientoperator's capacity to react with speed and accuracy to every detected ordetectable attack, mitigation requests triggered by detected attack conditionsreduce the operational burden on the DOTS client operator and minimize thelatency between attack detection and the start of mitigation.¶
Mitigation requests are triggered in this scenario by operator-specified networkconditions. Attack detection is deployment specific and not constrained by thisarchitecture. Similarly, the specifics of a condition are left to the discretionof the operator, though common conditions meriting mitigation include thefollowing:¶
When automated conditional mitigation requests are enabled, violations of any ofthe above conditions, or any additional operator-defined conditions, willtrigger a mitigation request from the DOTS client to the DOTS server. Theinterfaces between the application detecting the condition violation and theDOTS client are implementation specific.¶
To maintain a DOTS signal channel session, the DOTS client and the DOTS serverexchange regular but infrequent messages across the signal channel. In theabsence of an attack, the probability of message loss in the signaling channelshould be extremely low. Under attack conditions, however, some signal loss maybe anticipated as attack traffic congests the link, depending on the attacktype.¶
While[RFC8612] specifies the DOTS protocol be robust when signaling underattack conditions, there are nevertheless scenarios in which the DOTS signal islost in spite of protocol best efforts. To handle such scenarios, a DOTSoperator may request one or more mitigations, which are triggered only when theDOTS server ceases receiving DOTS client heartbeats beyond the miss count orinterval permitted by the protocol.¶
The impact of mitigating due to loss of signal in either direction must beconsidered carefully before enabling it. Attack traffic congesting links is not the only reason why signal could be lost, and as such, mitigation requests triggeredby signal channel degradation in either direction may incur unnecessary costs due to scrubbing traffic,adversely impact network performance and operational expense alike.¶
This document has no IANA actions.¶
This section describes identified security considerations for the DOTS architecture.¶
Security considerations and security requirements discussed in[RFC8612] need tobe taken into account.¶
DOTS is at risk from three primary attack vectors: agent impersonation, traffic injection, and signal blocking. These vectors may be exploited individually or in concert by an attacker to confuse, disable, take information from, or otherwise inhibit DOTS agents.¶
Any attacker with the ability to impersonate a legitimate DOTS client or server or, indeed, inject false messages into the stream may potentially trigger/withdraw traffic redirection, trigger/cancel mitigation activities or subvert drop-/accept-lists. From an architectural standpoint, operatorsMUST ensure conformance to the security requirements defined inSection 2.4 of [RFC8612] to secure data in transit. Similarly, as the received data may contain network topology, telemetry, and threat and mitigation information that could be considered sensitive in certain environments, itSHOULD be protected at rest per required local policy.¶
DOTS agentsMUST perform mutual authentication to ensure authenticity of each other, and DOTS serversMUST verify that the requesting DOTS client is authorized to request mitigation for specific target resources (seeSection 2.2.2).¶
A man-in-the-middle (MITM) attacker can intercept and drop packets, preventing 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 with risks discussed inSection 3.3.3.¶
An attacker with control of a DOTS client may negatively influence network traffic by requesting and withdrawing requests for mitigation for particular prefixes, leading to route or DNS flapping. DOTS operators should carefully monitor and audit DOTS clients to detect misbehavior and deter misuse.¶
Any attack targeting the availability of DOTS servers may disrupt the ability of the system to receive and process DOTS signals resulting in failure to fulfill a mitigation request. DOTS serversMUST be given adequate protections in accordance with best current practices for network and host security.¶
Thanks toMatt Richardson,Roman Danyliw,Frank Xialiang,Roland Dobbins,Wei Pan,Kaname Nishizuka,Jon Shallow,Paul Kyzivat,Warren Kumari,Benjamin Kaduk, andMohamed Boucadair for their comments and suggestions.¶
Special thanks toRoman Danyliw for the AD review.¶