idnits 2.17.00 (12 Aug 2021) /tmp/idnits35360/draft-li-dots-knowledge-trans-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 238 has weird spacing: '...nd-time strin...' == Line 249 has weird spacing: '...ishdate uin...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 2022) is 88 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DOTS 3 Internet-Draft K. Li 5 H. Zhou 6 Z. Tu 7 F. Liu 8 W. Wang 9 Document: draft-li-dots-knowledge-trans-02.txt Beijing Jiaotong 10 University 11 Expires: August 2022 February 2022 13 Knowledge Transmission Using Distributed Denial-of-Service Open 14 Threat Signaling (DOTS) Data Channel 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute working 23 documents as Internet-Drafts. The list of current Internet-Drafts is 24 at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 Copyright Notice 33 Copyright (c) 2021 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (https://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents carefully, 40 as they describe your rights and restrictions with respect to this 41 document. Code Components extracted from this document must include 42 Simplified BSD License text as described in Section 4.e of the Trust 43 Legal Provisions and are provided without warranty as described in 44 the Simplified BSD License. 46 Abstract 47 The document specifies new DOTS data channel configuration parameters 48 that customize the DDoS knowledge transmission configuration between 49 distributed knowledge bases. These options enable assist the 50 distributed knowledge base to share attack knowledge in different 51 fields and actively adapt to dynamically changing DDoS attacks. 53 Table of Contents 55 1. Introduction...................................................2 56 2. Terminology....................................................3 57 3. DOTS Knowledge Transmission Architecture.......................3 58 4. DOTS Knowledge Transmission YANG Module........................5 59 4.1 Generic Tree Structure.....................................5 60 4.2 YANG Module................................................6 61 5. Managing DOTS Knowledge Transmission..........................10 62 6. IANA Considerations...........................................11 63 7. Security Considerations.......................................11 64 8. References....................................................12 65 8.1 Normative References......................................12 66 8.2 Informative References....................................12 67 Acknowledgments..................................................13 68 Author's Addresses...............................................13 70 1. Introduction 72 To detect DDoS attacks, various security organizations have designed 73 series of network security datasets by conducting various simulations 74 or collecting data related to DDoS attacks in actual network 75 environments. Such an effort is meant aiming to reflect the recent 76 trends of DDoS attacks that are more sophisticated and dynamic by 77 designing a comprehensive data set containing normal and abnormal 78 behavior. 80 As a new knowledge representation method, the knowledge graph [KG] 81 represents the relationship between entities in the form of graphs, 82 and is essentially a semantic network that reveals the relationships 83 between entities. Knowledge graph technology can standardize and 84 integrate DDoS attack-related intelligence, generate DDoS attack 85 knowledge and store it in the network security malicious behavior 86 knowledge base to solve the problem that multi-source heterogeneous 87 data is difficult to share and reuse. 89 The DOTS data channel [RFC8783] is used to exchange bulk data between 90 DOTS agents, coordinate multiple DOTS servers and DOTS clients, and 91 perform tasks such as creating resource aliases and managing 92 filtering rules. [RFC8783] specifies the YANG data model and the 93 basic data channel functions. 95 The knowledge base can describe the malicious behavior of DDoS 96 attacks from multiple dimensions, and contains a large number of DDoS 97 attack-related data and knowledge graph structures, thereby assisting 98 the DOTS server to issue mitigation measures to defend against DDoS 99 attack traffic. In order to ensure the timeliness of the knowledge 100 base, it is necessary to continuously transmit new data for the 101 knowledge base and ensure the sharing and synchronization of 102 knowledge among the distributed knowledge bases. The data channel as 103 specified in [RFC8783] lacks a knowledge transmission structure. 104 Therefore, it is difficult to meet the dynamically changing form of 105 DDoS attacks. 107 This document defines new DOTS data channel attributes. It mainly 108 builds a new YANG data model for distributed scenarios that need to 109 constantly update and synchronize the content of the knowledge base, 110 including a general tree structure and YANG data modules, aiming to 111 customize the DDoS knowledge transmission configuration between 112 distributed knowledge bases. 114 2.Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 Readers should be familiar with the terms and concepts defined in 123 [RFC8612] [RFC8783] and [RFC8811]. 125 3.DOTS Knowledge Transmission Architecture 127 A complete example of the DOTS knowledge transmission architecture 128 may be a DDoS attack-oriented network security knowledge base 129 deployed on a large scale in the form of distributed nodes as the 130 server, and the attacked target as the client. The host suspects that 131 it is under a DDoS attack based on the detection results of the 132 third-party intrusion detection model. It obtains DDoS attack 133 information according to the traffic feature extraction tool deployed 134 on the DOTS client, and forwards it through the access gateway. The 135 access gateway matches DDoS attack traffic and converts it into 136 attack knowledge and stores it in a nearby network security knowledge 137 base. Specifically, each access gateway stores a mapping table 138 between the knowledge base and the arrival delay. The access gateway 139 will transmit the attack knowledge to the knowledge base with the 140 lowest transmission delay at the current moment. After DDoS attacks 141 are mitigated, distributed nodes transmit new knowledge through data 142 channels to achieve knowledge synchronization. Therefore, they aim to 143 share attack knowledge in different domains and actively adapt to 144 dynamically changing DDoS attacks. 146 The basic DOTS knowledge transmission architecture is illustrated in 147 Figure 1: 149 +------------+ +--------------+ +-------------+ 150 | | |Access Gateway| | | 151 | +--------+ | +--------------+ | +---------+ | 152 | |DDoS | | | Knowledge | | |knowledge| | 153 | |Target-1| | | Collection | +--> |base-1 | | 154 | +--------+ | +-------+------+ | | +---------+ | 155 | | | | | | | | 156 DDoS | +--------+ | +-------v------+ | | +---------+ | 157 Attack | |DDoS | | | Knowledge | | | |knowledge| | 158 ------>| |Target-2| | | Transmission | +--> |base-2 | | 159 | +--------+ | +------+-+-----+ | | +---------+ | 160 | ...... | | | | | | | ...... | 161 | +--------+ | | | | | | | +---------+ | 162 | |DDoS | | | | | | | | |knowledge| | 163 | |Target-n| | | | | | +--> |base-n | | 164 | +--------+ | | Data Channel | | | +---------+ | 165 | C <--+--------------+--+--> S | 166 +------------+ +--------------+ +-------------+ 167 * C is for DOTS client 168 * S is for DOTS server 169 Figure 1: Basic DOTS Knowledge Transmission Architecture 171 In some cases, part of the domain has never been attacked, and 172 another part of the domain may be frequently subjected to DDoS 173 attacks, so new knowledge of DDoS attacks will be continuously 174 introduced. The administrator needs to configure a corresponding 175 update cycle according to the attack situation in the DOTS client 176 domain. Specifically, for domains with few attack records, the update 177 period should be appropriately extended to reduce bandwidth 178 consumption. For domains with high security requirements, such as 179 enterprise networks, the number of requests should be increased and 180 DOTS data channels should be established with more domains with 181 similar security requirements to obtain more comprehensive knowledge 182 of DDoS attacks. 184 This document augments the "ietf-dots-data-channel" (dots-data) DOTS 185 data YANG module defined in [RFC8783] with the following additional 186 attributes that can be shared between DOTS servers to realize the 187 secure and periodic transmission of DDoS attack knowledge: 189 related-time: This attribute contains the creation-time and merge- 190 time of DDoS attack knowledge. The default value of this attribute is 191 'now-date' obtained from the system. 193 This is an optional attribute. 195 label: This attribute represents the type of network security 196 knowledge graph currently transmitted. Different types of graphs are 197 responsible for different security functions. Among them, the graph 198 type used to maintain traffic characteristics is set to '0'. The 199 graph type used to describe topological relationships is set to '1'. 200 The graph type used to store the detection results corresponding to 201 the flow is set to '2'. The default value of this attribute is '0'. 203 This is an optional attribute. 205 knowledge-base: This attribute represents the name of the currently 206 transmitted network security knowledge graph. The default value of 207 this attribute is 'none'. 209 This is an optional attribute. 211 entities: This attribute contains all node information in the 212 knowledge graph. Optional under this attribute include 'type', 'id', 213 'labels', and 'properties'. 215 This is an optional attribute. 217 relationship: This attribute contains all the node relationships in 218 the knowledge graph. Optional under this attribute include 'id', 219 'type', 'label', 'properties', 'start', and 'end'. 221 This is an optional attribute. 223 4. DOTS Knowledge Transmission YANG Module 225 4.1 Generic Tree Structure 227 This document defines the YANG module "li-dots-knowledge-trans" 228 (Section 3), which has the following tree structure: 230 module: li-dots-knowledge-trans 231 +--rw dots-data 232 +--rw dots-client* [cuid] 233 | ... 234 +--ro capabilities 235 | ... 236 +-- knowledge-trans 237 +-- related-time 238 | +--rw creation-date-and-time string 239 | +--rw merge-date-and-time string 240 +--rw label 241 +--rw knowledge-base string 242 +--rw model-param string 243 +-- entities 244 | +--rw type string 245 | +--rw id uint32 246 | +--rw labels string 247 | +-- properties 248 | +-- rw name string 249 | +-- rw establishdate uint8 250 +-- relationship 251 +--rw id uint32 252 +--rw type string 253 +--rw label string 254 +--rw properties string 255 +-- start 256 | +--rw id uint32 257 | +--rw labels string 258 +-- end 259 +--rw id uint32 260 +--rw labels1 string 261 Figure 2: DOTS Knowledge Transmission Subtree 263 Based on the above-mentioned yang module structure, a method is 264 provided for the distributed network security knowledge base to 265 periodically update and synchronize the new DDoS attack knowledge in 266 each domain, so as to more effectively deal with the ever-changing 267 DDoS attack types. 269 4.2 YANG Module 271 This module uses the common YANG types defined in [RFC6991] and types 272 defined in [RFC8519]. 274 file "li-dots-knowledge-trans@2021-08-06.yang" 275 module li-dots-knowledge-trans { 276 yang-version 1.1; 277 namespace "urn:ietf:params:xml:ns:yang:li-dots-knowledge-trans"; 278 prefix dots-knowledge; 280 import ietf-dots-data-channel { 281 prefix dots-data; 282 reference 283 "RFC 8783: Distributed Denial-of-Service Open Threat 284 Signaling (DOTS) Data Channel Specification"; 286 } 288 organization 289 "IETF DDoS Open Threat Signaling (DOTS) Working Group"; 290 contact 291 "WG Web: 292 WG List: 294 Author: Kun Li 295 ; 297 Author: Huachun Zhou 298 "; 300 Author: Zhe Tu 301 ; 303 Author: Feiyang Liu 304 ; 306 Author: Weilin Wang 307 ; 309 description 310 "This module contains YANG definitions for the configuration 311 of parameters that can be negotiated between DOTS servers to 312 realize the secure and periodic transmission of DDoS 313 attack knowledge. 315 Copyright (c) 2021 IETF Trust and the persons identified as 316 authors of the code. All rights reserved. 318 Redistribution and use in source and binary forms, with or 319 without modification, is permitted pursuant to, and subject 320 to the license terms contained in, the Simplified BSD License 321 set forth in Section 4.c of the IETF Trust's Legal Provisions 322 Relating to IETF Documents 323 (http://trustee.ietf.org/license-info). 325 This version of this YANG module is part of RFC 8783; see 326 the RFC itself for full legal notices."; 328 revision 2021-08-06 { 329 description 330 "Initial revision."; 331 reference 332 "RFC 8783: Knowledge Transmission Using Distributed 333 Denial-of-Service Open Threat Signaling 334 (DOTS) Data Channel"; 336 } 338 list knowledge-trans { 339 description 340 "Top-level grouping for knowledge transmission."; 341 container related-time { 342 description 343 "Relevant time for knowledge transmission."; 344 leaf creation-date-and-time { 345 type string 346 description 347 "Knowledge graph establishment date and time."; 348 } 349 leaf merge-date-and-time { 350 type string 351 description 352 "Knowledge synchronization initiation date and time."; 353 } 354 } 355 leaf label { 356 type string 357 description 358 "Type of network security knowledge graph currently 359 transmitted."; 360 } 361 leaf knowledge-base { 362 type string 363 description 364 "Name of network security knowledge graph currently 365 transmitted."; 366 } 367 leaf model-param { 368 type string 369 description 370 "Attached machine learning h5 model parameters."; 371 } 372 list entities { 373 key id; 374 description 375 "Entity contains all node information in the knowledge 376 graph."; 377 leaf id { 378 type uint32 379 description 380 "Id of the new node."; 381 } 382 leaf type { 383 type string 384 description 385 "Type of the new node."; 386 } 387 leaf labels { 388 type string 389 description 390 "Label of the new node."; 391 } 392 container properties { 393 description 394 "Properties of the new node."; 395 leaf name { 396 type string 397 description 398 "Property name of the new node."; 399 } 400 leaf establishdate { 401 type uint8 402 description 403 "Node creation time."; 404 } 405 } 406 } 407 list relationship { 408 key id; 409 description 410 "Relationship contains all the node relationships in the 411 knowledge graph."; 412 leaf id { 413 type uint32 414 description 415 "Id of the new relationship."; 416 } 417 leaf type { 418 type string 419 description 420 "Type of the new relationship."; 421 } 422 leaf labels { 423 type string 424 description 425 "Label of the new relationship."; 426 } 427 leaf properties { 428 type string 429 description 430 "Properties of the new relationship."; 431 } 432 container start { 433 description 434 "Starting node of the new relationship."; 435 leaf id { 436 type uint32 437 description 438 "Id of starting node."; 439 } 440 leaf labels { 441 type string 442 description 443 "Label of starting node."; 444 } 445 } 446 container end { 447 description 448 "Ending node of the new relationship."; 449 leaf id { 450 type uint32 451 description 452 "Id of ending node."; 453 } 454 leaf labels { 455 type string 456 description 457 "Label of ending node."; 458 } 459 } 460 } 461 } 462 464 5. Managing DOTS Knowledge Transmission 466 A POST request is used by a DOTS client to periodically synchronize 467 knowledge about DDoS attacks. This knowledge can be used to guide 468 subsequent mitigation measures to more effectively deal with multiple 469 types of DDoS attacks. An example of a request for periodic 470 transmission of DDoS attack knowledge is shown in Figure 3. 472 POST /restconf/data/ietf-dots-data-channel:dots-data\ 473 /dots-client=cuid HTTP/1.1 474 Host: {host}: {port} 475 Content-Type: application/yang-data+json 477 { 478 "ietf-dots-data-channel:knowledge-trans": { 479 [ 480 { 481 "type": "node", 482 "id": 0, 483 "labels": ["Slow-DDoS"], 484 "properties": { 485 "name": "Shrew", 486 "establishdate": 20210806094618 487 }, 488 { 489 "type": "node", 490 "id": 1, 491 "labels": ["Application-layer-DDoS"], 492 "properties": { 493 "name": "Http-get", 494 "establishdate": 20210806100512 495 }, 496 }, 497 { 498 "id": 0, 499 "type": "relationship", 500 "label": "Related-to", 501 "properties": {} 502 "start": { 503 "id": 0, 504 "labels": "Slow-DDoS" 505 } 506 "end": { 507 "id": 1, 508 "labels": "Application-layer-DDoS" 509 } 510 } 511 ] 512 } 513 } 515 Figure 3: An Example of DOTS Request Knowledge Update Process 517 A DOTS client use the POST request to update the knowledge, 518 otherwise the server respond with a "404 Not Found" status-line. 520 6. IANA Considerations 522 This document has no IANA actions. 524 7. Security Considerations 526 The security considerations for the DOTS data channel protocol are 527 discussed in Section 10 of [RFC8783]. 529 This document defines YANG data structures that are meant to be used 530 as an abstract representation in DOTS data channel. As such, 531 the "li-dots-knowledge-trans" module does not introduce any new 532 vulnerabilities beyond those specified above. 534 8. References 536 8.1 Normative References 538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 539 Requirement Levels", BCP 14, RFC 2119,DOI 10.17487/RFC2119, 540 March 1997, . 542 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 543 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 544 2017, . 546 [RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed 547 Denial-of-Service Open Threat Signaling (DOTS) Data Channel 548 Specification", RFC 8783, DOI 10.17487/RFC8783, May 2020, 549 . 551 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, 552 DOI 10.17487/RFC6991, July 2013, . 555 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 556 "YANG Data Model for Network Access Control Lists (ACLs)", 557 RFC 8519, DOI 10.17487/RFC8519, March 2019, . 560 8.2 Informative References 562 [RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open 563 Threat Signaling (DOTS) Requirements", RFC 8612, 564 DOI 10.17487/RFC8612, May 2019, . 567 [RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., Teague, 568 N., "DDoS Open Threat Signaling (DOTS) 569 Architecture", RFC 8811, DOI 10.17487/RFC8811, 570 August 2020, . 572 [KG] Knowledge Graph, "A Survey on Knowledge Graphs: 573 "Representation, Acquisition and Applications", 574 Architecture", April 2021, 575 577 Acknowledgments 579 Thanks to Boucadair Mohamed for comments and review. 581 Author's Addresses 583 Kun Li 584 Beijing Jiaotong University 585 Beijing 586 Phone: <86-15652992293> 587 Email: 19111021@bjtu.edu.cn 589 Huachun Zhou 590 Beijing Jiaotong University 591 Beijing 592 Phone: <86-13718168186> 593 Email: hchzhou@bjtu.edu.cn 595 Zhe Tu 596 Beijing Jiaotong University 597 Beijing 598 Phone: <86-13146050755> 599 Email: 19111038@bjtu.edu.cn 601 Feiyang Liu 602 Beijing Jiaotong University 603 Beijing 604 Phone: <86-18813006511> 605 Email: 19120077@bjtu.edu.cn 607 Weilin Wang 608 Beijing Jiaotong University 609 Beijing 610 Phone: <86-15910887582> 611 Email: 20120122@bjtu.edu.cn