Inter-Domain DOTS Use Cases
draft-nishizuka-dots-inter-domain-usecases-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Kaname Nishizuka | ||
| Last updated | 2016-03-20 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-nishizuka-dots-inter-domain-usecases-01
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,
<http://www.rfc-editor.org/info/rfc2119>.
[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]