idnits 2.17.1 draft-lingga-i2nsf-application-interface-dm-03.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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. -- 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 405 has weird spacing: '...sf-name uni...' -- The document date (28 April 2022) is 728 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) ** Downref: Normative reference to an Informational RFC: RFC 8329 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-semantics' == Outdated reference: A later version (-29) exists of draft-ietf-i2nsf-nsf-facing-interface-dm-26 == Outdated reference: A later version (-32) exists of draft-ietf-i2nsf-capability-data-model-30 == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-18 == Outdated reference: A later version (-07) exists of draft-jeong-i2nsf-security-management-automation-03 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 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: 30 October 2022 Y. Choi 6 ETRI 7 28 April 2022 9 I2NSF Application Interface YANG Data Model 10 draft-lingga-i2nsf-application-interface-dm-03 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 a Security Controller in an 17 I2NSF system in a Network Functions Virtualization (NFV) environment. 18 The YANG data model described in this document is based on the I2NSF 19 NSF-Facing Interface and the I2NSF Monitoring Interface for enabling 20 feedback delivery based on the information received from a Network 21 Security Function (NSF). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 30 October 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Information Model for Application Interface . . . . . . . . . 4 59 3.1. Information Model for Policy Reconfiguration . . . . . . 5 60 3.2. YANG Tree Structure for Policy Reconfiguration . . . . . 7 61 3.3. Information Model for Feedback Information . . . . . . . 9 62 3.4. YANG Tree Structure for Feedback Information . . . . . . 10 63 4. YANG Data Model of Application Interface . . . . . . . . . . 12 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 65 6. XML Configuration Examples of Feedback Policy . . . . . . . . 25 66 6.1. Feedback Policy for DDoS Detection . . . . . . . . . . . 25 67 6.2. Feedback Information for Overloaded NSF . . . . . . . . . 28 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 30 71 8.2. Informative References . . . . . . . . . . . . . . . . . 33 72 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 33 73 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 34 74 Appendix C. Changes from 75 draft-lingga-i2nsf-application-interface-dm-02 . . . . . 34 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 78 1. Introduction 80 In Interface to Network Security Functions (I2NSF) [RFC8329], the 81 Monitoring Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model] is 82 defined as an interface to collect information (e.g., network 83 statistics, resources) from NSF(s). The information can be received 84 by a query or a report. In a query-based, the information is 85 obtained by a request from a client (I2NSF Analyzer). But in a 86 report-based, the information is provided by a server (NSFs) when the 87 notification or alarm is triggered by an event. In this model, the 88 report-based collection information is used for realizing the 89 Security Management Automation (SMA) in cloud-based security services 90 [I-D.jeong-i2nsf-security-management-automation]. as the information 91 is sent automatically by the NSFs. Figure 1 shows the I2NSF 92 Framework for Security Management Automation. 94 +------------+ 95 | I2NSF User | 96 +------------+ 97 ^ 98 | Consumer-Facing Interface 99 v 100 +-------------------+ Registration +-----------------------+ 101 |Security Controller|<-------------------->|Developer's Mgmt System| 102 +-------------------+ Interface +-----------------------+ 103 ^ ^ 104 | | 105 | | Application Interface +-----------------------+ 106 | +------------------------>| I2NSF Analyzer | 107 | +-----------------+-----+ 108 | NSF-Facing Interface ^ 109 | | 110 +--------------------------+ | 111 | | | 112 v v | 113 +------+---------+ +-------+--------+ | 114 | NSF-1 | ... | NSF-N | Monitoring | 115 | (Firewall) | |(DDoS Mitigator)+--------------+ 116 +------+---------+ +-------+--------+ Interface | 117 | | 118 +--------------------------------------------------+ 120 Figure 1: I2NSF Framework for Security Management Automation 122 The automatic reports by the NSFs are collected in a single instance 123 (i.e., I2NSF Analyzer) to be analyzed. By analyzing the information, 124 a new security policy can be produced to further enhance the security 125 of the network. To create the automated system, the analyzer should 126 be done automatically with the help of machine learning. The 127 automated analyzer is not in the scope of this document. 129 The new security policy needs to be delivered from the I2NSF Analyzer 130 to the Security Controller so the new policy can be listed and 131 monitored properly. For that purpose, this document introduces the 132 Application Interface as the intermediary between the I2NSF Analyzer 133 and the Security Controller. Then the policy should be delivered 134 directly to the NSFs by the Security Controller via the NSF-Facing 135 Interface [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 137 The purpose of this document is to provide a standard for a feedback 138 interface in an I2NSF Framework called Application Interface. With 139 the provided Application Interface, the realization of Security 140 Management Automation (SMA) should be possible. 142 2. Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in BCP 147 14 [RFC2119] [RFC8174] when, and only when, they appear in all 148 capitals, as shown here. 150 This document uses the terminology described in [RFC8329]. 152 This document follows the guidelines of [RFC8407] and adopts the 153 Network Management Datastore Architecture (NMDA). The meaning of the 154 symbols in tree diagrams is defined in [RFC8340]. 156 3. Information Model for Application Interface 158 This document introduces Application Interface as an interface to 159 deliver a report of the augmentation or generation of security policy 160 rules created by I2NSF Analyzer to Security Controller 161 [I-D.jeong-i2nsf-security-management-automation]. This allows 162 Security Controller to actively reinforce the network with its 163 security policy management. Figure 2 shows the high-level concept of 164 Application Interface such as Policy Reconfiguration and Feedback 165 Information. 167 +-----------------+ 168 | Application | 169 | Interface | 170 +--------+--------+ 171 ^ 172 | 173 +------------+-----------+ 174 | | 175 +--------+--------+ +-------+-----+ 176 | Policy | | Feedback | 177 | Reconfiguration | | Information | 178 +--------+--------+ +-------+-----+ 179 ^ ^ 180 | | 181 +------------+-----------+ 182 | 183 +-------------+------------+ 184 | | | 185 +-----+-----+ +-----+----+ +-----+-----+ 186 | NSF Name | | Problem | | Solution | 187 +-----------+ +----------+ +-----------+ 189 Figure 2: Diagram for Application Interface 191 Both policy reconfiguration and feedback information provide the 192 following high-level abstraction: 194 * NSF Name: It is the name or IP address of the NSF for identifying 195 the NSF with problem. The name is a unique string to identify an 196 NSF, including a Fully Qualified Domain Name (FQDN). 198 * Problem: It describes the issue(s) in the NSF that needs to be 199 handled. 201 * Solution: It specifies the possible solution(s) for the problem. 203 3.1. Information Model for Policy Reconfiguration 205 Policy reconfiguration is the rearrangement of a security policy in a 206 different form or combination of the existing security policy to 207 enhance the security service in the network. A policy 208 reconfiguration is generated by the I2NSF Analyzer after receiving 209 and analyzing monitoring information of NSF Events from an NSF 210 [I-D.ietf-i2nsf-nsf-monitoring-data-model]. 212 Policy reconfiguration works together with the three I2NSF interfaces 213 defined for the I2NSF Framework, i.e., NSF-Facing Interface 214 [I-D.ietf-i2nsf-nsf-facing-interface-dm], NSF Monitoring Interface 215 [I-D.ietf-i2nsf-nsf-monitoring-data-model], and Application 216 Interface, to create a closed-loop system for reinforcing the network 217 security. Figure 3 shows an illustration of the closed-loop system 218 for the I2NSF Framework. 220 +------------+ +----------+ 221 | Security | <--------------------------| I2NSF | 222 | Controller | Application Interface | Analyzer | 223 +------------+ (Policy Reconfiguration) +----------+ 224 | ^ 225 | | 226 NSF-Facing | +---------+ | Monitoring 227 Interface | +------->| NSF-1 |-------+ | Interface 228 (Policy | | +---------+ | |(Monitoring 229 Configuration)| | | | Data & 230 | | +---------+ | | Statistics) 231 +-------+------->| NSF-2 |-------+-----+ 232 | +---------+ | 233 | . | 234 | . | 235 | . | 236 | +---------+ | 237 +------->| NSF-n |-------+ 238 +---------+ 240 Figure 3: A Closed-Loop Architecture for Security Management 241 Automation (SMA) 243 Figure 3 shows a closed-loop system between Security Controller, NSF, 244 and I2NSF Analyzer. The Security Controller delivers a security 245 policy to an appropriate NSF via the NSF-Facing Interface 246 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. The NSF will prepare for a 247 security service according to the given configuration and provide a 248 security service for the network. The NSF SHOULD also provide 249 monitoring information (e.g., NSF Events and System Alarms) to be 250 analyzed. This monitoring information can be delivered from the NSF 251 to an I2NSF Analyzer via the Monitoring Interface 252 [I-D.ietf-i2nsf-nsf-monitoring-data-model]. Then the I2NSF Analyzer 253 analyzes the monitoring information for the reconfiguration of an 254 existing security policy, the generation of a new security policy, 255 and the feedback for security system management (e.g., the scaling-up 256 or scaling-down of resources related to NSFs). To fully automate the 257 closed-loop system, the I2NSF Analyzer should analyze the monitoring 258 information automatically using machine learning techniques (e.g., 259 Deep Learning [Deep-Learning]). The results of the analysis may 260 trigger the reconfiguration of an existing security policy or the 261 generation of a new security policy to strengthen the network 262 security. The reconfiguration or configuration request will be 263 delivered from the I2NSF Analyzer to the Security Controller via the 264 Application Interface. 266 To realize the closed-loop system, the Application Interface needs to 267 properly follow the similar guidelines for the I2NSF Framework 268 [RFC8329]. The Application Interface follows 269 [I-D.ietf-i2nsf-nsf-facing-interface-dm] to create a security policy 270 to reconfigure an existing security policy of NSF(s) or to generate a 271 new security policy. 273 Application Interface holds a list of security policies so that the 274 (re)configuration of a security policy and the feedback information 275 can be provided to the Security Controller. Each policy consists of 276 a list of rule to be enhanced on the NSF. Note that the 277 synchronization of the list of security policies should be done 278 between the Security Controller and the I2NSF Analyzer and the 279 specific mechanism is out of the scope of this document. A 280 (re)configured security policy rule should be able to cope with 281 attacks or failures that can happen to the network in near future. 282 Such a rule is reconfigured or generated by the I2NSF Analyzer to 283 tackle a detected problem in the network. It uses the Event- 284 Condition-Action (ECA) model as the basis for the design of I2NSF 285 Policy (Re)configuration as described in [RFC8329] and 286 [I-D.ietf-i2nsf-capability-data-model]. 288 An example of Policy (Re)configuration is a DDoS Attack that is 289 detected by a DDoS Mitigator. The DDoS Mitigator creates monitoring 290 information and delivers it to the I2NSF Analyzer. The I2NSF 291 Analyzer analyzes the information and generates a new policy to 292 handle the DDoS Attack, such as a firewall rule to drop all packets 293 from the source of the DDoS Attack. 295 3.2. YANG Tree Structure for Policy Reconfiguration 297 The YANG tree structure for policy reconfiguration is provided 298 through the augmentation of the NSF-Facing Interface YANG Module 299 [I-D.ietf-i2nsf-nsf-facing-interface-dm] as follows: 301 augment /nsfintf:i2nsf-security-policy: 302 +--rw nsf-name? union 303 +--rw problem 304 +--rw (attack-detection)? 305 +--:(ddos-detected) 306 | +--rw ddos-detected 307 | +--rw attack-src-ip* inet:ip-address-no-zone 308 | +--rw attack-dst-ip* inet:ip-address-no-zone 309 | +--rw attack-src-port* inet:port-number 310 | +--rw attack-dst-port* inet:port-number 311 +--:(virus-detected) 312 | +--rw virus-detected 313 | +--rw virus-name? string 314 | +--rw virus-type? identityref 315 | +--rw host? union 316 | +--rw file-type? string 317 | +--rw file-name? string 318 | +--rw os? string 319 +--:(intrusion-detected) 320 | +--rw intrusion-detected 321 | +--rw protocol? identityref 322 | +--rw app? identityref 323 | +--rw attack-type? identityref 324 +--:(web-attack-detected) 325 | +--rw web-attack-detected 326 | +--rw attack-type? identityref 327 | +--rw req-method? identityref 328 | +--rw req-uri? string 329 | +--rw req-user-agent? string 330 | +--rw cookies? string 331 | +--rw req-host? string 332 | +--rw response-code? string 333 +--:(voip-vocn-detected) 334 +--rw voip-vocn-detected 335 +--rw source-voice-id* string 336 +--rw destination-voice-id* string 337 +--rw user-agent* string 339 Figure 4: YANG Tree Structure of Policy Reconfiguration 341 The policy reconfiguration must include the following information: 343 NSF Name: The name or IP address (IPv4 or IPv6) of the NSF to be 344 configured. If the given nsf-name is not IP address, the name can 345 be an arbitrary string including FQDN (Fully Qualified Domain 346 Name). 348 Problem: The issue that is emitted by an NSF via the I2NSF 349 Monitoring Interface. The problem for policy configuration 350 includes the NSF Events described in NSF Monitoring Interface YANG 351 Data Model [I-D.ietf-i2nsf-nsf-monitoring-data-model], such as 352 DDoS detection, Virus detection, Intrusion detection, Web-attack 353 detection, and Voice over Internet Protocol (VoIP) or Voice over 354 Cellular Network (VoCN) violation detection. 356 Solution: The solution for policy (re)configuration is the 357 security policy that is reconfigured or generated to solve a 358 detected attack. The security policy can be configured using the 359 NSF-Facing Interface YANG data model 360 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 362 3.3. Information Model for Feedback Information 364 Feedback information is information about problem(s) of an NSF for a 365 security service such as system resource over-usage or malfunction. 366 This problem cannot be handled by creating a new policy. In the 367 similar way with policy reconfiguration, the feedback information 368 should be delivered from the I2NSF Analyzer to the Security 369 Controller that will be able to handle the reported problem(s). 371 +------------+ 372 | I2NSF | 373 | User | 374 +------+-----+ 375 ^ 376 | Report 377 | 378 +-----------+ +------+-----+ Application +----------+ 379 |Developer's|<----------+ Security |<---------------| I2NSF | 380 |Mgmt System| Query | Controller | Interface | Analyzer | 381 +-----------+ +------------+ +----------+ 383 Figure 5: Handling of Feedback Information 385 Figure 5 shows the handling of feedback information. For feedback 386 information, the given feedback is not a security policy, hence the 387 Security Controller needs to take an action to handle the reported 388 problem(s). The action includes the report to the I2NSF User and the 389 query of the system resource management of the relevant NSF(s) to the 390 Developer's Management System (DMS). DMS will communicate with the 391 Management and Orchestration (MANO) Unit in the Network Functions 392 Virtualization (NFV) Framework to deal with the system management 393 issue(s) of the relevant NSFs [I-D.ietf-i2nsf-applicability]. The 394 details of the handling process are out of the scope of this 395 document. 397 3.4. YANG Tree Structure for Feedback Information 399 The YANG tree structure for feedback information is provided with the 400 use of the NSF Monitoring Interface YANG Module 401 [I-D.ietf-i2nsf-nsf-monitoring-data-model] as follows: 403 module: ietf-i2nsf-feedback-policy 404 +--rw i2nsf-feedback-information* [nsf-name time] 405 +--rw nsf-name union 406 +--rw time yang:date-and-time 407 +--rw language? string 408 +--rw problem 409 | +--rw (alarm-type)? 410 | +--:(memory-alarm) 411 | | +--rw memory-alarm 412 | | +--rw usage? uint8 413 | | +--rw message? string 414 | | +--rw duration? uint32 415 | +--:(cpu-alarm) 416 | | +--rw cpu-alarm 417 | | +--rw usage? uint8 418 | | +--rw message? string 419 | | +--rw duration? uint32 420 | +--:(disk-alarm) 421 | | +--rw disk-alarm 422 | | +--rw disk-id? string 423 | | +--rw usage? uint8 424 | | +--rw message? string 425 | | +--rw duration? uint32 426 | +--:(hardware-alarm) 427 | | +--rw hardware-alarm 428 | | +--rw component-name? string 429 | | +--rw message? string 430 | | +--rw duration? uint32 431 | +--:(interface-alarm) 432 | +--rw interface-alarm 433 | +--rw interface-id? string 434 | +--rw interface-state? enumeration 435 | +--rw message? string 436 | +--rw duration? uint32 437 +--rw solution* string 439 Figure 6: YANG Tree Structure of Feedback Information 441 Figure 6 shows the high-level abstraction of Feedback Information. 442 The feedback information should include: 444 * NSF Name: The name or IP address (IPv4 or IPv6) of the NSF that 445 detected the problem. If the given nsf-name is not IP address, 446 the name can be an arbitrary string including FQDN. 448 * Time: The time of the delivery of the feedback information. 450 * Language: The language tag that is used for the natural language 451 text that is included in the "message" and "solution" attributes. 452 The language field is encoded following the rules in Section 2.1 453 of [RFC5646]. The default language tag is "en-US". 455 * Problem: The issue that is emitted by an NSF via the I2NSF 456 Monitoring Interface. The problem for feedback information 457 includes the system alarms described in NSF Monitoring Interface 458 YANG Data Model [I-D.ietf-i2nsf-nsf-monitoring-data-model], such 459 as Memory alarm, CPU alarm, Disk alarm, Hardware alarm, and 460 Interface alarm. 462 * Solution: A possible solution given as feedback is in the form of 463 a free-form string (as a high-level instruction). 465 4. YANG Data Model of Application Interface 467 This section shows the YANG module of Application Interface. The 468 YANG module in this document is referencing to [RFC6991] 469 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 470 [I-D.ietf-i2nsf-nsf-monitoring-data-model]. 472 The YANG module makes references to [RFC5646] [RFC6265] [RFC8343] 473 [I-D.ietf-httpbis-semantics] 475 file "ietf-i2nsf-feedback-policy@2022-04-28.yang" 476 module ietf-i2nsf-feedback-policy { 477 yang-version 1.1; 478 namespace 479 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-feedback-policy"; 480 prefix nsffbck; 482 import ietf-inet-types{ 483 prefix inet; 484 reference "RFC 6991"; 485 } 487 import ietf-yang-types{ 488 prefix yang; 489 reference "RFC 6991"; 490 } 492 import ietf-i2nsf-policy-rule-for-nsf { 493 prefix nsfintf; 494 reference 495 "Section 4.1 of draft-ietf-i2nsf-nsf-facing-interface-dm-21"; 496 } 497 import ietf-i2nsf-nsf-monitoring { 498 prefix nsfmi; 499 reference 500 "Section 7 of draft-ietf-i2nsf-nsf-monitoring-data-model-15"; 501 } 503 organization 504 "IETF I2NSF (Interface to Network Security Functions) 505 Working Group"; 507 contact 508 "WG Web: 509 WG List: 511 Editor: Patrick Lingga 512 514 Editor: Jaehoon Paul Jeong 515 "; 517 description 518 "This module is a YANG module for Application Interface. 520 Copyright (c) 2022 IETF Trust and the persons identified as 521 authors of the code. All rights reserved. 523 Redistribution and use in source and binary forms, with or 524 without modification, is permitted pursuant to, and subject 525 to the license terms contained in, the Revised BSD License 526 set forth in Section 4.c of the IETF Trust's 527 Legal Provisions Relating to IETF Documents 528 (https://trustee.ietf.org/license-info). 530 This version of this YANG module is part of RFC XXXX 531 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 532 for full legal notices."; 534 // RFC Ed.: replace XXXX with an actual RFC number and remove 535 // this note. 537 revision "2022-04-28" { 538 description "Initial revision."; 539 reference 540 "RFC XXXX: I2NSF Application Interface YANG Data Model"; 542 // RFC Ed.: replace XXXX with an actual RFC number and remove 543 // this note. 544 } 545 augment "/nsfintf:i2nsf-security-policy" { 546 description 547 "Augment the NSF-Facing Interface Data Model for the policy 548 reconfiguration"; 549 leaf nsf-name { 550 type union { 551 type string; 552 type inet:ip-address; 553 } 554 description 555 "The name or IP address (IPv4 or IPv6) of the NSF to be 556 configured. If the given nsf-name is not IP address, the 557 name can be an arbitrary string including FQDN (Fully 558 Qualified Domain Name)."; 559 } 561 container problem { 562 description 563 "Problem: The issue that is emitted by an NSF via the 564 I2NSF Monitoring Interface such as DDoS detection, Virus 565 detection, Intrusion detection, Web-attack detection, and 566 VoIP/VoCN violation detection."; 567 choice attack-detection { 568 description 569 "The detected attack type"; 570 case ddos-detected { 571 container ddos-detected { 572 leaf-list attack-src-ip { 573 type inet:ip-address-no-zone; 574 description 575 "The source IPv4 or IPv6 addresses of attack 576 traffic. It can hold multiple IPv4 or IPv6 577 addresses. Note that all IP addresses should not be 578 included, but only limited IP addresses are included 579 to conserve the server resources. The listed attacking 580 IP addresses can be an arbitrary sampling of the 581 'top talkers', i.e., the attackers that send the 582 highest amount of traffic."; 583 } 584 leaf-list attack-dst-ip { 585 type inet:ip-address-no-zone; 586 description 587 "The destination IPv4 or IPv6 addresses of attack 588 traffic. It can hold multiple IPv4 or IPv6 589 addresses."; 590 } 591 leaf-list attack-src-port { 592 type inet:port-number; 593 description 594 "The transport-layer source ports of the DDoS attack. 595 Note that not all ports will have been seen on all the 596 corresponding source IP addresses."; 597 } 598 leaf-list attack-dst-port { 599 type inet:port-number; 600 description 601 "The transport-layer destination ports of the DDoS 602 attack. Note that not all ports will have been seen 603 on all the corresponding destination IP addresses."; 604 } 605 description 606 "A container for DDoS Attack"; 607 } 608 description 609 "A DDoS Attack is detected"; 610 } 611 case virus-detected { 612 container virus-detected { 613 leaf virus-name { 614 type string; 615 description 616 "The name of the detected virus"; 617 } 618 leaf virus-type { 619 type identityref { 620 base nsfmi:virus-type; 621 } 622 description 623 "The virus type of the detected virus"; 624 } 625 leaf host { 626 type union { 627 type string; 628 type inet:ip-address-no-zone; 629 } 630 description 631 "The name or IP address of the host/device. This is 632 used to identify the host/device that is infected by 633 the virus. If the given name is not an IP address, the 634 name can be an arbitrary string including a FQDN 635 (Fully Qualified Domain Name). The name MUST be unique 636 in the scope of management domain for identifying the 637 device that has been infected with a virus."; 638 } 639 leaf file-type { 640 type string; 641 description 642 "The type of a file (indicated by the file's suffix, 643 e.g., .exe) where virus code is found (if 644 applicable)."; 645 } 646 leaf file-name { 647 type string; 648 description 649 "The name of file virus code is found in (if 650 applicable)."; 651 } 652 leaf os { 653 type string; 654 description 655 "The operating system of the device."; 656 } 657 description 658 "A Virus Attack is detected"; 659 } 660 description 661 "A virus is detected"; 662 } 663 case intrusion-detected { 664 container intrusion-detected { 665 leaf protocol { 666 type identityref { 667 base nsfmi:transport-protocol; 668 } 669 description 670 "The transport protocol type for 671 nsf-detection-intrusion notification"; 672 } 673 leaf app { 674 type identityref { 675 base nsfmi:application-protocol; 676 } 677 description 678 "The employed application layer protocol"; 679 } 680 leaf attack-type { 681 type identityref { 682 base nsfmi:intrusion-attack-type; 683 } 684 description 685 "The sub attack type for intrusion attack"; 686 } 687 description 688 "An intrusion is detected"; 690 } 691 } 692 case web-attack-detected { 693 container web-attack-detected { 694 leaf attack-type { 695 type identityref { 696 base nsfmi:web-attack-type; 697 } 698 description 699 "Concrete web attack type, e.g., SQL injection, 700 command injection, XSS, and CSRF."; 701 } 702 leaf req-method { 703 type identityref { 704 base nsfmi:req-method; 705 } 706 description 707 "The HTTP request method, e.g., PUT or GET."; 708 reference 709 "draft-ietf-httpbis-semantics-19: HTTP Semantics - 710 Request Methods"; 711 } 712 leaf req-uri { 713 type string; 714 description 715 "The Requested URI"; 716 } 717 leaf req-user-agent { 718 type string; 719 description 720 "The request user agent"; 721 } 722 leaf cookies { 723 type string; 724 description 725 "The HTTP Cookies header field of the request from 726 the user agent. The cookie information needs to be 727 kept confidential and is NOT RECOMMENDED to be 728 included in the monitoring data unless the information 729 is absolutely necessary to help to enhance the 730 security of the network."; 731 reference 732 "RFC 6265: HTTP State Management Mechanism - Cookie"; 733 } 734 leaf req-host { 735 type string; 736 description 737 "The domain name of the requested host"; 739 } 740 leaf response-code { 741 type string; 742 description 743 "The HTTP Response code"; 744 reference 745 "IANA Website: Hypertext Transfer Protocol (HTTP) 746 Status Code Registry"; 747 } 748 description 749 "A web attack is detected"; 750 } 751 description 752 "A web attack is detected"; 753 } 754 case voip-vocn-detected { 755 container voip-vocn-detected { 756 leaf-list source-voice-id { 757 type string; 758 description 759 "The detected source voice ID for Voice over Internet 760 Protocol (VoIP) and Voice over Cellular Network 761 (VoCN) that violates the security policy."; 762 } 763 leaf-list destination-voice-id { 764 type string; 765 description 766 "The detected destination voice ID for Voice over 767 Internet Protocol (VoIP) and Voice over Cellular 768 Network (VoCN) that violates the security policy."; 769 } 770 leaf-list user-agent { 771 type string; 772 description 773 "The detected user-agent for VoIP and VoCN that 774 violates the security policy."; 775 } 776 description 777 "A violation of VoIP/VoCN is detected"; 778 } 779 description 780 "A violation of VoIP/VoCN is detected"; 781 } 782 } 783 } 784 } 786 list i2nsf-feedback-information { 787 key "nsf-name time"; 789 description 790 "Feedback information is information about problem(s) of an 791 NSF for a security service such as system resource over-usage 792 or malfunction. "; 794 leaf nsf-name { 795 type union { 796 type string; 797 type inet:ip-address; 798 } 799 description 800 "The name or IP address (IPv4 or IPv6) of the NSF to be 801 configured. If the given nsf-name is not IP address, the 802 name can be an arbitrary string including FQDN (Fully 803 Qualified Domain Name)."; 804 } 806 leaf time { 807 type yang:date-and-time; 808 description 809 "The time of the feedback information delivered"; 810 } 812 leaf language { 813 type string { 814 pattern '(([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})' 815 + '{0,2})?|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})?' 816 + '(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}' 817 + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WY-Za-wy-z]' 818 + '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]' 819 + '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|' 820 + '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-' 821 + '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-' 822 + '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-' 823 + '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]' 824 + '|[Ii]-[Hh][Aa][Kk]|' 825 + '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|' 826 + '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|' 827 + '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|' 828 + '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|' 829 + '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|' 830 + '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-' 831 + '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-' 832 + '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-' 833 + '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|' 834 + '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-' 835 + '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|' 836 + '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-' 837 + '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-' 838 + '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))'; 839 } 840 default "en-US"; 841 description 842 "The value in this field indicates the language tag 843 used for all of the text in the module 844 (i.e., 'leaf message' and 'leaf-list solution'). 846 The attribute is encoded following the rules in Section 2.1 847 in RFC 5646. The default language tag is 'en-US'"; 848 reference 849 "RFC 5646: Tags for Identifying Languages"; 850 } 852 container problem { 853 description 854 "The issue that is emitted by an NSF via the I2NSF Monitoring 855 Interface. The problem for feedback information includes the 856 system alarms, such as Memory alarm, CPU alarm, Disk alarm, 857 Hardware alarm, and Interface alarm."; 858 choice alarm-type { 859 description 860 "The detected alarm type"; 861 case memory-alarm { 862 container memory-alarm { 863 leaf usage { 864 type uint8 { 865 range "0..100"; 866 } 867 units "percent"; 868 description 869 "The average usage for the duration of the alarm."; 870 } 871 leaf message { 872 type string; 873 description 874 "A message explaining the problem."; 875 } 876 leaf duration { 877 type uint32; 878 description 879 "Specify the duration of the first alarm triggered 880 until the feedback information is created."; 881 } 882 description 883 "The container for memory-alarm"; 884 } 885 description 886 "The detected alarm type is memory-alarm"; 887 } 888 case cpu-alarm { 889 container cpu-alarm { 890 leaf usage { 891 type uint8 { 892 range "0..100"; 893 } 894 units "percent"; 895 description 896 "The average usage for the duration of the alarm."; 897 } 898 leaf message { 899 type string; 900 description 901 "A message explaining the problem."; 902 } 903 leaf duration { 904 type uint32; 905 description 906 "Specify the duration of the first alarm triggered 907 until the feedback information is created."; 908 } 909 description 910 "The container for cpu-alarm"; 911 } 912 description 913 "The detected alarm type is cpu-alarm"; 914 } 915 case disk-alarm { 916 container disk-alarm { 917 leaf disk-id { 918 type string; 919 description 920 "The ID of the storage disk. It is a free form 921 identifier to identify the storage disk."; 922 } 923 leaf usage { 924 type uint8 { 925 range "0..100"; 926 } 927 units "percent"; 928 description 929 "The average usage for the duration of the alarm."; 930 } 931 leaf message { 932 type string; 933 description 934 "A message explaining the problem."; 935 } 936 leaf duration { 937 type uint32; 938 description 939 "Specify the duration of the first alarm triggered 940 until the feedback information is created."; 941 } 942 description 943 "The container for disk-alarm"; 944 } 945 description 946 "The detected alarm type is disk-alarm"; 947 } 948 case hardware-alarm { 949 container hardware-alarm { 950 leaf component-name { 951 type string; 952 description 953 "The hardware component responsible for generating 954 the message. Applicable for Hardware Failure 955 Alarm."; 956 } 957 leaf message { 958 type string; 959 description 960 "A message explaining the problem."; 961 } 962 leaf duration { 963 type uint32; 964 description 965 "Specify the duration of the first alarm triggered 966 until the feedback information is created."; 967 } 968 description 969 "The container for hardware-alarm"; 970 } 971 description 972 "The detected alarm type is hardware-alarm"; 973 } 974 case interface-alarm { 975 container interface-alarm { 976 leaf interface-id { 977 type string; 978 description 979 "The interface ID responsible for generating 980 the message."; 981 } 982 leaf interface-state { 983 type enumeration { 984 enum up { 985 value 1; 986 description 987 "The interface state is up and not congested. 988 The interface is ready to pass packets."; 989 } 990 enum down { 991 value 2; 992 description 993 "The interface state is down, i.e., does not pass 994 any packets."; 995 } 996 enum congested { 997 value 3; 998 description 999 "The interface state is up but congested."; 1000 } 1001 enum testing { 1002 value 4; 1003 description 1004 "In some test mode. No operational packets can 1005 be passed."; 1006 } 1007 enum unknown { 1008 value 5; 1009 description 1010 "Status cannot be determined for some reason."; 1011 } 1012 enum dormant { 1013 value 6; 1014 description 1015 "Waiting for some external event."; 1016 } 1017 enum not-present { 1018 value 7; 1019 description 1020 "Some component (typically hardware) is 1021 missing."; 1022 } 1023 enum lower-layer-down { 1024 value 8; 1025 description 1026 "Down due to state of lower-layer interface(s)."; 1028 } 1029 } 1030 description 1031 "The state of the interface. Applicable for Network 1032 Interface Failure Alarm."; 1033 reference 1034 "RFC 8343: A YANG Data Model for Interface Management 1035 - Operational States"; 1036 } 1037 leaf message { 1038 type string; 1039 description 1040 "A message explaining the problem."; 1041 } 1042 leaf duration { 1043 type uint32; 1044 description 1045 "Specify the duration of the first alarm triggered 1046 until the feedback information is created."; 1047 } 1048 description 1049 "The container for interface-alarm"; 1050 } 1051 description 1052 "The detected alarm type is interface-alarm"; 1053 } 1054 } 1055 } 1057 leaf-list solution { 1058 type string; 1059 description 1060 "A possible solution given as feedback is in the form of 1061 a free-form string (as a high-level instruction)."; 1062 } 1063 } 1064 } 1065 1067 Figure 7: YANG for Application Interface 1069 5. IANA Considerations 1071 This document requests IANA to register the following URI in the 1072 "IETF XML Registry" [RFC3688]: 1074 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-feedback-policy 1075 Registrant Contact: The IESG. 1076 XML: N/A; the requested URI is an XML namespace. 1078 This document requests IANA to register the following YANG module in 1079 the "YANG Module Names" registry [RFC7950][RFC8525]: 1081 name: ietf-i2nsf-feedback-policy 1082 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-feedback-policy 1083 prefix: nsffb 1084 reference: RFC XXXX 1086 // RFC Ed.: replace XXXX with an actual RFC number and remove 1087 // this note. 1089 6. XML Configuration Examples of Feedback Policy 1091 This section shows XML configuration examples of feedback policy 1092 rules that are delivered from the I2NSF Analyzer to the Security 1093 Controller over the Application Interface after the I2NSF Analyzer 1094 analyzes the Monitoring Information. 1096 6.1. Feedback Policy for DDoS Detection 1098 In this example, the scenario can be seen in Figure 8. 1100 +---------------------------------+ 1101 +---------------+ | Secure Network (203.0.113.0/24) | 1102 | DDoS Attacker | | | 1103 | 192.0.2.8, | DDoS | +---------+ +---------+ | 1104 | 192.0.2.9, +-------->| |Firewall | |Server 1 | | 1105 | 192.0.2.10 | Attack | +---------+ +---------+ | 1106 +---------------+ | | | 1107 | v +---------+ | 1108 | +---------+ |Server 2 | | 1109 | |DDoS | ----> +---------+ | 1110 | |Mitigator| | 1111 | +---------+ +---------+ | 1112 | |Server 3 | | 1113 | +---------+ | 1114 +---------------------------------+ 1116 Figure 8: A Scenario Example of DDoS Attack 1118 In this scenario, a DDoS Mitigator detects a DDoS Attack and sends a 1119 notification to the I2NSF Analyzer as shown in Figure 9. 1121 1122 1124 2021-08-27T09:00:01.00Z 1125 1127 subscription 1128 on-change 1129 on-repetition 1130 1131 nsfmi:syn-flood 1132 2021-08-27T09:00:00.00Z 1133 192.0.2.8 1134 192.0.2.9 1135 192.0.2.10 1136 203.0.113.0/24 1137 100 1138 A DDoS Attack is detected 1139 DDoS_mitigator 1140 1141 1142 1144 Figure 9: A Detected DDoS Attack by DDoS Mitigator 1146 In the scenario shown in Figure 9, the description of the XML example 1147 is as follows: 1149 1. The DDoS attack is detected at 9 am on August 27 in 2021. 1151 2. The sources of the attack are 192.0.2.8, 192.0.2.9, and 1152 192.0.2.10. 1154 3. The destination of the attack is 203.0.113.0/24. 1156 After receiving the information, the I2NSF Analyzer analyzes the data 1157 and creates a new feedback policy to enforce the security of the 1158 network. The I2NSF Analyzer delivers a feedback policy to the 1159 Security Controller as shown in Figure 10. 1161 1162 1164 1165 feedback_policy_for_ddos_attack 1166 1167 1168 deny_ddos_attack 1169 1170 1171 1172 192.0.2.8 1173 192.0.2.10 1174 1175 1176 1177 1180 1181 1182 1183 1184 drop 1185 1186 1187 1188 Firewall 1189 1190 1191 192.0.2.8 1192 192.0.2.9 1193 192.0.2.10 1194 203.0.113.0/24 1195 1196 1197 1199 Figure 10: Policy Reconfiguration for a Detected DDoS Attack 1201 The policy reconfiguration in Figure 10 means the following: 1203 1. The feedback policy is named as 1204 "feedback_policy_for_ddos_attack". 1206 2. The rule is named as "deny_ddos_attack". 1208 3. The rule starts from 09:00 am on August 24 in 2021. The 1209 condition of the rule is from the sources of the IP addresses 1210 192.0.2.8, 192.0.2.9, and 192.0.2.10. 1212 4. The action required is to "drop" any access from the the IP 1213 addresses have been identified as malicious. 1215 5. The NSF to be configured is named "Firewall". 1217 6. The problem that triggered the generation of the feedback is a 1218 DDoS attack from the sources of the IP addresses 192.0.2.8, 1219 192.0.2.9, and 192.0.2.10 to the protected network of 1220 203.0.113.0/24. 1222 6.2. Feedback Information for Overloaded NSF 1224 In this scenario, an NSF is overloaded and sends a notification to 1225 the I2NSF Analyzer as shown in Figure 11. 1227 1228 1230 2021-08-27T07:43:52.181088+00:00 1231 1233 subscription 1234 on-change 1235 on-repetition 1236 en-US 1237 1238 memory-alarm 1239 91 1240 90 1241 Memory Usage Exceeded the Threshold 1242 time_based_firewall 1243 high 1244 1245 1246 1248 Figure 11: The Monitoring of an Overloaded NSF 1250 In the scenario shown in Figure 11, the description of the XML 1251 example is as follows: 1253 1. The NSF that sends the information is named "firewall". 1255 2. The memory usage of the NSF triggered the alarm. 1257 3. The memory usage of the NSF is 98 percent. 1259 4. The memory threshold to trigger the alarm is 80 percent. 1261 5. The event is delivered at 2021-08-27T07:43:52.181088+00:00. 1263 After receiving the information, the I2NSF Analyzer analyzes the data 1264 and creates a new feedback policy to solve the problem that is 1265 detected in the NSF. The I2NSF Analyzer delivers a feedback 1266 information to the Security Controller as shown in Figure 12. 1268 1269 1271 1272 Firewall 1273 en-US 1274 1275 1276 95 1277 Memory Usage Exceeded the Threshold 1278 3600 1279 1280 1281 1282 Add more memory capacity to the NSF 1283 1284 1285 Create a new NSF with the same security service 1286 1287 1289 Figure 12: Feedback Information for the Overloaded NSF 1291 The feedback information in Figure 12 means the following: 1293 1. The name of the NSF that needs to be handled is called 1294 "Firewall". 1296 2. The feedback information is delivered at 1297 2021-08-27T08:43:52.000000+00:00. 1299 3. The problem is that the Memory Usage Exceeded the Threshold with 1300 the average usage of memory as 95. 1302 4. The problem persists for 3,600 seconds (1 hour) without any fix. 1304 5. The proposed solution to the problem is to add more memory 1305 capacity in hardware to the NSF or to create a new NSF with the 1306 same security service. 1308 7. Security Considerations 1310 The YANG module specified in this document defines a data schema 1311 designed to be accessed through network management protocols such as 1312 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is 1313 the secure transport layer, and the required secure transport is 1314 Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, 1315 and the required secure transport is TLS [RFC8446]. 1317 The NETCONF access control model [RFC8341] provides a means of 1318 restricting access to specific NETCONF or RESTCONF users to a 1319 preconfigured subset of all available NETCONF or RESTCONF protocol 1320 operations and content. 1322 There are a number of data nodes defined in this YANG module that are 1323 writable/creatable/deletable (i.e., config true, which is the 1324 default). These data nodes may be considered sensitive or vulnerable 1325 in some network environments. Write operations (e.g., edit-config) 1326 to these data nodes without proper protection can have a negative 1327 effect on network operations. And the data model in this document 1328 uses the data model from NSF-Facing Interface data model, it MUST 1329 follow the Security Considerations mentioned in the 1330 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 1332 Some of the readable data nodes in this YANG module may be considered 1333 sensitive or vulnerable in some network environments. It is thus 1334 important to control read access (e.g., via get, get-config, or 1335 notification) to these data nodes. This document also MUST follow 1336 the Security Considerations about the readable data nodes mentioned 1337 in the [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 1339 8. References 1341 8.1. Normative References 1343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1344 Requirement Levels", BCP 14, RFC 2119, 1345 DOI 10.17487/RFC2119, March 1997, 1346 . 1348 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1349 DOI 10.17487/RFC3688, January 2004, 1350 . 1352 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 1353 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 1354 September 2009, . 1356 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1357 and A. Bierman, Ed., "Network Configuration Protocol 1358 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1359 . 1361 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1362 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1363 . 1365 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1366 DOI 10.17487/RFC6265, April 2011, 1367 . 1369 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1370 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1371 . 1373 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1374 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1375 . 1377 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1378 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1379 . 1381 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1382 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1383 May 2017, . 1385 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1386 Kumar, "Framework for Interface to Network Security 1387 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 1388 . 1390 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1391 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1392 . 1394 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1395 Access Control Model", STD 91, RFC 8341, 1396 DOI 10.17487/RFC8341, March 2018, 1397 . 1399 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1400 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1401 . 1403 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1404 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1405 DOI 10.17487/RFC8407, October 2018, 1406 . 1408 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1409 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1410 . 1412 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 1413 and R. Wilton, "YANG Library", RFC 8525, 1414 DOI 10.17487/RFC8525, March 2019, 1415 . 1417 [I-D.ietf-httpbis-semantics] 1418 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 1419 Semantics", Work in Progress, Internet-Draft, draft-ietf- 1420 httpbis-semantics-19, 12 September 2021, 1421 . 1424 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 1425 Kim, J. (., Jeong, J. (., Park, J., Hares, S., and Q. Lin, 1426 "I2NSF Network Security Function-Facing Interface YANG 1427 Data Model", Work in Progress, Internet-Draft, draft-ietf- 1428 i2nsf-nsf-facing-interface-dm-26, 19 April 2022, 1429 . 1432 [I-D.ietf-i2nsf-capability-data-model] 1433 Hares, S., Jeong, J. (., Kim, J. (., Moskowitz, R., and Q. 1434 Lin, "I2NSF Capability YANG Data Model", Work in Progress, 1435 Internet-Draft, draft-ietf-i2nsf-capability-data-model-30, 1436 13 April 2022, . 1439 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 1440 Jeong, J. (., Lingga, P., Hares, S., Xia, L. (., and H. 1441 Birkholz, "I2NSF NSF Monitoring Interface YANG Data 1442 Model", Work in Progress, Internet-Draft, draft-ietf- 1443 i2nsf-nsf-monitoring-data-model-18, 19 April 2022, 1444 . 1447 8.2. Informative References 1449 [I-D.jeong-i2nsf-security-management-automation] 1450 Jeong, J. (., Lingga, P., and J. Park, "An Extension of 1451 I2NSF Framework for Security Management Automation in 1452 Cloud-Based Security Services", Work in Progress, 1453 Internet-Draft, draft-jeong-i2nsf-security-management- 1454 automation-03, 21 February 2022, 1455 . 1458 [I-D.ietf-i2nsf-applicability] 1459 Jeong, J. P., Hyun, S., Ahn, T., Hares, S., and D. R. 1460 Lopez, "Applicability of Interfaces to Network Security 1461 Functions to Network-Based Security Services", Work in 1462 Progress, Internet-Draft, draft-ietf-i2nsf-applicability- 1463 18, 16 September 2019, . 1466 [Deep-Learning] 1467 Goodfellow, I., Bengio, Y., and A. Courville, "Deep 1468 Learning", Publisher: The MIT Press, 1469 URL: https://www.deeplearningbook.org/, November 2016. 1471 Appendix A. Acknowledgments 1473 This document is a product by the I2NSF Working Group (WG) including 1474 WG Chairs (i.e., Linda Dunbar and Yoav Nir) and Diego Lopez. This 1475 document took advantage of the review and comments from the following 1476 experts: Roman Danyliw and Tom Petch. The authors sincerely 1477 appreciate their sincere efforts and kind help. 1479 This work was supported by Institute of Information & Communications 1480 Technology Planning & Evaluation (IITP) grant funded by the Korea 1481 MSIT (Ministry of Science and ICT) (2020-0-00395, Standard 1482 Development of Blockchain based Network Management Automation 1483 Technology). This work was supported in part by the IITP 1484 (R-20160222-002755, Cloud based Security Intelligence Technology 1485 Development for the Customized Security Service Provisioning). This 1486 work was supported in part by the MSIT under the Information 1487 Technology Research Center (ITRC) support program (IITP- 1488 2022-2017-0-01633) supervised by the IITP. 1490 Appendix B. Contributors 1492 The following are co-authors of this document: 1494 Jeonghyeon Kim - Department of Electrical and Computer Engineering, 1495 Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 1496 16419, Republic of Korea, EMail: jeonghyeon12@skku.edu 1498 Jung-Soo Park - Electronics and Telecommunications Research 1499 Institute, 218 Gajeong-Ro, Yuseong-Gu, Daejeon, 34129, Republic of 1500 Korea, EMail: pjs@etri.re.kr 1502 Younghan Kim - School of Electronic Engineering, Soongsil University, 1503 369, Sangdo-ro, Dongjak-gu, Seoul 06978, Republic of Korea, EMail: 1504 younghak@ssu.ac.kr 1506 Appendix C. Changes from draft-lingga-i2nsf-application-interface-dm-02 1508 The following changes are made from draft-lingga-i2nsf-application- 1509 interface-dm-02: 1511 * This version has been updated to follow the latest versions of the 1512 NSF-Facing Interface YANG Data Model 1513 [I-D.ietf-i2nsf-nsf-facing-interface-dm] and the NSF Monitoring 1514 Interface YANG Data Model 1515 [I-D.ietf-i2nsf-nsf-monitoring-data-model]. 1517 * Especially, the XML examples are updated to follow the latest 1518 versions of both the YANG data models. 1520 Authors' Addresses 1522 Patrick Lingga (editor) 1523 Department of Electrical and Computer Engineering 1524 Sungkyunkwan University 1525 2066 Seobu-Ro, Jangan-Gu 1526 Suwon 1527 Gyeonggi-Do 1528 16419 1529 Republic of Korea 1530 Phone: +82 31 299 4957 1531 Email: patricklink@skku.edu 1533 Jaehoon Paul Jeong (editor) 1534 Department of Computer Science and Engineering 1535 Sungkyunkwan University 1536 2066 Seobu-Ro, Jangan-Gu 1537 Suwon 1538 Gyeonggi-Do 1539 16419 1540 Republic of Korea 1541 Phone: +82 31 299 4957 1542 Email: pauljeong@skku.edu 1543 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1545 Yunchul Choi 1546 Electronics and Telecommunications Research Institute 1547 218 Gajeong-Ro, Yuseong-Gu 1548 Daejeon 1549 34129 1550 Republic of Korea 1551 Phone: +82 42 860 5978 1552 Email: cyc79@etri.re.kr