3.1.Upstream DDoS Mitigation by an Upstream Internet Transit Provider

This use case describes how an enterprise or a residential customernetwork may take advantage of a pre-existing relation with its ITP in order to mitigate a DDoS attack targeting itsnetwork.¶

For clarity of discussion, the targeted network is indicated as an enterprisenetwork, but the same scenario applies to any downstream network, includingresidential and cloud hosting networks.¶

As the ITP provides connectivity to the enterprisenetwork, it is already on the path of the inbound and outbound traffic ofthe enterprise network and is well aware of the networking parametersassociated with the enterprise network WAN connectivity. This eases both theconfiguration and the instantiation of a DDoS Mitigation Service.¶

Thissection considers two kinds of DDoS Mitigation Service between anenterprise network and an ITP:¶

• The upstream ITP may instantiate a DMS uponreceiving a request from the enterprise network. This typicallycorresponds to a case when the enterprise network is under attack.¶
• On the other hand, the ITP may identify an enterprise network as thesource of an attack and send a mitigation request to the enterprise DMSto mitigate this at the source.¶

The two scenarios, though different, have similar interactions betweenthe DOTS client and server. For the sake of simplicity, only the firstscenario will be detailed in this section. Nevertheless, the second scenario is also in scope for DOTS.¶

In the first scenario, as depicted inFigure 1, an enterprise networkwith self-hosted Internet-facing properties such as web servers,authoritative DNS servers, and Voice over IP (VoIP) servers has a DMS deployed toprotect those servers and applications from DDoS attacks. In addition toon-premise DDoS defense capabilities, the enterprise has contracted withits ITP for DDoS Mitigation Services when attacksthreaten to overwhelm the bandwidth of their WAN link(s).¶

    +------------------+        +------------------+    | Enterprise       |        | Upstream         |    | Network          |        | Internet Transit |    |                  |        | Provider         |    |      +--------+  |        |             DDoS Attack    |      | DDoS   |  | <=================================    |      | Target |  | <=================================    |      +--------+  |        |  +------------+  |    |                  | +-------->| DDoS       |  |    |                  | |      |S | Mitigation |  |    |                  | |      |  | System     |  |    |                  | |      |  +------------+  |    |                  | |      |                  |    |                  | |      |                  |    |                  | |      |                  |    |  +------------+  | |      |                  |    |  | DDoS       |<---+      |                  |    |  | Mitigation |C |        |                  |    |  | System     |  |        |                  |    |  +------------+  |        |                  |    +------------------+        +------------------+       * C is for DOTS client functionality       * S is for DOTS server functionality

The enterprise DMS is configured such that if the incoming Internettraffic volume exceeds 50% of the provisioned upstream Internet WANlink capacity, the DMS will request DDoS Mitigation assistance from theupstream transit provider. More sophisticated detection means may be consideredas well.¶

The requests to trigger, manage, and finalize a DDoS Mitigation betweenthe enterprise DMS and the ITP are made using DOTS. The enterpriseDMS implements a DOTS client while the ITP implements a DOTS server,which is integrated with their DMS in this example.¶

When the enterprise DMS locally detects an inbound DDoS attack targetingits resources (e.g., servers, hosts, or applications), it immediatelybegins a DDoS Mitigation.¶

During the course of the attack, the inbound traffic volume to the enterprise network exceeds the50% threshold, and the enterprise DMS escalates the DDoS Mitigation. Theenterprise DMS DOTS client signals to the DOTS server on the upstream ITPto initiate DDoS Mitigation. The DOTS server replies to the DOTS clientthat it can serve this request, and mitigation is initiated on the ITPnetwork by the ITP DMS.¶

Over the course of the attack, the DOTS server of the ITP periodicallyinforms the DOTS client on the mitigation status,statistics related to DDoS attack traffic mitigation, and relatedinformation. Once the DDoS attack has ended or decreased to a certainlevel that the enterprise DMS might handle by itself, the DOTS serversignals the enterprise DMS DOTS client that the attack has subsided.¶

The DOTS client on the enterprise DMS then requests that the ITP terminatethe DDoS Mitigation. The DOTS server on the ITP receives this requestand, once the mitigation has ended, confirms the end of upstream DDoSMitigation to the enterprise DMS DOTS client.¶

The following is an overview of the DOTS communication model for thisuse case:¶

1. A DDoS attack is initiated against resources of anetwork organization (here, the enterprise), which has deployed aDOTS-capable DMS -- typically a DOTS client.¶
2. The enterprise DMS detects, classifies, and begins the DDoS Mitigation.¶
3. The enterprise DMS determines that its capacity and/or capabilityto mitigate the DDoS attack is insufficient and sends a DOTS DDoS Mitigation request via its DOTSclient to one or more DOTS serversresiding on the upstream ITP.¶
4. The DOTS server, which receives the DOTS Mitigation request,determines that it has been configured to honor requests from therequesting DOTS client and does so by orchestratingits own DMS.¶
5. While the DDoS Mitigation is active, the DOTS serverregularly transmits DOTS DDoS Mitigation status updates to the DOTSclient.¶
6. Informed by the DOTS server status update that the attack hasended or subsided, the DOTS client transmits a DOTS DDoS Mitigationtermination request to the DOTS server.¶
7. The DOTS server terminates DDoS Mitigation and sends thenotification to the DOTS client.¶

Note that communications between the enterprise DOTS client and theupstream ITP DOTS server may take place in band within the main InternetWAN link between the enterprise and the ITP; out of band via a separate,dedicated wireline network link utilized solely for DOTS signaling; orout of band via some other form of network connectivity such asthird-party wireless 4G network connectivity.¶

Note also that a DOTS client that sends a DOTS Mitigation requestmay also be triggered by a network admin that manually confirms therequest to the upstream ITP, in which case the request may be sent froman application such as a web browser or a dedicated mobile application.¶

Note also that when the enterprise is multihomed and connected tomultiple upstream ITPs, each ITP is only able to provide a DDoSMitigation Service for the traffic it transits. As a result, theenterprise network may be required to coordinate the various DDoS MitigationServices associated with each link. More multihoming considerations arediscussed in[DOTS-MULTIHOMING].¶

3.2.DDoS Mitigation by a Third-Party DDoS Mitigation Service Provider

This use case differs from the previous use case described inSection 3.1 in that the DDoS Mitigation Service is not provided by an upstreamITP. In other words, as represented inFigure 2, the traffic is notforwarded through the DDoS Mitigation Service Provider by default. Inorder to steer the traffic to the DDoS Mitigation Service Provider, somenetwork configuration changes are required. As such, this use case islikely to apply to large enterprises or large data centers but, as forthe other use cases, is not exclusively limited to them.¶

Another typical scenario for this use case is for there to be a relationshipbetween DDoS Mitigation Service Providers, forming an overlay of DMS. Whena DDoS Mitigation Service Provider mitigating a DDoS attack reaches itsresource capacity, it may choose to delegate the DDoS Mitigation toanother DDoS Mitigation Service Provider.¶

   +------------------+        +------------------+   | Enterprise       |        | Upstream         |   | Network          |        | Internet Transit |   |                  |        | Provider         |   |      +--------+  |        |             DDoS Attack   |      | DDoS   |  | <=================================   |      | Target |  | <=================================   |      +--------+  |        |                  |   |                  |        |                  |   |                  |        +------------------+   |                  |   |                  |        +------------------+   |                  |        | DDoS Mitigation  |   |                  |        | Service Provider |   |                  |        |                  |   |  +------------+  |        |  +------------+  |   |  | DDoS       |<------------>| DDoS       |  |   |  | Mitigation |C |        | S| Mitigation |  |   |  | System     |  |        |  | System     |  |   |  +------------+  |        |  +------------+  |   +------------------+        +------------------+       * C is for DOTS client functionality       * S is for DOTS server functionality

In this scenario, an enterprise network has entered into a prearrangedDDoS Mitigation assistance agreement with one or more third-party DDoSMitigation Service Providers in order to ensure that sufficient DDoSMitigation capacity and/or capabilities may be activated in the eventthat a given DDoS attack threatens to overwhelm the ability of theenterprise or any other given DMS to mitigate the attack on its own.¶

The prearrangement typically includes agreement on the mechanismsused to redirect the traffic to the DDoS Mitigation Service Provider, aswell as the mechanism to re-inject the traffic back to the EnterpriseNetwork. Redirection to the DDoS Mitigation Service Provider typicallyinvolves BGP prefix announcement or DNS redirection, while re-injectionof the scrubbed traffic to the enterprise network may be performed viatunneling mechanisms (e.g., GRE). The exact mechanismsused for traffic steering are out of scope of DOTS but will need to be prearranged, while in some contexts such changes could be detected and considered as an attack.¶

In some cases, the communication between the enterprise DOTS client andthe DOTS server of the DDoS Mitigation Service Provider may go throughthe ITP carrying the DDoS attack, which would affect the communication.On the other hand, the communication between the DOTS client and DOTSserver may take a path that is not undergoing a DDoS attack.¶

  +------------------+        +------------------+  | Enterprise       |        | Upstream         |  | Network          |        | Internet Transit |  |                  |        | Provider         |  |      +--------+  |        |             DDoS Attack  |      | DDoS   |  |<----------------+         | ++====  |      | Target |  |    Mitigated    |         | || ++=  |      +--------+  |        |        |         | || ||  |                  |        |        |         | || ||  |                  |        +--------|---------+ || ||  |                  |                 |           || ||  |                  |        +--------|---------+ || ||  |                  |        | DDoS Mitigation  | || ||  |                  |        | Service Provider | || ||  |                  |        |        |         | || ||  |  +------------+  |        |  +------------+  | || ||  |  | DDoS       |<------------>| DDoS       |  | || ||  |  | mitigation |C |        |S | mitigation |<===++ ||  |  | system     |  |        |  | system     |<======++  |  +------------+  |        |  +------------+  |  +------------------+        +------------------+       * C is for DOTS client functionality       * S is for DOTS server functionality

When the enterprise network is under attack or at least is reaching itscapacity or ability to mitigate a given DDoS attack, the DOTSclient sends a DOTS request to the DDoS Mitigation Service Provider toinitiate network traffic diversion -- as represented inFigure 3 -- andDDoS Mitigation activities. Ongoing attack and mitigation statusmessages may be passed between the enterprise network and the DDoSMitigation Service Provider using DOTS. If the DDoS attack has stopped or theseverity of the attack has subsided, the DOTS client can request that theDDoS Mitigation Service Provider terminate the DDoS Mitigation.¶

3.3.DDoS Orchestration

In this use case, one or more DDoS telemetry systems or monitoringdevices monitor a network -- typically an ISP network, an enterprisenetwork, or a data center. Upon detection of a DDoS attack, these DDoStelemetry systems alert an orchestrator in charge of coordinating thevarious DMSs within the domain. The DDoS telemetry systems may beconfigured to provide required information, such as a preliminaryanalysis of the observation, to the orchestrator.¶

The orchestrator analyzes the various sets of information it receives from DDoStelemetry systems and initiates one or more DDoS Mitigationstrategies. For example, the orchestrator could select the DMS in the enterprise network or one provided by the ITP.¶

DMS selection and DDoS Mitigation techniques maydepend on the type of the DDoS attack. In some cases, a manual confirmationor selection may also be required to choose a proposed strategy toinitiate a DDoS Mitigation. The DDoS Mitigation may consist of multiplesteps such as configuring the network or updating already-instantiatedDDoS Mitigation functions. Eventually, the coordination of themitigation may involve external DDoS Mitigation resources such as atransit provider or a third-party DDoS Mitigation Service Provider.¶

The communication used to trigger a DDoS Mitigation between the DDoStelemetry and monitoring systems and the orchestrator is performed usingDOTS. The DDoS telemetry system implements a DOTS client while theorchestrator implements a DOTS server.¶

The communication between a network administrator and the orchestratoris also performed using DOTS. The network administrator uses, for example, a webinterface that interacts with a DOTS client, while the orchestratorimplements a DOTS server.¶

The communication between the orchestrator and the DMSs is performed using DOTS. The orchestrator implements a DOTSclient while the DMSs implement a DOTS server.¶

The configuration aspects of each DMS, as well as theinstantiations of DDoS Mitigation functions or network configuration, arenot part of DOTS. Similarly, the discovery of available DDoS Mitigationfunctions is not part of DOTS and, as such, is out of scope.¶

       +----------+       | network  |C            (Enterprise Network)       | admini-  |<-+       | strator  |  |       +----------+  |                     |       +----------+  | S+--------------+     +-----------+       |telemetry/|  +->|              |C   S| DDoS      |+       |monitoring|<--->| Orchestrator |<--->| mitigation||       |systems   |C   S|              |<-+  | systems   ||       +----------+     +--------------+C |  +-----------+|                                          |    +----------+       -----------------------------------|-----------------                                          |                                          |          (Internet Transit Provider)     |                                          |  +-----------+                                          | S| DDoS      |+                                          +->| mitigation||                                             | systems   ||                                             +-----------+|       * C is for DOTS client functionality    +----------+       * S is for DOTS server functionality

The DDoS telemetry systems monitor various aspects of the network traffic and performsome measurement tasks.¶

These systems are configured so that when an event or some measurementindicators reach a predefined level, their associated DOTS client sends aDOTS mitigation request to the orchestrator DOTS server. The DOTSmitigation request may be associated with some optional mitigation hintsto let the orchestrator know what has triggered the request. In particular, it is possible for something that looks like an attack locally to one telemetry system is not actually an attack when seen from the broader scope (e.g., of the orchestrator).¶

Upon receipt of the DOTS mitigation request from the DDoS telemetrysystem, the orchestrator DOTS server responds with an acknowledgment toavoid retransmission of the request for mitigation. The orchestratormay begin collecting additional fine-grained and specific informationfrom various DDoS telemetry systems in order to correlate themeasurements and provide an analysis of the event. Eventually, theorchestrator may ask for additional information from the DDoS telemetrysystem; however, the collection of this information is out of scope of DOTS.¶

The orchestrator may be configured to start a DDoS Mitigation uponapproval from a network administrator. The analysis from theorchestrator is reported to the network administrator via, for example, a webinterface. If the network administrator decides to start the mitigation,the network administrator triggers the DDoS Mitigation request using, for example, aweb interface of a DOTS client communicating to the orchestrator DOTSserver. This request is expected to be associated with a context thatprovides sufficient information to the orchestrator DOTS server to infer, elaborate, and coordinatethe appropriate DDoS Mitigation.¶

Upon receiving a request to mitigate a DDoS attack aimed at atarget, the orchestrator may evaluate the volume of the attack aswell as the value that the target represents. The orchestrator mayselect the DDoS Mitigation Service Provider based on the attackseverity. It may also coordinate the DDoS Mitigation performed by theDDoS Mitigation Service Provider with some other tasks such as, forexample, moving the target to another network so new sessions will notbe impacted. The orchestrator requests a DDoS Mitigation by the selectedDMSs via its DOTS client, as described inSection 3.1.¶

The orchestrator DOTS client is notified that the DDoS Mitigation iseffective by the selected DMSs. The orchestrator DOTSserver returns this information to the network administrator.¶

Similarly, when the DDoS attack has stopped, the orchestrator DOTSclient is notified and the orchestrator's DOTS server indicates the end of the DDoS Mitigation to the DDoS telemetry systems as well as to the network administrator.¶

In addition to the DDoS orchestration shown inFigure 4, the selected DMS can return a mitigation request to theorchestrator as an offloading. For example, when the DDoS attack becomes severe andthe DMS's utilization rate reaches its maximumcapacity, the DMS can send mitigation requests withadditional hints, such as its blocked traffic information, to theorchestrator. Then the orchestrator can take further actions such as requesting forwarding nodes (e.g., routers) to filter the traffic. Inthis case, the DMS implements a DOTS client while theorchestrator implements a DOTS server. Similar to other DOTS use cases, the offloading scenario assumes that some validation checks are followed by the DMS, the orchestrator, or both (e.g., avoid exhausting the resources of the forwarding nodes or inadvertent disruption of legitimate services). These validation checks are part of the mitigation and are therefore out of the scope of the document.¶