Internet DRAFT - draft-h-dots-mitigation-offload-expansion
draft-h-dots-mitigation-offload-expansion
DOTS Y. Hayashi
Internet-Draft NTT
Intended status: Experimental K. Nishizuka
Expires: April 18, 2019 NTT Communications
October 15, 2018
DDoS mitigation offload usecase and YANG module expansion in signal
channel
draft-h-dots-mitigation-offload-expansion-00
Abstract
This document describes a DDoS Mitigation offload usecase and an
expansion of the YANG module in the DOTS signal channel for
mitigating DDoS attack traffic correctly with general routers or
switches. The proposed usecase and YANG module enhance DOTS
capability to send attacker information and enable service providers
to mitigate DDoS attack traffic by using general routers or switches
in their intra-domain NW.
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 https://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 April 18, 2019.
Copyright Notice
Copyright (c) 2018 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
(https://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
Hayashi & Nishizuka Expires April 18, 2019 [Page 1]
Internet-Draft draft-h-dots-mitigation-offload-expansion October 2018
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DDoS Mitigation Offload Usecase . . . . . . . . . . . . . . . 3
4. Expansion of DOTS Signal Channel . . . . . . . . . . . . . . 6
4.1. Expansion of YANG Module of DOTS Signal Channel . . . . . 6
4.2. Expansion of Mapping Parameters to CBOR . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Volume based distributed denial-of-service (DDoS) attacks such as DNS
amplification attacks are threats for internet service providers
because of their impact on network services. When such attacks
occur, service providers have to mitigate them immediately to protect
or recover their service. Therefore, for the service providers to
immediately protect their network services from DDoS attacks, DDoS
mitigation needs to be automated. To automate DDoS attack
mitigation, it is desirable that multi-vendor elements concerned with
DDoS attack detection, mitigation and so on collaborate.
On the other hand, the number of DDoS Mitigation Systems (DMS) that
can be deployed in a service providers network is limited due to
equipment cost. Thus, DMS's utilization rate can reach maximum
capacity soon when the volume of DDoS attacks is enormous. When the
rate reaches maximum capacity, the network needs to offload
mitigation action from the DMS to cost-effective network devices such
as switches and routers.
DDoS Open Threat Signaling (DOTS) is a protocol to standardize real-
time signaling, threat-handling requests, and data between the multi-
vendor elements [I-D.ietf-dots-use-cases]. This document describes
an automated DDoS Mitigation offload usecase inherited from a DOTS
usecase [I-D.ietf-dots-use-cases], which enables cost-effective DDoS
Mitigation in an intra-domain network. Furthermore, this document
describes an expansion of the YANG module in the DOTS signal channel
Hayashi & Nishizuka Expires April 18, 2019 [Page 2]
Internet-Draft draft-h-dots-mitigation-offload-expansion October 2018
[I-D.ietf-dots-signal-channel], which enables a service provider's
network to mitigate attack traffic correctly in the usecase.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119]
The readers should be familiar with the terms defined in
[I-D.ietf-dots-requirements] [I-D.ietf-dots-use-cases]
The terminology related to YANG data modules is defined in [RFC7950]
In addition, this document uses the terms defined below:
Mitigation offload: Getting rid of a DMS's mitigation action and
assigning the action to another entity when the utilization rate
of the DMS reaches an inacceptable level.
DDoS attackers: Devices that carry out DDoS attacks.
Utilization rate: A scale to measure load of an entity such as link
utilization rate and CPU utilization rate.
Top Talker: A top N list of attackers who attack the same target.
The list is ordered in terms of a two-tuple bandwidth such as bps
or pps.
3. DDoS Mitigation Offload Usecase
The purpose of this usecase is to protect intra-domain network from
volume-based DDoS attacks automatically, cost-effectively, and
vendor-independently. The usecase is inherited from the DDoS
Orchestration usecase in [I-D.ietf-dots-use-cases] and works on an
intra-domain network.
Figure 1 and Figure 2 show a component diagram and C-plane sequence
diagram of the usecase, respectively.
Hayashi & Nishizuka Expires April 18, 2019 [Page 3]
Internet-Draft draft-h-dots-mitigation-offload-expansion October 2018
+----------+
| network |C
| adminis |-+
| trator | |
+----------+ |
|
+----------+ | S+--------------+C S+-----------+
|telemetry/| +-->| |---->| DDoS |+
|monitoring|---->| Orchestrator |<----| mitigation||
|systems |C S| |S C| systems ||
+----------+ +--------------+ +-----------+|
| +----------+
| ex. BGP, BGP Flowspec
|
| +------------------+
+->| Routers/Switches |+
+------------------+|
+-----------------+
* C is for DOTS Client functionality
* S is for DOTS Server functionality
Figure 1: Component diagram of DDoS Mitigation offload usecase
This component diagram shown in Figure 1 differs from that of DDoS
Orchestration usecase in [I-D.ietf-dots-use-cases] in some respects.
First, the DDoS mitigation systems have a DOTS client function to
send mitigation requests to the orchestrator. Second, the
orchestrator sends a request to routers or switches to block attack
traffic.
Hayashi & Nishizuka Expires April 18, 2019 [Page 4]
Internet-Draft draft-h-dots-mitigation-offload-expansion October 2018
+-------+ +----------+ +------------+ +----------+ +----------+
|network| |telemetry/|+ | | |DDoS |+ |Routers |+
|adminis| |monitoring|| |Orchestrator| |Mitigation|| |Switches ||
|trator | |systems || | | |Systems || | ||
+-------+ +----------+| +------------+ +----------+| +---------+|
| +----------+ | +----------+ +---------+
| | DOTS: | | |
| | Mitigation | | |
| | Request | | |
| DOTS: |C------------>S| | |
| Mitigation | | ex. BGP: | |
| Request | | Redirect | |
|C------------------------->S| Attack Traffic | |
| | | to DMS | |
| | |---------------------------------->|
| | | | |
| | | DOTS: | |
| | | Mitigation Request | |
| | |S<-----------------C| |
| | | | |
| | | ex. BGP Flowspec | |
| | | Mitigate | |
| | | Attack Traffic | |
| | |---------------------------------->|
| | | | |
* C is for DOTS Client functionality
* S is for DOTS Server functionality
Figure 2: C-plane Sequence diagram of DDoS Mitigation offload usecase
In this usecase, when the telemetry/monitoring system detects a
volume-based DDoS attack in the network, it sends a DOTS mitigation
request to the orchestrator with target information such as target-
prefix. Then, the network administrator confirms the request and
sends a DOTS mitigation request to the orchestrator with the target
information.
After that, the orchestrator requests the routers or switches to
redirect attack traffic to the DMS by a configuration protocol such
as a routing protocol like BGP [RFC4271] on the basis of the target
information. Then the DMS analyzes attack traffic in detail and
detects not only target but also attacker information, such as top-
talker, and mitigates the attack traffic on the basis of the detected
information.
Hayashi & Nishizuka Expires April 18, 2019 [Page 5]
Internet-Draft draft-h-dots-mitigation-offload-expansion October 2018
When the volume-based attack becomes intense, DMS's utilization rate
can reach maximum capacity. Then the DMS sends a DOTS mitigation
request to the orchestrator as an offload request with the detection
information. After that, the orchestrator requests the routers or
switches to block attack traffic to the DMS by dissemination of flow
specification rules protocols such as BGP flowspec [RFC5575] on the
basis of the detected information.
4. Expansion of DOTS Signal Channel
It is desirable that the routers or switches mitigate attack traffic
correctly after the DMS sends a DOTS Mitigation Request as an offload
request in the usecase described in Section 3. For mitigating attack
traffic correctly, this document proposes expanding DOTS signal
channel [I-D.ietf-dots-signal-channel] so that it can send not only
target information but also representative attacker information such
as top talker. Note that it is difficult to send all attacker
information because there is an enormous number of attackers when a
volume-based DDoS attack occurs.
This section describes expansion of the YANG module [RFC7950] and
mapping parameters to CBOR [RFC7049] of the DOTS Signal Channel.
4.1. Expansion of YANG Module of DOTS Signal Channel
Figure 3 shows an expanded YANG Module of the DOTS Signal Channel.
Note that the "augment" statement allows a module to insert
additional nodes into existing data models. The module defines a new
grouping "attacker" and adds the grouping to an existing Signal
Channel module by using an "augment" statement.
module ietf-dots-signal-channel-mitigation-offload-expansion {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:
ietf-dots-signal-channel:mitigation-offload-expansion";
import ietf-dots-signal-channel {
prefix signal;
}
import ietf-inet-types {
prefix inet;
}
organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group";
Hayashi & Nishizuka Expires April 18, 2019 [Page 6]
Internet-Draft draft-h-dots-mitigation-offload-expansion October 2018
contact
"WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org>
Editor: Yuhei Hayashi
<mailto:hayashi.yuhei@lab.ntt.co.jp>
description
"This module contains the YANG definition for expanding signaling
messages exchanged between a DOTS client and a DOTS server.
Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
revision 2018-07-30 {
description
"Initial revision.";
reference
"RFC XXXX: ietf-dots-signal-channel";
}
/*
* Groupings
*/
grouping attacker {
description
"Specifies the attackers of the mitigation request.";
leaf-list attacker-top-talker-prefix {
type inet:ip-prefix;
description
"IPv4/IPv6 prefix identifying the top-talker in attackers.";
}
}
/*
* Main Container for DOTS Signal Channel Expansion
*/
augment "/signal:dots-signal/signal:scope/"{
uses attacker;
}
Hayashi & Nishizuka Expires April 18, 2019 [Page 7]
Internet-Draft draft-h-dots-mitigation-offload-expansion October 2018
}
Figure 3: Expansion of YANG Module of DOTS Signal Channel
4.2. Expansion of Mapping Parameters to CBOR
Figure 4 shows expansion of Mapping Parameters to CBOR [RFC7049]
related to Figure 3.
+----------------------+-------------+-----+---------------+--------+
| Parameter Name | YANG | CBOR| CBOR Major | JSON |
| | Type | Key | Type & | Type |
| | | | Information | |
+----------------------+-------------+-----+---------------+--------+
| ... | ... | ...| ... | ... |
| attacker-top-talker | leaf-list | XX | 4 array | Array |
| -prefix | inet: | | | |
| | ip-prefix | | 3 text string | String |
+----------------------+-------------+-----+---------------+--------+
Figure 4: Expansion of Mapping Parameters to CBOR
5. Security Considerations
TBD
6. IANA Considerations
TBD
7. Acknowledgement
TBD
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,
<https://www.rfc-editor.org/info/rfc2119>.
Hayashi & Nishizuka Expires April 18, 2019 [Page 8]
Internet-Draft draft-h-dots-mitigation-offload-expansion October 2018
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<https://www.rfc-editor.org/info/rfc5575>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
8.2. Informative References
[I-D.ietf-dots-requirements]
Mortensen, A., Moskowitz, R., and R. K, "Distributed
Denial of Service (DDoS) Open Threat Signaling
Requirements", draft-ietf-dots-requirements-15 (work in
progress), August 2018.
[I-D.ietf-dots-signal-channel]
K, R., Boucadair, M., Patil, P., Mortensen, A., and N.
Teague, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Signal Channel Specification", draft-
ietf-dots-signal-channel-25 (work in progress), September
2018.
[I-D.ietf-dots-use-cases]
Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
Open Threat Signaling", draft-ietf-dots-use-cases-16 (work
in progress), July 2018.
Authors' Addresses
Yuhei Hayashi
NTT
3-9-11, Midori-cho
Musashino-shi , Tokyo 180-8585
Japan
Email: hayashi.yuhei@lab.ntt.co.jp, yuuhei.hayashi@gmail.com
Hayashi & Nishizuka Expires April 18, 2019 [Page 9]
Internet-Draft draft-h-dots-mitigation-offload-expansion October 2018
Kaname Nishizuka
NTT Communications
GranPark 16F 3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
Email: kaname@nttv6.jp
Hayashi & Nishizuka Expires April 18, 2019 [Page 10]
