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.


Table of Contents

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:

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.

3. Terminology and Abbreviations

The terminology and abbreviations used in this document are defined in this section.

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:

Analysis and Statistics:

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:

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:

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.

Author's Address

Yang Boyle China Mobile China EMail: boyxd@hotmail.com