idnits 2.17.1 draft-lingga-i2nsf-application-interface-dm-00.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 398 has weird spacing: '...sf-name uni...' -- The document date (27 August 2021) is 966 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) == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-08 == Outdated reference: A later version (-07) exists of draft-jeong-i2nsf-security-management-automation-02 == Outdated reference: A later version (-29) exists of draft-ietf-i2nsf-nsf-facing-interface-dm-12 == Outdated reference: A later version (-32) exists of draft-ietf-i2nsf-capability-data-model-17 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group P. Lingga, Ed. 3 Internet-Draft J. Jeong, Ed. 4 Intended status: Standards Track Sungkyunkwan University 5 Expires: 28 February 2022 Y. Choi 6 ETRI 7 27 August 2021 9 I2NSF Application Interface YANG Data Model 10 draft-lingga-i2nsf-application-interface-dm-00 12 Abstract 14 This document describes an information model and a YANG data model 15 for the Application Interface between an Interface to Network 16 Security Functions (I2NSF) Analyzer and Security Controller in an 17 I2NSF system in a Network Functions Virtualization (NFV) environment. 18 The information model and YANG data model is based on the I2NSF 19 Consumer-Facing Interface for enabling feedback delivery based on the 20 information received from the Network Security Function (NSF). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 28 February 2022. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Information Model for Application Interface . . . . . . . . . 4 58 3.1. Information Model for Policy Reconfiguration . . . . . . 5 59 3.2. YANG Tree Structure for Policy Reconfiguration . . . . . 7 60 3.3. Information Model for Feedback Information . . . . . . . 9 61 3.4. YANG Tree Structure for Feedback Information . . . . . . 10 62 4. YANG Data Model of Application Interface . . . . . . . . . . 11 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 64 6. XML Configuration Examples of Feedback Policy . . . . . . . . 21 65 6.1. Feedback Policy for DDoS Detection . . . . . . . . . . . 22 66 6.2. Feedback Information for Overloaded NSF . . . . . . . . . 25 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 68 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 69 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 29 72 10.2. Informative References . . . . . . . . . . . . . . . . . 30 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 75 1. Introduction 77 In Interface to Network Security Functions (I2NSF) [RFC8329], the 78 Monitoring Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model] is 79 defined as an interface to collect information (e.g., network 80 statistics, resources) from NSF(s). The information can be received 81 by a query or a report. In a query-based, the information is 82 obtained by a request from a client (I2NSF Analyzer). But in a 83 report-based, the information is provided by a server (NSFs) when the 84 notification or alarm is triggered by an event. In this model, the 85 report-based collection information is used for realizing the 86 Security Management Automation (SMA) in cloud-based security services 87 [I-D.jeong-i2nsf-security-management-automation]. as the information 88 is sent automatically by the NSFs. Figure 1 shows the I2NSF 89 Framework for Security Management Automation. 91 +------------+ 92 | I2NSF User | 93 +------------+ 94 ^ 95 | Consumer-Facing Interface 96 v 97 +-------------------+ Registration +-----------------------+ 98 |Security Controller|<-------------------->|Developer's Mgmt System| 99 +-------------------+ Interface +-----------------------+ 100 ^ ^ 101 | | 102 | | Application Interface +-----------------------+ 103 | +------------------------>| I2NSF Analyzer | 104 | +-----------------+-----+ 105 | NSF-Facing Interface ^ 106 | | 107 +--------------------------+ | 108 | | | 109 v v | 110 +------+---------+ +-------+--------+ | 111 | NSF-1 | ... | NSF-N | Monitoring | 112 | (Firewall) | |(DDoS Mitigator)+--------------+ 113 +------+---------+ +-------+--------+ Interface | 114 | | 115 +--------------------------------------------------+ 117 Figure 1: I2NSF Framework for Security Management Automation 119 The automatic reports by the NSFs are collected in a single instance 120 (i.e., I2NSF Analyzer) to be analyzed. By analyzing the information, 121 a new security policy can be produced to further enhance the security 122 of the network. To create the automated system, the analyzer should 123 be done automatically with the help of machine learning. The 124 automated analyzer is not in the scope of this document. 126 The new security policy needs to be delivered from the I2NSF Analyzer 127 to the Security Controller so the new policy can be listed and 128 monitored properly. For that purpose, this document introduces the 129 Application Interface as the intermediary between the I2NSF Analyzer 130 and the Security Controller. Then the policy should be delivered 131 directly to the NSFs by the Security Controller via the NSF-Facing 132 Interface [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 134 The purpose of this document is to provide a standard for a feedback 135 interface in an I2NSF Framework called Application Interface. With 136 the provided Application Interface, the realization of Security 137 Management Automation (SMA) should be possible. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 This document uses the terminology described in [RFC8329]. 149 This document follows the guidelines of [RFC8407] and adopts the 150 Network Management Datastore Architecture (NMDA). The meaning of the 151 symbols in tree diagrams is defined in [RFC8340]. 153 3. Information Model for Application Interface 155 This document introduces Application Interface as an interface to 156 deliver a report of the augmentation or generation of security policy 157 rules created by I2NSF Analyzer to Security Controller 158 [I-D.jeong-i2nsf-security-management-automation]. This allows 159 Security Controller to actively reinforce the network with its 160 security policy management. Figure 2 shows the high-level concept of 161 Application Interface such as Policy Reconfiguration and Feedback 162 Information. 164 +-----------------+ 165 | Application | 166 | Interface | 167 +--------+--------+ 168 ^ 169 | 170 +------------+-----------+ 171 | | 172 +--------+--------+ +-------+-----+ 173 | Policy | | Feedback | 174 | Reconfiguration | | Information | 175 +--------+--------+ +-------+-----+ 176 ^ ^ 177 | | 178 +------------+-----------+ 179 | 180 +-------------+------------+ 181 | | | 182 +-----+-----+ +-----+----+ +-----+-----+ 183 | NSF Name | | Problem | | Solution | 184 +-----------+ +----------+ +-----------+ 186 Figure 2: Diagram for Application Interface 188 Both policy reconfiguration and feedback information provide the 189 following high-level abstraction: 191 * NSF Name: It is the name or IP address of the NSF for identifying 192 the NSF with problem. The name is a unique string to identity an 193 NSF, including a Fully Qualified Domain Name (FQDN). 195 * Problem: It describes the issue(s) in the NSF that needs to be 196 handled. 198 * Solution: It specifies the possible solution(s) for the problem. 200 3.1. Information Model for Policy Reconfiguration 202 Policy reconfiguration is the rearrangement of a security policy in a 203 different form or combination of the existing security policy to 204 enhance the security service in the network. A policy 205 reconfiguration is generated by the I2NSF Analyzer after receiving 206 and analyzing monitoring information of NSF Events from an NSF 207 [I-D.ietf-i2nsf-nsf-monitoring-data-model]. 209 Policy reconfiguration works together with the three I2NSF interfaces 210 defined for the I2NSF Framework, i.e., NSF-Facing Interface 211 [I-D.ietf-i2nsf-nsf-facing-interface-dm], NSF Monitoring Interface 212 [I-D.ietf-i2nsf-nsf-monitoring-data-model], and Application 213 Interface, to create a closed-loop system for reinforcing the network 214 security. Figure 3 shows an illustration of the closed-loop system 215 for the I2NSF Framework. 217 +------------+ +----------+ 218 | Security | <--------------------------| I2NSF | 219 | Controller | Application Interface | Analyzer | 220 +------------+ (Policy Reconfiguration) +----------+ 221 | ^ 222 | | 223 NSF-Facing | +---------+ | Monitoring 224 Interface | +------->| NSF-1 |-------+ | Interface 225 (Policy | | +---------+ | |(Monitoring 226 Configuration)| | | | Data & 227 | | +---------+ | | Statistics) 228 +-------+------->| NSF-2 |-------+-----+ 229 | +---------+ | 230 | . | 231 | . | 232 | . | 233 | +---------+ | 234 +------->| NSF-n |-------+ 235 +---------+ 237 Figure 3: A Close Loop Architecture for Security Management 238 Automation (SMA) 240 Figure 3 shows a close-loop system between Security Controller, NSF, 241 and I2NSF Analyzer. The Security Controller delivers a security 242 policy to an appropriate NSF via the NSF-Facing Interface 243 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. The NSF will prepare for a 244 security service according to the given configuration and provide a 245 security service for the network. The NSF SHOULD also provide 246 monitoring information (e.g., NSF Events and System Alarms) to be 247 analyzed. This monitoring information can be delivered from the NSF 248 to an I2NSF Analyzer via the Monitoring Interface 249 [I-D.ietf-i2nsf-nsf-monitoring-data-model]. Then the I2NSF Analyzer 250 analyzes the monitoring information for the reconfiguration of an 251 existing security policy, the generation of a new security policy, 252 and the feedback for security system management (e.g., the scaling-up 253 or scaling-down of resources related to NSFs). To fully automate the 254 close-loop system, the I2NSF Analyzer should analyze the monitoring 255 information automatically using machine learning techniques (e.g., 256 Deep Learning [Deep-Learning]). The results of the analysis may 257 trigger the reconfiguration of an existing security policy or the 258 generation of a new security policy to strengthen the network 259 security. The reconfiguration or configuration request will be 260 delivered from the I2NSF Analyzer to the Security Controller via the 261 Application Interface. 263 To realize the close loop system, the Application Interface needs to 264 properly follow the similar guidelines for the I2NSF Framework 265 [RFC8329]. The Application Interface follows 266 [I-D.ietf-i2nsf-nsf-facing-interface-dm] to create a security policy 267 to reconfigure an existing security policy of NSF(s) or to generate a 268 new security policy. 270 Application Interface holds a list of security policies so that the 271 (re)configuration of a security policy and the feedback information 272 can be provided to the Security Controller. Each policy consists of 273 a list of rule to be enhanced on the NSF. Note that the 274 synchronization of the list of security policies should be done 275 between the Security Controller and the I2NSF Analyzer and the 276 specific mechanism is out of the scope of this document. A 277 (re)configured security policy rule should be able to cope with 278 attacks or failures that can happen to the network in near future. 279 Such a rule is reconfigured or generated by the I2NSF Analyzer to 280 tackle a detected problem in the network. It uses the Event- 281 Condition-Action (ECA) model as the basis for the design of I2NSF 282 Policy (Re)configuration as described in [RFC8329] and 283 [I-D.ietf-i2nsf-capability-data-model]. 285 An example of Policy (Re)configuration is a DDoS Attack that is 286 detected by a DDoS Mitigator. The DDoS Mitigator creates monitoring 287 information and delivers it to the I2NSF Analyzer. The I2NSF 288 Analyzer analyzes the information and generates a new policy to 289 handle the DDoS Attack, such as a firewall rule to drop all packets 290 from the source of the DDoS Attack. 292 3.2. YANG Tree Structure for Policy Reconfiguration 294 The YANG tree structure for policy reconfiguration is provided 295 through the augmentation of the NSF-Facing Interface YANG Module 296 [I-D.ietf-i2nsf-nsf-facing-interface-dm] as follows: 298 augment /nsfintf:i2nsf-security-policy: 299 +--rw nsf-name? union 300 +--rw problem 301 +--rw (attack-detection)? 302 +--:(ddos-detected) 303 | +--rw ddos-detected 304 | +--rw attack-src-ip* inet:ip-address 305 | +--rw attack-dst-ip* inet:ip-prefix 306 | +--rw attack-src-port* inet:port-number 307 | +--rw attack-dst-port* inet:port-number 308 +--:(virus-detected) 309 | +--rw virus-detected 310 | +--rw virus-name? string 311 | +--rw file-type? string 312 | +--rw file-name? string 313 +--:(intrusion-detected) 314 | +--rw intrusion-detected 315 | +--rw protocol? identityref 316 | +--rw app? identityref 317 | +--rw attack-type? identityref 318 +--:(web-attack-detected) 319 | +--rw web-attack-detected 320 | +--rw attack-type? identityref 321 | +--rw request-method? identityref 322 | +--rw req-uri? string 323 | +--rw req-user-agent? string 324 | +--rw req-cookie? string 325 | +--rw req-host? string 326 | +--rw response-code? string 327 +--:(voip-volte-detected) 328 +--rw voip-volte-detected 329 +--rw source-voice-id* string 330 +--rw destination-voice-id* string 331 +--rw user-agent* string 333 Figure 4: YANG Tree Structure of Policy Reconfiguration 335 The policy reconfiguration must include the following information: 337 NSF Name: The name or IP address (IPv4 or IPv6) of the NSF to be 338 configured. If the given nsf-name is not IP address, the name can 339 be an arbitrary string including FQDN (Fully Qualified Domain 340 Name). 342 Problem: The issue that is emitted by an NSF via the I2NSF 343 Monitoring Interface. The problem for policy configuration 344 includes the NSF Events described in NSF Monitoring Interface YANG 345 Data Model [I-D.ietf-i2nsf-nsf-monitoring-data-model], such as 346 DDoS detection, Virus detection, Intrusion detection, Web-attack 347 detection, and VoIP/VoLTE violation detection. 349 Solution: The solution for policy (re)configuration is the 350 security policy that is reconfigured or generated to solve a 351 detected attack. The security policy can be configured using the 352 NSF-Facing Interface YANG data model 353 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 355 3.3. Information Model for Feedback Information 357 Feedback information is information about problem(s) of an NSF for a 358 security service such as system resource over-usage or malfunction. 359 This problem cannot be handled by creating a new policy. In the 360 similar way with policy reconfiguration, the feedback information 361 should be delivered from the I2NSF Analyzer to the Security 362 Controller that will be able to handle the reported problem(s). 364 +------------+ 365 | I2NSF | 366 | User | 367 +------+-----+ 368 ^ 369 | Report 370 | 371 +-----------+ +------+-----+ Application +----------+ 372 |Developer's|<----------+ Security |<---------------| I2NSF | 373 |Mgmt System| Request | Controller | Interface | Analyzer | 374 +-----------+ +------------+ +----------+ 376 Figure 5: Handling of Feedback Information 378 Figure 5 shows the handling of feedback information. For feedback 379 information, the given feedback is not a security policy, hence the 380 Security Controller needs to take an action to handle the reported 381 problem(s). The action includes the reporting to the I2NSF User and 382 the requesting of the system resource management of the relevant 383 NSF(s) to the Developer's Management System (DMS). DMS will 384 communicate with the Management and Orchestration (MANO) Unit in the 385 Network Functions Virtualization (NFV) Framework to deal with the 386 system management issue(s) of the relevant NSFs 387 [I-D.ietf-i2nsf-applicability]. The details of the handling process 388 are out of the scope of this document. 390 3.4. YANG Tree Structure for Feedback Information 392 The YANG tree structure for feedback information is provided with the 393 use of the NSF Monitoring Interface YANG Module 394 [I-D.ietf-i2nsf-nsf-monitoring-data-model] as follows: 396 module: ietf-i2nsf-feedback-policy 397 +--rw i2nsf-feedback-information* [nsf-name time] 398 +--rw nsf-name union 399 +--rw time yang:date-and-time 400 +--rw problem 401 | +--rw (alarm-type)? 402 | +--:(memory-alarm) 403 | | +--rw memory-alarm 404 | | +--rw usage? uint8 405 | | +--rw message? string 406 | | +--rw duration? uint32 407 | +--:(cpu-alarm) 408 | | +--rw cpu-alarm 409 | | +--rw usage? uint8 410 | | +--rw message? string 411 | | +--rw duration? uint32 412 | +--:(disk-alarm) 413 | | +--rw disk-alarm 414 | | +--rw disk-id? string 415 | | +--rw usage? uint8 416 | | +--rw message? string 417 | | +--rw duration? uint32 418 | +--:(hardware-alarm) 419 | | +--rw hardware-alarm 420 | | +--rw component-name? string 421 | | +--rw message? string 422 | | +--rw duration? uint32 423 | +--:(interface-alarm) 424 | +--rw interface-alarm 425 | +--rw interface-id? string 426 | +--rw interface-state? enumeration 427 | +--rw message? string 428 | +--rw duration? uint32 429 +--rw solution* string 431 Figure 6: YANG Tree Structure of Feedback Information 433 Figure 6 shows the high-level abstraction of Feedback Information. 434 The feedback information should include: 436 * NSF Name: The name or IP address (IPv4 or IPv6) of the NSF that 437 detected the problem. If the given nsf-name is not IP address, 438 the name can be an arbitrary string including FQDN. 440 * Time: The time of the delivery of the feedback information. 442 * Problem: The issue that is emitted by an NSF via the I2NSF 443 Monitoring Interface. The problem for feedback information 444 includes the system alarms described in NSF Monitoring Interface 445 YANG Data Model [I-D.ietf-i2nsf-nsf-monitoring-data-model], such 446 as Memory alarm, CPU alarm, Disk alarm, Hardware alarm, and 447 Interface alarm. 449 * Solution: A possible solution given as feedback is in the form of 450 a free-form string (as a high-level instruction). 452 4. YANG Data Model of Application Interface 454 This section shows the YANG module of Application Interface. The 455 YANG module in this document is referencing to [RFC6991] 456 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 458 file "ietf-i2nsf-feedback-policy@2021-08-27.yang" 459 module ietf-i2nsf-feedback-policy { 460 yang-version 1.1; 461 namespace 462 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-feedback-policy"; 463 prefix nsffbck; 465 import ietf-inet-types{ 466 prefix inet; 467 reference "RFC 6991"; 468 } 470 import ietf-yang-types{ 471 prefix yang; 472 reference "RFC 6991"; 473 } 475 import ietf-i2nsf-policy-rule-for-nsf { 476 prefix nsfintf; 477 reference 478 "Section 4.1 of draft-ietf-i2nsf-nsf-facing-interface-dm-13"; 479 } 481 import ietf-i2nsf-nsf-monitoring { 482 prefix nsfmi; 483 reference 484 "Section 7 of draft-ietf-i2nsf-nsf-monitoring-data-model-09"; 485 } 487 organization 488 "IETF I2NSF (Interface to Network Security Functions) 489 Working Group"; 491 contact 492 "WG Web: 493 WG List: 495 Editor: Patrick Lingga 496 498 Editor: Jaehoon Paul Jeong 499 "; 501 description 502 "This module is a YANG module for Consumer-Facing Interface. 504 Copyright (c) 2021 IETF Trust and the persons identified as 505 authors of the code. All rights reserved. 507 Redistribution and use in source and binary forms, with or 508 without modification, is permitted pursuant to, and subject to 509 the license terms contained in, the Simplified BSD License set 510 forth in Section 4.c of the IETF Trust's Legal Provisions 511 Relating to IETF Documents 512 (https://trustee.ietf.org/license-info). 514 This version of this YANG module is part of RFC XXXX 515 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 516 for full legal notices."; 518 // RFC Ed.: replace XXXX with an actual RFC number and remove 519 // this note. 521 revision "2021-08-27" { 522 description "Initial revision."; 523 reference 524 "RFC XXXX: I2NSF Application Interface YANG Data Model"; 526 // RFC Ed.: replace XXXX with an actual RFC number and remove 527 // this note. 528 } 530 augment "/nsfintf:i2nsf-security-policy" { 531 description 532 "Augment the NSF-Facing Interface Data Model for the policy 533 reconfiguration"; 534 leaf nsf-name { 535 type union { 536 type string; 537 type inet:ip-address; 538 } 539 description 540 "The name or IP address (IPv4 or IPv6) of the NSF to be 541 configured. If the given nsf-name is not IP address, the 542 name can be an arbitrary string including FQDN (Fully 543 Qualified Domain Name)."; 544 } 546 container problem { 547 description 548 "Problem: The issue that is emitted by an NSF via the 549 I2NSF Monitoring Interface such as DDoS detection, Virus 550 detection, Intrusion detection, Web-attack detection, and 551 VoIP/VoLTE violation detection."; 552 choice attack-detection { 553 description 554 "The detected attack type"; 555 case ddos-detected { 556 container ddos-detected { 557 leaf-list attack-src-ip { 558 type inet:ip-address; 559 description 560 "The source IPv4 (or IPv6) addresses of attack 561 traffic. It can hold multiple IPv4 (or IPv6) 562 addresses."; 563 } 564 leaf-list attack-dst-ip { 565 type inet:ip-prefix; 566 description 567 "The destination IPv4 (or IPv6) addresses of attack 568 traffic. It can hold multiple IPv4 (or IPv6) 569 addresses."; 570 } 571 leaf-list attack-src-port { 572 type inet:port-number; 573 description 574 "The source ports of the DDoS attack"; 575 } 576 leaf-list attack-dst-port { 577 type inet:port-number; 578 description 579 "The destination ports of the DDoS attack"; 581 } 582 description 583 "A container for DDoS Attack"; 584 } 585 description 586 "A DDoS Attack is detected"; 587 } 588 case virus-detected { 589 container virus-detected { 590 leaf virus-name { 591 type string; 592 description 593 "The name of the detected virus"; 594 } 595 leaf file-type { 596 type string; 597 description 598 "The type of file virus code is found in (if 599 applicable)."; 600 reference 601 "IANA Website: Media Types"; 602 } 603 leaf file-name { 604 type string; 605 description 606 "The name of file virus code is found in (if 607 applicable)."; 608 } 609 description 610 "A Virus Attack is detected"; 611 } 612 description 613 "A virus is detected"; 614 } 615 case intrusion-detected { 616 container intrusion-detected { 617 leaf protocol { 618 type identityref { 619 base nsfmi:transport-protocol; 620 } 621 description 622 "The transport protocol type for 623 nsf-detection-intrusion notification"; 624 } 625 leaf app { 626 type identityref { 627 base nsfmi:application-protocol; 628 } 629 description 630 "The employed application layer protocol"; 631 } 632 leaf attack-type { 633 type identityref { 634 base nsfmi:intrusion-attack-type; 635 } 636 description 637 "The sub attack type for intrusion attack"; 638 } 639 description 640 "An intrusion is detected"; 641 } 642 } 643 case web-attack-detected { 644 container web-attack-detected { 645 leaf attack-type { 646 type identityref { 647 base nsfmi:web-attack-type; 648 } 649 description 650 "Concrete web attack type, e.g., SQL injection, 651 command injection, XSS, and CSRF."; 652 } 653 leaf request-method { 654 type identityref { 655 base nsfmi:request-method; 656 } 657 description 658 "The HTTP request method, e.g., PUT or GET."; 659 reference 660 "RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): 661 Semantics and Content - Request Methods"; 662 } 663 leaf req-uri { 664 type string; 665 description 666 "The Requested URI"; 667 } 668 leaf req-user-agent { 669 type string; 670 description 671 "The request user agent"; 672 } 673 leaf req-cookie { 674 type string; 675 description 676 "The HTTP Cookie previously sent by the server with 677 Set-Cookie"; 678 } 679 leaf req-host { 680 type string; 681 description 682 "The domain name of the requested host"; 683 } 684 leaf response-code { 685 type string; 686 description 687 "The HTTP Response code"; 688 reference 689 "IANA Website: Hypertext Transfer Protocol (HTTP) 690 Status Code Registry"; 691 } 692 description 693 "A web attack is detected"; 694 } 695 description 696 "A web attack is detected"; 697 } 698 case voip-volte-detected { 699 container voip-volte-detected { 700 leaf-list source-voice-id { 701 type string; 702 description 703 "The detected source voice ID for VoIP and VoLTE that 704 violates the security policy."; 705 } 706 leaf-list destination-voice-id { 707 type string; 708 description 709 "The detected destination voice ID for VoIP and VoLTE 710 that violates the security policy."; 711 } 712 leaf-list user-agent { 713 type string; 714 description 715 "The detected user-agent for VoIP and VoLTE that 716 violates the security policy."; 717 } 718 description 719 "A violation of VoIP/VoLTE is detected"; 720 } 721 description 722 "A violation of VoIP/VoLTE is detected"; 723 } 724 } 726 } 727 } 729 list i2nsf-feedback-information { 730 key "nsf-name time"; 732 description 733 "Feedback information is information about problem(s) of an 734 NSF for a security service such as system resource over-usage 735 or malfunction. "; 737 leaf nsf-name { 738 type union { 739 type string; 740 type inet:ip-address; 741 } 742 description 743 "The name or IP address (IPv4 or IPv6) of the NSF to be 744 configured. If the given nsf-name is not IP address, the 745 name can be an arbitrary string including FQDN (Fully 746 Qualified Domain Name)."; 747 } 749 leaf time { 750 type yang:date-and-time; 751 description 752 "The time of the feedback information delivered"; 753 } 755 container problem { 756 description 757 "The issue that is emitted by an NSF via the I2NSF Monitoring 758 Interface. The problem for feedback information includes the 759 system alarms, such as Memory alarm, CPU alarm, Disk alarm, 760 Hardware alarm, and Interface alarm."; 761 choice alarm-type { 762 description 763 "The detected alarm type"; 764 case memory-alarm { 765 container memory-alarm { 766 leaf usage { 767 type uint8 { 768 range "0..100"; 769 } 770 units "percent"; 771 description 772 "The average usage for the duration of the alarm."; 773 } 774 leaf message { 775 type string; 776 description 777 "A message explaining the problem."; 778 } 779 leaf duration { 780 type uint32; 781 description 782 "Specify the duration of the first alarm triggered 783 until the feedback information is created."; 784 } 785 description 786 "The container for memory-alarm"; 787 } 788 description 789 "The detected alarm type is memory-alarm"; 790 } 791 case cpu-alarm { 792 container cpu-alarm { 793 leaf usage { 794 type uint8 { 795 range "0..100"; 796 } 797 units "percent"; 798 description 799 "The average usage for the duration of the alarm."; 800 } 801 leaf message { 802 type string; 803 description 804 "A message explaining the problem."; 805 } 806 leaf duration { 807 type uint32; 808 description 809 "Specify the duration of the first alarm triggered 810 until the feedback information is created."; 811 } 812 description 813 "The container for cpu-alarm"; 814 } 815 description 816 "The detected alarm type is cpu-alarm"; 817 } 818 case disk-alarm { 819 container disk-alarm { 820 leaf disk-id { 821 type string; 822 description 823 "The ID of the storage disk. It is a free form 824 identifier to identify the storage disk."; 825 } 826 leaf usage { 827 type uint8 { 828 range "0..100"; 829 } 830 units "percent"; 831 description 832 "The average usage for the duration of the alarm."; 833 } 834 leaf message { 835 type string; 836 description 837 "A message explaining the problem."; 838 } 839 leaf duration { 840 type uint32; 841 description 842 "Specify the duration of the first alarm triggered 843 until the feedback information is created."; 844 } 845 description 846 "The container for disk-alarm"; 847 } 848 description 849 "The detected alarm type is disk-alarm"; 850 } 851 case hardware-alarm { 852 container hardware-alarm { 853 leaf component-name { 854 type string; 855 description 856 "The hardware component responsible for generating 857 the message. Applicable for Hardware Failure 858 Alarm."; 859 } 860 leaf message { 861 type string; 862 description 863 "A message explaining the problem."; 864 } 865 leaf duration { 866 type uint32; 867 description 868 "Specify the duration of the first alarm triggered 869 until the feedback information is created."; 871 } 872 description 873 "The container for hardware-alarm"; 874 } 875 description 876 "The detected alarm type is hardware-alarm"; 877 } 878 case interface-alarm { 879 container interface-alarm { 880 leaf interface-id { 881 type string; 882 description 883 "The interface ID responsible for generating 884 the message."; 885 } 886 leaf interface-state { 887 type enumeration { 888 enum down { 889 description 890 "The interface state is down."; 891 } 892 enum up { 893 description 894 "The interface state is up and not congested."; 895 } 896 enum congested { 897 description 898 "The interface state is up but congested."; 899 } 900 } 901 description 902 "The state of the interface (i.e., up, down, 903 congested). Applicable for Network Interface Failure 904 Alarm."; 905 } 906 leaf message { 907 type string; 908 description 909 "A message explaining the problem."; 910 } 911 leaf duration { 912 type uint32; 913 description 914 "Specify the duration of the first alarm triggered 915 until the feedback information is created."; 916 } 917 description 918 "The container for interface-alarm"; 920 } 921 description 922 "The detected alarm type is interface-alarm"; 923 } 924 } 925 } 927 leaf-list solution { 928 type string; 929 description 930 "A possible solution given as feedback is in the form of 931 a free-form string (as a high-level instruction)."; 932 } 933 } 934 } 935 937 Figure 7: YANG for Application Interface 939 5. IANA Considerations 941 This document requests IANA to register the following URI in the 942 "IETF XML Registry" [RFC3688]: 944 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-feedback-policy 945 Registrant Contact: The IESG. 946 XML: N/A; the requested URI is an XML namespace. 948 This document requests IANA to register the following YANG module in 949 the "YANG Module Names" registry [RFC7950][RFC8525]: 951 name: ietf-i2nsf-feedback-policy 952 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-feedback-policy 953 prefix: nsffb 954 reference: RFC XXXX 956 // RFC Ed.: replace XXXX with an actual RFC number and remove 957 // this note. 959 6. XML Configuration Examples of Feedback Policy 961 This section shows XML configuration examples of feedback policy 962 rules that are delivered from the I2NSF Analyzer to the Security 963 Controller over the Application Interface after the I2NSF Analyzer 964 analyzes the Monitoring Information. 966 6.1. Feedback Policy for DDoS Detection 968 In this example, the scenario can be seen in Figure 8. 970 +---------------------------------+ 971 +---------------+ | Secure Network (203.0.113.0/24) | 972 | DDoS Attacker | | | 973 | 192.0.2.8, | DDoS | +---------+ +---------+ | 974 | 192.0.2.9, +-------->| |Firewall | |Server 1 | | 975 | 192.0.2.10 | Attack | +---------+ +---------+ | 976 +---------------+ | | | 977 | v +---------+ | 978 | +---------+ |Server 2 | | 979 | |DDoS | ----> +---------+ | 980 | |Mitigator| | 981 | +---------+ +---------+ | 982 | |Server 3 | | 983 | +---------+ | 984 +---------------------------------+ 986 Figure 8: A Scenario Example of DDoS Attack 988 In this scenario, a DDoS Mitigator detects a DDoS Attack and sends a 989 notification to the I2NSF Analyzer as shown in Figure 9. 991 992 994 2021-08-27T09:00:01.00Z 995 997 998 1001 nsfmi:syn-flood 1002 1003 1006 nsfmi:subscription 1007 1008 1011 nsfmi:on-change 1012 1013 1016 nsfmi:on-repetition 1017 1018 2021-08-27T09:00:00.00Z 1019 192.0.2.8 1020 192.0.2.9 1021 192.0.2.10 1022 203.0.113.0/24 1023 100 1024 A DDoS Attack is detected 1025 DDoS_mitigator 1026 1027 1028 1030 Figure 9: A Detected DDoS Attack by DDoS Mitigator 1032 In the scenario shown in Figure 9, the description of the XML example 1033 is as follows: 1035 1. The DDoS attack is detected at 9 am on August 27 in 2021. 1037 2. The sources of the attack are 192.0.2.8, 192.0.2.9, and 1038 192.0.2.10. 1040 3. The destination of the attack is 203.0.113.0/24. 1042 After receiving the information, the I2NSF Analyzer analyzes the data 1043 and creates a new feedback policy to enforce the security of the 1044 network. The I2NSF Analyzer delivers a feedback policy to the 1045 Security Controller as shown in Figure 10. 1047 1048 1050 1051 feedback_policy_for_ddos_attack 1052 1053 1054 deny_ddos_attack 1055 1056 2021-08-27T09:00:01.00Z 1057 1058 1059 1060 1061 192.0.2.8 1062 192.0.2.10 1063 1064 1065 1066 1067 1068 drop 1069 1070 1071 1072 Firewall 1073 1074 1075 192.0.2.8 1076 192.0.2.9 1077 192.0.2.10 1078 203.0.113.0/24 1079 1080 1081 1083 Figure 10: Policy Reconfiguration for a Detected DDoS Attack 1085 The policy reconfiguration in Figure 10 means the following: 1087 1. The feedback policy is named as 1088 "feedback_policy_for_ddos_attack". 1090 2. The rule is named as "deny_ddos_attack". 1092 3. The rule starts from 09:00 am on August 24 in 2021. The 1093 condition of the rule is from the sources of the IP addresses 1094 192.0.2.8, 192.0.2.9, and 192.0.2.10. 1096 4. The action required is to "drop" any access from the the IP 1097 addresses have been identified as malicious. 1099 5. The NSF to be configured is named "Firewall". 1101 6. The problem that triggered the generation of the feedback is a 1102 DDoS attack from the sources of the IP addresses 192.0.2.8, 1103 192.0.2.9, and 192.0.2.10 to the protected network of 1104 203.0.113.0/24. 1106 6.2. Feedback Information for Overloaded NSF 1108 In this scenario, an NSF is overloaded and sends a notification to 1109 the I2NSF Analyzer as shown in Figure 11. 1111 1112 1114 2021-08-27T07:43:52.181088+00:00 1115 1117 1118 1121 nsfmi:memory-alarm 1122 1123 1126 nsfmi:subscription 1127 1128 1131 nsfmi:on-change 1132 1133 1136 nsfmi:on-repetition 1137 1138 98 1139 80 1140 Memory Usage Exceeded the Threshold 1141 firewall 1142 high 1143 1144 1145 1147 Figure 11: The Monitoring of an Overloaded NSF 1149 In the scenario shown in Figure 11, the description of the XML 1150 example is as follows: 1152 1. The NSF that sends the information is named "firewall". 1154 2. The memory usage of the NSF triggered the alarm. 1156 3. The memory usage of the NSF is 98 percent. 1158 4. The memory threshold to trigger the alarm is 80 percent. 1160 5. The event is delivered at 2021-08-27T07:43:52.181088+00:00. 1162 After receiving the information, the I2NSF Analyzer analyzes the data 1163 and creates a new feedback policy to solve the problem that is 1164 detected in the NSF. The I2NSF Analyzer delivers a feedback 1165 information to the Security Controller as shown in Figure 12. 1167 1168 1170 1171 Firewall 1172 1173 1174 95 1175 Memory Usage Exceeded the Threshold 1176 3600 1177 1178 1179 1180 Add more memory capacity to the NSF 1181 1182 1183 Create a new NSF with the same security service 1184 1185 1187 Figure 12: Feedback Information for the Overloaded NSF 1189 The feedback information in Figure 12 means the following: 1191 1. The name of the NSF that needs to be handled is called 1192 "Firewall". 1194 2. The feedback information is delivered at 1195 2021-08-27T08:43:52.000000+00:00. 1197 3. The problem is that the Memory Usage Exceeded the Threshold with 1198 the average usage of memory as 95. 1200 4. The problem persists for 3,600 seconds (1 hour) without any fix. 1202 5. The proposed solution to the problem is to add more memory 1203 capacity in hardware to the NSF or to create a new NSF with the 1204 same security service. 1206 7. Security Considerations 1208 The YANG module specified in this document defines a data schema 1209 designed to be accessed through network management protocols such as 1210 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 1211 the secure transport layer, and the required secure transport is 1212 Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, 1213 and the required secure transport is TLS [RFC8446]. 1215 The NETCONF access control model [RFC8341] provides a means of 1216 restricting access to specific NETCONF or RESTCONF users to a 1217 preconfigured subset of all available NETCONF or RESTCONF protocol 1218 operations and content. 1220 There are a number of data nodes defined in this YANG module that are 1221 writable/creatable/deletable (i.e., config true, which is the 1222 default). These data nodes may be considered sensitive or vulnerable 1223 in some network environments. Write operations (e.g., edit-config) 1224 to these data nodes without proper protection can have a negative 1225 effect on network operations. And the data model in this document 1226 uses the data model from NSF-Facing Interface data model, it MUST 1227 follow the Security Considerations mentioned in the 1228 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 1230 Some of the readable data nodes in this YANG module may be considered 1231 sensitive or vulnerable in some network environments. It is thus 1232 important to control read access (e.g., via get, get-config, or 1233 notification) to these data nodes. This document also MUST follow 1234 the Security Considerations about the readable data nodes mentioned 1235 in the [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 1237 8. Acknowledgments 1239 This work was supported by Institute of Information & Communications 1240 Technology Planning & Evaluation (IITP) grant funded by the Korea 1241 MSIT (Ministry of Science and ICT) (2020-0-00395, Standard 1242 Development of Blockchain based Network Management Automation 1243 Technology). This work was supported in part by the IITP 1244 (R-20160222-002755, Cloud based Security Intelligence Technology 1245 Development for the Customized Security Service Provisioning). This 1246 work was supported in part by the MSIT under the Information 1247 Technology Research Center (ITRC) support program (IITP- 1248 2021-2017-0-01633) supervised by the IITP. 1250 9. Contributors 1252 This document is made by the group effort of I2NSF working group. 1253 Many people actively contributed to this document, such as Linda 1254 Dunbar, Yoav Nir, Susan Hares, and Diego Lopez. The authors 1255 sincerely appreciate their contributions. 1257 The following are co-authors of this document: 1259 Jeonghyeon Kim Department of Computer Science and Engineering 1260 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 1261 16419 Republic of Korea EMail: jeonghyeon12@skku.edu 1263 Jinyong (Tim) Kim Department of Computer Science and Engineering 1264 Sungkyunkwan University 2066 Seo-ro Jangan-gu Suwon, Gyeonggi-do 1265 16419 Republic of Korea EMail: timkim@skku.edu 1267 Jung-Soo Park Electronics and Telecommunications Research Institute 1268 218 Gajeong-Ro, Yuseong-Gu Daejeon, 34129 Republic of Korea EMail: 1269 pjs@etri.re.kr 1271 Younghan Kim School of Electronic Engineering Soongsil University 1272 369, Sangdo-ro, Dongjak-gu Seoul 06978 Republic of Korea EMail: 1273 younghak@ssu.ac.kr 1275 10. References 1277 10.1. Normative References 1279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1280 Requirement Levels", BCP 14, RFC 2119, 1281 DOI 10.17487/RFC2119, March 1997, 1282 . 1284 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1285 DOI 10.17487/RFC3688, January 2004, 1286 . 1288 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1289 and A. Bierman, Ed., "Network Configuration Protocol 1290 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1291 . 1293 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1294 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1295 . 1297 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1298 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1299 . 1301 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1302 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1303 . 1305 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1306 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1307 . 1309 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1310 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1311 May 2017, . 1313 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1314 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1315 . 1317 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1318 Access Control Model", STD 91, RFC 8341, 1319 DOI 10.17487/RFC8341, March 2018, 1320 . 1322 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1323 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1324 DOI 10.17487/RFC8407, October 2018, 1325 . 1327 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1328 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1329 . 1331 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 1332 and R. Wilton, "YANG Library", RFC 8525, 1333 DOI 10.17487/RFC8525, March 2019, 1334 . 1336 10.2. Informative References 1338 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1339 Kumar, "Framework for Interface to Network Security 1340 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 1341 . 1343 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 1344 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 1345 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 1346 Model", Work in Progress, Internet-Draft, draft-ietf- 1347 i2nsf-nsf-monitoring-data-model-08, 29 April 2021, 1348 . 1351 [I-D.jeong-i2nsf-security-management-automation] 1352 Jeong, J. (., Lingga, P., and J. Park, "An Extension of 1353 I2NSF Framework for Security Management Automation in 1354 Cloud-Based Security Services", Work in Progress, 1355 Internet-Draft, draft-jeong-i2nsf-security-management- 1356 automation-02, 21 August 2021, 1357 . 1360 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 1361 Kim, J. (., Jeong, J. (., Park, J., Hares, S., and Q. Lin, 1362 "I2NSF Network Security Function-Facing Interface YANG 1363 Data Model", Work in Progress, Internet-Draft, draft-ietf- 1364 i2nsf-nsf-facing-interface-dm-12, 8 March 2021, 1365 . 1368 [I-D.ietf-i2nsf-capability-data-model] 1369 Hares, S., Jeong, J. (., Kim, J. (., Moskowitz, R., and Q. 1370 Lin, "I2NSF Capability YANG Data Model", Work in Progress, 1371 Internet-Draft, draft-ietf-i2nsf-capability-data-model-17, 1372 14 August 2021, . 1375 [I-D.ietf-i2nsf-applicability] 1376 Jeong, J. P., Hyun, S., Ahn, T., Hares, S., and D. R. 1377 Lopez, "Applicability of Interfaces to Network Security 1378 Functions to Network-Based Security Services", Work in 1379 Progress, Internet-Draft, draft-ietf-i2nsf-applicability- 1380 18, 16 September 2019, . 1383 [Deep-Learning] 1384 Goodfellow, I., Bengio, Y., and A. Courville, "Deep 1385 Learning", Publisher: The MIT Press, 1386 URL: https://www.deeplearningbook.org/, November 2016. 1388 Authors' Addresses 1389 Patrick Lingga (editor) 1390 Department of Electrical and Computer Engineering 1391 Sungkyunkwan University 1392 2066 Seobu-Ro, Jangan-Gu 1393 Suwon 1394 Gyeonggi-Do 1395 16419 1396 Republic of Korea 1398 Phone: +82 31 299 4957 1399 Email: patricklink@skku.edu 1401 Jaehoon Paul Jeong (editor) 1402 Department of Computer Science and Engineering 1403 Sungkyunkwan University 1404 2066 Seobu-Ro, Jangan-Gu 1405 Suwon 1406 Gyeonggi-Do 1407 16419 1408 Republic of Korea 1410 Phone: +82 31 299 4957 1411 Email: pauljeong@skku.edu 1412 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1414 Yunchul Choi 1415 Electronics and Telecommunications Research Institute 1416 218 Gajeong-Ro, Yuseong-Gu 1417 Daejeon 1418 305-700 1419 Republic of Korea 1421 Phone: +82 42 860 5978 1422 Email: cyc79@etri.re.kr