DOTS
Internet-Draft K. Li
Intended status: Proposed Standard H. Zhou
Z. Tu
F. Liu
W. Wang
Document: draft-li-dots-knowledge-trans-01.txt Beijing Jiaotong
University
Expires: July 2022 January 2022
Knowledge Transmission Using Distributed Denial-of-Service Open
Threat Signaling (DOTS) Data Channel
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."
Copyright Notice
Copyright (c) 2021 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.
Abstract
Li, et al. Expires - July 2022 [Page 1]
DOTS Knowledge Trans January 2022
The document specifies new DOTS data channel configuration parameters
that customize the DDoS knowledge transmission configuration between
distributed knowledge bases. These options enable assist the
distributed knowledge base to share attack knowledge in different
fields and actively adapt to dynamically changing DDoS attacks.
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................3
3. DOTS Knowledge Transmission Architecture.......................3
4. DOTS Knowledge Transmission YANG Module........................5
4.1 Generic Tree Structure.....................................5
4.2 YANG Module................................................6
5. Managing DOTS Knowledge Transmission..........................10
6. IANA Considerations...........................................11
7. Security Considerations.......................................11
8. References....................................................11
8.1 Normative References......................................11
8.2 Informative References....................................12
Acknowledgments..................................................12
Author's Addresses...............................................12
1. Introduction
To detect the threat of DDoS attacks, various security organizations
have designed a series of network security datasets by collecting
various complex simulations or DDoS attacks in actual network
environments, aiming to reflect the modern complex and changeable
DDoS attack environment by designing a comprehensive data set
containing normal and abnormal behavior.
As a new knowledge representation method, the knowledge graph
represents the relationship between entities in the form of graphs,
and is essentially a semantic network that reveals the relationships
between entities. Knowledge graph technology can standardize and
integrate DDoS attack-related intelligence, generate DDoS attack
knowledge and store it in the network security malicious behavior
knowledge base to solve the problem that multi-source heterogeneous
data is difficult to share and reuse.
DOTS data channel can exchange data between DOTS agents, coordinate
multiple DOTS servers and DOTS clients, and perform tasks such as
creating resource aliases and managing filtering strategies. The DOTS
data channel specification [RFC8783] defines the data channel
hierarchical structure, the YANG data model and the basic functions
of the data channel.
Li, et al. Expires - July 2022 [Page 2]
DOTS Knowledge Trans January 2022
DOTS data channel is used for reliable data interaction between DOTS
client and server, but the existing data channel lacks a knowledge
transmission structure and corresponding YANG data model, and cannot
realize the transmission of DDoS attack knowledge stored in a
knowledge graph structure. Therefore, it is difficult to meet the
dynamically changing form of DDoS attacks.
This document defines new DOTS data channel attributes. It mainly
builds a new YANG data model for distributed scenarios that need to
constantly update and synchronize the content of the knowledge base,
including a general tree structure and YANG data modules, aiming to
customize the DDoS knowledge transmission configuration between
distributed knowledge bases.
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Readers should be familiar with the terms and concepts defined in
[RFC8612] [RFC8783] and [RFC8811].
3. DOTS Knowledge Transmission Architecture
The basic DOTS knowledge transmission architecture is illustrated in
Figure 1:
+------------+ +--------------+ +-------------+
| | | DOTSG | | |
| +--------+ | +--------------+ | +---------+ |
| |DDoS | | | Knowledge | | |knowledge| |
| |Target-1| | | Collection | +--> |base-1 | |
| +--------+ | +-------+------+ | | +---------+ |
| | | | | | | |
DDoS | +--------+ | +-------v------+ | | +---------+ |
Attack | |DDoS | | | Knowledge | | | |knowledge| |
------>| |Target-2| | | Transmission | +--> |base-2 | |
| +--------+ | +------+-+-----+ | | +---------+ |
| ...... | | | | | | | ...... |
| +--------+ | | | | | | | +---------+ |
| |DDoS | | | | | | | | |knowledge| |
| |Target-n| | | | | | +--> |base-n | |
| +--------+ | | Data Channel | | | +---------+ |
Li, et al. Expires - July 2022 [Page 3]
DOTS Knowledge Trans January 2022
| C <--+--------------+--+--> S |
+------------+ +--------------+ +-------------+
* C is for DOTS client functionality
* S is for DOTS server functionality
Figure 1: Basic DOTS Knowledge Transmission Architecture
A simple example of the DOTS knowledge transmission architecture may
be a DDoS attack-oriented network security knowledge base deployed on
a large scale in the form of distributed nodes as the server, and the
attacked target as the client. The host suspects that it has been
attacked by a DDoS, and obtains information about the DDoS attack
based on the DOTS client and forwards it via the DOTS gateway. The
DOTS gateway matches DDoS attack traffic and converts it into attack
knowledge and stores it in a nearby network security knowledge base.
After a certain period of time, distributed nodes transmit new
knowledge through data channels to achieve knowledge synchronization.
Therefore, they aim to share attack knowledge in different domains
and actively adapt to dynamically changing DDoS attacks.
In some cases, part of the domain is always in a state of being
unattended, and another part of the domain may be frequently
subjected to DDoS attacks, so new knowledge of DDoS attacks will be
continuously introduced. The administrator needs to configure a
reasonable update cycle according to the attack situation in the
control domain. For domains with few attack records, the update
period should be appropriately extended to reduce bandwidth
consumption. For domains with high security requirements, the number
of requests should be increased and DOTS data channels should be
established with more domains to obtain more comprehensive knowledge
of DDoS attacks.
This document augments the "ietf-dots-data-channel" (dots-data) DOTS
data YANG module defined in [RFC8783] with these additional
attributes that can be negotiated between DOTS servers to realize the
secure and periodic transmission of DDoS attack knowledge:
related-time: This attribute contains the creation-time and merge-
time of DDoS attack knowledge. The default value of this attribute is
'now-date' obtained from the system.
This is an optional attribute.
label: This attribute represents the type of network security
knowledge graph currently transmitted. The default value of this
attribute is '0'.
This is an optional attribute.
Li, et al. Expires - July 2022 [Page 4]
DOTS Knowledge Trans January 2022
knowledge-base-name: This attribute represents the name of the
currently transmitted network security knowledge graph. The default
value of this attribute is 'none'.
This is an optional attribute.
entities: This attribute contains all node information in the
knowledge graph. Optional under this attribute include 'type', 'id',
'labels', and 'properties'.
This is an optional attribute.
relationship: This attribute contains all the node relationships in
the knowledge graph. Optional under this attribute include 'id',
'type', 'label', 'properties', 'start', and 'end'.
This is an optional attribute.
4. DOTS Knowledge Transmission YANG Module
4.1 Generic Tree Structure
This document defines the YANG module "li-dots-knowledge-trans"
(Section 3), which has the following tree structure:
module: li-dots-knowledge-trans
+--rw dots-data
+--rw dots-client* [cuid]
| ...
+--ro capabilities
| ...
+--rw knowledge-trans
+--rw related-time
| +--rw creation-time string
| +--rw merge-time string
+--rw label
+--rw knowledge-base-name string
+--rw model-param string
+--rw eneities
| +--rw type string
| +--rw id uint32
| +--rw labels string
| +--rw properties
| +-- rw name string
| +-- rw establishdate uint8
+--rw relationship
+--rw id uint32
+--rw type string
+--rw label string
Li, et al. Expires - July 2022 [Page 5]
DOTS Knowledge Trans January 2022
+--rw properties string
+--rw start
| +--rw id uint32
| +--rw labels string
+--rw end
+--rw id uint32
+--rw labels1 string
Figure 2: DOTS Knowledge Transmission Subtree
Based on the above-mentioned yang module structure, a method is
provided for the distributed network security knowledge base to
periodically update and synchronize the new DDoS attack knowledge in
each domain, so as to more effectively deal with the ever-changing
DDoS attack types.
4.2 YANG Module
This module uses the common YANG types defined in [RFC6991] and types
defined in [RFC8519].
<CODE BEGINS> file "li-dots-knowledge-trans@2021-08-06.yang"
module li-dots-knowledge-trans {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:li-dots-knowledge-trans";
prefix dots-knowledge;
import ietf-dots-data-channel {
prefix dots-data;
reference
"RFC 8783: Distributed Denial-of-Service Open Threat
Signaling (DOTS) Data Channel Specification";
}
organization
"IETF DDoS Open Threat Signaling (DOTS) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/dots/>
WG List: <mailto:dots@ietf.org>
Author: Kun Li
<mailto:19111021@bjtu.edu.cn>;
Author: Huachun Zhou
<mailto:hchzhou@bjtu.edu.cn>";
Author: Zhe Tu
<mailto:19111038@bjtu.edu.cn>;
Li, et al. Expires - July 2022 [Page 6]
DOTS Knowledge Trans January 2022
Author: Feiyang Liu
<mailto:19120077@bjtu.edu.cn>;
Author: Weilin Wang
<mailto:19111021@bjtu.edu.cn>;
description
"This module contains YANG definitions for the configuration
of parameters that can be negotiated between DOTS servers to
realize the secure and periodic transmission of DDoS
attack knowledge.
Copyright (c) 2021 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 8783; see
the RFC itself for full legal notices.";
revision 2021-08-06 {
description
"Initial revision.";
reference
"RFC 8783: Knowledge Transmission Using Distributed
Denial-of-Service Open Threat Signaling
(DOTS) Data Channel";
}
grouping knowledge-trans {
description
"Top-level grouping for knowledge transmission.";
container related-time {
description
"Relevant time for knowledge transmission.";
leaf creation-time {
type string
description
"Knowledge graph establishment time.";
}
leaf merge-time {
type string
description
"Knowledge synchronization initiation time.";
Li, et al. Expires - July 2022 [Page 7]
DOTS Knowledge Trans January 2022
}
}
leaf label {
type string
description
"Type of network security knowledge graph currently
transmitted.";
}
leaf knowledge-base-name {
type string
description
"Name of network security knowledge graph currently
transmitted.";
}
leaf model-param {
type string
description
"Attached machine learning h5 model parameters.";
}
list eneities {
key id;
description
"Entity contains all node information in the knowledge
graph.";
leaf id {
type uint32
description
"Id of the new node.";
}
leaf type {
type string
description
"Type of the new node.";
}
leaf labels {
type string
description
"Label of the new node.";
}
container properties {
description
"Properties of the new node.";
leaf name {
type string
description
"Property name of the new node.";
}
leaf establishdate {
type uint8
description
"Node creation time.";
}
}
}
Li, et al. Expires - July 2022 [Page 8]
DOTS Knowledge Trans January 2022
list relationship {
key id;
description
"Relationship contains all the node relationships in the
knowledge graph.";
leaf id {
type uint32
description
"Id of the new relationship.";
}
leaf type {
type string
description
"Type of the new relationship.";
}
leaf labels {
type string
description
"Label of the new relationship.";
}
leaf properties {
type string
description
"Properties of the new relationship.";
}
container start {
description
"Starting node of the new relationship.";
leaf id {
type uint32
description
"Id of starting node.";
}
leaf labels {
type string
description
"Label of starting node.";
}
}
container end {
description
"Ending node of the new relationship.";
leaf id {
type uint32
description
"Id of ending node.";
}
leaf labels {
type string
Li, et al. Expires - July 2022 [Page 9]
DOTS Knowledge Trans January 2022
description
"Label of ending node.";
}
}
}
}
<CODE ENDS>
5. Managing DOTS Knowledge Transmission
A POST request is used by a DOTS client to periodically synchronize
knowledge about DDoS attacks. This knowledge can be used to guide
subsequent mitigation measures to more effectively deal with multiple
types of DDoS attacks. An example of a request for periodic
transmission of DDoS attack knowledge is shown in Figure 3.
POST /restconf/data/ietf-dots-data-channel:dots-data\
/dots-client=cuid HTTP/1.1
Host: {host}: {port}
Content-Type: application/yang-data+json
{
"ietf-dots-data-channel:knowledge-trans": {
[
{
"type": "node",
"id": 0,
"labels": ["Slow-DDoS"],
"properties": {
"name": "Shrew",
"establishdate": 20210806094618
},
{
"type": "node",
"id": 1,
"labels": ["Application-layer-DDoS"],
"properties": {
"name": "Http-get",
"establishdate": 20210806100512
},
},
{
"id": 0,
"type": "relationship",
"label": "Related-to",
"properties": {}
"start": {
"id": 0,
Li, et al. Expires - July 2022 [Page 10]
DOTS Knowledge Trans January 2022
"labels": "Slow-DDoS"
}
"end": {
"id": 1,
"labels": "Application-layer-DDoS"
}
}
]
}
}
Figure 3: An Example of DOTS Request Knowledge Update Process
A DOTS client MUST use the POST request to request to update the
knowledge, otherwise the server MUST respond with a "404 Not Found"
status-line.
6. IANA Considerations
This document has no IANA actions.
7. Security Considerations
The security considerations for the DOTS data channel protocol are
discussed in Section 10 of [RFC8783].
This document defines YANG data structures that are meant to be used
as an abstract representation in DOTS data channel messages. As such,
the "li-dots-knowledge-trans" module does not introduce any new
vulnerabilities beyond those specified above.
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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed
Denial-of-Service Open Threat Signaling (DOTS) Data Channel
Specification", RFC 8783, DOI 10.17487/RFC8783, May 2020,
<https://www.rfc-editor.org/info/rfc8783>.
Li, et al. Expires - July 2022 [Page 11]
DOTS Knowledge Trans January 2022
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991,
DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor
.org/info/rfc6991>.
[RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair,
"YANG Data Model for Network Access Control Lists (ACLs)",
RFC 8519, DOI 10.17487/RFC8519, March 2019, <https://www.
rfc-editor.org/info/rfc8519>.
8.2 Informative References
[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
Threat Signaling (DOTS) Requirements", RFC 8612,
DOI 10.17487/RFC8612, May 2019, <https://www.rfc-
editor.org/info/rfc8612>.
[RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., Teague,
N., and R. Compton, "DDoS Open Threat Signaling (DOTS)
Architecture", RFC 8811, DOI 10.17487/RFC8811,
August 2020, <https://www.rfc-editor.org/info/rfc8811>.
Acknowledgments
TBC
Author's Addresses
Kun Li
Beijing Jiaotong University
Beijing
Phone: <86-15652992293>
Email: 19111021@bjtu.edu.cn
Huachun Zhou
Beijing Jiaotong University
Beijing
Phone: <86-13718168186>
Email: hchzhou@bjtu.edu.cn
Zhe Tu
Beijing Jiaotong University
Beijing
Phone: <86-13146050755>
Email: 19111038@bjtu.edu.cn
Feiyang Liu
Beijing Jiaotong University
Li, et al. Expires - July 2022 [Page 12]
DOTS Knowledge Trans January 2022
Beijing
Phone: <86-18813006511>
Email: 19120077@bjtu.edu.cn
Weilin Wang
Beijing Jiaotong University
Beijing
Phone: <86-15910887582>
Email: 20120122@bjtu.edu.cn
Li, et al. Expires - July 2022 [Page 13]