Internet DRAFT - draft-yang-dos-type-for-dots
draft-yang-dos-type-for-dots
DOTS B. Yang
Internet-Draft China Mobile
Intended status: Informational July 1, 2018
Expires: January 2, 2019
Introduce DoS type for DOTS signaling
draft-yang-dos-type-for-dots-00
Abstract
The purpose of this document is to analyze the usage of DoS type in
DOTS signaling, provide a classification framework for DoS type, and
give suggestions on introducing DoS-Type into DOTS signaling.
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 January 2, 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
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.
Yang Expires January 2, 2019 [Page 1]
Internet-Draft DoS Type for DOTS July 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
4. Usage of DoS-type in DOTS signaling . . . . . . . . . . . . . 3
5. Defination of DoS-type . . . . . . . . . . . . . . . . . . . 4
6. Suggetion on adding DoS-type into DOTS signaling message . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
DOTS defines a method of coordinating defensive measures among
willing peers to mitigate attacks quickly and efficiently, DOTS
signaling enables hybrid attack coordination between DOTS client that
talks with attack target and DOTS server that talks with Mitigators
[draft-ietf-dots-architecture]. But in [draft-ietf-dots-signal-
channel] the YANG module "ietf-dots-signal-channel" did not include
the DoS-Type field, which is important for the DDoS mitigation as
well as network operations.
DoS attacks can be genrated using different mechanism, such as ICMP
Flood, TCP Flag Misuse, DNS replay. Here list some DoS that occurs
in different layer:
o Network layer: ICMP
o Transport layer: TCP, UDP
o Application layer: HTTP, SIP, DNS, NTP, ...
Different DDoS mechanism may requires different mitigation method.
but currently, different vendors have different view point on
classifying DoS, which leads to interoperating and interworking
issues.
This document is to analyze the usage of DoS type in DOTS signaling,
provide a classification framework for DoS type, and give suggestions
on introducing DoS-Type into DOTS signaling.
2. Requirements Language
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 RFC 2119 [RFC2119].
Yang Expires January 2, 2019 [Page 2]
Internet-Draft DoS Type for DOTS July 2018
3. Terminology and Abbreviations
The terminology and abbreviations used in this document are defined
in this section.
o DDoS: A distributed denial-of-service attack, in which traffic
originating from multiple sources is directed at a target on a
network. DDoS attacks are intended to cause a negative impact on
the availability and/or other functionality of an attack target.
Denial-of-service considerations are discussed in detail in [RFC
4732].
o DDoS attack target: A network connected entity with a finite set
of resources, such as network bandwidth, memory or CPU, that is
the target of a DDoS attack. Potential targets include (but are
not limited to) network elements, network links, servers, and
services.
o Mitigator: An entity, typically a network element, capable of
performing mitigation of a detected or reported DDoS attack. The
means by which this entity performs these mitigations and how they
are requested of it are out of scope. The mitigator and DOTS
server receiving a mitigation request are assumed to belong to the
same administrative entity.
4. Usage of DoS-type in DOTS signaling
Various DoS-type means different attack method, may need different
mitiagtion method also. If DoS-type is included in to the DOTS
signalling message, it will helps:
o Message routing:
o
* DOTS Client: shall be able to make decision on which server to
send the DOTS mitigation requests, in the one-Client multiple
Server connection topology, according to predefined server
capability configurations.
* DOTS Server: considering there are different kind of
mitigators, each kind provides some types of DoS mitigation
service accrodingly, the DOTS server shall need to know which
mitigator is suitable for ceritain DoS attack. This is very
common situation when the mitigator is deployed in a
virtualized resource pool.
Analysis and Statistics:
Yang Expires January 2, 2019 [Page 3]
Internet-Draft DoS Type for DOTS July 2018
Both the DOTS gateway and DOTS server shall need to analysis and/or
statistic the amount DoS attack and mitigation informations for
operational purpose.
5. Defination of DoS-type
As we metioned different vendors have different view point on
classifying DoS, New DoS types are constantly emerging, we can not
can't enumerat all the DOS types exhaustively. But we can define an
open framework, that includes all common DoS types, while allows easy
extension.
The DoS type framework is classfied into different layers, i.e.,
Network Layer, Transport Layer, Application Layer. Listed as
follows:
Yang Expires January 2, 2019 [Page 4]
Internet-Draft DoS Type for DOTS July 2018
Layer Protocols Attack-Type Attack-Subtype
--------------------------------------------------------
Network
ICMP ICMP-Flood
ICMP-Fragment
Transport
UDP UDP-Flood
UDP-Fragment
TCP ACK-Flood
SYN-Flood
FIN_RST-Flood
TCP-Flag-Misuse
TCP-Connection-Flood
TCP-Fragment
Application
HTTP HTTP-Flood Get_Post-Flood
CC-Attack
HTTP-Slow-Attack Slow-POST
Slow-Headers
HTTPS HTTPS-Flood
SIP SIP-Flood
DNS DNS-Query-Flood
DNS-Reply-Flood
DNS-Amplification
SSDP SSDP-Amplification
NTP NTP-Amplification
Chargen Chargen-Amplification
SNMP SNMP-Amplification
Extended
'string' 'user-defined-type-string'
Table 1. DoS-Type defination framework.
Figure 1
Accroding to Table 1:
o This framework shall allow service providers, vendors to define
they extended DoS type.
o The representation of each DoS type shall use a string type, and
take the form of "Attack-type.Attack-Subtype".
Yang Expires January 2, 2019 [Page 5]
Internet-Draft DoS Type for DOTS July 2018
6. Suggetion on adding DoS-type into DOTS signaling message
Accroding to the [draft-ietf-dots-signal-channel] the YANG module
"ietf-dots-signal-channel" a DoS-Type field shall be added as
follows:
+--rw (message-type)?
+--:(mitigation-scope)
| +--rw scope* [cuid mid]
| +--rw cdid? string
| +--rw cuid string
| +--rw mid uint32
| +--rw target-prefix* inet:ip-prefix
| +--rw target-port-range* [lower-port upper-port]
| | +--rw lower-port inet:port-number
| | +--rw upper-port inet:port-number
| +--rw target-protocol* uint8
| +--rw target-fqdn* inet:domain-name
| +--rw target-uri* inet:uri
| +--rw DoS-Type* string
| +--rw alias-name* string
| +--...
Figure 2
7. 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>.
Author's Address
Yang Boyle
China Mobile
China
Email: boyxd@hotmail.com
Yang Expires January 2, 2019 [Page 6]
