Internet DRAFT - draft-nishizuka-dots-inter-domain-usecases

draft-nishizuka-dots-inter-domain-usecases







DOTS                                                        K. Nishizuka
Internet-Draft                                        NTT Communications
Intended status: Informational                        September 20, 2016
Expires: March 24, 2017


                      Inter-Domain DOTS Use Cases
             draft-nishizuka-dots-inter-domain-usecases-02

Abstract

   This document describes inter-domain use cases of the DDoS Open
   Threat Signaling(DOTS).  The use cases descirbed in this draft will
   be merged into [I-D.draft-ietf-dots-use-cases].

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 March 24, 2017.

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 March 24, 2017                 [Page 1]

Internet-Draft         Inter-Domain DOTS Use Cases        September 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)  . . . . . . . . . . . . . . . . . . .   7
       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  . . . . . . . . . . . . . .  12
   4.  Inter-Domain Dots Use Cases . . . . . . . . . . . . . . . . .  13
     4.1.  Customer-to-Provider Cases  . . . . . . . . . . . . . . .  13
       4.1.1.  Usecase 1: Single-home Model  . . . . . . . . . . . .  13
       4.1.2.  Usecase 2: Multi-home Model . . . . . . . . . . . . .  14
     4.2.  Provider-to-Provider Cases  . . . . . . . . . . . . . . .  15
       4.2.1.  Usecase 3: Delegation Model . . . . . . . . . . . . .  15
       4.2.2.  Usecase 4: Distributed Architecture Model . . . . . .  17
       4.2.3.  Usecase 5: Centralized Architecture Model . . . . . .  18
   5.  Consolidated Usecases . . . . . . . . . . . . . . . . . . . .  19
     5.1.  Intra-domain Use Case . . . . . . . . . . . . . . . . . .  19
     5.2.  Primary Inter-domain Usecase  . . . . . . . . . . . . . .  20
     5.3.  Primary Inter-domain Usecase with multiple upstream DDoS
           mitigation providers  . . . . . . . . . . . . . . . . . .  20
     5.4.  Inter-domain Usecase with Client-Side DOTS Relay  . . . .  20
     5.5.  Inter-domain Usecase with Server-Side DOTS Relay  . . . .  21
     5.6.  Inter-domain Usecase with bilateral coordination  . . . .  21
     5.7.  Inter-domain Usecase with multilateral coordination . . .  22
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  22
     8.2.  URL References  . . . . . . . . . . . . . . . . . . . . .  24
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  24

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.



Nishizuka                Expires March 24, 2017                 [Page 2]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


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



Nishizuka                Expires March 24, 2017                 [Page 3]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


   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.

   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



Nishizuka                Expires March 24, 2017                 [Page 4]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


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





Nishizuka                Expires March 24, 2017                 [Page 5]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


   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.

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.








Nishizuka                Expires March 24, 2017                 [Page 6]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


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:

         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



Nishizuka                Expires March 24, 2017                 [Page 7]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


   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

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



Nishizuka                Expires March 24, 2017                 [Page 8]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


   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.

   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






Nishizuka                Expires March 24, 2017                 [Page 9]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


   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

   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





Nishizuka                Expires March 24, 2017                [Page 10]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


   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.

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.




Nishizuka                Expires March 24, 2017                [Page 11]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


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

   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



Nishizuka                Expires March 24, 2017                [Page 12]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


   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.

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    |
            +---------------+              +---------------+





Nishizuka                Expires March 24, 2017                [Page 13]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


   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.

                              +-------------+
                           +--|  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



Nishizuka                Expires March 24, 2017                [Page 14]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


   connected to the domains of the DOTS client, they can accommodate
   customers remotely.

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.

































Nishizuka                Expires March 24, 2017                [Page 15]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


                                            +-------------+
                                            |  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

   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



Nishizuka                Expires March 24, 2017                [Page 16]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


   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.

                   +-------------+   +-------------+
                   |  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



Nishizuka                Expires March 24, 2017                [Page 17]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


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





























Nishizuka                Expires March 24, 2017                [Page 18]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


                                           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]

5.  Consolidated Usecases

   This section provides consolidated usecases with [I-D.draft-ietf-
   dots-use-cases].

5.1.  Intra-domain Use Case

   In intra-domain use case, all DOTS components are assumed to be
   managed by one organization.  There are several merits of using DOTS
   signaling even in an intra-domain manner as follows:





Nishizuka                Expires March 24, 2017                [Page 19]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


   1.  It will facilitate interoperability between DDoS solutions/
       services by providing a standards-based, programmatic
       communications mechanism

   2.  It will reduce time to service

   The communication form between a DOTS client and a DOTS server is a
   direct signaling described in [I-D.draft-ietf-dots-architecture] The
   required data exchange between DOTS client and DOTS server is
   equivalent to or subset of information set of inter-domain use cases.

5.2.  Primary Inter-domain Usecase

   In this inter-domain usecase, a DOTS client and a DOTS server are
   assumed to be in different domains.  This is the most basic scenario
   of inter-domain usecases.  The communication form between a DOTS
   client and a DOTS server is a direct signaling described in [I-
   D.draft-ietf-dots-architecture] The main difference from the intra-
   domain usecase is that two organizations are related.  It will
   clarify the requirement of authentication.  Also an unreliable
   transport condition between DOTS client and server will introduce a
   constraint regarding to a specification of transport of DOTS
   protocol.  Merits of using DOTS signaling in inter-domain usecases
   are almost same as the intra-domain usecase.

   1.  It will facilitate interoperability between DDoS solutions/
       services by providing a standards-based, programmatic
       communications mechanism

   2.  It will reduce time to service

5.3.  Primary Inter-domain Usecase with multiple upstream DDoS
      mitigation providers

   In this usecase, a DOTS client asks for help to multiple DOTS servers
   which are in different domains.  It is natural that DDoS attacks are
   coming from several ingress point of a network.  The DOTS client in
   the targeted network will ask for help to all of the connected
   network and other effective candidate network in order to stop the
   attack completely.

5.4.  Inter-domain Usecase with Client-Side DOTS Relay

   In this usecase, A DOTS client and a DOTS server are in different
   domains and a DOTS relay is in the DOTS client's domain.  The DOTS
   relay is a back-to-back DOTS server and client.  The communication
   form of DOTS components is a relayed signaling(Client-Side Relay)




Nishizuka                Expires March 24, 2017                [Page 20]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


   described in [I-D.draft-ietf-dots-architecture] The DOTS relay is a
   gateway of the DOTS signaling of the DOTS clients.

   The gateway function will be needed in case that the initial DOTS
   clients don't have enough function to behave as a whole DOTS client.
   The DOTS relay will aggregate the DOTS signaling to convey it to the
   DOTS server.  The signaling between the initial DOTS clients and the
   DOTS relay is DOTS protocol, at the same time the signaling between
   the DOTS relay and the DOTS server is DOTS protocol.  The transport
   of DOTS signaling can be transformed by the DOTS relay while the
   relationship between the DOTS relay and the DOTS server is opaque to
   the initial clients.

5.5.  Inter-domain Usecase with Server-Side DOTS Relay

   In this usecase, a DOTS client and a DOTS server are in different
   domains and a DOTS relay is in the DOTS server's domain.  The DOTS
   relay is a back-to-back DOTS server and client.  The DOTS client
   communicate with a DOTS server, then the DOTS server acts as a DOTS
   client of other DOTS servers, which results in that the intermediary
   DOTS server acts as a DOTS relay.

   The DOTS signals are relayed when the upstream organization decides
   that they need additinal protection by other organization.  The
   reasons could be as follows:

   1.  The capacity of the mitigator is insufficient

   2.  Available protection methods are not suitable to ongoing attack

   3.  They are also suffering from the attack

   The relationship between the intermediary DOTS server and the actual
   DOTS server is opaque to the initial clients.  The communication form
   of DOTS components is a relayed signaling(Server-Side Relay)
   described in [I-D.draft-ietf-dots-architecture] In order to avoid
   routing loop, returning path information of cleaned traffic should be
   propagated to all of DOTS servers.

5.6.  Inter-domain Usecase with bilateral coordination

   In this usecase, DOTS servers are distributed in different domains
   and have bilateral relationships.  Bilateral relationships are peer
   to peer communication among all the participating operators.  The
   DOTS client ask for help to one of the DOTS servers, then the DOTS
   server acts as a DOTS client to request inter-domain DDoS protection
   to other DOTS servers with which it has bilateral relationship.  The




Nishizuka                Expires March 24, 2017                [Page 21]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


   communication form of DOTS components is a Recursive Signaling
   described in [I-D.draft-ietf-dots-architecture]

   If one DOTS server finds the attack volume exceeds its capacity, the
   attack type is unknown type, or it is suffering from the attack, it
   can ask for help to other alliance DOTS servers, vice versa.  DOTS
   protocol can be used on the communication between the DOTS servers.
   More details are described in [I-D.draft-nishizuka-dots-inter-domain-
   mechanism]

5.7.  Inter-domain Usecase with multilateral coordination

   In this usecase, DOTS servers are distributed in different domains
   and have multilateral relationships Multilateral relationships among
   all of the participating operator are client-server communication via
   one orchestrator.  The DOTS client ask for help to one of the DOTS
   servers, then the DOTS server acts as a DOTS client to request inter-
   domain DDoS protection to the orchestrator which will coordinate
   appropriate protection.  The communication form of DOTS components is
   a Recursive Signaling described in [I-D.draft-ietf-dots-architecture]

   If one DOTS server finds the attack volume exceeds its capacity, the
   attack type is unknown type, or it is suffering from the attack, it
   can ask for help to the orchestrator.  DOTS protocol can be used on
   the communication between the DOTS servers and the orchestrator.
   More details are described in [I-D.draft-nishizuka-dots-inter-domain-
   mechanism]

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

7.  IANA Considerations

   No need to describe any request regarding number assignment.

8.  References

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



Nishizuka                Expires March 24, 2017                [Page 22]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


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

   [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-ietf-dots-architecture]
              A. Mortensen., F. Andreasen., T. Reddy., C. Gray., R.
              Compton., N. Teague., "Distributed-Denial-of-Service Open
              Threat Signaling (DOTS) Architecture, July 2016".

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







Nishizuka                Expires March 24, 2017                [Page 23]

Internet-Draft         Inter-Domain DOTS Use Cases        September 2016


8.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 March 24, 2017                [Page 24]