One document matched: draft-nishizuka-dots-inter-domain-mechanism-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?txt version="1.0" encoding="US-ASCII"?>
<!-- change the "txt" on the previous line to "xml" to make this a valid XML2RFC template -->
<!-- this is version 5 of this xml2rfc template -->
<!--
DOCTYPE processing
To use this XML template, the rfc2629.dtd from the xml2rfc distribution should
be in the local directory. The xml2rfc distribution is available from
http://xml.resource.org/
The ENTITY clauses create an include of the named XML files, which
contains references written in xml2rfc format.
XML2RFC offers an include feature described in the XML2RFC README
file. That syntax, however, contradicts the DTD requirements to
have <reference> elements within the <references> element, so an
XML parser is likely to find your XML file invalid. It may be
possible that XML2RFC will change their DTD so that the XML file
remains valid when their style of include is used.
Some editors, such as XXE, resolve the ENTITY clauses before displaying the
document to be edited.
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2223 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2223.xml">
<!ENTITY rfc2578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml">
<!ENTITY rfc2579 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml">
<!ENTITY rfc2580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2580.xml">
<!ENTITY rfc2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY rfc3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
<!ENTITY rfc4181 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4181.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<!-- Document section
Specify the category attribute per RFC2026
options are info, std, bcp, or exp.
docname is the name of the output document. This is optional;
the default is to use the base portion of the XML filename.
For Internet-drafts, indicate which intellectual property notice
to use per the rules of RFC3978. The value (as of this template) can be:
trust200902 -
noModificationTrust200902 -
noDerivativesTrust200902 -
pre5378Trust200902 -
The Intellectual Property section will be generated automatically by
XML2RFC, based on the ipr attribute in the rfc element.
If this document obsoletes an RFC, specify the RFC in the "obsoletes" attribute
If this document updates an RFC, specify the RFC in the "updates" attribute
-->
<rfc category="std"
docName="draft-nishizuka-dots-inter-domain-mechanism-00"
ipr="trust200902">
<front>
<!--Enter the full document title and an abbreviated version to use in the page header.-->
<title
abbrev="Inter-domain cooperative DDoS protection">Inter-domain cooperative DDoS protection problems and mechanism</title>
<author fullname="Kaname Nishizuka" initials="K" surname="Nishizuka">
<organization>NTT Communications</organization>
<address>
<postal>
<street>GranPark 16F</street>
<city>3-4-1 Shibaura, Minato-ku, Tokyo</city>
<country>108-8118,Japan</country>
</postal>
<email>kaname@nttv6.jp</email>
</address>
</author>
<author fullname="Liang Xia" initials="L" surname="Xia">
<organization>Huawei Technologies Co., Ltd.</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhuatai District</street>
<city>Nanjing, Jiangsu</city>
<country>210012, China</country>
</postal>
<email>frank.xialiang@huawei.com</email>
</address>
</author>
<author fullname="Jinwei Xia" initials="J" surname="Xia">
<organization>Huawei Technologies Co., Ltd.</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhuatai District</street>
<city>Nanjing, Jiangsu</city>
<country>210012, China</country>
</postal>
<email>xiajinwei@huawei.com</email>
</address>
</author>
<author fullname="Dacheng Zhang" initials="D" surname="Zhang">
<organization/>
<address>
<postal>
<street/>
<city>Beijing</city>
<country>China</country>
</postal>
<email>dacheng.zdc@aliabab-inc.com</email>
</address>
</author>
<author fullname="Luyuan Fang" initials="L" surname="Fang">
<organization>Microsoft</organization>
<address>
<postal>
<street>15590 NE 31st St</street>
<city>Redmond, WA 98052</city>
<country/>
</postal>
<email>lufang@microsoft.com</email>
</address>
</author>
<date year="2016"/>
<!-- IETF area is optional -->
<area>Security Area</area>
<!--WG name at the upperleft corner of the doc, IETF is fine for non-WG IETF submissions -->
<workgroup>DOTS</workgroup>
<keyword>Security</keyword>
<keyword>DDoS</keyword>
<!--add additional keywords here for IETF website search engine -->
<abstract>
<t>As DDoS attack evolves rapidly in the aspect of volume and
sophistication, cooperation among operators for sharing the capacity of
the protection system to cope with it becomes very necessary. This
document describes some possible solutions to the cooperative
inter-domain DOTS problems.</t>
</abstract>
</front>
<middle>
<section title="Motivations">
<t>These days, DDoS attacks are getting bigger and more sophisticated.
Preliminary measures for minimizing damages caused by such attacks are
indispensable to all organizations facing to the internet. Due to the
variations of UDP reflection attack, there are still too big platforms
of DDoS attack which consist of vulnerable servers, broadband routers
and other network equipments distributed all over the world. Because of
the amplification feature of the reflection attack, attackers can generate massive
attacks with small resources. Moreover, there are many booters who are
selling DDoS attacks as a service. DDoS attack is commoditized, so
frequency of DDoS attack is also increasing.</t>
<t>These trends of the attack could exceed a capacity of a protection
system of one organization in the aspect of volume and frequency.
Therefore, sharing the capacity of the protection system with each other
to cope with such attacks becomes very necessary.</t>
<t>By utilizing other organization's resources, the burden of the
protection is shared. The shared resources are not only CPU/memory
resources of dedicated mitigation devices but also the capability of
blackholing and filtering. We call the protection which utilize
resources of each other "cooperative DDoS protection".</t>
<t>The cooperative DDoS protection have numerous merits. First, as
described above, it can leverage the capacity of the protection by
sharing the resources among organizations. Generally DDoS attack happens unexpectedly, thus the capacity utilization
ratio of a protection system is not constant. So, while the utilization
ratio is low, it can be used by other organization which is under
attack. Second, organizations can get various countermeasures. If an
attack is highly sophisticated and there is no countermeasure in the
system, cooperative DDoS protection can offer optimal countermeasure of
all partners. Third, it can block malicious traffic near to the origin
of the attack. Near source defense is ideal for the health of the
internet because it can reduce the total cost of forwarding packets
which are mostly consist of useless massive attack traffic.
Moreover, it is also very
effective to solve the inter-domain uplink congestion problem. Finally,
it can reduce time to respond. After getting attacked, prompt response
is important because the outage of the service can make significant loss
to the victim organization. Cooperating channel between partner
organizations would be automated by dots protocol.</t>
</section>
<section title="Cooperative DDoS Protection Problems">
<t>In this section, problems regarding to cooperative DDoS protection are described.</t>
<section title="Bootstrapping Problem">
<t>DDoS attacks are unpredictable, so preliminary measures are
important to maximize the utility of cooperative DDoS protection,
which are accomplished by provisioning of DDoS protection system of
each other in advance. However, it is difficult to set up DDoS
protection of each other's service in secure manner.</t>
<section title="Automatic Provisioning vs Manual Provisioning">
<t>Manual provisioning is easier way to utilize DDoS protection
service of other organizations. An organization can trust other
organization who are going to use their DDoS protection service by
any means like phone, e-mail, Web portal, etc,. However, it will
take much time to provision the DDoS protection system, then the
attack will succeed to make significant impact on the protected
service. To reduce the time to start the protection, automatic
provisioning is desirable. If an organization could acquire relevant
information of the DDoS protection service of other organization and
utilize it by dots signaling in short time, the cooperative DDoS
protection will succeed at a certain level. It is needed to find a
way to provision other DDoS protection service in secure manner.
In the later section, the total scenario is divided into two stages, those are provisioning stage and signaling stage. It is assumed that dots signaling is authorized by some
credentials provided in provisioning stage in advance. Other
important works carried out in the bootstrapping process are
auto-discovery, automatic capability building between the member
DDoS protection service providers as the basis for the following coordination process.</t>
</section>
</section>
<section title="Coordination Problem">
<t>The number of the member DDoS protection service provider of cooperative DDoS protection is
important factor. If only two providers are involved, there is bilateral
relationship only. It is easy to negotiate about the capacity of their
own DDoS protection system. In the state of emergency, they can decide
to ask for help each other if the capacity of their own system is
insufficient. When a lot of providers are joining cooperative DDoS
protection, it is difficult to decide where to ask for help. They need
to negotiate about their capacity with every participant. It is needed to
take into account all combinations to do appropriate protection. The coordination between the member providers of cooperative DDoS protection is a complete process consisting of mitigation start/stop, status notification, mitigation policy updates and so on.</t>
<t>In addition, inter-domain uplink congestion problem can only be
solved by coordinating the protection services provided by the
upstream operators.</t>
</section>
<section title="Near Source Protection Problem">
<t>Stopping malicious traffic at the nearest point in the internet
will reduce exhaustion of resources in all the path of the attack. To
find the entry point of the attack, traceback of the attack
traffic to the origin is needed. If there is cooperative partner near the attack
source, asking for help to the ISP is most effective. However, the
problem is that it is difficult to decide which ISP is nearest to the
attack source because in many cases source address of attack packets
are spoofed to avoid to be visible from others. Moreover, some
topology information of ISP's NW will be uncovered in order to make the decision correctly, however there could be privacy protection issue
between ISPs. Those problems will lead to the difficulties of locating
the attack source. The problems can be divided into two problems. The
first is how to find the attacker. The second is how to decide whom to
ask for help.</t>
</section>
<section title="Returning Path Problem">
<t>As one of protection methods, some DDoS protection service provider
announce BGP route to detour the attack traffic to their own network
to deal with it. After scrubbing, cleaned traffic should be returned
to the original destination. The returning path is often called "clean
pipe". The DDoS service provider should be careful about routing loop
because if the end point of a clean pipe is still included in a reach
of the announced BGP route, the traffic will return to the mitigation
path again and again. When thinking about cooperative DDoS protection,
returning path information should be propagated to partners.</t>
</section>
<section title="Billing Information Problem">
<t>This is not technical nor a part of dots protocol but it has
relation to deployment models. If other organization utilized
resources of DDoS protection service, it is natural to charge it
according to the amount of use. However, how to count the amount of
use differs among DDoS protection service providers. For example, some
DDoS protection service provider charges users by volume of the attack
traffic or dropped packets. On the other hand, some of them use volume
of normal traffic. Number of execution can be also used. We can not
decide what information should be taken into account for billing
purpose in advance, however those information is needed to be
exchanged while coordinating DDoS protection. These information could
be also used to determine which service would be used when asking for
help. Though it is out of the scope of dots, coordinating and
optimizing the cooperation in the aspect of business is difficult to
solve.</t>
</section>
</section>
<section title="Inter-domain DOTS Architecture">
<t>As described above, with the fast growth of DDoS attack volume and
sophistication, a global cooperative DDoS protection service is
desirable. This service can not only address the inter-domain uplink
congestion problem, but also take full advantage of global DDoS
mitigation resources from different ISPs efficiently and enable the near
source mitigation. Moreover, with the way of providing DDoS mitigation
as service, more customers will get it flexibly by their demands with
maximized territory and resources. Together with on-premise DDoS
protection appliance, the multiple layer DDoS system provides a
comprehensive DDoS protection against all types of attacks, such as
application layer attacks, network layer large traffic attacks and
others. The signaling mechanisms between on-premise DDoS protection
appliance and cloud service are in scope of DOTS.</t>
<t>The inter-domain DDoS protection service is set up based on the
member ISPs' own DDoS protection systems and the coordination protocol
between them. The inter-domain protocol (or signaling mechanism) for the
goal of DDoS protection coordination is the main focus of this document.
Note that not only ISPs but also cloud based DDoS protection providers
can participate in the inter-domain DDoS protection service.
In general, the member ISP's own DDoS systems should at least consist of
controller, mitigator or possibly flow analyser, which:</t>
<t><list hangIndent="6" style="hanging">
<t hangText="controller:">be responsible for intra-domain DDoS
mitigation controlling and communication for customers and
inter-domain coordination</t>
<t hangText="mitigator:">be responsible for mitigation and results
report</t>
<t hangText="flow analyser:">be responsible for attack detection and
source traceback.</t>
</list></t>
<t>The inter-domain DDoS protection service has two different deployment
models: distributed architecture or centralized architecture. The
following parts give the respective discussion to them by aligning to
DOTS terms.</t>
<section title="Distributed Architecture">
<t>Several ISPs can set up the bilateral cooperative relation of DDoS
protection between each other, thereby a distributed inter-domain DDoS
protection service is provided with the support of peer to peer
communication. The corresponding distributed architecture is
illustrated in the following diagram:</t>
<figure align="center"
title="Figure 1: Distributed Architecture for Inter-domain DDoS Protection Service">
<artwork> Customer
+-------+
|DOTS |
|Client |
+----A--+
|
---------------- --+------
////- \\\\ /// | \\\
/// +-----------------------------+-------+ \\
// +-----------------+-------+ \\ / | | \
|| | | | || +-----V-+-----V-+ |
| +----V----------+ +---V---+---V---+ | | |DOTS |DOTS | |
| |DOTS |DOTS <-->DOTS |DOTS <--+----+--->Server |Client | |
| |Server |Client | |Server |Client | | | +-----A-+------A+ |
| +--A----+-------+ +----A--+---A---+ | | Controller / |
| | Controller Controller\ | | / / |
|| | | \ \ || \ // // /
\\| | \ // \\/ ISP2 / //
|\\ ISP1 | \ // \ / \\ / ///
| \\\\- | -//// \ / ----/----
| -+-----------+- \ \ / /
| | \ \ / /
| | \ \ / /
+---V---+ +----V--+ \ -----/--- //
|DOTS | |DOTS | \// / \\ \\ /
|Client | |Client | // \ / \ /\\
+-------+ +-------+ / \ / \ / \
Customer Customer +---V---+----V--+ | +-------+
| |DOTS |DOTS | | |DOTS |
| |Client |Server <---+---->Client |
| +-------+-------+ | +-------+
| Controller | Customer
| |
\ cloud based /
\\ Anti-DDoS //
\\\ Provider ///
--------</artwork>
</figure>
<t>As illustrated in the above diagram, when the customer is suffering
a large traffic DDoS attack, it acts as the DOTS client to request
DDoS protection service from its ISP. The ISP controller acts as the
DOTS server to authenticate the customer's validity and then initiate
the intra-domain DDoS mitigation service with its own resource for the
customer. If the ISP controller finds the attack volume exceeds it
capacity, or the attack type is unknown type, or its inter-domain
upstream link is congested, it should act as the DOTS client to
request inter-domain coordination to all or its upstream ISP
controllers which it has cooperative relation with. The ISP controller
should support the functions of DOTS server and DOTS client at the
same time in order to participate in the system of inter-domain DDoS
protection service. In other words, as the representative for an ISP's
DDoS protective service, the ISP controller manages and provides DDoS
mitigation service to its customer in one hand, but may require helps
from other ISPs under some situation especially when the attack volume
exceeds its capacity or the attack is from other ISPs. The
inter-domain coordination can be a repeated process until the attack
source faced ISP receives the inter-domain coordination request and
mitigates the attack traffic.</t>
<t>In particular, each ISP is able to decide its responding actions to
its peering ISPs' request flexibly by following the internal policies,
such as whether or not perform the mitigation function, or whether or
not relay the request message to other ISPs. But these are out of the
scope of this document.</t>
<t>The distributed architecture is straightforward and simple when the
member ISPs are not too many. Regarding to deployment, all the work an
ISP needs to do is to configure other cooperative member ISPs'
information (i.e., IP, port, certificate, etc) and relevant
cooperative policies for the following inter-domain communication.
Regarding to operation, each ISP's controller just performs the
mitigation service according to customer's request and possibly asks
for inter-domain helps to other ISPs if necessary. In the meantime,
the mitigation report and statistics information is required to
exchange between the peering ISPs for the goal of monitoring and
accounting.</t>
<t>But there are still some problems for the distributed
architecture:</t>
<t><list style="symbols">
<t>Every ISP controller only has the information of those ISPs
which have cooperative relation with it, not the all ISPs
participated in the inter-domain DDoS protection service. The
incomplete information may not lead to the most optimized
operation</t>
<t>When the member ISPs reach a certain number, a new joining ISP
will be required to configure and maintain a lot of peering ISPs'
information. It's complex and error-prone</t>
<t>Due to the exclusive repeated nature of the this architecture
mentioned above, it's possible that the really effective
mitigation service by one upstream ISP happens after several
rounds of repeating the inter-domain coordination process. It may
take a long time and is unacceptable.</t>
</list></t>
</section>
<section title="Centralized Architecture">
<t>For the centralized architecture, the biggest difference from the
distributed architecture is that a centralized orchestrator exists
aimed at controlling the inter-domain DDoS coordination centrally. The
centralized architecture for the inter-domain DDoS protection service
is illustrated in the following diagram:</t>
<figure align="center"
title="Figure 2: Centralized Architecture for Inter-domain DDoS Protection Service">
<artwork> Orchestrator
+-------+-------+
ADOTS |DOTS A
/|Server |Client |\
/ +---AA--+A--A---+ \
/ | \ / \
/ |/ /\ \
/ /| / \ \
-----/---------- / / \ --\------
////- / /\\\\| \ /// \ \\\
/// / / / |\\ \ // \ \\
// / / / | \\ \/ \ \
|| / / / | || \ +-------+---V---+ |
| +-----V---------+ /+---V---+---V---+ | | \|DOTS |DOTS | |
| |DOTS |DOTS V |DOTS |DOTS | | | VClient |Server | |
| |Client |Server | |Server |Client | | | +-------+---A---+ |
| +-------+---A---+ +----A--+-------+ | | Controller | |
| Controller | | Controller | | | |
|| | | || \ | /
\\ | | // \\ ISP2 | //
\\\ | ISP1 | // \\\ |///
\\\\- | | -//// --------+
-+-----------+- |
| | |
| | |
+-----V-+ +----V--+ +---V---+
|DOTS | |DOTS | |DOTS |
|Client | |Client | |Client |
+-------+ +-------+ +-------+
Customer Customer Customer
</artwork>
</figure>
<t>As illustrated in the above diagram, the orchestrator is the core
component to the inter-domain system. Each ISP controller only
communicates with it for the goal of registering, coordination
requesting and reporting. When it receives the inter-domain
coordination request message from the ISP controller, a simple way is
to notify all the other ISP controllers which have registered to the
orchestrator, to enable the possible mitigation services. Another way
is to choose a number of ISPs to notify them enable the mitigation
services according to the traceback result or other policies. The
details is to be added in future. Based on the above analysis, the
orchestrator is also a combination of DOTS server and DOTS client
which support both functions at the same time.</t>
<t>In addition to the orchestrator and its related functions, the
signaling and operations of centralized architecture are very similar
to the implementation of distributed architecture.</t>
<t>The centralized architecture has its own characteristics as
below:</t>
<t><list style="symbols">
<t>Due to the centralized architecture, the orchestrator is easy
to suffer the problems of congestion or performance downgrade to
influence the availability of the whole system. This can be
improved by the redundant orchestrator deployment</t>
<t>A centralized orchestrator facilitates the auto-discovery
mechanism for the member ISPs. And for each ISP controller, its
deployment and operation becomes very easy cause it is only
required to communicate with the orchestrator during the whole
time</t>
<t>With the help of direct communication between the orchestrator
and all ISP controllers, an inter-domain DDoS coordination is
finished in a short and fixed time period.</t>
</list></t>
</section>
</section>
<section title="Inter-domain DOTS Protocol">
<t>According to [I-D.draft-ietf-dots-requirements], DOTS protocols MUST
take steps to protect the confidentiality, integrity and authenticity of
messages sent between the DOTS client and server, and provide peer
mutual authentication between the DOTS client and server before a DOTS
session is considered active. The DOTS agents can use HTTPS (with TLS)
for the goal of protocol security. The HTTP RESTful APIs are used in
this section as the protocol channel, and the DOTS message content can
be in JSON format.</t>
<t>With respect to the inter-domain DOTS protocol, all the DOTS messages
are exchanged between DOTS client and server, no matter what the
architecture (distributed or centralized) is. So, the message formats
and operations of DOTS protocol is ought to be unified for all
architecture options. The DOTS messages can be categorized by which
stage they are mainly required in during DDoS protection, as below:</t>
<t><list style="symbols">
<t>Provisioning stage: Before getting attacked by malicious traffic,
a DOTS client needs register to the DOTS server, as well as enable
capacity building in advance;</t>
<t>Signaling stage: This stage covers the time period when the DDoS
attack is happening. At the beginning, the DOTS client should signal
the DOTS server to provide DDoS mitigation service to the customer
service under attack. At the end, once the attack is over, the DOTS
client should notify the DOTS server to stop the mitigation
service.</t>
</list></t>
<t>DOTS protocol can run on HTTPS (with TLS) and employ several
different ways for authentication:</t>
<t><list style="symbols">
<t>Employ bidirectional certificate authentication ([ITU-T X.509])
on the DOTS server and client: Both DOTS server and client need to
verify the certificates of each other;</t>
<t>Employ unidirectional certificate authentication ([ITU-T X.509])
on the DOTS server: Only the DOTS server needs to install the
certificate. The DOTS client needs to verify its certificate. In the
opposite direction, DOTS server can authenticate DOTS client by the
ways of user/role:password, IP address white-list or digital
signature;</t>
<t>Employ bidirectional digital signature authentication on the DOTS
server and client: In this condition, the DOTS server and client
must keep the customer's private key safely, which is used for
calculate the digital signature.</t>
</list></t>
<t>Besides authenticating the DOTS client, the DOTS server also verifies
the timestamp of the packets from the DOTS client. If the time
difference between the timestamp and the current time of the DOTS server
exceeds the specified threshold (60 seconds as an example), the DOTS
server will consider the packet invalid and will not process it.
Therefore, NTP must be configured on both the DOTS server and client to
ensure time synchronization. This method can protect DOTS server against
the replay attack effectively.</t>
<t>The following sections present the detailed description of all the
DOTS messages for each stage, and the relevant DOTS protocol
operations.</t>
<section title="Provisioning Stage">
<t>In the provisioning stage, DOTS client can be located in the
customer side, in the ISP controller or in the inter-domain
orchestrator (for the centralized architecture). In any cases, the
DOTS client is required to register to its peering DOTS server which
provides the intra/inter domain DDoS mitigation service to it, in
order to set up the DOTS protocol channel. More importantly, the
registration process also facilitates the auto-discovery and capacity
building between the DOTS client and server.</t>
<section title="Messages">
<t>In the provisioning stage, the messages of registration (DOTS
client to server), registration response (DOTS server to client),
registration cancelling (DOTS client to server) and registration
cancelling response (DOTS server to client) are required.</t>
<t>The HTTP POST method with the message body in JSON format is used
for the registration and registration response messages as
below:</t>
<figure align="left" title="">
<artwork> METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/registration
registration body:
{
"customer_name": string;
"ip_version": string;
"protected_zone": string;
"protected_port": string;
"protected_protocol": string;
"countermeasures": string;
"tunnel_information": string;
"next_hop": string;
"white_list": string;
"black_list": string;
}
registration response body:
{
"customer_name": string;
"customer_id": string;
"access_token": string;
"thresholds_bps": number;
"thresholds_pps": number;
"duration": number;
"capable_attack_type": string;
"registration_time": string;
"mitigation_status": string;
}
Registration body:
customer_name: The name of the customer (DOTS client);
ip_version: Current IP version. It can be "v4" or "v6";
protected_zone: Limit the address range of protection.
Especially it will be limited to the prefixes possessed by
the customer;
protected_port: Limit the port range of protection;
protected_protocol: Valid protected protocol values
include tcp and udp;
countermeasures: Some of the protection need mitigation
and others need Blackholing;
tunnel_information: The tunnel between the mitigation
provider's network and the customer's network.
Tunnel technologies such as GRE[RFC2784] can be used to
return normal traffic;
next_hop: The returning path to the customer's network;
white_list: The white-list information provided to the DOTS server;
black_list: The black-list information provided to the DOTS server.
registration response body:
customer_name: The name of the customer (DOTS client);
customer_id: The unique id of the customer (DOTS client);
access_token: Authentication token (e.g. pre-shared nonce);
thresholds_bps: If an attack volume is over this threshold,
the controller will reject the protection in order to
compliance with the negotiated contract;
thresholds_pps: If an attack volume is over this threshold,
the controller will reject the protection in order to
compliance with the negotiated contract;
duration: If an attack longed over this threshold,
the controller will reject the protection in order to
compliance with the negotiated contract;
capable_attack_type: Limit the protectable attack type;
registration_time: The time of registration;
mitigation_status: The status of current mitigation service
of the ISP. </artwork>
</figure>
<t>Similarly, another HTTP POST method with the message body in JSON
format is used for the registration cancelling and registration
cancelling response messages as below:</t>
<figure align="center" title="">
<artwork> METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/
registration_cancelling
registration cancelling body:
{
"customer_id": string;
"reasons": string;
}
registration cancelling response body:
{
"customer_id": string;
"result": string;
}
Registration cancelling body:
customer_id: The unique id of the customer (DOTS client);
reasons: The reasons why the DOTS client cancel the registration;
registration cancelling response body:
customer_id: The unique id of the customer (DOTS client);
result: The final result if the DOTS controller accepts
the registration cancelling request. </artwork>
</figure>
</section>
<section title="Operations">
<t>The main operations in the provisioning stage include:</t>
<t><list style="symbols">
<t>The customers (DOTS client) registers to ISP controller with
capability building including protection methods, process
capacity, ip address scope, deployment position, etc;</t>
<t>The DOTS client in ISP controller registers to the DOTS
server in inter-domain orchestrator (centralized architecture)
or other ISP controllers (distributed architecture) according to
inter-domain DDoS protection requirements;</t>
<t>The DOTS client can send the registration cancelling message
to the DOTS server for cancelling its DDoS protection
service.</t>
</list></t>
</section>
</section>
<section title="Signaling Stage">
<t>Once the DOTS client detects the attack to the customer service, a
mitigation request message is created and sent to the provisioned DOTS
server to call for the ISP DDoS protection service. The DOTS server
decides to protect the customer service based on the provisioned
information, and sends the mitigation response message to the DOTS
client. One ISP's DOTS server may resume sending the mitigation
request message to other ISPs' DOTS server to request the inter-domain
coordinated mitigation service while it notices it isn't able to
handle the attack by itself. Meanwhile, some other messages are
required for status exchange and statistics report. When the DOTS
server is informed from the mitigator that the attack is over, it
should notify the DOTS client to terminate the mitigation service.</t>
<section title="Messages">
<t>In the signaling stage, the messages of mitigation request (DOTS
client to server), mitigation response (DOTS server to client),
mitigation scope update (DOTS client to server), mitigation efficacy
notification (DOTS client to server), mitigation status request
(DOTS client to server), mitigation termination notification (DOTS
client to server), mitigation termination (DOTS client to server),
mitigation termination response (DOTS server to client) and
heartbeat (bidirectional message) are required.</t>
<t>Mitigation Request:</t>
<t>A HTTP POST method with the message body in JSON is used for the
mitigation request and response messages:</t>
<figure align="center" title="">
<artwork> METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/
mitigation_request
mitigation request body:
{
"access_token": string;
"traffic_protocol": string;
"source_port": string;
"destination_port": string;
"source_ip": string;
"destination_ip": string;
"time": string;
"dstip_current_bps": string;
"dstip_current_pps": string;
"dstip_peak_bps": string;
"dstip_peak_pps": string;
"dstip_average_bps": string;
"dstip_average_pps": string;
"bandwidth_threshold": string;
"type": string;
"severity": string;
"mitigation_action": string;
}
mitigation response body:
{
"access_token": string;
"mitigation_id": number;
"policy_id": number;
"description": string;
"start_time": string;
"current_bps": string;
"current_pps": string;
}
mitigation request body:
access_token: Authentication token (e.g. pre-shared nonce);
traffic_protocol: Valid protocol values include tcp and udp;
source_port: For TCP or UDP or SCTP or DCCP:
the source range of ports (e.g., 1024-65535);
destination_port: For TCP or UDP or SCTP or DCCP:
the destination range of ports (e.g., 1-443);
source_ip: The source IP addresses or prefixes;
destination_ip: The destination IP addresses or prefixes;
time: the time the event was triggered. The timestamp of
the record may be used to determine the resulting duration;
dstip_current_bps: The current volume of the attack in bps;
dstip_current_pps: The current volume of the attack in pps;
dstip_peak_bps: The peak volume of the attack in bps;
dstip_peak_pps: The peak volume of the attack in pps;
dstip_average_bps: The average volume of the attack in bps;
dstip_average_pps: The average volume of the attack in pps;
bandwidth_threshold: Event bandwidth as a % of overall
link capacity of DOTS client;
type: The attack type determined from the attack definitions;
severity: The severity of the attack;
mitigation_action: The mitigation actions customer anticipated,
such as: block, mitigation, etc.
mitigation response body:
access_token: Authentication token (e.g. pre-shared nonce);
mitigation_id: The unique mitigation event identifier;
policy_id: Protection policy identifier allocated in
the DOTS server;
description: Textual notes;
start_time: The time the mitigation was started.
current_bps: The current level of offramped traffic in bps;
current_pps: The current level of offramped traffic in pps.</artwork>
</figure>
<t>Mitigation Status Exchange:</t>
<t>A HTTP POST method with the message body in JSON is used for the
mitigation scope update and response message:</t>
<figure align="center" title="">
<artwork> METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/
mitigation_scope_update
mitigation scope update body:
{
TBD
}
mitigation scope update response body:
{
TBD
}
mitigation scope update body:
TBD
mitigation scope update response body:
TBD</artwork>
</figure>
<t>A HTTP POST method with the message body in JSON is used for the
mitigation efficacy notification message:</t>
<figure align="center" title="">
<artwork> METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/
mitigation_efficacy_notification
mitigation efficacy notification body:
{
TBD
}
mitigation efficacy notification response body:
{
TBD
}
mitigation efficacy notification body:
TBD
mitigation efficacy notification response body:
TBD</artwork>
</figure>
<t>A HTTP POST method with the message body in JSON is used for the
mitigation status request message:</t>
<figure align="center" title="">
<artwork> METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/
mitigation_status_request
mitigation status request body:
{
"mitigation_id": number;
"start_time": string;
"end_time": string;
}
mitigation status request response body:
{
"mitigation_id": number;
"mitigation_status": number;
"source_port": string;
"destination_port": string;
"source_ip": string;
"destination_ip": string;
"TCP_flag": string;
"start_time": string;
"end_time": string;
"error_num": number;
"routing_state": string;
"forwarded_total_packets": number;
"forwarded_total_bits": number;
"forwarded_peak_pps": number;
"forwarded_peak_bps": number;
"forwarded_average_pps": number;
"forwarded_average_bps": number;
"malicious_total_packets": number;
"malicious_total_bits": number;
"malicious_peak_pps": number;
"malicious_peak_bps": number;
"malicious_average_pps": number;
"malicious_average_bps": number;
"record_time": string;
}
mitigation status request body:
mitigation_id: The unique mitigation event identifier;
start_time: The requested start time for the duration
of the mitigation status message;
end_time: The requested end time for the duration
of the mitigation status message;
mitigation status request response body:
mitigation_id: The unique mitigation event identifier;
mitigation_status: Current mitigation status,
such as: pending, ongoing, done;
source_port: For TCP or UDP or SCTP or DCCP: the source
range of ports (e.g., 1024-65535) of the discarded traffic;
destination_port: For TCP or UDP or SCTP or DCCP: the
destination range of ports (e.g., 1-443) of the discarded traffic;
source_ip: The source IP addresses or prefixes of
the discarded traffic;
destination_ip: The destination IP addresses or prefixes
of the discarded traffic;
TCP_flag: TCP flag of the discarded traffic;
start_time: The start time for the duration of this mitigation
status message;
end_time: The end time for the duration of this mitigation
status message;
error_num: error message id;
routing_state: Current routing state;
forwarded_total_packets: The total number of packets forwarded;
forwarded_total_bits: The total bits for all the packets forwarded;
forwarded_peak_pps: The peak pps of the traffic forwarded;
forwarded_peak_bps: The peak bps of the traffic forwarded;
forwarded_average_pps: The average pps of the traffic forwarded;
forwarded_average_bps: The average bps of the traffic forwarded;
malicious_total_packets: The total number of malicious packets;
malicious_total_bits: The total bits of malicious packets;
malicious_peak_pps: The peak pps of the malicious traffic;
malicious_peak_bps: The peak bps of the malicious traffic;
malicious_average_pps: The average pps of the malicious traffic;
malicious_average_bps: The average bps of the malicious traffic;
record_time: The time the mitigation status message is created;
</artwork>
</figure>
<t>Mitigation Termination:</t>
<t>A HTTP POST method with the message body in JSON is used for the
mitigation termination notification message:</t>
<figure align="center" title="">
<artwork> METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/
mitigation_termination_notification
mitigation termination notification body:
{
"mitigation_id": number;
"reason": string;
}
mitigation termination notification body:
mitigation_id: The unique mitigation event identifier;
reason: The reason of notifying the DOTS client to
terminate the mitigation service;
</artwork>
</figure>
<t>A HTTP POST method with the message body in JSON is used for the
mitigation termination and response messages:</t>
<figure align="center" title="">
<artwork> METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/
mitigation_termination
mitigation termination body:
{
"mitigation_id": number;
}
mitigation termination response body:
{
"mitigation_id": number;
"start_time": string;
"end_time": string;
}
mitigation termination body:
mitigation_id: The unique mitigation event identifier;
mitigation termination response body:
mitigation_id: The unique mitigation event identifier;
start_time: The start time of the mitigation service;
end_time: The end time of the mitigation service.</artwork>
</figure>
<t>Heartbeat:</t>
<t>A HTTP POST method with the message body in JSON is used for the
heartbeat message:</t>
<figure align="center" title="">
<artwork> METHOD:POST - URL:{scheme}://{host}:{port}/dots/api/heartbeat
heartbeat body
{
}</artwork>
</figure>
</section>
<section title="Operations">
<t>The main operations in the signaling stage include:</t>
<t><list style="symbols">
<t>The customer (DOTS client) detects malicious attack, requests
mitigation service to its ISP controller (DOTS server);</t>
<t>ISP controller authenticates the customer and provides its
intra-domain mitigation service to customer;</t>
<t>When the ISP controller are mitigating the attack and finding
the attack volume exceeds it capacity, or the attack type is
unknown type, or its upstream link is congested, it should
request to the inter-domain orchestrator for inter-domain
cooperation;</t>
<t>The inter-domain orchestrator straightforwardly forward the
mitigation request to all other registered ISP controllers to
enable possible mitigation services. It is simple and for
avoiding privacy exposure of ISPs;</t>
<t>Working ISP controllers reports its statistics result by
mitigation status request message to the orchestrator for
counting purpose;</t>
<t>The customer can updates its mitigation scope to the ISP
controller. It also can notify its mitigation efficacy result to
the ISP controller;</t>
<t>When the ISP controller is informed from the mitigator that
the attack is over, it should notify the customer to terminate
the mitigation service;</t>
<t>The heartbeat message is exchange between the DOTS client and
DOTS server to check their respective status. If any side of the
channel fails to receive the heartbeat message, then it will
trigger an alert or further investigation into why they never
reached their destination.</t>
</list></t>
</section>
</section>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>No need to describe any request regarding number assignment.</t>
</section>
</middle>
<back>
<references title="Normative References">
<!--
[TEMPLATE TODO] rfc2119, 2578, 2579, and 2580 are required to support MIB
module boilerplate text.
&rfc2578;
&rfc2579;
&rfc2580;
-->
&rfc2119;
<reference anchor="RFC2784">
<front>
<title>Generic Routing Encapsulation (GRE), March 2000</title>
<author>
<organization>D. Farinacci., T. Li., S. Hanks., D. Meyer., and P.
Traina.</organization>
</author>
<date year=""/>
</front>
</reference>
<reference anchor="I-D.draft-ietf-dots-requirements">
<front>
<title>DDoS Open Threat Signaling Requirements,
draft-ietf-dots-requirements-00, October 2015</title>
<author>
<organization>A. Mortensen., R. Moskowitz., and T. Reddy.</organization>
</author>
<date year=""/>
</front>
</reference>
<reference anchor="I-D.draft-reddy-dots-transport">
<front>
<title>Co-operative DDoS Mitigation, October 2015</title>
<author>
<organization>T. Reddy., D. Wing., P. Patil., M. Geller., M.
Boucadair., and R. Moskowitz.</organization>
</author>
<date year=""/>
</front>
</reference>
</references>
<!--
<references title="Informative References">
&rfc2223;
&rfc3410;
&rfc2629;
&rfc4181;
</references>
-->
<!--
<references title="URL References">
<reference anchor="Cloudflare">
<front>
<title> https://blog.cloudflare.com/the-ddos-that-knocked-spamhaus-offline-and-ho/</title>
<author>
<organization>Cloudflare</organization>
</author>
<date year=""></date>
</front>
</reference>
</references>
-->
<!--
<reference anchor="ops">
<front>
<title>http://www.ops.ietf.org</title>
<author>
<organization>the IETF OPS Area</organization>
</author>
<date year=""></date>
</front>
</reference>
</references>
-->
<!--
<section title="Change Log ">
<t>Note to RFC Editor: if this document does not obsolete an existing RFC,
please remove this appendix before publication as an RFC.</t>
from draft 12 to draft 13
<t><list style="numbers">
<t></t>
</list></t>
</section>
-->
<!--
<section title="Open Issues">
<t>Note to RFC Editor: please remove this appendix before publication as an RFC.</t>
<t><list style="numbers">
<t>Contributor addresses need to be updated</t>
</list></t>
</section>
$Id: mib-doc-template.xml,v 1.5 2014/04/08 17:39:56 H73653 Exp $
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:40:07 |