DOTS K. Nishizuka Internet-Draft NTT Communications Intended status: Informational March 20, 2016 Expires: September 21, 2016 Inter-Domain DOTS Use Cases draft-nishizuka-dots-inter-domain-usecases-01 Abstract This document describes inter-domain use cases of the DDoS Open Threat Signaling(DOTS). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 21, 2016. Copyright Notice Copyright (c) 2016 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 (http://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. Nishizuka Expires September 21, 2016 [Page 1] Internet-Draft Inter-Domain DOTS Use Cases March 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Inter-Domain DDoS Protection Scenario . . . . . . . . . . . . 3 3.1. Protection Methods . . . . . . . . . . . . . . . . . . . 4 3.1.1. Blackholing . . . . . . . . . . . . . . . . . . . . . 4 3.1.2. Selective Blackholing . . . . . . . . . . . . . . . . 5 3.1.3. RTBH with uRPF . . . . . . . . . . . . . . . . . . . 5 3.1.4. BGP flowspec . . . . . . . . . . . . . . . . . . . . 6 3.1.5. Filtering(ACL) . . . . . . . . . . . . . . . . . . . 6 3.1.6. DDoS mitigation Appliances . . . . . . . . . . . . . 7 3.1.7. Detouring Technologies . . . . . . . . . . . . . . . 8 3.2. Restriction on the Range of IP Addresses . . . . . . . . 8 3.3. Attack Telemetry . . . . . . . . . . . . . . . . . . . . 8 3.4. DDoS Protection Status . . . . . . . . . . . . . . . . . 11 3.5. DDoS Protection Registration . . . . . . . . . . . . . . 11 4. Inter-Domain Dots Use Cases . . . . . . . . . . . . . . . . . 12 4.1. Customer-to-Provider Cases . . . . . . . . . . . . . . . 13 4.1.1. Usecase 1: Single-home Model . . . . . . . . . . . . 13 4.1.2. Usecase 2: Multi-home Model . . . . . . . . . . . . . 13 4.2. Provider-to-Provider Cases . . . . . . . . . . . . . . . 15 4.2.1. Usecase 3: Delegation Model . . . . . . . . . . . . . 15 4.2.2. Usecase 4: Distributed Architecture Model . . . . . . 16 4.2.3. Usecase 5: Centralized Architecture Model . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . 19 7.2. URL References . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Maximum size of DDoS attack is increasing. According to a report from Cloudflare[Cloudflare], in 2013, over 300 Gbps DDoS attack against Spamhaus was observed which exploited DNS reflection mechanism to create massive attack with intention to overwhelm the capacity of the targeted system. If this trend continued, the volume of DDoS attack will exceed preparable DDoS protection capability by one organization mostly in the aspect of cost. Moreover, possibility of DDoS attack is unpredictable, so it is not realistic that every organization prepare sufficient DDoS protection system. This problem could be solved by sharing DDoS protection system over multi-organizations. We can share the burden of protection against Nishizuka Expires September 21, 2016 [Page 2] Internet-Draft Inter-Domain DOTS Use Cases March 2016 DDoS attack by inter-domain cooperation. To accomplish this goal, we need a framework which use common interface to call for protection. In order to describe the mechanism of such a framework, use cases are classified into intra-domain use cases and inter-domain use cases. The focus of this draft is inter-domain use cases, which can be categorized to customer-to-provider cases and provider-to-provider cases. 1. intra-domain use cases(a DOTS client, a DOTS server and mitigators are in the same organization) 2. inter-domain use cases(a DOTS server and mitigators are in a different organization from a DOTS client) By blocking DDoS attack with inter-domain cooperation, average usage of DDoS mitigation equipment will increase. This will leverage total capacity of DDoS protection system in all over the internet. With this mechanism, we can manage DDoS attacks which exceed the capacity of its own platform. 2. Terminology Terminology and acronyms are inherited from [I-D.draft-ietf-dots- requirements] The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Inter-Domain DDoS Protection Scenario In this inter-domain DDoS protection scenario, it is assumed that a service of an organization is being attacked over the internet and a DOTS client in the organization ask for help to one or more DOTS server in other organizations through signal channel between DOTS elements. Then DOTS server enables mitigation by communicating with mitigators in its domain by conveying information provided by the DOTS client. As noted in [I-D.draft-ietf-dots-requirements], A DOTS server may also be a mitigator. The request for help would be made in the case that a capacity of a protection system in the attacked organization is insufficient to protect the service. If an up-link connected to transit networks get congested due to the massive DDoS attack, there is no way to protect the service other than asking for help to upper transit providers or cloud-type of DDoS mitigation providers. Nishizuka Expires September 21, 2016 [Page 3] Internet-Draft Inter-Domain DOTS Use Cases March 2016 Especially in the case of inter-domain DDoS protection, it would be needed to care about protection capability of mitigators. The capability would be defined by possible protection methods taken by the mitigator and restriction of the usage. 3.1. Protection Methods There are many available protection methods of mitigators, which include blackholing, ACLs, flowspec, dedicated DDoS appliances, etc. Required information for protection vary according to the protection methods. Some of information are mandatory, others are optional. Though the minimum information for protection is IP address of the system under attack, optional information would increase efficiency of the protection. Also, these methods have their own max capacity. This section enumerates possible protection methods. For future extensibility, DOTS protocol should be independent of these method. However, these protection methods would depict the protection scenario by describing mandatory information and optional information. 3.1.1. Blackholing Black-holing technique blocks DDoS attacks destined to a particular network by driving all traffic to a null interface on routers. In RTBH, Remotely Triggered Black-Holing[RFC3882], BGP announcement triggers black-holing in their network or neighbor networks by advertising routes with unreachable next-hop address or dedicated black-holing community. This technique results in that all traffic destined to the attacked network will be dropped on all ingress routers of the announced AS. This technique is widely used in ISPs and IXPs[draft-ietf-grow-blackholing-00]. RTBH can be used over eBGP peering, thus it inherently works in inter-domain manner by signaling over BGP. However, a victim organization doesn't always have eBGP peer to RTBH-enabled neighbor AS from which DDoS attack is coming. DOTS-enabled RTBH can help such scenario. In this scenario, a DOTS client ask for help to a DOTS server in a transit network. Then the DOTS server triggers RTBH in its network by announcing blackholing BGP routes. mandatory information: Destination Address RTBH works with destination IP address only, thus a mandatory information conveyed by the DOTS client to the DOTS server is IP address or prefix of the victim system. As noted in the security consideration section of [RFC3882], eBGP customers might be able to blackhole a particular subnet using the Nishizuka Expires September 21, 2016 [Page 4] Internet-Draft Inter-Domain DOTS Use Cases March 2016 blackhole communities. Like that, a DOTS client can blackhole a particular subnet by sending DOTS message with arbitrary destination address, which can be another attack vector. To eliminate the risk, the range of valid IP address should be limited to the prefixes of the victim organization. 3.1.2. Selective Blackholing In the case of blackholing, it stops the traffic destined to the service totally. In a way, the "denial" of service is successful. Selective blackhole provides the ability to limit the scope of the blackholing. It allows more flexible blackholing because some of traffic are blocked at the same time others are not affected according to geographic locations. mandatory information: Destination Address optional information: BGP Community, Next-hop Address Selective Blackholing also works with destination IP address only. Moreover, by sending intended BGP community of selective blackholing, it gives more effective control on DDoS attacks. When some network element in the transit network announced the selective blackholing route, the next-hop address of the announced route should be unchanged from the original announcement because the traffic not blocked by selective blackholing still should be destined to the original network. Therefore, the DOTS server might need to know a desired next-hop of the prefix of the victim network. 3.1.3. RTBH with uRPF Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)[RFC5635] is expansion of destination-based RTBH filtering which enable filtering by source address. By coupling unicast Reverse Path Forwarding (uRPF) [RFC3704] techniques with RTBH filtering, packets will be discarded not based on destination address, but on source address of DDoS traffic. mandatory information: Source Address By sending source address of the attack traffic from a DOTS client to a DOTS server, the DOTS server can utilize RTBH with uRPF via BGP. However, this technique also drops packets destined to other networks, which can be another denial-of-service of the source address depending on the topology. Nishizuka Expires September 21, 2016 [Page 5] Internet-Draft Inter-Domain DOTS Use Cases March 2016 3.1.4. BGP flowspec BGP flowspec[RFC5575] defines a new BGP NLRI encoding format by which routing system can propagate information regarding more specific components of the traffic. By pre-defined action rules, this technique can be used to automate inter-domain coordination of traffic filtering. mandatory information: Flow Type: Destination Prefix Source Prefix IP Protocol Port Destination Port Source Port ICMP type ICMP Code TCP flags Packet Length DSCP Fragment Action Rule: traffic-rate traffic-action redirect traffic-remarking Like blackholing, if a victim organization doesn't have capability of BGP flowspec, DOTS protocol could help it to work in inter-domain manner. If a DOTS client got a statistics of an ongoing attack to its site, it can send a combination of flow type and action rule information to a DOTS server in other network. Then the DOTS server can generate BGP flowspec route based on the information provided by the DOTS signaling, then it will be applied to its network to make it work. 3.1.5. Filtering(ACL) Access list(ACL) based filtering is widely used in ISPs to protect customers. They configure the routers connected to the customer manually or automatically to discard or rate-limit traffic base on the request from the customer. This kind of effort can be covered by DOTS protocol. Here is an example of the mandatory information of ACL. mandatory information: Nishizuka Expires September 21, 2016 [Page 6] Internet-Draft Inter-Domain DOTS Use Cases March 2016 Match Rule: IP Protocol Destination Prefix Source Prefix Destination Port Source Port Action Rule: permit deny 3.1.6. DDoS mitigation Appliances There are many DDoS mitigation appliances, however, they have their own implementation and information model which result in that there is no compatibility each other. As noted in [draft-ietf-dots-use- cases], providing a standard-based mechanism is one of the goal of the DOTS. The merit of DDoS mitigation appliances is that only the malicious traffic will be discarded on the box and the scrubbed normal traffic will be returned to the original service, thus service continuity will be kept. Various countermeasures are implemented on those appliances to eliminate the possibility of false positives and false negatives. DDoS mitigation appliances can be used in intra- domain manner and inter-domain manner. Some of ISPs are using DDoS mitigation appliances to protect their customer. If a mitigation box is placed inline to a customer and dedicated only to them, the customer would be always benefited from it. In this case, a DOTS client would send message to a DOTS server about only turning on/off of protection. A mitigation box can be placed on offramp position and shared with many customers because it is more cost effective. In this case, the mitigation can be accomplished by combined with detouring technologies. The DDoS mitigation appliances apply pre-defined countermeasures with the destination IP address of the targeted customer. The total volume of processable traffic is limited to the capacity of the hardware. Therefore, if the DDoS mitigation appliances are shared among customers, capability should be negotiated carefully because insufficient capacity compared to total volume[bps/pps] of DDoS traffic could affect the service. Traffic volume and other attack telemetry can help the mitigation appliances to determine the mitigation behavior. Attack telemetry is noted in more detail in a later section. mandatory information: Destination Address optional information: (Desired)Countermeasures, Attack Telemetry Nishizuka Expires September 21, 2016 [Page 7] Internet-Draft Inter-Domain DOTS Use Cases March 2016 3.1.7. Detouring Technologies Detouring technologies are used with other protection methods to deal with DDoS attack traffic in its domain. It eases topological constraints of protection methods and leverages limited capacity of them. By injecting more specific route in routing system, the attack traffic would be diverted to protection instance of mitigators. After the classification of malicious traffic and normal traffic, normal traffic should be returned to the original path, however simply returning traffic to the internet can cause routing loop because the returning traffic could re-enter the diversion path again. To avoid this routing loop, the safe returning path should be designated. If there is no dedicated line between the mitigator and the service, tunnel technology such as GRE[RFC2784] can be used. In that case, tunnel information should be provided. In general, next- hop and prefix information should be provided to the DOTS server to determine the returning path of the mitigated traffic. mandatory information: Destination Address, Next-Hop optional information: Tunnel Information 3.2. Restriction on the Range of IP Addresses As reviewed in the previous section, some of protection methods can be another denial-of-service vector to other organization if there is no restriction on the range of destination IP addresses. Especially, in case of blackholing, they can abuse other systems by blocking all of the traffic. A DOTS server SHOULD refuse request from a DOTS client if it could result in packet loss of communication of third party. 3.3. Attack Telemetry Attack telemetry is a set of summarized traffic information which characterizes the feature of the DDoS attack. Attack telemetry implicitly indicates the reason why the DOTS client assumed the observed traffic contains an attack. A DOTS client can call for help to a DOTS server by sending attack telemetry with authorization information via DOTS signal. The DOTS server which received the DOTS signal reacts to start mitigation as follows: 1. The DOTS server checks the authorization information to decide the signaling is legitimate or not. If failed, it may return an error status. Nishizuka Expires September 21, 2016 [Page 8] Internet-Draft Inter-Domain DOTS Use Cases March 2016 2. The DOTS server checks the destination IP address in the request with according DDoS protection entity. If the IP address doesn't match for the prefixes of the customer who made the DOTS request, there might be a risk of packet loss of communication of third party, then it may return an error status. 3. The DOTS server selects an appropriate protection method while checking a protection capability of mitigators. 4. The DOTS server enables mitigation by communicating with the mitigator in its domain by conveying attack telemetry provided by the DOTS client. The following list is an attack telemetry which characterizes the feature of the DDoS attack. As reviewed in the previous section, a destination IP address is key value which identifies a series of DDoS attack. Attack Telemetry: Mandatory: Dst IP Optional: Attack ID Dst Port Src IP/Port TCP Flag Type of Attack (Average/Maximum/Current)Traffic Volume[bps/pps] Severity Attack Start Time Duration o Attack ID Attack ID could be assigned by a DOTS client. By receiving the attack ID, a DOTS server can tell the attack vector is the same or not from the observation of the DOTS client. o Dst Port Destination port of the DDoS attack characterizes the attack because it indicates what kind of service is targeted. This information can be used especially by filter type of protection methods. However, it should be noted that the targeted port can be changed by the attacker if they noticed the attack on the port is not effective. o Src IP/Port Nishizuka Expires September 21, 2016 [Page 9] Internet-Draft Inter-Domain DOTS Use Cases March 2016 Source IP/Port of the DDoS attack characterizes the attack. Source port indicates the attack platforms in the case of amplification attack. Blocking or rate-limiting based on the source IP/Port can mitigate the attack effectively. However, in some cases, source IP/ Port of the DDoS attack are spoofed. They could be widely spread in address space and continuously changing. Thus, the mitigation based on source IP/Port information is not always applicable. o TCP Flag TCP flag of the DDoS attack characterizes the attack because it indicates the attack vector itself. TCP flag information can be used to distinguish malicious traffic and legitimate traffic. o Type of attack Similar to TCP flag information, type of attack declares that what kind of attack vector is used by the attacker, ex) fragment attack, land attack etc,.. Decision of the type of attack might be overwritten by the mitigator if it can inspect the traffic more deeply. o (Average/Maximum/Current)Traffic Volume[bps/pps] Traffic volume information can be used to determine protection method. However, In the case of massive DDoS attack, the circuit connected to the internet could be saturated by the traffic, so there is no way to know how much traffic is incoming on the saturated link from the victim network. Thus, traffic volume information provided by the DOTS client is optional information. o Severity Severity information can be used to determine protection method. However, in many cases, DDoS attack vectors change time to time, so there is no constant index of severity. Moreover, the monitoring system on the service side could look through the important attack vector which is very severe to the service, so the severity must be overwritten by the mitigator if it can inspect the traffic more deeply. Therefore this is optional information. o Attack start time and Duration Attack start time and Duration information indicates the status and the severity of the attack. The DOTS server and the mitigator can find the attack effectively by this information if it has a monitoring system in its domain. Nishizuka Expires September 21, 2016 [Page 10] Internet-Draft Inter-Domain DOTS Use Cases March 2016 3.4. DDoS Protection Status The DOTS client may stop the mitigation by sending protection-stop- instruction message via DOTS protocol. However, sometimes, it is difficult to know whether the DDoS attack has ended or not from the monitoring point of the DOTS client especially in the inter-domain usecases. The information listed below should be provided from the DOTS server to the DOTS client. o Attack telemetry Attack telemetry observed at the monitoring point of the DOTS server or the mitigator should be reported to the DOTS client periodically. In addition, the operator of the service will eager to know what kind of attack was attempted. Then, they can study how to try to find the best plan to cope with attacks in future. o Status of ongoing protection Status of the protection(The attack is ongoing or not) will be used to determine that the system is already safe without the protection. The DOTS server should have interface from which the DOTS client can get the status of the protection. o Data for billing In the inter-domain usecases, there might be a contract between two organizations. Some kind of data which indicates the usage of the protection resources may be used for billing. The typical examples are the number of the dropped packets, the number of the legitimate packets, duration of the protection, etc,.. Defining the billing data is out of scope of DOTS. 3.5. DDoS Protection Registration If there is a contract between two organizations, a DOTS client might need to be registered to a DOTS server in advance. Authentication information might be provided in this registration. As reviewed in the previous section, some of protection methods needs more information in addition to attack telemetry in order to work properly. The information listed below might be registered in advance to the DOTS server, though these information could be registered and updated automatically during an attack. o Authentication information Nishizuka Expires September 21, 2016 [Page 11] Internet-Draft Inter-Domain DOTS Use Cases March 2016 Authentication information might be provided in customer registration. This information will be used in any phase after the registration to avoid abuse of the protection system. o Proper IP address Proper IP address of the customer might be provided in customer registration. This information will be used by the DOTS server for checking a protection request in order to avoid abuse of the protection system. Also, consistency of the IP address might be checked with the routing system. o Desired Protection Method A DOTS server will select a protection methods based on the attack telemetry provided by a DOTS client, however, the DOTS client could have preferred protection methods. If there is a possibility of mis- classification on some protection method, the client might not choose it. The selectable protection methods might be registered to the DOTS server in advance. o Thresholds of Protection Methods If a threshold of a protection, rate-limit for example, is stricter than a normal trend of the protected system, it may cause significant packet loss of the legitimate traffic. The appropriate thresholds of protection methods varies according to the customer's service. Thus, the customer might want to decide the thresholds of each protection method in advance. o Returning Path Information If a protection method was coupled with detouring technologies, the legitimate traffic will be returned to the normal path to the customer. In order to make it work properly, the returning path information should be provided to the DOTS server in advance. Some protection method needs next-hop information and tunnel information. 4. Inter-Domain Dots Use Cases In inter-domain use cases, a DOTS server and mitigators are in a different organization from a DOTS client. Those can be categorized to customer-to-provider cases and provider-to-provider cases. Nishizuka Expires September 21, 2016 [Page 12] Internet-Draft Inter-Domain DOTS Use Cases March 2016 4.1. Customer-to-Provider Cases 4.1.1. Usecase 1: Single-home Model The single-home model is the most basic model of the inter-domain usecase. There are one DOTS client in customer side and one DOTS server in provider side. The DOTS server communicate with the mitigator(s) in its domain to protect the service of the customer. If the service got attacked and the customer found suspicious traffic statistics, the DOTS client send attack telemetry, in which the IP address of the service under attack must be included, to the DOTS server via DOTS signaling. The DOTS server checks the message, then communicate with the mitigator in its domain to protect the service from attack traffic. The legitimate traffic will be kept going to the service. In the case of blackholing, all of the traffic destined to the service will be dropped in the provider's domain. +-------------+ | Attacker | +-------------+ | attack traffic | (destined to V service A) +---------------+ +---------------+ | Domain B | | Domain B | | |<------------>| | | DOTS Server | | Mitigator | +---------------+ +---------------+ ^ DOTS Signaling | Provider | (Attack Telemetry) | legitimate traffic ==================================================================== Customer | V +---------------+ +---------------+ | Domain A | | Domain A | | |<------------>| | | DOTS Client | | Service A | +---------------+ +---------------+ Figure 1: Usecase 1: Single-home Model 4.1.2. Usecase 2: Multi-home Model In the multi-home model, there are one DOTS client and multi DOTS servers. The DOTS client can use both DOTS servers. Nishizuka Expires September 21, 2016 [Page 13] Internet-Draft Inter-Domain DOTS Use Cases March 2016 +-------------+ +--| Attacker |--+ | +-------------+ | | attack traffic | | (destined to | | service A) | V V +-------------+ +-------------+ +-------------+ +-------------+ | Domain B | | Domain B | | Domain C | | Domain C | | |-| | | |-| | | DOTS Server | | Mitigator | | Mitigator | | DOTS Server | +-------------+ +-------------+ +-------------+ +-------------+ ^ | | legitimate ^ Provider | | | traffic | ==================================================================== Customer | V V | | +--------------+ | | | Domain A | DOTS Signaling| +-------------+ | | (Attack | | Domain A |<----->| Service A | Telemetry)| | | +--------------+ | | DOTS Client |---------------------------------------+ +-------------+ Figure 2: Usecase 2: Multi-home Model An example of this situation is that an organization is connected to two transit providers. When the customer get attacked, the DDoS traffic would come from transit B and C. Signaling to the DOTS server in transit B can stop only the DDoS traffic from transit B, and vice verse. After detecting the DDoS attack, the DOTS client can send attack telemetry, in which the IP address of the service under attack must be included, to the both DOTS server via DOTS signaling at the same time. Common interface of DOTS signaling will shorten the lead time of the DDoS protection on both transits. Another example of this situation is cloud type of DDoS mitigation service providers. Cloud type of DDoS mitigation service providers divert traffic to its own domain using DNS or routing protocols, that is BGP route injection. Though they need to provision the returning path mostly on the tunnel interface because they are not directly connected to the domains of the DOTS client, they can accommodate customers remotely. Nishizuka Expires September 21, 2016 [Page 14] Internet-Draft Inter-Domain DOTS Use Cases March 2016 4.2. Provider-to-Provider Cases In these cases, a DOTS server in a provider send DOTS request to other providers. If the capacity of the protection system of the provider is insufficient to protect the customer, the task of the protection can be delegated to other DDoS protection providers. The DOTS server in the provider can be a DOTS client of the other DOTS servers in the other providers. The mitigator can delegate the burden of the mitigation, therefore they can accommodate more services which exceed the capacity of its own platform. 4.2.1. Usecase 3: Delegation Model In the delegation model, a DOTS server is a DOTS client of the other DOTS servers at the same time. +-------------+ | Attacker | +-------------+ | attack traffic | (destined to V service A) +---------------+ +---------------+ | Domain C | | Domain C | | |<------------>| |-----+ | DOTS Server | | Mitigator | | +---------------+ +---------------+ | ^ DOTS Signaling | legitimate | Provider | (Attack Telemetry) | traffic | ==================================================================== | V | +---------------+ +---------------+ | | Domain B | | Domain B | | | DOTS client |<------------>| | | | DOTS Server | | Mitigator | | +---------------+ +---------------+ | ^ DOTS Signaling | legitimate | Provider | (Attack Telemetry) | traffic | ==================================================================== Customer | V | +---------------+ +---------------+ | | Domain A | | Domain A | | | |<------------>| |<----+ | DOTS Client | | Service A | +---------------+ +---------------+ Figure 3: Usecase 3: Delegation Model Nishizuka Expires September 21, 2016 [Page 15] Internet-Draft Inter-Domain DOTS Use Cases March 2016 If the capacity of the mitigator in provider B is insufficient in comparison with ongoing DDoS attack, the DOTS server in B can be a DOTS client of the DOTS server in C. It needs to be considered whether or not the attack telemetry from A to B (client-to-provider) is the same as the attack telemetry from B to C (provider-to- provider). By just relaying the DOTS signaling information to the DOTS server in domain C, the mitigator in domain C could protect the service A. The DOTS client in A might not notice that the protection was delegated to other domain. However, if the circuit between domain A and domain B is saturated, attack telemetry derived from the observation point of domain A could be insufficient to protect the service. The overwritten attack telemetry derived from observation point of domain B would make the protection more precise. In addition, the returning path of the legitimate traffic also needs to be considered. The mitigator in domain C can return the legitimate traffic to domain B or domain A. In the former case, the attack traffic could re-enter the protection system of the domain B. In the latter case, the returning path information from domain C to domain A might need to be registered in advance. Even if the capacity of the protection system in domain B is enough, in some cases, it is effective to delegate the protection to upstream domain C because stopping DDoS traffic at an ingress border will reduce unnecessary forwarding. 4.2.2. Usecase 4: Distributed Architecture Model The distributed architecture is one of the multi-provider coordinated DDoS protection, which is a cluster of mutual delegation relations. Nishizuka Expires September 21, 2016 [Page 16] Internet-Draft Inter-Domain DOTS Use Cases March 2016 +-------------+ +-------------+ | Attacker | | Attacker | +-------------+ +-------------+ attack traffic | \ / | attack traffic (destined to | X | (destined to service A ) | / \ | service D) | / \ | +-------------+ | / \ | +-------------+ | Domain B |--------+---+-------+---+------>| Domain C | | DOTS Client |<-------+--+---------+--+-------| DOTS Client | | DOTS Server | | | DOTS | | | DOTS Server | +-------------+ V V Signaling V V +-------------+ ^ ^ +-------------+ +-------------+ ^ ^ DOTS | | | Domain B | | Domain C | | | DOTS Signaling | +--->| | | |<---+ | Signaling (Attack | | Mitigator | | Mitigator | | (Attack Telemetry)| +-------------+ +-------------+ | Telemetry) | | \ / | | Provider | | \ / | | ==================================================================== Customer | | \ / | legitimate | | | X | traffic | | | / \ | | | V V V V | +-------------+ +-------------+ +-------------+ +-------------+ | Domain A | | Domain A | | Domain D | | Domain D | | |-| | | |-| | | DOTS Client | | Service A | | Service D | | DOTS client | +-------------+ +-------------+ +-------------+ +-------------+ Figure 4: Usecase 4: Mutual Delegation Model The DOTS client in domain A ask for help to the DOTS server in domain B. Then the DOTS server in domain B delegate the protection to the DOTS server in domain C. The mitigator in domain C protect the service of domain A. On the other hand, the DOTS client in domain D ask for help to the DOTS server in domain C. Then the DOTS server in domain C delegate the protection to the DOTS server in domain B. The mitigator in domain B protect the service of domain D. In this model, the DOTS element in domain B and C is delegating the protection each other. They can leverage total capacity of the mitigator by utilizing the others facility. If the number of the providers involving the coordinated protection increased and letting them make mutual(peer-to-peer) relationship between each other, that is distributed architecture of cooperative DDoS protection. It becomes difficult to select appropriate DDoS protection according to the capacities of the each mitigator. In Nishizuka Expires September 21, 2016 [Page 17] Internet-Draft Inter-Domain DOTS Use Cases March 2016 this case, billing data could be more important to adjust the cost distribution fairly. 4.2.3. Usecase 5: Centralized Architecture Model The centralized architecture model is another multi-provider coordinated DDoS protection, which could overcome the disadvantages of the distributed architecture. DOTS +-------------+ Signaling | Domain D | +---------------| DOTS Client | | | DOTS Server | DOTS | +-------------+ Signaling | +-------------+ +-------------+ +-------------+ | Domain B | | Domain C | | Domain E | | DOTS Client |---------| DOTS Client |---------| DOTS Client | | DOTS Server | | DOTS Server | | DOTS Server | +-------------+ +-------------+ +-------------+ ^ | DOTS | | +-------------+ Signaling | | | Domain F | (Attack | +---------------| DOTS Client | Telemetry)| | DOTS Server | | +-------------+ Provider | ==================================================================== Customer | | +-------------+ +-------------+ | Domain A | | Domain A | | |-| | | DOTS Client | | Service A | +-------------+ +-------------+ Figure 5: Usecase 5: Centralized Architecture Model In this model, the DOTS server in domain B can utilize the protection service in domain C, D, E and F. The DOTS server in domain C coordinates the protection services of these providers centrally. The further discussion about the centralized architecture and the distributed architecture is described in [draft-nishizuka-dots-inter- domain-mechanism] Nishizuka Expires September 21, 2016 [Page 18] Internet-Draft Inter-Domain DOTS Use Cases March 2016 5. Security Considerations As described in the protection methods section, the DOTS framework can be another attack vector to other organizations. Only the legitimate DOTS client should be able to communicate with the DOTS server and the protecting IP address in the request should be checked and restricted in order to eliminate the risks of abuse. 6. IANA Considerations No need to describe any request regarding number assignment. 7. References 7.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, . [RFC2784] D. Farinacci., T. Li., S. Hanks., D. Meyer., and P. Traina., "Generic Routing Encapsulation (GRE), March 2000". [RFC3882] D. Turk. Bell Canada, "Configuring BGP to Block Denial-of- Service Attacks, September 2004". [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules, August 2009". [RFC5635] W. Kumari. and D. McPherson., "Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF), August 2009". [I-D.draft-ietf-grow-blackholing] T. King., C. Dietzel., J. Snijders., G. Doering., and G. Hankins., "BLACKHOLE BGP Community for Blackholing, draft- ietf-grow-blackholing-00, November 2015". [I-D.draft-ietf-dots-requirements] A. Mortensen., R. Moskowitz., and T. Reddy., "DDoS Open Threat Signaling Requirements, draft-ietf-dots- requirements-00, October 2015". Nishizuka Expires September 21, 2016 [Page 19] Internet-Draft Inter-Domain DOTS Use Cases March 2016 [I-D.draft-ietf-dots-use-cases] R. Dobbins, Ed., S. Fouant., D. Migault., R. Moskowitz., N. Teague., L. Xia, "Use cases for DDoS Open Threat Signaling, October 2015". [I-D.draft-reddy-dots-transport] T. Reddy., D. Wing., P. Patil., M. Geller., M. Boucadair., and R. Moskowitz., "Co-operative DDoS Mitigation, October 2015". [I-D.draft-nishizuka-dots-inter-domain-mechanism] K. Nishizuka., L. Xia., J. Xia., D. Zhang., and L. Fang., "Inter-domain cooperative DDoS protection problems and mechanism, Feburuary 2016". 7.2. URL References [Cloudflare] Cloudflare, "https://blog.cloudflare.com/the-ddos-that- knocked-spamhaus-offline-and-ho/". Author's Address Kaname Nishizuka NTT Communications GranPark 16F 3-4-1 Shibaura, Minato-ku, Tokyo 108-8118,Japan EMail: kaname@nttv6.jp Nishizuka Expires September 21, 2016 [Page 20]