idnits 2.17.1 draft-ietf-i2nsf-nsf-monitoring-data-model-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 29, 2021) is 1086 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) == Unused Reference: 'RFC2119' is defined on line 3817, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2nsf-capability' is defined on line 3944, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Unknown state RFC: RFC 956 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 3954 ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Downref: Normative reference to an Historic RFC: RFC 6587 ** Downref: Normative reference to an Informational RFC: RFC 8329 == Outdated reference: A later version (-31) exists of draft-ietf-i2nsf-consumer-facing-interface-dm-13 == Outdated reference: A later version (-29) exists of draft-ietf-i2nsf-nsf-facing-interface-dm-12 == Outdated reference: A later version (-26) exists of draft-ietf-i2nsf-registration-interface-dm-10 == Outdated reference: A later version (-16) exists of draft-yang-i2nsf-security-policy-translation-08 Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jeong, Ed. 3 Internet-Draft P. Lingga 4 Intended status: Standards Track Sungkyunkwan University 5 Expires: October 31, 2021 S. Hares 6 L. Xia 7 Huawei 8 H. Birkholz 9 Fraunhofer SIT 10 April 29, 2021 12 I2NSF NSF Monitoring Interface YANG Data Model 13 draft-ietf-i2nsf-nsf-monitoring-data-model-08 15 Abstract 17 This document proposes an information model and the corresponding 18 YANG data model of an interface for monitoring Network Security 19 Functions (NSFs) in the Interface to Network Security Functions 20 (I2NSF) framework. If the monitoring of NSFs is performed with the 21 NSF monitoring interface in a comprehensive way, it is possible to 22 detect the indication of malicious activity, anomalous behavior, the 23 potential sign of denial of service attacks, or system overload in a 24 timely manner. This monitoring functionality is based on the 25 monitoring information that is generated by NSFs. Thus, this 26 document describes not only an information model for the NSF 27 monitoring interface along with a YANG data diagram, but also the 28 corresponding YANG data model. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on October 31, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Use Cases for NSF Monitoring Data . . . . . . . . . . . . . . 4 67 4. Classification of NSF Monitoring Data . . . . . . . . . . . . 5 68 4.1. Retention and Emission . . . . . . . . . . . . . . . . . 6 69 4.2. Notifications and Events . . . . . . . . . . . . . . . . 7 70 4.3. Unsolicited Poll and Solicited Push . . . . . . . . . . . 7 71 4.4. I2NSF Monitoring Terminology for Retained Information . . 8 72 5. Conveyance of NSF Monitoring Information . . . . . . . . . . 9 73 5.1. Information Types and Acquisition Methods . . . . . . . . 10 74 6. Basic Information Model for All Monitoring Data . . . . . . . 10 75 7. Extended Information Model for Monitoring Data . . . . . . . 11 76 7.1. System Alarms . . . . . . . . . . . . . . . . . . . . . . 11 77 7.1.1. Memory Alarm . . . . . . . . . . . . . . . . . . . . 11 78 7.1.2. CPU Alarm . . . . . . . . . . . . . . . . . . . . . . 11 79 7.1.3. Disk Alarm . . . . . . . . . . . . . . . . . . . . . 12 80 7.1.4. Hardware Alarm . . . . . . . . . . . . . . . . . . . 12 81 7.1.5. Interface Alarm . . . . . . . . . . . . . . . . . . . 12 82 7.2. System Events . . . . . . . . . . . . . . . . . . . . . . 13 83 7.2.1. Access Violation . . . . . . . . . . . . . . . . . . 13 84 7.2.2. Configuration Change . . . . . . . . . . . . . . . . 13 85 7.2.3. Traffic flows . . . . . . . . . . . . . . . . . . . . 14 86 7.3. NSF Events . . . . . . . . . . . . . . . . . . . . . . . 14 87 7.3.1. DDoS Detection . . . . . . . . . . . . . . . . . . . 14 88 7.3.2. Session Table Event . . . . . . . . . . . . . . . . . 15 89 7.3.3. Virus Event . . . . . . . . . . . . . . . . . . . . . 15 90 7.3.4. Intrusion Event . . . . . . . . . . . . . . . . . . . 16 91 7.3.5. Botnet Event . . . . . . . . . . . . . . . . . . . . 16 92 7.3.6. Web Attack Event . . . . . . . . . . . . . . . . . . 17 93 7.4. System Logs . . . . . . . . . . . . . . . . . . . . . . . 18 94 7.4.1. Access Log . . . . . . . . . . . . . . . . . . . . . 18 95 7.4.2. Resource Utilization Log . . . . . . . . . . . . . . 19 96 7.4.3. User Activity Log . . . . . . . . . . . . . . . . . . 19 97 7.5. NSF Logs . . . . . . . . . . . . . . . . . . . . . . . . 20 98 7.5.1. DPI Log . . . . . . . . . . . . . . . . . . . . . . . 20 99 7.5.2. Vulnerability Scanning Log . . . . . . . . . . . . . 21 100 7.6. System Counter . . . . . . . . . . . . . . . . . . . . . 21 101 7.6.1. Interface Counter . . . . . . . . . . . . . . . . . . 21 102 7.7. NSF Counters . . . . . . . . . . . . . . . . . . . . . . 22 103 7.7.1. Firewall Counter . . . . . . . . . . . . . . . . . . 22 104 7.7.2. Policy Hit Counter . . . . . . . . . . . . . . . . . 24 105 8. NSF Monitoring Management in I2NSF . . . . . . . . . . . . . 24 106 9. Tree Structure . . . . . . . . . . . . . . . . . . . . . . . 25 107 10. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 33 108 11. I2NSF Event Stream . . . . . . . . . . . . . . . . . . . . . 74 109 12. XML Examples for I2NSF NSF Monitoring . . . . . . . . . . . . 75 110 12.1. I2NSF System Detection Alarm . . . . . . . . . . . . . . 75 111 12.2. I2NSF Interface Counters . . . . . . . . . . . . . . . . 77 112 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78 113 14. Security Considerations . . . . . . . . . . . . . . . . . . . 79 114 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80 115 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 80 116 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 81 117 17.1. Normative References . . . . . . . . . . . . . . . . . . 81 118 17.2. Informative References . . . . . . . . . . . . . . . . . 84 119 Appendix A. Changes from draft-ietf-i2nsf-nsf-monitoring-data- 120 model-07 . . . . . . . . . . . . . . . . . . . . . . 86 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 123 1. Introduction 125 According to [RFC8329], the interface provided by a Network Security 126 Function (NSF) (e.g., Firewall, IPS, Anti-DDoS, or Anti-Virus 127 function) to administrative entities (e.g., Security Controller) to 128 enable remote management (i.e., configuring and monitoring) is 129 referred to as an I2NSF Monitoring Interface. Monitoring procedures 130 intent to acquire vital types of data with respect to NSFs, (e.g., 131 alarms, records, and counters) via data in motion (e.g., queries, 132 notifications, and events). The monitoring of NSF plays an important 133 role in an overall security framework, if it is done in a timely and 134 comprehensive way. The monitoring information generated by an NSF 135 can be a good, early indication of anomalous behavior or malicious 136 activity, such as denial of service attacks (DoS). 138 This document defines a comprehensive information model of an NSF 139 monitoring interface that provides visibility for an NSF for an NSF 140 data collector (e.g., Security Controller and NSF Data Analyzer). 141 Note that an NSF data collector is defined as an entity to collect 142 NSF monitoring data from an NSF, such as Security Controller and NSF 143 Data Analyzer. It specifies the information and illustrates the 144 methods that enable an NSF to provide the information required in 145 order to be monitored in a scalable and efficient way via the NSF 146 Monitoring Interface. The information model for the NSF monitoring 147 interface presented in this document is a complementary information 148 model to the information model for the security policy provisioning 149 functionality of the NSF-Facing Interface specified in 150 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 152 This document also defines a YANG [RFC7950] data model for the NSF 153 monitoring interface, which is derived from the information model for 154 the NSF monitoring interface. 156 2. Terminology 158 This document uses the terminology described in [RFC8329]. 160 This document follows the guidelines of [RFC8407], uses the common 161 YANG types defined in [RFC6991], and adopts the Network Management 162 Datastore Architecture (NMDA) [RFC8342]. The meaning of the symbols 163 in tree diagrams is defined in [RFC8340]. 165 3. Use Cases for NSF Monitoring Data 167 As mentioned earlier, monitoring plays a critical role in an overall 168 security framework. The monitoring of the NSF provides very valuable 169 information to an NSF data collector (e.g., Security Controller and 170 NSF data analyzer) in maintaining the provisioned security posture. 171 Besides this, there are various other reasons to monitor the NSF as 172 listed below: 174 o The security administrator with I2NSF User can configure a policy 175 that is triggered on a specific event occurring in the NSF or the 176 network [RFC8329] [I-D.ietf-i2nsf-consumer-facing-interface-dm]. 177 If an NSF data collector detects the specified event, it 178 configures additional security functions as defined by policies. 180 o The events triggered by an NSF as a result of security policy 181 violation can be used by Security Information and Event Management 182 (SIEM) to detect any suspicious activity in a larger correlation 183 context. 185 o The events and activity logs from an NSF can be used to build 186 advanced analytics, such as behavior and predictive models to 187 improve security posture in large deployments. 189 o The NSF data collector can use events from the NSF for achieving 190 high availability. It can take corrective actions such as 191 restarting a failed NSF and horizontally scaling up the NSF. 193 o The events and activity logs from the NSF can aid in the root 194 cause analysis of an operational issue, so it can improve 195 debugging. 197 o The activity logs from the NSF can be used to build historical 198 data for operational and business reasons. 200 4. Classification of NSF Monitoring Data 202 In order to maintain a strong security posture, it is not only 203 necessary not only to configure an NSF's security policies but also 204 to continuously monitor the NSF by consuming acquirable and 205 observable information. This enables security administrators to 206 assess the state of the network topology in a timely fashion. It is 207 not possible to block all the internal and external threats based on 208 static security posture. A more practical approach is supported by 209 enabling dynamic security measures, for which continuous visibility 210 is required. This document defines a set of information elements 211 (and their scope) that can be acquired from an NSF and can be used as 212 NSF monitoring information. In essence, these types of monitoring 213 information can be leveraged to support constant visibility on 214 multiple levels of granularity and can be consumed by the 215 corresponding functions. 217 Three basic domains about the monitoring information originating from 218 a system entity [RFC4949] or an NSF are highlighted in this document. 220 o Retention and Emission 222 o Notifications and Events 224 o Unsolicited Poll and Solicited Push 226 The Alarm Management Framework in [RFC3877] defines an Event as 227 something that happens as a thing of of interest. It defines a fault 228 as a change in status, crossing a threshold, or an external input to 229 the system. In the I2NSF domain, I2NSF events are created and the 230 scope of the Alarm Management Framework's Events is still applicable 231 due to its broad definition. The model presented in this document 232 elaborates on the workflow of creating I2NSF events in the context of 233 NSF monitoring and on the way initial I2NSF events are created. 235 As with I2NSF components, every generic system entity can include a 236 set of capabilities that creates information about the context, 237 composition, configuration, state or behavior of that system entity. 238 This information is intended to be provided to other consumers of 239 information and in the scope of this document, which deals with NSF 240 information monitoring in an automated fashion. 242 4.1. Retention and Emission 244 Typically, a system entity populates standardized interface, such as 245 SNMP, NETCONF, RESTCONF or CoMI to provide and emit created 246 information directly via NSF Monitoring Interface. Alternatively, 247 the created information is retained inside the system entity (or a 248 hierarchy of system entities in a composite device) via records or 249 counters that are not exposed directly via NSF Monistoring Interface. 251 Information emitted via standardized interfaces can be consumed by an 252 I2NSF User that includes the capability to consume information not 253 only via an I2NSF Interface (e.g., Consumer-Facing Interface 254 [I-D.ietf-i2nsf-consumer-facing-interface-dm]), but also via 255 interfaces complementary to the standardized interfaces a generic 256 system entity provides. 258 Information retained on a system entity requires a corresponding 259 I2NSF User to access aggregated records of information, typically in 260 the form of log-files or databases. There are ways to aggregate 261 records originating from different system entities over a network, 262 for examples via Syslog Protocol [RFC5424] or Syslog over TCP 263 [RFC6587]. But even if records are conveyed, the result is the same 264 kind of retention in form of a bigger aggregate of records on another 265 system entity. 267 An I2NSF User is required to process fresh [RFC4949] records created 268 by I2NSF Functions in order to provide them to other I2NSF Components 269 via the corresponding I2NSF Interfaces in a timely manner. This 270 process is effectively based on homogenizing functions, which can 271 access and convert specific kinds of records into information that 272 can be provided and emitted via I2NSF interfaces. 274 When retained or emitted, the information required to support 275 monitoring processes has to be processed by an I2NSF User at some 276 point in the workflow. Typical locations of these I2NSF Users are: 278 o a system entity that creates the information 280 o a system entity that retains an aggregation of records 282 o an I2NSF Component that includes the capabilities of using 283 standardized interfaces provided by other system entities that are 284 not I2NSF Components 286 o an I2NSF Component that creates the information 288 4.2. Notifications and Events 290 A specific task of I2NSF User is to process I2NSF Policy Rules. The 291 rules of a policy are composed of three clauses: Events, Conditions, 292 and Actions. In consequence, an I2NSF Event is specified to trigger 293 an I2NSF Policy Rule. Such an I2NSF Event is defined as any 294 important occurrence over time in the system being managed, and/or in 295 the environment of the system being managed, which aligns well with 296 the generic definition of Event from [RFC3877]. 298 The model illustrated in this document introduces a complementary 299 type of information that can be a conveyed notification. 301 Notification: An occurrence of a change of context, composition, 302 configuration, state or behavior of a system entity that can be 303 directly or indirectly observed by an I2NSF User and can be used 304 as input for an event-clause in I2NSF Policy Rules. 306 A notification is similar to an I2NSF Event with the exception 307 that it is created by a system entity that is not an I2NSF 308 Component and that its importance is yet to be assessed. 309 Semantically, a notification is not an I2NSF Event in the context 310 of I2NSF, although they can potentially use the exact same 311 information or data model. In respect to [RFC3877], a 312 Notification is a specific subset of events, because they convey 313 information about something that happens as a thing of of 314 interest. In consequence, Notifications may contain information 315 with very low expressiveness or relevance. Hence, additional 316 post-processing functions, such as aggregation, correlation or 317 simple anomaly detection, might have to be employed to satisfy a 318 level of expressiveness that is required for an event-clause of an 319 I2NSF Policy Rule. 321 It is important to note that the consumer of a notification (the 322 observer) assesses the importance of a notification and not the 323 producer. The producer can include metadata in a notification that 324 supports the observer in assessing the importance (even metadata 325 about severity), but the deciding entity is an I2NSF User. 327 4.3. Unsolicited Poll and Solicited Push 329 The freshness of the monitored information depends on the acquisition 330 method. Ideally, an I2NSF User is accessing every relevant 331 information about the I2NSF Component and is emitting I2NSF Events to 332 an NSF data collector (e.g., Security Controller and NSF data 333 analyzer) in a timely manner. Publication of events via a pubsub/ 334 broker model, peer-2-peer meshes, or static defined channels are only 335 a few examples on how a solicited push of I2NSF Events can be 336 facilitated. The actual mechanic implemented by an I2NSF Component 337 is out of the scope of this document. 339 Often, the corresponding management interfaces have to be queried in 340 intervals or on-demand if required by an I2NSF Policy rule. In some 341 cases, a collection of information has to be conducted via login 342 mechanics provided by a system entity. Accessing records of 343 information via this kind of unsolicited polls can introduce a 344 significant latency in regard to the freshness of the monitored 345 information. The actual definition of intervals implemented by an 346 I2NSF Component is also out of scope of this document. 348 4.4. I2NSF Monitoring Terminology for Retained Information 350 Records: Unlike information emitted via notifications and events, 351 records do not require immediate attention from an analyst but may 352 be useful for visibility and retroactive cyber forensic. 353 Depending on the record format, there are different qualities in 354 regard to structure and detail. Records are typically stored in 355 log-files or databases on a system entity or NSF. Records in the 356 form of log-files usually include less structures but potentially 357 more detailed information in regard to the changes of a system 358 entity's characteristics. In contrast, databases often use more 359 strict schemas or data models, therefore enforcing a better 360 structure. However, they inhibit storing information that do not 361 match those models ("closed world assumption"). Records can be 362 continuously processed by I2NSF Agents that act as I2NSF Producer 363 and emit events via functions specifically tailored to a certain 364 type of record. Typically, records are information generated 365 either by an NSF or a system entity about operational and 366 informational data, or various changes in system characteristics, 367 such as user activities, network/traffic status, and network 368 activity. They are important for debugging, auditing and security 369 forensic. 371 Counters: A specific representation of continuous value changes of 372 information elements that potentially occur in high frequency. 373 Prominent example are network interface counters, e.g., PDU amount 374 or byte amount, drop counters, and error counters. Counters are 375 useful in debugging and visibility into operational behavior of an 376 NSF. An I2NSF Agent that observes the progression of counters can 377 act as an I2NSF Producer and emit events in respect to I2NSF 378 Policy Rules. 380 5. Conveyance of NSF Monitoring Information 382 As per the use cases of NSF monitoring data, information needs to be 383 conveyed to various I2NSF Consumers based on requirements imposed by 384 I2NSF Capabilities and workflows. There are multiple aspects to be 385 considered in regard to the emission of monitoring information to 386 requesting parties as listed below: 388 o Pull-Push Model: A set of data can be pushed by an NSF to a 389 requesting party or pulled by a requesting party from an NSF. 390 Specific types of information might need both the models at the 391 same time if there are multiple I2NSF Consumers with varying 392 requirements. In general, any I2NSF Event including a high 393 severity assessment is considered to be of great importance and 394 should be processed as soon as possible (push-model). Records, in 395 contrast, are typically not as critical (pull-model). The I2NSF 396 Architecture does not mandate a specific scheme for each type of 397 information and is therefore out of scope of this document. 399 o Pub-Sub Model: In order for an I2NSF Provider to push monitoring 400 information to multiple appropriate I2NSF Consumers, a 401 subscription can be maintained by both I2NSF Components. 402 Discovery of available monitoring information can be supported by 403 an I2NSF Controller that takes the role of a broker and therefore 404 includes I2NSF Capabilities that support registration. 406 o Export Frequency: Monitoring information can be emitted 407 immediately upon generation by an NSF to requesting I2NSF 408 Consumers or can be pushed periodically. The frequency of 409 exporting the data depends upon its size and timely usefulness. 410 It is out of the scope of I2NSF and left to each NSF 411 implementation. 413 o Authentication: There may be a need for authentication between an 414 I2NSF Producer of monitoring information and its corresponding 415 I2NSF Consumer to ensure that critical information remains 416 confidential. Authentication in the scope of I2NSF can also 417 require its corresponding content authorization. This may be 418 necessary, for example, if an NSF emits monitoring information to 419 an I2NSF Consumer outside its administrative domain. The I2NSF 420 Architecture does not mandate when and how specific authentication 421 has to be implemented. 423 o Data-Transfer Model: Monitoring information can be pushed by an 424 NSF using a connection-less model that does require a persistent 425 connection or streamed over a persistent connection. An 426 appropriate model depends on the I2NSF Consumer requirements and 427 the semantics of the information to be conveyed. 429 o Data Model and Interaction Model for Data in Motion: There are a 430 lot of transport mechanisms such as IP, UDP, and TCP. There are 431 also open source implementations for specific set of data such as 432 systems counter, e.g. IPFIX [RFC7011] and NetFlow [RFC3954]. The 433 I2NSF does not mandate any specific method for a given data set, 434 so it is up to each implementation. 436 5.1. Information Types and Acquisition Methods 438 In this document, most defined information types defined benefit from 439 high visibility with respect to value changes, e.g., alarms and 440 records. In contrast, values that change monotonically in a 441 continuous way do not benefit from this high visibility. On the 442 contrary, emitting each change would result in a useless amount of 443 value updates. Hence, values, such as counter, are best acquired in 444 periodic intervals. 446 The mechanisms provided by YANG Push [I-D.ietf-netconf-yang-push] and 447 YANG Subscribed Notifications 448 [I-D.ietf-netconf-subscribed-notifications] address exactly these set 449 of requirements. YANG also enables semantically well-structured 450 information, as well as subscriptions to datastores or event streams 451 - by changes or periodically. 453 In consequence, this information model in this document is intended 454 to support data models used in solicited or unsolicited event streams 455 that potentially are facilitated by a subscription mechanism. A 456 subset of information elements defined in the information model 457 address this domain of application. 459 6. Basic Information Model for All Monitoring Data 461 As explained in the above section, there is a wealth of data 462 available from the NSF that can be monitored. Firstly, there must be 463 some general information with each monitoring message sent from an 464 NSF that helps a consumer to identify meta data with that message, 465 which are listed as below: 467 o message: Event, Alert, Alarm, Log, Counter, etc. 469 o vendor-name: The name of the NSF vendor. 471 o nsf-name: The name (or IP) of the NSF generating the message. 473 o severity: It indicates the severity level. There are total four 474 levels, from 0 to 3. The smaller the numeral is, the higher the 475 severity is. 477 7. Extended Information Model for Monitoring Data 479 This section covers the additional information associated with the 480 system messages. The extended information model is only for the 481 structured data such as alarm. Any unstructured data is specified 482 with basic information model only. 484 7.1. System Alarms 486 Characteristics: 488 o acquisition-method: subscription 490 o emission-type: on-change 492 o dampening-type: on-repetition 494 7.1.1. Memory Alarm 496 The following information should be included in a Memory Alarm: 498 o event-name: mem-usage-alarm 500 o usage: specifies the size of memory used. 502 o threshold: The threshold triggering the alarm 504 o severity: The severity of the alarm such as critical, high, 505 medium, low 507 o message: The memory usage exceeded the threshold 509 7.1.2. CPU Alarm 511 The following information should be included in a CPU Alarm: 513 o event-name: cpu-usage-alarm 515 o usage: Specifies the size of CPU used. 517 o threshold: The threshold triggering the event 519 o severity: The severity of the alarm such as critical, high, 520 medium, low 522 o message: The CPU usage exceeded the threshold. 524 7.1.3. Disk Alarm 526 The following information should be included in a Disk Alarm: 528 o event-name: disk-usage-alarm 530 o usage: Specifies the size of disk space used. 532 o threshold: The threshold triggering the event 534 o severity: The severity of the alarm such as critical, high, 535 medium, low 537 o message: The disk usage exceeded the threshold. 539 7.1.4. Hardware Alarm 541 The following information should be included in a Hardware Alarm: 543 o event-name: hw-failure-alarm 545 o component-name: It indicates the HW component responsible for 546 generating this alarm. 548 o severity: The severity of the alarm such as critical, high, 549 medium, low 551 o message: The HW component has failed or degraded. 553 7.1.5. Interface Alarm 555 The following information should be included in an Interface Alarm: 557 o event-name: ifnet-state-alarm 559 o interface-name: The name of interface 561 o interface-state: up, down, congested 563 o threshold: The threshold triggering the event 565 o severity: The severity of the alarm such as critical, high, 566 medium, low 568 o message: Current interface state 570 7.2. System Events 572 Characteristics: 574 o acquisition-method: subscription 576 o emission-type: on-change 578 o dampening-type: on-repetition 580 7.2.1. Access Violation 582 The following information should be included in this event: 584 o event-name: access-denied 586 o user: Name of a user 588 o group: Group to which a user belongs 590 o login-ip-address: Login IP address of a user 592 o authentication: User authentication mode. e.g., Local 593 Authentication, Third-Party Server Authentication, Authentication 594 Exemption, Single Sign-On (SSO) Authentication 596 o message: access is denied. 598 7.2.2. Configuration Change 600 The following information should be included in this event: 602 o event-name: config-change 604 o user: Name of a user 606 o group: Group to which a user belongs 608 o login-ip-address: Login IP address of a user 610 o authentication: User authentication mode. e.g., Local 611 Authentication, Third-Party Server Authentication, Authentication 612 Exemption, SSO Authentication 614 o message: Configuration is modified. 616 7.2.3. Traffic flows 618 The following information should be included in this event: 620 o src-ip: The source IPv4 or IPv6 address of the flows 622 o dst-ip: The destination IPv4 or IPv6 address of the flows 624 o src-port: The source port of the flows 626 o dst-port: The destination port of the flows 628 o protocol: The protocol of the packet flows. 630 o arrival-rate: Arrival rate of the same flow. 632 7.3. NSF Events 634 Characteristics: 636 o acquisition-method: subscription 638 o emission-type: on-change 640 o dampening-type: on-repetition 642 7.3.1. DDoS Detection 644 The following information should be included in a DDoS Event: 646 o event-name: detection-ddos 648 o attack-type: Any one of SYN flood, ACK flood, SYN-ACK flood, FIN/ 649 RST flood, TCP Connection flood, UDP flood, ICMP flood, HTTPS 650 flood, HTTP flood, DNS query flood, DNS reply flood, SIP flood, 651 and etc. 653 o dst-ip: The IP address of a victim under attack 655 o dst-port: The port number that the attack traffic aims at. 657 o start-time: The time stamp indicating when the attack started 659 o end-time: The time stamp indicating when the attack ended. If the 660 attack is still undergoing when sending out the alarm, this field 661 can be empty. 663 o attack-rate: The PPS of attack traffic 664 o attack-speed: the bps of attack traffic 666 o rule-name: The name of the rule being triggered 668 o profile: Security profile that traffic matches. 670 7.3.2. Session Table Event 672 The following information should be included in a Session 673 Table Event: 675 o event-name: session-table 677 o current-session: The number of concurrent sessions 679 o maximum-session: The maximum number of sessions that the session 680 table can support 682 o threshold: The threshold triggering the event 684 o message: The number of session table exceeded the threshold. 686 7.3.3. Virus Event 688 The following information should be included in a Virus Event: 690 o event-name: detection-virus 692 o virus: Type of the virus. e.g., trojan, worm, macro virus type 694 o virus-name: Name of the virus 696 o dst-ip: The destination IP address of the packet where the virus 697 is found 699 o src-ip: The source IP address of the packet where the virus is 700 found 702 o src-port: The source port of the packet where the virus is found 704 o dst-port: The destination port of the packet where the virus is 705 found 707 o src-zone: The source security zone of the packet where the virus 708 is found 710 o dst-zone: The destination security zone of the packet where the 711 virus is found 713 o file-type: The type of the file where the virus is hided within 715 o file-name: The name of the file where the virus is hided within 717 o raw_info: The information describing the packet triggering the 718 event. 720 o rule_name: The name of the rule being triggered 722 7.3.4. Intrusion Event 724 The following information should be included in an Intrusion Event: 726 o event-name: The name of event. e.g., detection-intrusion 728 o attack-type: Attack type, e.g., brutal force and buffer overflow 730 o src-ip: The source IP address of the packet 732 o dst-ip: The destination IP address of the packet 734 o src-port:The source port number of the packet 736 o dst-port: The destination port number of the packet 738 o src-zone: The source security zone of the packet 740 o dst-zone: The destination security zone of the packet 742 o protocol: The employed transport layer protocol. e.g.,TCP and UDP 744 o app: The employed application layer protocol. e.g.,HTTP and FTP 746 o rule-name: The name of the rule being triggered 748 o raw-info: The information describing the packet triggering the 749 event 751 7.3.5. Botnet Event 753 The following information should be included in a Botnet Event: 755 o event-name: The name of event. e.g., detection-botnet 757 o botnet-name: The name of the detected botnet 759 o src-ip: The source IP address of the packet 760 o dst-ip: The destination IP address of the packet 762 o src-port: The source port number of the packet 764 o dst-port: The destination port number of the packet 766 o src-zone: The source security zone of the packet 768 o dst-zone: The destination security zone of the packet 770 o protocol: The employed transport layer protocol. e.g.,TCP and UDP 772 o role: The role of the communicating parties within the botnet: 774 1. The packet from the zombie host to the attacker 776 2. The packet from the attacker to the zombie host 778 3. The packet from the IRC/WEB server to the zombie host 780 4. The packet from the zombie host to the IRC/WEB server 782 5. The packet from the attacker to the IRC/WEB server 784 6. The packet from the IRC/WEB server to the attacker 786 7. The packet from the zombie host to the victim 788 o rule-name: The name of the rule being triggered 790 o raw-info: The information describing the packet triggering the 791 event. 793 7.3.6. Web Attack Event 795 The following information should be included in a Web Attack Alarm: 797 o event-name: The name of event. e.g., detection-web-attack 799 o attack-type: Concrete web attack type. e.g., SQL injection, 800 command injection, XSS, CSRF 802 o src-ip: The source IP address of the packet 804 o dst-ip: The destination IP address of the packet 806 o src-port: The source port number of the packet 807 o dst-port: The destination port number of the packet 809 o src-zone: The source security zone of the packet 811 o dst-zone: The destination security zone of the packet 813 o request-method: The method of requirement. For instance, "PUT" 814 and "GET" in HTTP 816 o req-uri: Requested URI 818 o rsp-code: Response code 820 o req-clientapp: The client application 822 o req-cookies: Cookies 824 o req-host: The domain name of the requested host 826 o uri-category: Matched URI category 828 o filtering-type: URL filtering type. e.g., Blacklist, Whitelist, 829 User-Defined, Predefined, Malicious Category, and Unknown 831 o rule-name: The name of the rule being triggered 833 o profile: Security profile that traffic matches 835 7.4. System Logs 837 Characteristics: 839 o acquisition-method: subscription 841 o emission-type: on-change 843 o dampening-type: on-repetition 845 7.4.1. Access Log 847 Access logs record administrators' login, logout, and operations on a 848 device. By analyzing them, security vulnerabilities can be 849 identified. The following information should be included in an 850 operation report: 852 o Administrator: Administrator that operates on the device 854 o login-ip-address: IP address used by an administrator to log in 855 o login-mode: Specifies the administrator logs in mode e.g. root, 856 user 858 o operation-type: The operation type that the administrator execute, 859 e.g., login, logout, and configuration. 861 o result: Command execution result 863 o content: Operation performed by an administrator after login. 865 7.4.2. Resource Utilization Log 867 Running reports record the device system's running status, which is 868 useful for device monitoring. The following information should be 869 included in running report: 871 o system-status: The current system's running status 873 o cpu-usage: Specifies the CPU usage. 875 o memory-usage: Specifies the memory usage. 877 o disk-usage: Specifies the disk usage. 879 o disk-left: Specifies the available disk space left. 881 o session-number: Specifies total concurrent sessions. 883 o process-number: Specifies total number of systems processes. 885 o in-traffic-rate: The total inbound traffic rate in pps 887 o out-traffic-rate: The total outbound traffic rate in pps 889 o in-traffic-speed: The total inbound traffic speed in bps 891 o out-traffic-speed: The total outbound traffic speed in bps 893 7.4.3. User Activity Log 895 User activity logs provide visibility into users' online records 896 (such as login time, online/lockout duration, and login IP addresses) 897 and the actions that users perform. User activity reports are 898 helpful to identify exceptions during a user's login and network 899 access activities. 901 o user: Name of a user 902 o group: Group to which a user belongs 904 o login-ip-addr: Login IP address of a user 906 o authentication: User authentication mode. e.g., Local 907 Authentication, Third-Party Server Authentication, Authentication 908 Exemption, SSO Authentication 910 o access: User access mode. e.g., PPP, SVN, LOCAL 912 o online-duration: Online duration 914 o logout-duration: Logout duration 916 o additional-info: Additional Information for login: 918 1. type: User activities. e.g., Successful User Login, Failed 919 Login attempts, User Logout, Successful User Password Change, 920 Failed User Password Change, User Lockout, User Unlocking, 921 Unknown 923 2. cause: Cause of a failed user activity 925 7.5. NSF Logs 927 Characteristics: 929 o acquisition-method: subscription 931 o emission-type: on-change 933 o dampening-type: on-repetition 935 7.5.1. DPI Log 937 DPI Logs provide statistics on uploaded and downloaded files and 938 data, sent and received emails, and alert and block records on 939 websites. It is helpful to learn risky user behaviors and why access 940 to some URLs is blocked or allowed with an alert record. 942 o attack-type: DPI action types. e.g., File Blocking, Data 943 Filtering, and Application Behavior Control 945 o src-user: User source who generates the policy 947 o policy-name: Security policy name that traffic matches 948 o action: Action defined in the file blocking rule, data filtering 949 rule, or application behavior control rule that traffic matches. 951 7.5.2. Vulnerability Scanning Log 953 Vulnerability scanning logs record the victim host and its related 954 vulnerability information that should to be fixed. The following 955 information should be included in the report: 957 o victim-ip: IP address of the victim host which has vulnerabilities 959 o vulnerability-id: The vulnerability id 961 o level: The vulnerability level. e.g., high, middle, and low 963 o OS: The operating system of the victim host 965 o service: The service which has vulnerability in the victim host 967 o protocol: The protocol type. e.g., TCP and UDP 969 o port-num: The port number 971 o vulnerability-info: The information about the vulnerability 973 o fix-suggestion: The fix suggestion to the vulnerability. 975 7.6. System Counter 977 Characteristics: 979 o acquisition-method: subscription or query 981 o emission-type: periodical 983 o dampening-type: none 985 7.6.1. Interface Counter 987 Interface counters provide visibility into traffic into and out of an 988 NSF, and bandwidth usage. 990 o interface-name: Network interface name configured in NSF 992 o in-total-traffic-pkts: Total inbound packets 994 o out-total-traffic-pkts: Total outbound packets 995 o in-total-traffic-bytes: Total inbound bytes 997 o out-total-traffic-bytes: Total outbound bytes 999 o in-drop-traffic-pkts: Total inbound drop packets 1001 o out-drop-traffic-pkts: Total outbound drop packets 1003 o in-drop-traffic-bytes: Total inbound drop bytes 1005 o out-drop-traffic-bytes: Total outbound drop bytes 1007 o in-traffic-average-rate: Inbound traffic average rate in pps 1009 o in-traffic-peak-rate: Inbound traffic peak rate in pps 1011 o in-traffic-average-speed: Inbound traffic average speed in bps 1013 o in-traffic-peak-speed: Inbound traffic peak speed in bps 1015 o out-traffic-average-rate: Outbound traffic average rate in pps 1017 o out-traffic-peak-rate: Outbound traffic peak rate in pps 1019 o out-traffic-average-speed: Outbound traffic average speed in bps 1021 o out-traffic-peak-speed: Outbound traffic peak speed in bps 1023 7.7. NSF Counters 1025 Characteristics: 1027 o acquisition-method: subscription or query 1029 o emission-type: periodical 1031 o dampening-type: none 1033 7.7.1. Firewall Counter 1035 Firewall counters provide visibility into traffic signatures, 1036 bandwidth usage, and how the configured security and bandwidth 1037 policies have been applied. 1039 o src-zone: Source security zone of traffic 1041 o dst-zone: Destination security zone of traffic 1042 o src-region: Source region of traffic 1044 o dst-region: Destination region of traffic 1046 o src-ip: Source IP address of traffic 1048 o src-user: User who generates traffic 1050 o dst-ip: Destination IP address of traffic 1052 o src-port: Source port of traffic 1054 o dst-port: Destination port of traffic 1056 o protocol: Protocol type of traffic 1058 o app: Application type of traffic 1060 o policy-id: Security policy id that traffic matches 1062 o policy-name: Security policy name that traffic matches 1064 o in-interface: Inbound interface of traffic 1066 o out-interface: Outbound interface of traffic 1068 o total-traffic: Total traffic volume 1070 o in-traffic-average-rate: Inbound traffic average rate in pps 1072 o in-traffic-peak-rate: Inbound traffic peak rate in pps 1074 o in-traffic-average-speed: Inbound traffic average speed in bps 1076 o in-traffic-peak-speed: Inbound traffic peak speed in bps 1078 o out-traffic-average-rate: Outbound traffic average rate in pps 1080 o out-traffic-peak-rate: Outbound traffic peak rate in pps 1082 o out-traffic-average-speed: Outbound traffic average speed in bps 1084 o out-traffic-peak-speed: Outbound traffic peak speed in bps. 1086 7.7.2. Policy Hit Counter 1088 Policy Hit Counters record the security policy that traffic matches 1089 and its hit count. It can check if policy configurations are 1090 correct. 1092 o src-zone: Source security zone of traffic 1094 o dst-zone: Destination security zone of traffic 1096 o src-region: Source region of the traffic 1098 o dst-region: Destination region of the traffic 1100 o src-ip: Source IP address of traffic 1102 o src-user: User who generates traffic 1104 o dst-ip: Destination IP address of traffic 1106 o src-port: Source port of traffic 1108 o dst-port: Destination port of traffic 1110 o protocol: Protocol type of traffic 1112 o app: Application type of traffic 1114 o policy-id: Security policy id that traffic matches 1116 o policy-name: Security policy name that traffic matches 1118 o hit-times: The hit times that the security policy matches the 1119 specified traffic. 1121 8. NSF Monitoring Management in I2NSF 1123 A standard model for monitoring data is required for an administrator 1124 to check the monitoring data generated by an NSF. The administrator 1125 can check the monitoring data through the following process. When 1126 the NSF monitoring data that is under the standard format is 1127 generated, the NSF forwards it to an NSF data collector via the I2NSF 1128 NSF Monitoring Interface. The NSF data collector delivers it to 1129 I2NSF Consumer or Developer's Management System (DMS) so that the 1130 administrator can know the state of the I2NSF framework. 1132 In order to communicate with other components, an I2NSF framework 1133 [RFC8329] requires the interfaces. The three main interfaces in 1134 I2NSF framework are used for sending monitoring data as follows: 1136 o I2NSF Consumer-Facing Interface 1137 [I-D.ietf-i2nsf-consumer-facing-interface-dm]: When an I2NSF User 1138 makes a security policy and forwards it to the Security Controller 1139 via Consumer-Facing Interface, it can specify the threat-feed for 1140 threat prevention, the custom list, the malicious code scan group, 1141 and the event map group. They can be used as an event to be 1142 monitored by an NSF. 1144 o I2NSF Registration Interface 1145 [I-D.ietf-i2nsf-registration-interface-dm]: The Network Functions 1146 Virtualization (NFV) architecture provides the lifecycle 1147 management of a Virtual Network Function (VNF) via the Ve-Vnfm 1148 interface. The role of Ve-Vnfm is to request VNF lifecycle 1149 management (e.g., the instantiation and de-instantiation of an 1150 NSF, and load balancing among NSFs), exchange configuration 1151 information, and exchange status information for a network 1152 service. In the I2NSF framework, the DMS manages data about 1153 resource states and network traffic for the lifecycle management 1154 of an NSF. Therefore, the generated monitoring data from NSFs are 1155 delivered from the NSF data collector to the DMS via either 1156 Registration Interface or a new interface (e.g., NSF Monitoring 1157 Interface). These data are delivered from the DMS to the VNF 1158 Manager in the Management and Orchestration (MANO) in the NFV 1159 system [I-D.ietf-i2nsf-applicability]. 1161 o I2NSF NSF Monitoring Interface [RFC8329]: After a high-level 1162 security policy from I2NSF User is translated by security policy 1163 translator [I-D.yang-i2nsf-security-policy-translation] in the 1164 Security Controller, the translated security policy (i.e., low- 1165 level policy) is applied to an NSF via NSF-Facing Interface. The 1166 monitoring data model for an NSF specifies the list of events that 1167 can trigger Event-Condition-Action (ECA) policies via NSF 1168 Monitoring Interface. 1170 9. Tree Structure 1172 The tree structure of the NSF monitoring YANG module is provided 1173 below: 1175 module: ietf-i2nsf-nsf-monitoring 1176 +--ro i2nsf-counters 1177 | +--ro system-interface* [interface-name] 1178 | | +--ro acquisition-method? identityref 1179 | | +--ro emission-type? identityref 1180 | | +--ro dampening-type? identityref 1181 | | +--ro interface-name string 1182 | | +--ro in-total-traffic-pkts? yang:counter32 1183 | | +--ro out-total-traffic-pkts? yang:counter32 1184 | | +--ro in-total-traffic-bytes? uint64 1185 | | +--ro out-total-traffic-bytes? uint64 1186 | | +--ro in-drop-traffic-pkts? yang:counter32 1187 | | +--ro out-drop-traffic-pkts? yang:counter32 1188 | | +--ro in-drop-traffic-bytes? uint64 1189 | | +--ro out-drop-traffic-bytes? uint64 1190 | | +--ro total-traffic? yang:counter32 1191 | | +--ro in-traffic-average-rate? uint32 1192 | | +--ro in-traffic-peak-rate? uint32 1193 | | +--ro in-traffic-average-speed? uint32 1194 | | +--ro in-traffic-peak-speed? uint32 1195 | | +--ro out-traffic-average-rate? uint32 1196 | | +--ro out-traffic-peak-rate? uint32 1197 | | +--ro out-traffic-average-speed? uint32 1198 | | +--ro out-traffic-peak-speed? uint32 1199 | | +--ro message? string 1200 | | +--ro vendor-name? string 1201 | | +--ro nsf-name? string 1202 | | +--ro severity? severity 1203 | +--ro nsf-firewall* [policy-name] 1204 | | +--ro acquisition-method? identityref 1205 | | +--ro emission-type? identityref 1206 | | +--ro dampening-type? identityref 1207 | | +--ro policy-name 1208 -> /nsfi:i2nsf-security-policy/system-policy/system-policy-name 1209 | | +--ro src-user? string 1210 | | +--ro total-traffic? yang:counter32 1211 | | +--ro in-traffic-average-rate? uint32 1212 | | +--ro in-traffic-peak-rate? uint32 1213 | | +--ro in-traffic-average-speed? uint32 1214 | | +--ro in-traffic-peak-speed? uint32 1215 | | +--ro out-traffic-average-rate? uint32 1216 | | +--ro out-traffic-peak-rate? uint32 1217 | | +--ro out-traffic-average-speed? uint32 1218 | | +--ro out-traffic-peak-speed? uint32 1219 | | +--ro message? string 1220 | | +--ro vendor-name? string 1221 | | +--ro nsf-name? string 1222 | | +--ro severity? severity 1223 | +--ro nsf-policy-hits* [policy-name] 1224 | +--ro acquisition-method? identityref 1225 | +--ro emission-type? identityref 1226 | +--ro dampening-type? identityref 1227 | +--ro policy-name 1228 -> /nsfi:i2nsf-security-policy/system-policy/system-policy-name 1229 | +--ro src-user? string 1230 | +--ro message? string 1231 | +--ro vendor-name? string 1232 | +--ro nsf-name? string 1233 | +--ro severity? severity 1234 | +--ro hit-times? yang:counter32 1235 +--rw i2nsf-monitoring-configuration 1236 +--rw i2nsf-system-detection-alarm 1237 | +--rw enabled? boolean 1238 | +--rw system-alarm* [alarm-type] 1239 | +--rw alarm-type enumeration 1240 | +--rw threshold? uint8 1241 | +--rw dampening-period? uint32 1242 +--rw i2nsf-system-detection-event 1243 | +--rw enabled? boolean 1244 | +--rw dampening-period? uint32 1245 +--rw i2nsf-traffic-flows 1246 | +--rw dampening-period? uint32 1247 | +--rw enabled? boolean 1248 +--rw i2nsf-nsf-detection-ddos {i2nsf-nsf-detection-ddos}? 1249 | +--rw enabled? boolean 1250 | +--rw dampening-period? uint32 1251 +--rw i2nsf-nsf-detection-session-table-configuration 1252 | +--rw enabled? boolean 1253 | +--rw dampening-period? uint32 1254 +--rw i2nsf-nsf-detection-virus {i2nsf-nsf-detection-virus}? 1255 | +--rw enabled? boolean 1256 | +--rw dampening-period? uint32 1257 +--rw i2nsf-nsf-detection-intrusion 1258 {i2nsf-nsf-detection-intrusion}? 1259 | +--rw enabled? boolean 1260 | +--rw dampening-period? uint32 1261 +--rw i2nsf-nsf-detection-botnet {i2nsf-nsf-detection-botnet}? 1262 | +--rw enabled? boolean 1263 | +--rw dampening-period? uint32 1264 +--rw i2nsf-nsf-detection-web-attack 1265 {i2nsf-nsf-detection-web-attack}? 1266 | +--rw enabled? boolean 1267 | +--rw dampening-period? uint32 1268 +--rw i2nsf-nsf-system-access-log 1269 | +--rw enabled? boolean 1270 | +--rw dampening-period? uint32 1271 +--rw i2nsf-system-res-util-log 1272 | +--rw enabled? boolean 1273 | +--rw dampening-period? uint32 1274 +--rw i2nsf-system-user-activity-log 1275 | +--rw enabled? boolean 1276 | +--rw dampening-period? uint32 1277 +--rw i2nsf-nsf-log-dpi {i2nsf-nsf-log-dpi}? 1278 | +--rw enabled? boolean 1279 | +--rw dampening-period? uint32 1280 +--rw i2nsf-nsf-log-vuln-scan {i2nsf-nsf-log-vuln-scan}? 1281 | +--rw enabled? boolean 1282 | +--rw dampening-period? uint32 1283 +--rw i2nsf-counter 1284 +--rw period? uint16 1286 notifications: 1287 +---n i2nsf-event 1288 | +--ro (sub-event-type)? 1289 | +--:(i2nsf-system-detection-alarm) 1290 | | +--ro i2nsf-system-detection-alarm 1291 | | +--ro alarm-category? identityref 1292 | | +--ro component-name? string 1293 | | +--ro interface-name? string 1294 | | +--ro interface-state? enumeration 1295 | | +--ro acquisition-method? identityref 1296 | | +--ro emission-type? identityref 1297 | | +--ro dampening-type? identityref 1298 | | +--ro usage? uint8 1299 | | +--ro threshold? uint8 1300 | | +--ro message? string 1301 | | +--ro vendor-name? string 1302 | | +--ro nsf-name? string 1303 | | +--ro severity? severity 1304 | +--:(i2nsf-system-detection-event) 1305 | | +--ro i2nsf-system-detection-event 1306 | | +--ro event-category? identityref 1307 | | +--ro acquisition-method? identityref 1308 | | +--ro emission-type? identityref 1309 | | +--ro dampening-type? identityref 1310 | | +--ro user string 1311 | | +--ro group string 1312 | | +--ro login-ip-addr inet:ip-address 1313 | | +--ro authentication? identityref 1314 | | +--ro message? string 1315 | | +--ro vendor-name? string 1316 | | +--ro nsf-name? string 1317 | | +--ro severity? severity 1318 | +--:(i2nsf-traffic-flows) 1319 | | +--ro i2nsf-traffic-flows 1320 | | +--ro src-ip? inet:ip-address 1321 | | +--ro dst-ip? inet:ip-address 1322 | | +--ro protocol? identityref 1323 | | +--ro src-port? inet:port-number 1324 | | +--ro dst-port? inet:port-number 1325 | | +--ro arrival-rate? uint32 1326 | | +--ro acquisition-method? identityref 1327 | | +--ro emission-type? identityref 1328 | | +--ro dampening-type? identityref 1329 | | +--ro message? string 1330 | | +--ro vendor-name? string 1331 | | +--ro nsf-name? string 1332 | | +--ro severity? severity 1333 | +--:(i2nsf-nsf-detection-session-table) 1334 | +--ro i2nsf-nsf-detection-session-table 1335 | +--ro current-session? uint32 1336 | +--ro maximum-session? uint32 1337 | +--ro threshold? uint32 1338 | +--ro message? string 1339 | +--ro vendor-name? string 1340 | +--ro nsf-name? string 1341 | +--ro severity? severity 1342 +---n i2nsf-log 1343 | +--ro (sub-logs-type)? 1344 | +--:(i2nsf-nsf-system-access-log) 1345 | | +--ro i2nsf-nsf-system-access-log 1346 | | +--ro login-ip inet:ip-address 1347 | | +--ro administrator? string 1348 | | +--ro login-mode? login-mode 1349 | | +--ro operation-type? operation-type 1350 | | +--ro result? string 1351 | | +--ro content? string 1352 | | +--ro acquisition-method? identityref 1353 | | +--ro emission-type? identityref 1354 | | +--ro dampening-type? identityref 1355 | | +--ro message? string 1356 | | +--ro vendor-name? string 1357 | | +--ro nsf-name? string 1358 | | +--ro severity? severity 1359 | +--:(i2nsf-system-res-util-log) 1360 | | +--ro i2nsf-system-res-util-log 1361 | | +--ro system-status? string 1362 | | +--ro cpu-usage? uint8 1363 | | +--ro memory-usage? uint8 1364 | | +--ro disk-usage? uint8 1365 | | +--ro disk-left? uint8 1366 | | +--ro session-num? uint8 1367 | | +--ro process-num? uint8 1368 | | +--ro in-traffic-rate? uint32 1369 | | +--ro out-traffic-rate? uint32 1370 | | +--ro in-traffic-speed? uint32 1371 | | +--ro out-traffic-speed? uint32 1372 | | +--ro acquisition-method? identityref 1373 | | +--ro emission-type? identityref 1374 | | +--ro dampening-type? identityref 1375 | | +--ro message? string 1376 | | +--ro vendor-name? string 1377 | | +--ro nsf-name? string 1378 | | +--ro severity? severity 1379 | +--:(i2nsf-system-user-activity-log) 1380 | +--ro i2nsf-system-user-activity-log 1381 | +--ro acquisition-method? identityref 1382 | +--ro emission-type? identityref 1383 | +--ro dampening-type? identityref 1384 | +--ro user string 1385 | +--ro group string 1386 | +--ro login-ip-addr inet:ip-address 1387 | +--ro authentication? identityref 1388 | +--ro message? string 1389 | +--ro vendor-name? string 1390 | +--ro nsf-name? string 1391 | +--ro severity? severity 1392 | +--ro access? identityref 1393 | +--ro online-duration? string 1394 | +--ro logout-duration? string 1395 | +--ro additional-info? string 1396 +---n i2nsf-nsf-event 1397 +--ro (sub-event-type)? 1398 +--:(i2nsf-nsf-detection-ddos) {i2nsf-nsf-detection-ddos}? 1399 | +--ro i2nsf-nsf-detection-ddos 1400 | +--ro dst-ip? inet:ip-address 1401 | +--ro dst-port? inet:port-number 1402 | +--ro rule-name 1403 -> /nsfi:i2nsf-security-policy/system-policy/rules/rule-name 1404 | +--ro raw-info? string 1405 | +--ro attack-type? identityref 1406 | +--ro start-time yang:date-and-time 1407 | +--ro end-time yang:date-and-time 1408 | +--ro attack-src-ip? inet:ip-address 1409 | +--ro attack-dst-ip? inet:ip-address 1410 | +--ro attack-rate? uint32 1411 | +--ro attack-speed? uint32 1412 | +--ro action? log-action 1413 | +--ro acquisition-method? identityref 1414 | +--ro emission-type? identityref 1415 | +--ro dampening-type? identityref 1416 | +--ro message? string 1417 | +--ro vendor-name? string 1418 | +--ro nsf-name? string 1419 | +--ro severity? severity 1420 +--:(i2nsf-nsf-detection-virus) {i2nsf-nsf-detection-virus}? 1421 | +--ro i2nsf-nsf-detection-virus 1422 | +--ro dst-ip? inet:ip-address 1423 | +--ro dst-port? inet:port-number 1424 | +--ro rule-name 1425 -> /nsfi:i2nsf-security-policy/system-policy/rules/rule-name 1426 | +--ro raw-info? string 1427 | +--ro src-ip? inet:ip-address 1428 | +--ro src-port? inet:port-number 1429 | +--ro src-zone? string 1430 | +--ro dst-zone? string 1431 | +--ro virus? identityref 1432 | +--ro virus-name? string 1433 | +--ro file-type? string 1434 | +--ro file-name? string 1435 | +--ro os? string 1436 | +--ro action? log-action 1437 | +--ro acquisition-method? identityref 1438 | +--ro emission-type? identityref 1439 | +--ro dampening-type? identityref 1440 | +--ro message? string 1441 | +--ro vendor-name? string 1442 | +--ro nsf-name? string 1443 | +--ro severity? severity 1444 +--:(i2nsf-nsf-detection-intrusion) 1445 {i2nsf-nsf-detection-intrusion}? 1446 | +--ro i2nsf-nsf-detection-intrusion 1447 | +--ro dst-ip? inet:ip-address 1448 | +--ro dst-port? inet:port-number 1449 | +--ro rule-name 1450 -> /nsfi:i2nsf-security-policy/system-policy/rules/rule-name 1451 | +--ro raw-info? string 1452 | +--ro src-ip? inet:ip-address 1453 | +--ro src-port? inet:port-number 1454 | +--ro src-zone? string 1455 | +--ro dst-zone? string 1456 | +--ro protocol? identityref 1457 | +--ro app? string 1458 | +--ro attack-type? identityref 1459 | +--ro action? log-action 1460 | +--ro attack-rate? uint32 1461 | +--ro attack-speed? uint32 1462 | +--ro acquisition-method? identityref 1463 | +--ro emission-type? identityref 1464 | +--ro dampening-type? identityref 1465 | +--ro message? string 1466 | +--ro vendor-name? string 1467 | +--ro nsf-name? string 1468 | +--ro severity? severity 1469 +--:(i2nsf-nsf-detection-botnet) 1470 {i2nsf-nsf-detection-botnet}? 1471 | +--ro i2nsf-nsf-detection-botnet 1472 | +--ro dst-ip? inet:ip-address 1473 | +--ro dst-port? inet:port-number 1474 | +--ro rule-name 1475 -> /nsfi:i2nsf-security-policy/system-policy/rules/rule-name 1476 | +--ro raw-info? string 1477 | +--ro src-ip? inet:ip-address 1478 | +--ro src-port? inet:port-number 1479 | +--ro src-zone? string 1480 | +--ro dst-zone? string 1481 | +--ro attack-type? identityref 1482 | +--ro protocol? identityref 1483 | +--ro botnet-name? string 1484 | +--ro role? string 1485 | +--ro action? log-action 1486 | +--ro botnet-pkt-num? uint8 1487 | +--ro os? string 1488 | +--ro acquisition-method? identityref 1489 | +--ro emission-type? identityref 1490 | +--ro dampening-type? identityref 1491 | +--ro message? string 1492 | +--ro vendor-name? string 1493 | +--ro nsf-name? string 1494 | +--ro severity? severity 1495 +--:(i2nsf-nsf-detection-web-attack) 1496 {i2nsf-nsf-detection-web-attack}? 1497 | +--ro i2nsf-nsf-detection-web-attack 1498 | +--ro dst-ip? inet:ip-address 1499 | +--ro dst-port? inet:port-number 1500 | +--ro rule-name 1501 -> /nsfi:i2nsf-security-policy/system-policy/rules/rule-name 1502 | +--ro raw-info? string 1503 | +--ro src-ip? inet:ip-address 1504 | +--ro src-port? inet:port-number 1505 | +--ro src-zone? string 1506 | +--ro dst-zone? string 1507 | +--ro attack-type? identityref 1508 | +--ro request-method? identityref 1509 | +--ro req-uri? string 1510 | +--ro uri-category? string 1511 | +--ro filtering-type* identityref 1512 | +--ro rsp-code? string 1513 | +--ro req-clientapp? string 1514 | +--ro req-cookies? string 1515 | +--ro req-host? string 1516 | +--ro acquisition-method? identityref 1517 | +--ro emission-type? identityref 1518 | +--ro dampening-type? identityref 1519 | +--ro action? log-action 1520 | +--ro message? string 1521 | +--ro vendor-name? string 1522 | +--ro nsf-name? string 1523 | +--ro severity? severity 1524 +--:(i2nsf-nsf-log-vuln-scan) {i2nsf-nsf-log-vuln-scan}? 1525 | +--ro i2nsf-nsf-log-vuln-scan 1526 | +--ro vulnerability-id? uint8 1527 | +--ro victim-ip? inet:ip-address 1528 | +--ro protocol? identityref 1529 | +--ro port-num? inet:port-number 1530 | +--ro level? severity 1531 | +--ro os? string 1532 | +--ro vulnerability-info? string 1533 | +--ro fix-suggestion? string 1534 | +--ro service? string 1535 | +--ro acquisition-method? identityref 1536 | +--ro emission-type? identityref 1537 | +--ro dampening-type? identityref 1538 | +--ro message? string 1539 | +--ro vendor-name? string 1540 | +--ro nsf-name? string 1541 | +--ro severity? severity 1542 +--:(i2nsf-nsf-log-dpi) {i2nsf-nsf-log-dpi}? 1543 +--ro i2nsf-nsf-log-dpi 1544 +--ro attack-type? dpi-type 1545 +--ro acquisition-method? identityref 1546 +--ro emission-type? identityref 1547 +--ro dampening-type? identityref 1548 +--ro policy-name 1549 -> /nsfi:i2nsf-security-policy/system-policy/system-policy-name 1550 +--ro src-user? string 1551 +--ro message? string 1552 +--ro vendor-name? string 1553 +--ro nsf-name? string 1554 +--ro severity? severity 1556 Figure 1: Information Model for NSF Monitoring 1558 10. YANG Data Model 1560 This section describes a YANG module of I2NSF NSF Monitoring. This 1561 YANG module imports from [RFC6991], and makes references to 1562 [RFC0768][RFC0791] [RFC0792][RFC0793][RFC0956] 1563 [RFC0959][RFC2616][RFC4443] [RFC8200][RFC8632][RFC8641]. 1565 file "ietf-i2nsf-nsf-monitoring@2021-04-29.yang" 1567 module ietf-i2nsf-nsf-monitoring { 1568 yang-version 1.1; 1569 namespace 1570 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring"; 1571 prefix 1572 nsfmi; 1573 import ietf-inet-types{ 1574 prefix inet; 1575 reference 1576 "Section 4 of RFC 6991"; 1577 } 1578 import ietf-yang-types { 1579 prefix yang; 1580 reference 1581 "Section 3 of RFC 6991"; 1582 } 1583 import ietf-i2nsf-policy-rule-for-nsf { 1584 prefix nsfi; 1585 reference 1586 "Section 4.1 of draft-ietf-i2nsf-nsf-facing-interface-dm-12"; 1587 } 1588 organization 1589 "IETF I2NSF (Interface to Network Security Functions) 1590 Working Group"; 1591 contact 1592 "WG Web: 1593 WG List: 1595 Editor: Jaehoon Paul Jeong 1596 1598 Editor: Patrick Lingga 1599 "; 1601 description 1602 "This module is a YANG module for I2NSF NSF Monitoring. 1604 Copyright (c) 2021 IETF Trust and the persons identified as 1605 authors of the code. All rights reserved. 1607 Redistribution and use in source and binary forms, with or 1608 without modification, is permitted pursuant to, and subject to 1609 the license terms contained in, the Simplified BSD License set 1610 forth in Section 4.c of the IETF Trust's Legal Provisions 1611 Relating to IETF Documents 1612 (https://trustee.ietf.org/license-info). 1614 This version of this YANG module is part of RFC XXXX 1615 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 1616 for full legal notices."; 1618 revision "2021-04-29" { 1619 description "Latest revision"; 1620 reference 1621 "RFC XXXX: I2NSF NSF Monitoring Interface YANG Data Model"; 1623 // RFC Ed.: replace XXXX with an actual RFC number and remove 1624 // this note. 1625 } 1627 /* 1628 * Typedefs 1629 */ 1631 typedef severity { 1632 type enumeration { 1633 enum critical { 1634 description 1635 "The 'critical' severity level indicates that 1636 an immediate corrective action is required. 1637 A 'critical' severity is reported when a service 1638 becomes totally out of service and must be restored."; 1639 } 1640 enum high { 1641 description 1642 "The 'high' severity level indicates that 1643 an urgent corrective action is required. 1644 A 'high' severity is reported when there is 1645 a severe degradation in the capability of the 1646 service and its full capability must be restored."; 1647 } 1648 enum middle { 1649 description 1650 "The 'middle' severity level indicates the 1651 existence of a non-service-affecting fault 1652 condition and corrective action should be done 1653 to prevent a more serious fault. The 'middle' 1654 severity is reported when the detected problem 1655 is not degrading the capability of the service but 1656 might happen if not prevented."; 1657 } 1658 enum low { 1659 description 1660 "The 'low' severity level indicates the detection 1661 of a potential fault before any effect is felt. 1663 The 'low' severity is reported when an action should 1664 be done before a fault happen."; 1665 } 1666 } 1667 description 1668 "An indicator representing severity level. The severity level 1669 starting from the highest are critical, high, middle, and 1670 low."; 1671 reference 1672 "RFC 8632: A YANG Data Model for Alarm Management - 1673 The severity levels are defined."; 1674 } 1676 typedef log-action { 1677 type enumeration { 1678 enum allow { 1679 description 1680 "If action is allowed"; 1681 } 1682 enum alert { 1683 description 1684 "If action is alert"; 1685 } 1686 enum block { 1687 description 1688 "If action is block"; 1689 } 1690 enum discard { 1691 description 1692 "If action is discarded"; 1693 } 1694 enum declare { 1695 description 1696 "If action is declared"; 1697 } 1698 enum block-ip { 1699 description 1700 "If action is block-ip"; 1701 } 1702 enum block-service{ 1703 description 1704 "If action is block-service"; 1705 } 1706 } 1707 description 1708 "The type representing action for logging."; 1709 } 1710 typedef dpi-type{ 1711 type enumeration { 1712 enum file-blocking{ 1713 description 1714 "DPI for blocking file"; 1715 } 1716 enum data-filtering{ 1717 description 1718 "DPI for filtering data"; 1719 } 1720 enum application-behavior-control{ 1721 description 1722 "DPI for controlling application behavior"; 1723 } 1724 } 1725 description 1726 "The type of deep packet inspection."; 1727 } 1729 typedef operation-type{ 1730 type enumeration { 1731 enum login{ 1732 description 1733 "Login operation"; 1734 } 1735 enum logout{ 1736 description 1737 "Logout operation"; 1738 } 1739 enum configuration{ 1740 description 1741 "Configuration operation"; 1742 } 1743 } 1744 description 1745 "The type of operation done by a user 1746 during a session."; 1747 } 1749 typedef login-mode{ 1750 type enumeration { 1751 enum root{ 1752 description 1753 "Root login-mode"; 1754 } 1755 enum user{ 1756 description 1757 "User login-mode"; 1759 } 1760 enum guest{ 1761 description 1762 "Guest login-mode"; 1763 } 1764 } 1765 description 1766 "The authorization login-mode done by a user."; 1767 } 1769 /* 1770 * Identity 1771 */ 1773 identity characteristics { 1774 description 1775 "Base identity for monitoring information 1776 characteristics"; 1777 } 1778 identity acquisition-method { 1779 base characteristics; 1780 description 1781 "The type of acquisition-method. It can be multiple 1782 types at once."; 1783 } 1784 identity subscription { 1785 base acquisition-method; 1786 description 1787 "The acquisition-method type is subscription."; 1788 } 1789 identity query { 1790 base acquisition-method; 1791 description 1792 "The acquisition-method type is query."; 1793 } 1794 identity emission-type { 1795 base characteristics; 1796 description 1797 "The type of emission-type."; 1798 } 1799 identity periodical { 1800 base emission-type; 1801 description 1802 "The emission-type type is periodical."; 1803 } 1804 identity on-change { 1805 base emission-type; 1806 description 1807 "The emission-type type is on-change."; 1808 } 1809 identity dampening-type { 1810 base characteristics; 1811 description 1812 "The type of dampening-type."; 1813 } 1814 identity no-dampening { 1815 base dampening-type; 1816 description 1817 "The dampening-type is no-dampening."; 1818 } 1819 identity on-repetition { 1820 base dampening-type; 1821 description 1822 "The dampening-type is on-repetition."; 1823 } 1824 identity none { 1825 base dampening-type; 1826 description 1827 "The dampening-type is none."; 1828 } 1829 identity authentication-mode { 1830 description 1831 "User authentication mode types: 1832 e.g., Local Authentication, 1833 Third-Party Server Authentication, 1834 Authentication Exemption, or Single Sign-On (SSO) 1835 Authentication."; 1836 } 1837 identity local-authentication { 1838 base authentication-mode; 1839 description 1840 "Authentication-mode : local authentication."; 1841 } 1842 identity third-party-server-authentication { 1843 base authentication-mode; 1844 description 1845 "If authentication-mode is 1846 third-party-server-authentication"; 1847 } 1848 identity exemption-authentication { 1849 base authentication-mode; 1850 description 1851 "If authentication-mode is 1852 exemption-authentication"; 1853 } 1854 identity sso-authentication { 1855 base authentication-mode; 1856 description 1857 "If authentication-mode is 1858 sso-authentication"; 1859 } 1860 identity alarm-type { 1861 description 1862 "Base identity for detectable alarm types"; 1863 } 1864 identity mem-usage-alarm { 1865 base alarm-type; 1866 description 1867 "A memory alarm is alerted."; 1868 } 1869 identity cpu-usage-alarm { 1870 base alarm-type; 1871 description 1872 "A CPU alarm is alerted."; 1873 } 1874 identity disk-usage-alarm { 1875 base alarm-type; 1876 description 1877 "A disk alarm is alerted."; 1878 } 1879 identity hw-failure-alarm { 1880 base alarm-type; 1881 description 1882 "A hardware alarm is alerted."; 1883 } 1884 identity ifnet-state-alarm { 1885 base alarm-type; 1886 description 1887 "An interface alarm is alerted."; 1888 } 1889 identity event-type { 1890 description 1891 "Base identity for detectable event types"; 1892 } 1893 identity access-denied { 1894 base event-type; 1895 description 1896 "The system event is access-denied."; 1897 } 1898 identity config-change { 1899 base event-type; 1900 description 1901 "The system event is config-change."; 1902 } 1903 identity attack-type { 1904 description 1905 "The root ID of attack-based notification 1906 in the notification taxonomy"; 1907 } 1908 identity system-attack-type { 1909 base attack-type; 1910 description 1911 "This ID is intended to be used 1912 in the context of system events."; 1913 } 1914 identity nsf-attack-type { 1915 base attack-type; 1916 description 1917 "This ID is intended to be used 1918 in the context of NSF event."; 1919 } 1920 identity botnet-attack-type { 1921 base nsf-attack-type; 1922 description 1923 "This indicates that this attack type is botnet. 1924 The usual semantic and taxonomy is missing 1925 and a name is used."; 1926 } 1927 identity virus-type { 1928 base nsf-attack-type; 1929 description 1930 "The type of virus. It caan be multiple types at once. 1931 This attack type is associated with a detected 1932 system-log virus-attack."; 1933 } 1934 identity trojan { 1935 base virus-type; 1936 description 1937 "The detected virus type is trojan."; 1938 } 1939 identity worm { 1940 base virus-type; 1941 description 1942 "The detected virus type is worm."; 1943 } 1944 identity macro { 1945 base virus-type; 1946 description 1947 "The detected virus type is macro."; 1948 } 1949 identity intrusion-attack-type { 1950 base nsf-attack-type; 1951 description 1952 "The attack type is associated with a detected 1953 system-log intrusion."; 1954 } 1955 identity brute-force { 1956 base intrusion-attack-type; 1957 description 1958 "The intrusion type is brute-force."; 1959 } 1960 identity buffer-overflow { 1961 base intrusion-attack-type; 1962 description 1963 "The intrusion type is buffer-overflow."; 1964 } 1965 identity web-attack-type { 1966 base nsf-attack-type; 1967 description 1968 "The attack type is associated with a detected 1969 system-log web-attack."; 1970 } 1971 identity command-injection { 1972 base web-attack-type; 1973 description 1974 "The detected web attack type is command injection."; 1975 } 1976 identity xss { 1977 base web-attack-type; 1978 description 1979 "The detected web attack type is XSS."; 1980 } 1981 identity csrf { 1982 base web-attack-type; 1983 description 1984 "The detected web attack type is CSRF."; 1985 } 1986 identity flood-type { 1987 base nsf-attack-type; 1988 description 1989 "Base identity for detectable flood types"; 1990 } 1991 identity syn-flood { 1992 base flood-type; 1993 description 1994 "A SYN flood is detected."; 1995 } 1996 identity ack-flood { 1997 base flood-type; 1998 description 1999 "An ACK flood is detected."; 2000 } 2001 identity syn-ack-flood { 2002 base flood-type; 2003 description 2004 "A SYN-ACK flood is detected."; 2005 } 2006 identity fin-rst-flood { 2007 base flood-type; 2008 description 2009 "A FIN-RST flood is detected."; 2010 } 2011 identity tcp-con-flood { 2012 base flood-type; 2013 description 2014 "A TCP connection flood is detected."; 2015 } 2016 identity udp-flood { 2017 base flood-type; 2018 description 2019 "A UDP flood is detected."; 2020 } 2021 identity icmp-flood { 2022 base flood-type; 2023 description 2024 "Either an ICMPv4 or ICMPv6 flood is detected."; 2025 } 2026 identity icmpv4-flood { 2027 base flood-type; 2028 description 2029 "An ICMPv4 flood is detected."; 2030 } 2031 identity icmpv6-flood { 2032 base flood-type; 2033 description 2034 "An ICMPv6 flood is detected."; 2035 } 2036 identity http-flood { 2037 base flood-type; 2038 description 2039 "An HTTP flood is detected."; 2040 } 2041 identity https-flood { 2042 base flood-type; 2043 description 2044 "An HTTPS flood is detected."; 2045 } 2046 identity dns-query-flood { 2047 base flood-type; 2048 description 2049 "A DNS query flood is detected."; 2050 } 2051 identity dns-reply-flood { 2052 base flood-type; 2053 description 2054 "A DNS reply flood is detected."; 2055 } 2056 identity sip-flood { 2057 base flood-type; 2058 description 2059 "An SIP flood is detected."; 2060 } 2062 identity req-method { 2063 description 2064 "A set of request types (if applicable). 2065 For instance, PUT or GET in HTTP."; 2066 } 2067 identity put-req { 2068 base req-method; 2069 description 2070 "The detected request type is PUT."; 2071 } 2072 identity get-req { 2073 base req-method; 2074 description 2075 "The detected request type is GET."; 2076 } 2077 identity filter-type { 2078 description 2079 "The type of filter used to detect an attack, 2080 for example, a web-attack. It can be applicable to 2081 more than web-attacks. It can be more than one type."; 2082 } 2083 identity whitelist { 2084 base filter-type; 2085 description 2086 "The applied filter type is whitelist."; 2087 } 2088 identity blacklist { 2089 base filter-type; 2090 description 2091 "The applied filter type is blacklist."; 2092 } 2093 identity user-defined { 2094 base filter-type; 2095 description 2096 "The applied filter type is user-defined."; 2097 } 2098 identity malicious-category { 2099 base filter-type; 2100 description 2101 "The applied filter is malicious category."; 2102 } 2103 identity unknown-filter { 2104 base filter-type; 2105 description 2106 "The applied filter is unknown."; 2107 } 2109 identity access-mode { 2110 description 2111 "Base identity for detectable access mode."; 2112 } 2113 identity ppp { 2114 base access-mode; 2115 description 2116 "Access-mode: ppp"; 2117 } 2118 identity svn { 2119 base access-mode; 2120 description 2121 "Access-mode: svn"; 2122 } 2123 identity local { 2124 base access-mode; 2125 description 2126 "Access-mode: local"; 2127 } 2129 identity protocol-type { 2130 description 2131 "An identity used to enable type choices in leaves 2132 and leaflists with respect to protocol metadata."; 2133 } 2134 identity tcp { 2135 base ipv4; 2136 base ipv6; 2137 description 2138 "TCP protocol type."; 2139 reference 2140 "RFC 793: Transmission Control Protocol"; 2141 } 2142 identity udp { 2143 base ipv4; 2144 base ipv6; 2145 description 2146 "UDP protocol type."; 2147 reference 2148 "RFC 768: User Datagram Protocol"; 2149 } 2150 identity icmp { 2151 base ipv4; 2152 base ipv6; 2153 description 2154 "General ICMP protocol type."; 2155 reference 2156 "RFC 792: Internet Control Message Protocol 2157 RFC 4443: Internet Control Message Protocol 2158 (ICMPv6) for the Internet Protocol Version 6 2159 (IPv6) Specification"; 2160 } 2161 identity icmpv4 { 2162 base ipv4; 2163 description 2164 "ICMPv4 protocol type."; 2165 reference 2166 "RFC 791: Internet Protocol 2167 RFC 792: Internet Control Message Protocol"; 2168 } 2169 identity icmpv6 { 2170 base ipv6; 2171 description 2172 "ICMPv6 protocol type."; 2173 reference 2174 "RFC 8200: Internet Protocol, Version 6 (IPv6) 2175 RFC 4443: Internet Control Message Protocol (ICMPv6) 2176 for the Internet Protocol Version 6 (IPv6) 2177 Specification"; 2178 } 2179 identity ip { 2180 base protocol-type; 2181 description 2182 "General IP protocol type."; 2183 reference 2184 "RFC 791: Internet Protocol 2185 RFC 8200: Internet Protocol, Version 6 (IPv6)"; 2186 } 2187 identity ipv4 { 2188 base ip; 2189 description 2190 "IPv4 protocol type."; 2192 reference 2193 "RFC 791: Internet Protocol"; 2194 } 2195 identity ipv6 { 2196 base ip; 2197 description 2198 "IPv6 protocol type."; 2199 reference 2200 "RFC 8200: Internet Protocol, Version 6 (IPv6)"; 2201 } 2202 identity http { 2203 base tcp; 2204 description 2205 "HTPP protocol type."; 2206 reference 2207 "RFC 2616: Hypertext Transfer Protocol"; 2208 } 2209 identity ftp { 2210 base tcp; 2211 description 2212 "FTP protocol type."; 2213 reference 2214 "RFC 959: File Transfer Protocol"; 2215 } 2217 /* 2218 * Grouping 2219 */ 2221 grouping common-monitoring-data { 2222 description 2223 "A set of common monitoring data that is needed 2224 as the basic information."; 2225 leaf message { 2226 type string; 2227 description 2228 "This is a freetext annotation for 2229 monitoring a notification's content."; 2230 } 2231 leaf vendor-name { 2232 type string; 2233 description 2234 "The name of the NSF vendor"; 2235 } 2236 leaf nsf-name { 2237 type string; 2238 description 2239 "The name (or IP) of the NSF generating the message."; 2241 } 2242 leaf severity { 2243 type severity; 2244 description 2245 "The severity of the alarm such as critical, high, 2246 middle, low."; 2247 } 2248 } 2249 grouping characteristics { 2250 description 2251 "A set of characteristics of a notification."; 2252 leaf acquisition-method { 2253 type identityref { 2254 base acquisition-method; 2255 } 2256 description 2257 "The acquisition-method for characteristics"; 2258 } 2259 leaf emission-type { 2260 type identityref { 2261 base emission-type; 2262 } 2263 description 2264 "The emission-type for characteristics"; 2265 } 2266 leaf dampening-type { 2267 type identityref { 2268 base dampening-type; 2269 } 2270 description 2271 "The dampening-type for characteristics"; 2272 } 2273 } 2274 grouping i2nsf-system-alarm-type-content { 2275 description 2276 "A set of contents for alarm type notification."; 2277 leaf usage { 2278 type uint8 { 2279 range "0..100"; 2280 } 2281 units "percent"; 2282 description 2283 "Specifies the used percentage"; 2284 } 2285 leaf threshold { 2286 type uint8 { 2287 range "0..100"; 2288 } 2289 units "percent"; 2290 description 2291 "The threshold percentage triggering the alarm or 2292 the event"; 2293 } 2294 } 2295 grouping i2nsf-system-event-type-content { 2296 description 2297 "System event metadata associated with system events 2298 caused by user activity."; 2299 leaf user { 2300 type string; 2301 mandatory true; 2302 description 2303 "The name of a user"; 2304 } 2305 leaf group { 2306 type string; 2307 mandatory true; 2308 description 2309 "The group to which a user belongs."; 2310 } 2311 leaf login-ip-addr { 2312 type inet:ip-address; 2313 mandatory true; 2314 description 2315 "The login IPv4 (or IPv6) address of a user."; 2316 } 2317 leaf authentication { 2318 type identityref { 2319 base authentication-mode; 2320 } 2321 description 2322 "The authentication-mode for authentication"; 2323 } 2324 } 2325 grouping i2nsf-nsf-event-type-content { 2326 description 2327 "A set of common IPv4 (or IPv6)-related NSF event 2328 content elements"; 2329 leaf dst-ip { 2330 type inet:ip-address; 2331 description 2332 "The destination IPv4 (IPv6) address of the packet"; 2333 } 2334 leaf dst-port { 2335 type inet:port-number; 2336 description 2337 "The destination port of the packet"; 2338 } 2339 leaf rule-name { 2340 type leafref { 2341 path 2342 "/nsfi:i2nsf-security-policy/nsfi:system-policy" 2343 +"/nsfi:rules/nsfi:rule-name"; 2344 } 2345 mandatory true; 2346 description 2347 "The name of the rule being triggered"; 2348 } 2349 leaf raw-info { 2350 type string; 2351 description 2352 "The information describing the packet 2353 triggering the event."; 2354 } 2355 } 2356 grouping i2nsf-nsf-event-type-content-extend { 2357 description 2358 "A set of extended common IPv4 (or IPv6)-related NSF 2359 event content elements"; 2360 uses i2nsf-nsf-event-type-content; 2361 leaf src-ip { 2362 type inet:ip-address; 2363 description 2364 "The source IPv4 (or IPv6) address of the packet"; 2365 } 2366 leaf src-port { 2367 type inet:port-number; 2368 description 2369 "The source port of the packet"; 2370 } 2371 leaf src-zone { 2372 type string { 2373 length "1..100"; 2374 pattern "[0-9a-zA-Z ]*"; 2375 } 2376 description 2377 "The source security zone of the packet"; 2378 } 2379 leaf dst-zone { 2380 type string { 2381 length "1..100"; 2382 pattern "[0-9a-zA-Z ]*"; 2383 } 2384 description 2385 "The destination security zone of the packet"; 2386 } 2387 } 2388 grouping log-action { 2389 description 2390 "A grouping for logging action."; 2391 leaf action { 2392 type log-action; 2393 description 2394 "Action type: allow, alert, block, discard, declare, 2395 block-ip, block-service"; 2396 } 2397 } 2398 grouping attack-rates { 2399 description 2400 "A set of traffic rates for monitoring attack traffic 2401 data"; 2402 leaf attack-rate { 2403 type uint32; 2404 units "pps"; 2405 description 2406 "The PPS rate of attack traffic"; 2407 } 2408 leaf attack-speed { 2409 type uint32; 2410 units "bps"; 2411 description 2412 "The BPS speed of attack traffic"; 2413 } 2414 } 2415 grouping traffic-rates { 2416 description 2417 "A set of traffic rates for statistics data"; 2418 leaf total-traffic { 2419 type yang:counter32; 2420 description 2421 "Total traffic"; 2422 } 2423 leaf in-traffic-average-rate { 2424 type uint32; 2425 units "pps"; 2426 description 2427 "Inbound traffic average rate in packets per second (pps)"; 2428 } 2429 leaf in-traffic-peak-rate { 2430 type uint32; 2431 units "pps"; 2432 description 2433 "Inbound traffic peak rate in packets per second (pps)"; 2434 } 2435 leaf in-traffic-average-speed { 2436 type uint32; 2437 units "bps"; 2438 description 2439 "Inbound traffic average speed in bits per second (bps)"; 2440 } 2441 leaf in-traffic-peak-speed { 2442 type uint32; 2443 units "bps"; 2444 description 2445 "Inbound traffic peak speed in bits per second (bps)"; 2446 } 2447 leaf out-traffic-average-rate { 2448 type uint32; 2449 units "pps"; 2450 description 2451 "Outbound traffic average rate in packets per second (pps)"; 2452 } 2453 leaf out-traffic-peak-rate { 2454 type uint32; 2455 units "pps"; 2456 description 2457 "Outbound traffic peak rate in packets per Second (pps)"; 2458 } 2459 leaf out-traffic-average-speed { 2460 type uint32; 2461 units "bps"; 2462 description 2463 "Outbound traffic average speed in bits per second (bps)"; 2464 } 2465 leaf out-traffic-peak-speed { 2466 type uint32; 2467 units "bps"; 2468 description 2469 "Outbound traffic peak speed in bits per second (bps)"; 2470 } 2471 } 2472 grouping i2nsf-system-counter-type-content{ 2473 description 2474 "A set of counters for an interface traffic data."; 2475 leaf interface-name { 2476 type string; 2477 description 2478 "Network interface name configured in an NSF"; 2479 } 2480 leaf in-total-traffic-pkts { 2481 type yang:counter32; 2482 description 2483 "Total inbound packets"; 2484 } 2485 leaf out-total-traffic-pkts { 2486 type yang:counter32; 2487 description 2488 "Total outbound packets"; 2489 } 2490 leaf in-total-traffic-bytes { 2491 type uint64; 2492 units "bytes"; 2493 description 2494 "Total inbound bytes"; 2495 } 2496 leaf out-total-traffic-bytes { 2497 type uint64; 2498 units "bytes"; 2499 description 2500 "Total outbound bytes"; 2501 } 2502 leaf in-drop-traffic-pkts { 2503 type yang:counter32; 2504 description 2505 "Total inbound drop packets"; 2506 } 2507 leaf out-drop-traffic-pkts { 2508 type yang:counter32; 2509 description 2510 "Total outbound drop packets"; 2511 } 2512 leaf in-drop-traffic-bytes { 2513 type uint64; 2514 units "bytes"; 2515 description 2516 "Total inbound drop bytes"; 2517 } 2518 leaf out-drop-traffic-bytes { 2519 type uint64; 2520 units "bytes"; 2521 description 2522 "Total outbound drop bytes"; 2523 } 2524 uses traffic-rates; 2525 } 2526 grouping i2nsf-nsf-counters-type-content{ 2527 description 2528 "A set of contents of a policy in an NSF."; 2530 leaf policy-name { 2531 type leafref { 2532 path 2533 "/nsfi:i2nsf-security-policy/nsfi:system-policy" 2534 +"/nsfi:system-policy-name"; 2535 } 2536 mandatory true; 2537 description 2538 "The name of the policy being triggered"; 2539 } 2540 leaf src-user{ 2541 type string; 2542 description 2543 "User who generates the policy"; 2544 } 2545 } 2547 grouping enable-notification { 2548 description 2549 "A grouping for enabling or disabling notification"; 2550 leaf enabled { 2551 type boolean; 2552 default "true"; 2553 description 2554 "Enables or Disables the notification. 2555 If 'true', then the notification is enabled. 2556 If 'false, then the notification is disabled."; 2557 } 2558 } 2560 grouping dampening { 2561 description 2562 "A grouping for dampening period of notification."; 2563 leaf dampening-period { 2564 type uint32; 2565 units "centiseconds"; 2566 default "0"; 2567 description 2568 "Specifies the minimum interval between the assembly of 2569 successive update records for a single receiver of a 2570 subscription. Whenever subscribed objects change and 2571 a dampening-period interval (which may be zero) has 2572 elapsed since the previous update record creation for 2573 a receiver, any subscribed objects and properties 2574 that have changed since the previous update record 2575 will have their current values marshalled and placed 2576 in a new update record. But if the subscribed objects change 2577 when the dampening-period is active, it should update the 2578 record without sending the notification until the dampening- 2579 period is finished. If multiple changes happen during the 2580 active dampening-period, it should update the record with the 2581 latest data. And at the end of the dampening-period, it should 2582 send the record as a notification with the latest updated 2583 record and restart the countdown."; 2584 reference 2585 "RFC 8641: Subscription to YANG Notifications for 2586 Datastore Updates - Section 5."; 2587 } 2588 } 2590 /* 2591 * Feature Nodes 2592 */ 2594 feature i2nsf-nsf-detection-ddos { 2595 description 2596 "This feature means it supports I2NSF nsf-detection-ddos 2597 notification"; 2598 } 2599 feature i2nsf-nsf-detection-virus { 2600 description 2601 "This feature means it supports I2NSF nsf-detection-virus 2602 notification"; 2603 } 2604 feature i2nsf-nsf-detection-intrusion { 2605 description 2606 "This feature means it supports I2NSF nsf-detection-intrusion 2607 notification"; 2608 } 2609 feature i2nsf-nsf-detection-botnet { 2610 description 2611 "This feature means it supports I2NSF nsf-detection-botnet 2612 notification"; 2613 } 2614 feature i2nsf-nsf-detection-web-attack { 2615 description 2616 "This feature means it supports I2NSF nsf-detection-web-attack 2617 notification"; 2618 } 2619 feature i2nsf-nsf-log-dpi { 2620 description 2621 "This feature means it supports I2NSF nsf-log-dpi 2622 notification"; 2623 } 2624 feature i2nsf-nsf-log-vuln-scan { 2625 description 2626 "This feature means it supports I2NSF nsf-log-vuln-scan 2627 notification"; 2628 } 2630 /* 2631 * Notification nodes 2632 */ 2634 notification i2nsf-event { 2635 description 2636 "Notification for I2NSF Event."; 2637 choice sub-event-type { 2638 description 2639 "This choice must be augmented with cases for each allowed 2640 sub-event. Only 1 sub-event will be instantiated in each 2641 i2nsf-event message. Each case is expected to define one 2642 container with all the sub-event fields."; 2643 case i2nsf-system-detection-alarm { 2644 container i2nsf-system-detection-alarm{ 2645 description 2646 "This notification is sent, when a system alarm 2647 is detected."; 2648 leaf alarm-category { 2649 type identityref { 2650 base alarm-type; 2651 } 2652 description 2653 "The alarm category for 2654 system-detection-alarm notification"; 2655 } 2656 leaf component-name { 2657 type string; 2658 description 2659 "The hardware component responsible for generating 2660 the message. Applicable for Hardware Failure 2661 Alarm."; 2662 } 2663 leaf interface-name { 2664 type string; 2665 description 2666 "The interface name responsible for generating 2667 the message. Applicable for Network Interface 2668 Failure Alarm."; 2669 } 2670 leaf interface-state { 2671 type enumeration { 2672 enum down { 2673 description 2674 "The interface state is down."; 2675 } 2676 enum up { 2677 description 2678 "The interface state is up."; 2679 } 2680 enum congested { 2681 description 2682 "The interface state is congested."; 2683 } 2684 } 2685 description 2686 "The state of the interface (i.e., up, down, congested). 2687 Applicable for Network Interface Failure Alarm."; 2688 } 2689 uses characteristics; 2690 uses i2nsf-system-alarm-type-content; 2691 uses common-monitoring-data; 2692 } 2693 } 2695 case i2nsf-system-detection-event { 2696 container i2nsf-system-detection-event { 2697 description 2698 "This notification is sent when a security-sensitive 2699 authentication action fails."; 2700 leaf event-category { 2701 type identityref { 2702 base event-type; 2703 } 2704 description 2705 "The event category for system-detection-event"; 2706 } 2707 uses characteristics; 2708 uses i2nsf-system-event-type-content; 2709 uses common-monitoring-data; 2710 } 2711 } 2713 case i2nsf-traffic-flows { 2714 container i2nsf-traffic-flows { 2715 description 2716 "This notification is sent to inform about the traffic 2717 flows."; 2718 leaf src-ip { 2719 type inet:ip-address; 2720 description 2721 "The source IPv4 (or IPv6) address of the packet"; 2722 } 2723 leaf dst-ip { 2724 type inet:ip-address; 2725 description 2726 "The destination IPv4 (or IPv6) address of the packet"; 2727 } 2728 leaf protocol { 2729 type identityref { 2730 base protocol-type; 2731 } 2732 description 2733 "The protocol type for nsf-detection-intrusion 2734 notification"; 2735 } 2736 leaf src-port { 2737 type inet:port-number; 2738 description 2739 "The source port of the packet"; 2740 } 2741 leaf dst-port { 2742 type inet:port-number; 2743 description 2744 "The destination port of the packet"; 2745 } 2746 leaf arrival-rate { 2747 type uint32; 2748 units "pps"; 2749 description 2750 "The arrival rate of the packet in packets 2751 per second"; 2752 } 2753 uses characteristics; 2754 uses common-monitoring-data; 2755 } 2756 } 2758 case i2nsf-nsf-detection-session-table { 2759 container i2nsf-nsf-detection-session-table { 2760 description 2761 "This notification is sent, when a session table 2762 event is detected."; 2763 leaf current-session { 2764 type uint32; 2765 description 2766 "The number of concurrent sessions"; 2767 } 2768 leaf maximum-session { 2769 type uint32; 2770 description 2771 "The maximum number of sessions that the session 2772 table can support"; 2773 } 2774 leaf threshold { 2775 type uint32; 2776 description 2777 "The threshold triggering the event"; 2778 } 2779 uses common-monitoring-data; 2780 } 2781 } 2782 } 2783 } 2785 notification i2nsf-log { 2786 description 2787 "Notification for I2NSF log. The notification is generated 2788 from the logs of the NSF."; 2789 choice sub-logs-type { 2790 description 2791 "This choice must be augmented with cases for each allowed 2792 sub-logs. Only 1 sub-event will be instantiated in each 2793 i2nsf-logs message. Each case is expected to define one 2794 container with all the sub-logs fields."; 2795 case i2nsf-nsf-system-access-log { 2796 container i2nsf-nsf-system-access-log { 2797 description 2798 "The notification is sent, if there is a new system 2799 log entry about a system access event."; 2800 leaf login-ip { 2801 type inet:ip-address; 2802 mandatory true; 2803 description 2804 "Login IP address of a user"; 2805 } 2806 leaf administrator { 2807 type string; 2808 description 2809 "Administrator that maintains the device"; 2810 } 2811 leaf login-mode { 2812 type login-mode; 2813 description 2814 "Specifies the administrator log-in mode"; 2815 } 2816 leaf operation-type { 2817 type operation-type; 2818 description 2819 "The operation type that the administrator executes"; 2820 } 2821 leaf result { 2822 type string; 2823 description 2824 "Command execution result"; 2825 } 2826 leaf content { 2827 type string; 2828 description 2829 "The Operation performed by an administrator after 2830 login"; 2831 } 2832 uses characteristics; 2833 uses common-monitoring-data; 2834 } 2835 } 2837 case i2nsf-system-res-util-log { 2838 container i2nsf-system-res-util-log { 2839 description 2840 "This notification is sent, if there is a new log 2841 entry representing resource utilization updates."; 2842 leaf system-status { 2843 type string; 2844 description 2845 "The current systems running status"; 2846 } 2847 leaf cpu-usage { 2848 type uint8; 2849 description 2850 "Specifies the relative size of CPU usage with 2851 respect to platform resources"; 2852 } 2853 leaf memory-usage { 2854 type uint8; 2855 description 2856 "Specifies the size of memory usage."; 2857 } 2858 leaf disk-usage { 2859 type uint8; 2860 description 2861 "Specifies the size of disk usage"; 2862 } 2863 leaf disk-left { 2864 type uint8; 2865 description 2866 "Specifies the size of disk left"; 2867 } 2868 leaf session-num { 2869 type uint8; 2870 description 2871 "The total number of sessions"; 2872 } 2873 leaf process-num { 2874 type uint8; 2875 description 2876 "The total number of process"; 2877 } 2878 leaf in-traffic-rate { 2879 type uint32; 2880 units "pps"; 2881 description 2882 "The total inbound traffic rate in pps"; 2883 } 2884 leaf out-traffic-rate { 2885 type uint32; 2886 units "pps"; 2887 description 2888 "The total outbound traffic rate in pps"; 2889 } 2890 leaf in-traffic-speed { 2891 type uint32; 2892 units "bps"; 2893 description 2894 "The total inbound traffic speed in bps"; 2895 } 2896 leaf out-traffic-speed { 2897 type uint32; 2898 units "bps"; 2899 description 2900 "The total outbound traffic speed in bps"; 2901 } 2902 uses characteristics; 2903 uses common-monitoring-data; 2904 } 2905 } 2907 case i2nsf-system-user-activity-log { 2908 container i2nsf-system-user-activity-log { 2909 description 2910 "This notification is sent, if there is a new user 2911 activity log entry."; 2913 uses characteristics; 2914 uses i2nsf-system-event-type-content; 2915 uses common-monitoring-data; 2916 leaf access { 2917 type identityref { 2918 base access-mode; 2919 } 2920 description 2921 "The access type for system-user-activity-log 2922 notification"; 2923 } 2924 leaf online-duration { 2925 type string; 2926 description 2927 "Online duration"; 2928 } 2929 leaf logout-duration { 2930 type string; 2931 description 2932 "Lockout duration"; 2933 } 2934 leaf additional-info { 2935 type string; 2936 description 2937 "User activities, e.g., Successful User Login, 2938 Failed Login attempts, User Logout, Successful User 2939 Password Change, Failed User Password Change, User 2940 Lockout, User Unlocking, and Unknown."; 2941 } 2942 } 2943 } 2944 } 2945 } 2947 notification i2nsf-nsf-event { 2948 description 2949 "Notification for I2NSF NSF Event. This notification is 2950 used for a specific NSF that supported such feature."; 2951 choice sub-event-type { 2952 description 2953 "This choice must be augmented with cases for each allowed 2954 sub-event. Only 1 sub-event will be instantiated in each 2955 i2nsf-event message. Each case is expected to define one 2956 container with all the sub-event fields."; 2957 case i2nsf-nsf-detection-ddos { 2958 if-feature "i2nsf-nsf-detection-ddos"; 2959 container i2nsf-nsf-detection-ddos { 2960 description 2961 "This notification is sent, when a specific flood type 2962 is detected."; 2963 uses i2nsf-nsf-event-type-content; 2964 leaf attack-type { 2965 type identityref { 2966 base flood-type; 2967 } 2968 description 2969 "Any one of Syn flood, ACK flood, SYN-ACK flood, 2970 FIN/RST flood, TCP Connection flood, UDP flood, 2971 ICMP (i.e., ICMPv4 or ICMPv6) flood, HTTP flood, 2972 HTTPS flood, DNS query flood, DNS reply flood, SIP 2973 flood, etc."; 2974 } 2975 leaf start-time { 2976 type yang:date-and-time; 2977 mandatory true; 2978 description 2979 "The time stamp indicating when the attack started"; 2980 } 2981 leaf end-time { 2982 type yang:date-and-time; 2983 mandatory true; 2984 description 2985 "The time stamp indicating when the attack ended"; 2986 } 2987 leaf attack-src-ip { 2988 type inet:ip-address; 2989 description 2990 "The source IPv4 (or IPv6) addresses of attack 2991 traffic. If there are a large number of IPv4 2992 (or IPv6) addresses, then pick a certain number 2993 of resources according to different rules."; 2994 } 2995 leaf attack-dst-ip { 2996 type inet:ip-address; 2997 description 2998 "The destination IPv4 (or IPv6) addresses of attack 2999 traffic. If there are a large number of IPv4 3000 (or IPv6) addresses, then pick a certain number 3001 of resources according to different rules."; 3002 } 3003 uses attack-rates; 3004 uses log-action; 3005 uses characteristics; 3006 uses common-monitoring-data; 3007 } 3008 } 3009 case i2nsf-nsf-detection-virus { 3010 if-feature "i2nsf-nsf-detection-virus"; 3011 container i2nsf-nsf-detection-virus { 3012 description 3013 "This notification is sent, when a virus is detected."; 3014 uses i2nsf-nsf-event-type-content-extend; 3015 leaf virus { 3016 type identityref { 3017 base virus-type; 3018 } 3019 description 3020 "The virus type for nsf-detection-virus notification"; 3021 } 3022 leaf virus-name { 3023 type string; 3024 description 3025 "The name of the detected virus"; 3026 } 3027 leaf file-type { 3028 type string; 3029 description 3030 "The type of file virus code is found in (if 3031 applicable)."; 3032 } 3033 leaf file-name { 3034 type string; 3035 description 3036 "The name of file virus code is found in (if 3037 applicable)."; 3038 } 3039 leaf os { 3040 type string; 3041 description 3042 "Simple OS information"; 3043 } 3044 uses log-action; 3045 uses characteristics; 3046 uses common-monitoring-data; 3047 } 3048 } 3049 case i2nsf-nsf-detection-intrusion { 3050 if-feature "i2nsf-nsf-detection-intrusion"; 3051 container i2nsf-nsf-detection-intrusion { 3052 description 3053 "This notification is sent, when an intrusion event 3054 is detected."; 3055 uses i2nsf-nsf-event-type-content-extend; 3056 leaf protocol { 3057 type identityref { 3058 base protocol-type; 3059 } 3060 description 3061 "The protocol type for nsf-detection-intrusion 3062 notification"; 3063 } 3064 leaf app { 3065 type string; 3066 description 3067 "The employed application layer protocol"; 3068 } 3069 leaf attack-type { 3070 type identityref { 3071 base intrusion-attack-type; 3072 } 3073 description 3074 "The sub attack type for intrusion attack"; 3075 } 3076 uses log-action; 3077 uses attack-rates; 3078 uses characteristics; 3079 uses common-monitoring-data; 3080 } 3081 } 3082 case i2nsf-nsf-detection-botnet { 3083 if-feature "i2nsf-nsf-detection-botnet"; 3084 container i2nsf-nsf-detection-botnet { 3085 description 3086 "This notification is sent, when a botnet event is 3087 detected."; 3088 uses i2nsf-nsf-event-type-content-extend; 3089 leaf attack-type { 3090 type identityref { 3091 base botnet-attack-type; 3092 } 3093 description 3094 "The attack type for botnet attack"; 3095 } 3096 leaf protocol { 3097 type identityref { 3098 base protocol-type; 3099 } 3100 description 3101 "The protocol type for nsf-detection-botnet 3102 notification"; 3103 } 3104 leaf botnet-name { 3105 type string; 3106 description 3107 "The name of the detected botnet"; 3108 } 3109 leaf role { 3110 type string; 3111 description 3112 "The role of the communicating 3113 parties within the botnet"; 3114 } 3115 uses log-action; 3116 leaf botnet-pkt-num{ 3117 type uint8; 3118 description 3119 "The number of the packets sent to or from the detected 3120 botnet"; 3121 } 3122 leaf os{ 3123 type string; 3124 description 3125 "Simple OS information"; 3126 } 3127 uses characteristics; 3128 uses common-monitoring-data; 3129 } 3130 } 3131 case i2nsf-nsf-detection-web-attack { 3132 if-feature "i2nsf-nsf-detection-web-attack"; 3133 container i2nsf-nsf-detection-web-attack { 3134 description 3135 "This notification is sent, when an attack event is 3136 detected."; 3137 uses i2nsf-nsf-event-type-content-extend; 3138 leaf attack-type { 3139 type identityref { 3140 base web-attack-type; 3141 } 3142 description 3143 "Concrete web attack type, e.g., SQL injection, 3144 command injection, XSS, and CSRF."; 3145 } 3146 leaf request-method { 3147 type identityref { 3148 base req-method; 3149 } 3150 description 3151 "The method of requirement. For instance, PUT or 3152 GET in HTTP."; 3154 } 3155 leaf req-uri { 3156 type string; 3157 description 3158 "Requested URI"; 3159 } 3160 leaf uri-category { 3161 type string; 3162 description 3163 "Matched URI category"; 3164 } 3165 leaf-list filtering-type { 3166 type identityref { 3167 base filter-type; 3168 } 3169 description 3170 "URL filtering type, e.g., Blacklist, Whitelist, 3171 User-Defined, Predefined, Malicious Category, 3172 and Unknown"; 3173 } 3174 leaf rsp-code { 3175 type string; 3176 description 3177 "Response code"; 3178 } 3179 leaf req-clientapp { 3180 type string; 3181 description 3182 "The client application"; 3183 } 3184 leaf req-cookies { 3185 type string; 3186 description 3187 "Cookies"; 3188 } 3189 leaf req-host { 3190 type string; 3191 description 3192 "The domain name of the requested host"; 3193 } 3194 uses characteristics; 3195 uses log-action; 3196 uses common-monitoring-data; 3197 } 3198 } 3199 case i2nsf-nsf-log-vuln-scan { 3200 if-feature "i2nsf-nsf-log-vuln-scan"; 3201 container i2nsf-nsf-log-vuln-scan { 3202 description 3203 "This notification is sent, if there is a new 3204 vulnerability-scan report in the NSF log."; 3205 leaf vulnerability-id { 3206 type uint8; 3207 description 3208 "The vulnerability ID"; 3209 } 3210 leaf victim-ip { 3211 type inet:ip-address; 3212 description 3213 "IPv4 (or IPv6) address of the victim host which 3214 has vulnerabilities"; 3215 } 3216 leaf protocol { 3217 type identityref { 3218 base protocol-type; 3219 } 3220 description 3221 "The protocol type for nsf-log-vuln-scan 3222 notification"; 3223 } 3224 leaf port-num { 3225 type inet:port-number; 3226 description 3227 "The port number"; 3228 } 3229 leaf level { 3230 type severity; 3231 description 3232 "The vulnerability severity"; 3233 } 3234 leaf os { 3235 type string; 3236 description 3237 "simple OS information"; 3238 } 3239 leaf vulnerability-info { 3240 type string; 3241 description 3242 "The information about the vulnerability"; 3243 } 3244 leaf fix-suggestion { 3245 type string; 3246 description 3247 "The fix suggestion to the vulnerability"; 3248 } 3249 leaf service { 3250 type string; 3251 description 3252 "The service which has vulnerability in the victim 3253 host"; 3254 } 3255 uses characteristics; 3256 uses common-monitoring-data; 3257 } 3258 } 3259 case i2nsf-nsf-log-dpi { 3260 if-feature "i2nsf-nsf-log-dpi"; 3261 container i2nsf-nsf-log-dpi { 3262 description 3263 "This notification is sent, if there is a new DPI 3264 event in the NSF log."; 3265 leaf attack-type { 3266 type dpi-type; 3267 description 3268 "The type of the DPI"; 3269 } 3270 uses characteristics; 3271 uses i2nsf-nsf-counters-type-content; 3272 uses common-monitoring-data; 3273 } 3274 } 3275 } 3276 } 3277 /* 3278 * Data nodes 3279 */ 3280 container i2nsf-counters { 3281 config false; 3282 description 3283 "This is probably better covered by an import as this 3284 will not be notifications. Counters are not very 3285 suitable as telemetry, maybe via periodic 3286 subscriptions, which would still violate the principle 3287 of least surprise."; 3288 list system-interface { 3289 key interface-name; 3290 description 3291 "Interface counters provide the visibility of traffic into and 3292 out of an NSF, and bandwidth usage."; 3293 uses characteristics; 3294 uses i2nsf-system-counter-type-content; 3295 uses common-monitoring-data; 3296 } 3297 list nsf-firewall { 3298 key policy-name; 3299 description 3300 "Firewall counters provide the visibility of traffic 3301 signatures, bandwidth usage, and how the configured security 3302 and bandwidth policies have been applied."; 3303 uses characteristics; 3304 uses i2nsf-nsf-counters-type-content; 3305 uses traffic-rates; 3306 uses common-monitoring-data; 3307 } 3308 list nsf-policy-hits { 3309 key policy-name; 3310 description 3311 "Policy Hit Counters record the number of hits that traffic 3312 packets match a security policy. It can check if policy 3313 configurations are correct or not."; 3314 uses characteristics; 3315 uses i2nsf-nsf-counters-type-content; 3316 uses common-monitoring-data; 3317 leaf hit-times { 3318 type yang:counter32; 3319 description 3320 "The number of times a policy is hit"; 3321 } 3322 } 3323 } 3325 container i2nsf-monitoring-configuration { 3326 description 3327 "The container for configuring I2NSF monitoring."; 3328 container i2nsf-system-detection-alarm { 3329 description 3330 "The container for configuring I2NSF system-detection-alarm 3331 notification"; 3332 uses enable-notification; 3333 list system-alarm { 3334 key alarm-type; 3335 description 3336 "Configuration for system alarm (i.e., CPU, Memory, 3337 and Disk Usage)"; 3338 leaf alarm-type { 3339 type enumeration { 3340 enum CPU { 3341 description 3342 "To configure the CPU usage threshold to trigger the 3343 CPU-USAGE-ALARM"; 3344 } 3345 enum Memory { 3346 description 3347 "To configure the Memory usage threshold to trigger the 3348 MEM-USAGE-ALARM"; 3349 } 3350 enum Disk { 3351 description 3352 "To configure the Disk (storage) usage threshold to 3353 trigger the DISK-USAGE-ALARM"; 3354 } 3355 } 3356 description 3357 "Type of alarm to be configured"; 3358 } 3359 leaf threshold { 3360 type uint8 { 3361 range "1..100"; 3362 } 3363 units "percent"; 3364 description 3365 "The configuration for threshold percentage to trigger 3366 the alarm. The alarm will be triggered if the usage 3367 is exceeded the threshold."; 3368 } 3369 uses dampening; 3370 } 3371 } 3372 container i2nsf-system-detection-event { 3373 description 3374 "The container for configuring I2NSF system-detection-event 3375 notification"; 3376 uses enable-notification; 3377 uses dampening; 3378 } 3379 container i2nsf-traffic-flows { 3380 description 3381 "The container for configuring I2NSF traffic-flows 3382 notification"; 3383 uses dampening; 3384 uses enable-notification; 3385 } 3386 container i2nsf-nsf-detection-ddos { 3387 if-feature "i2nsf-nsf-detection-ddos"; 3388 description 3389 "The container for configuring I2NSF nsf-detection-ddos 3390 notification"; 3391 uses enable-notification; 3392 uses dampening; 3393 } 3394 container i2nsf-nsf-detection-session-table-configuration { 3395 description 3396 "The container for configuring I2NSF nsf-detection-session- 3397 table notification"; 3398 uses enable-notification; 3399 uses dampening; 3400 } 3401 container i2nsf-nsf-detection-virus { 3402 if-feature "i2nsf-nsf-detection-virus"; 3403 description 3404 "The container for configuring I2NSF nsf-detection-virus 3405 notification"; 3406 uses enable-notification; 3407 uses dampening; 3408 } 3409 container i2nsf-nsf-detection-intrusion { 3410 if-feature "i2nsf-nsf-detection-intrusion"; 3411 description 3412 "The container for configuring I2NSF nsf-detection-intrusion 3413 notification"; 3414 uses enable-notification; 3415 uses dampening; 3416 } 3417 container i2nsf-nsf-detection-botnet { 3418 if-feature "i2nsf-nsf-detection-botnet"; 3419 description 3420 "The container for configuring I2NSF nsf-detection-botnet 3421 notification"; 3422 uses enable-notification; 3423 uses dampening; 3424 } 3425 container i2nsf-nsf-detection-web-attack { 3426 if-feature "i2nsf-nsf-detection-web-attack"; 3427 description 3428 "The container for configuring I2NSF nsf-detection-web-attack 3429 notification"; 3430 uses enable-notification; 3431 uses dampening; 3432 } 3433 container i2nsf-nsf-system-access-log { 3434 description 3435 "The container for configuring I2NSF system-access-log 3436 notification"; 3437 uses enable-notification; 3438 uses dampening; 3439 } 3440 container i2nsf-system-res-util-log { 3441 description 3442 "The container for configuring I2NSF system-res-util-log 3443 notification"; 3444 uses enable-notification; 3445 uses dampening; 3446 } 3447 container i2nsf-system-user-activity-log { 3448 description 3449 "The container for configuring I2NSF system-user-activity-log 3450 notification"; 3451 uses enable-notification; 3452 uses dampening; 3453 } 3454 container i2nsf-nsf-log-dpi { 3455 if-feature "i2nsf-nsf-log-dpi"; 3456 description 3457 "The container for configuring I2NSF nsf-log-dpi 3458 notification"; 3459 uses enable-notification; 3460 uses dampening; 3461 } 3462 container i2nsf-nsf-log-vuln-scan { 3463 if-feature "i2nsf-nsf-log-vuln-scan"; 3464 description 3465 "The container for configuring I2NSF nsf-log-vuln-scan 3466 notification"; 3467 uses enable-notification; 3468 uses dampening; 3469 } 3470 container i2nsf-counter { 3471 description 3472 "This is used to configure the counters 3473 for monitoring an NSF"; 3474 leaf period { 3475 type uint16; 3476 units "minutes"; 3477 default 0; 3478 description 3479 "The configuration for the period interval of reporting 3480 the counter. If 0, then the counter period is disabled. 3481 If value is not 0, then the counter will be reported 3482 following the period value."; 3483 } 3484 } 3485 } 3486 } 3487 3489 Figure 2: Data Model of Monitoring 3491 11. I2NSF Event Stream 3493 This section discusses the NETCONF event stream for I2NSF NSF 3494 Monitoring subscription. The YANG module in this document supports 3495 "ietf-subscribed-notifications" YANG module [RFC8639] for 3496 subscription. The reserved event stream name for this document is 3497 "I2NSF-Monitoring". The NETCONF Server (e.g., an NSF) MUST support 3498 "I2NSF-Monitoring" event stream for an NSF data collector (e.g., 3499 Security Controller and NSF data analyzer). The "I2NSF-Monitoring" 3500 event stream contains all I2NSF events described in this document. 3501 The following example shows the capabilities of the event streams of 3502 an NSF (e.g., "NETCONF" and "I2NSF-Monitoring" event streams) by the 3503 subscription of an NSF data collector; note that this example XML 3504 file is delivered by an NSF to an NSF data collector: 3506 3507 3509 3510 3511 3512 3513 NETCONF 3514 Default NETCONF Event Stream 3515 false 3516 3517 3518 I2NSF-Monitoring 3519 I2NSF Monitoring Event Stream 3520 true 3521 3522 2021-04-29T09:37:39+00:00 3523 3524 3525 3526 3527 3528 3530 Figure 3: Example of NETCONF Server supporting I2NSF-Monitoring Event 3531 Stream 3533 12. XML Examples for I2NSF NSF Monitoring 3535 This section shows the XML examples of I2NSF NSF Monitoring data 3536 delivered via Monitoring Interface from an NSF. 3538 12.1. I2NSF System Detection Alarm 3540 The following example shows an alarm triggered by Memory Usage of the 3541 server; note that this example XML file is delivered by an NSF to an 3542 NSF data collector: 3544 3545 3546 2021-04-29T07:43:52.181088+00:00 3547 3549 3550 3553 nsfmi:mem-usage-alarm 3554 3555 3558 nsfmi:subscription 3559 3560 3563 nsfmi:on-change 3564 3565 3568 nsfmi:on-repetition 3569 3570 91 3571 90 3572 Memory Usage Exceeded the Threshold 3573 time_based_firewall 3574 high 3575 3576 3577 3579 Figure 4: Example of I2NSF System Detection Alarm triggered by Memory 3580 Usage 3582 The XML data above shows: 3584 1. The NSF that sends the information is named 3585 "time_based_firewall". 3587 2. The memory usage of the NSF triggered the alarm. 3589 3. The monitoring information is received by subscription method. 3591 4. The monitoring information is emitted "on-change". 3593 5. The monitoring information is dampened "on-repetition". 3595 6. The memory usage of the NSF is 91 percent. 3597 7. The memory threshold to trigger the alarm is 90 percent. 3599 8. The severity level of the notification is high. 3601 12.2. I2NSF Interface Counters 3603 To get the I2NSF system interface counters information by query, 3604 NETCONF Client (e.g., NSF data collector) needs to initiate GET 3605 connection with NETCONF Server (e.g., NSF). The following XML file 3606 can be used to get the state data and filter the information. 3608 3609 3610 3611 3613 3614 3615 3616 3617 3618 3620 Figure 5: XML Example for NETCONF GET with System Interface Filter 3622 The following XML file shows the reply from the NETCONF Server (e.g., 3623 NSF): 3625 3626 3628 3629 3631 3632 ens3 3633 3636 nsfmi:query 3637 3638 549050 3639 814956 3640 0 3641 5078 3642 time_based_firewall 3643 3644 3645 lo 3646 3649 nsfmi:query 3650 3651 48487 3652 48487 3653 0 3654 0 3655 time_based_firewall 3656 3657 3658 3659 3661 Figure 6: Example of I2NSF System Interface Counters XML Information 3663 13. IANA Considerations 3665 This document requests IANA to register the following URI in the 3666 "IETF XML Registry" [RFC3688]: 3668 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring 3669 Registrant Contact: The IESG. 3670 XML: N/A; the requested URI is an XML namespace. 3672 This document requests IANA to register the following YANG module in 3673 the "YANG Module Names" registry [RFC7950][RFC8525]: 3675 name: ietf-i2nsf-nsf-monitoring 3676 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring 3677 prefix: nsfmi 3678 reference: RFC XXXX 3680 // RFC Ed.: replace XXXX with an actual RFC number and remove 3681 // this note. 3683 14. Security Considerations 3685 The YANG module described in this document defines a schema for data 3686 that is designed to be accessed via network management protocols such 3687 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 3688 is the secure transport layer, and the mandatory-to-implement secure 3689 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 3690 is HTTPS, and the mandatory-to-implement secure transport is TLS 3691 [RFC8446]. 3693 The NETCONF access control model [RFC8341] provides the means to 3694 restrict access for particular NETCONF or RESTCONF users to a 3695 preconfigured subset of all available NETCONF or RESTCONF protocol 3696 operations and content. 3698 All data nodes defined in the YANG module which can be created, 3699 modified and deleted (i.e., config true, which is the default) are 3700 considered sensitive. Write operations (e.g., edit-config) applied 3701 to these data nodes without proper protection can negatively affect 3702 framework operations. The monitoring YANG module should be protected 3703 by the secure communication channel, to ensure its confidentiality 3704 and integrity. In another side, the NSF and NSF data collector can 3705 all be faked, which lead to undesirable results (i.e., leakage of an 3706 NSF's important operational information, and faked NSF sending false 3707 information to mislead the NSF data collector). The mutual 3708 authentication is essential to protected against this kind of attack. 3709 The current mainstream security technologies (i.e., TLS, DTLS, IPsec, 3710 and X.509 PKI) can be employed appropriately to provide the above 3711 security functions. 3713 In addition, to defend against the DDoS attack caused by a lot of 3714 NSFs sending massive notifications to the NSF data collector, the 3715 rate limiting or similar mechanisms should be considered in both an 3716 NSF and NSF data collector, whether in advance or just in the process 3717 of DDoS attack. 3719 15. Acknowledgments 3721 This work was supported by Institute of Information & Communications 3722 Technology Planning & Evaluation (IITP) grant funded by the Korea 3723 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 3724 Security Intelligence Technology Development for the Customized 3725 Security Service Provisioning). This work was supported in part by 3726 the IITP (2020-0-00395, Standard Development of Blockchain based 3727 Network Management Automation Technology). This work was supported 3728 in part by the MSIT under the Information Technology Research Center 3729 (ITRC) support program (IITP-2021-2017-0-01633) supervised by the 3730 IITP. 3732 16. Contributors 3734 This document is made by the group effort of I2NSF working group. 3735 Many people actively contributed to this document. The authors 3736 sincerely appreciate their contributions. 3738 The following are co-authors of this document: 3740 Chaehong Chung 3741 Department of Electronic, Electrical and Computer Engineering 3742 Sungkyunkwan University 3743 2066 Seo-ro Jangan-gu 3744 Suwon, Gyeonggi-do 16419 3745 Republic of Korea 3747 EMail: darkhong@skku.edu 3749 Jinyong (Tim) Kim 3750 Department of Electronic, Electrical and Computer Engineering 3751 Sungkyunkwan University 3752 2066 Seo-ro Jangan-gu 3753 Suwon, Gyeonggi-do 16419 3754 Republic of Korea 3756 EMail: timkim@skku.edu 3758 Dongjin Hong 3759 Department of Electronic, Electrical and Computer Engineering 3760 Sungkyunkwan University 3761 2066 Seo-ro Jangan-gu 3762 Suwon, Gyeonggi-do 16419 3763 Republic of Korea 3764 EMail: dong.jin@skku.edu 3766 Dacheng Zhang 3767 Huawei 3769 EMail: dacheng.zhang@huawei.com 3771 Yi Wu 3772 Aliababa Group 3774 EMail: anren.wy@alibaba-inc.com 3776 Rakesh Kumar 3777 Juniper Networks 3778 1133 Innovation Way 3779 Sunnyvale, CA 94089 3780 USA 3782 EMail: rkkumar@juniper.net 3784 Anil Lohiya 3785 Juniper Networks 3787 EMail: alohiya@juniper.net 3789 17. References 3791 17.1. Normative References 3793 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3794 DOI 10.17487/RFC0768, August 1980, 3795 . 3797 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3798 DOI 10.17487/RFC0791, September 1981, 3799 . 3801 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3802 RFC 792, DOI 10.17487/RFC0792, September 1981, 3803 . 3805 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 3806 RFC 793, DOI 10.17487/RFC0793, September 1981, 3807 . 3809 [RFC0956] Mills, D., "Algorithms for synchronizing network clocks", 3810 RFC 956, DOI 10.17487/RFC0956, September 1985, 3811 . 3813 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 3814 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 3815 . 3817 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3818 Requirement Levels", BCP 14, RFC 2119, 3819 DOI 10.17487/RFC2119, March 1997, 3820 . 3822 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3823 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3824 Transfer Protocol -- HTTP/1.1", RFC 2616, 3825 DOI 10.17487/RFC2616, June 1999, 3826 . 3828 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3829 DOI 10.17487/RFC3688, January 2004, 3830 . 3832 [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management 3833 Information Base (MIB)", RFC 3877, DOI 10.17487/RFC3877, 3834 September 2004, . 3836 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 3837 Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, 3838 . 3840 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3841 Control Message Protocol (ICMPv6) for the Internet 3842 Protocol Version 6 (IPv6) Specification", STD 89, 3843 RFC 4443, DOI 10.17487/RFC4443, March 2006, 3844 . 3846 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 3847 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 3848 . 3850 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 3851 DOI 10.17487/RFC5424, March 2009, 3852 . 3854 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3855 and A. Bierman, Ed., "Network Configuration Protocol 3856 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3857 . 3859 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 3860 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 3861 . 3863 [RFC6587] Gerhards, R. and C. Lonvick, "Transmission of Syslog 3864 Messages over TCP", RFC 6587, DOI 10.17487/RFC6587, April 3865 2012, . 3867 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3868 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3869 . 3871 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 3872 "Specification of the IP Flow Information Export (IPFIX) 3873 Protocol for the Exchange of Flow Information", STD 77, 3874 RFC 7011, DOI 10.17487/RFC7011, September 2013, 3875 . 3877 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3878 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3879 . 3881 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3882 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 3883 . 3885 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3886 (IPv6) Specification", STD 86, RFC 8200, 3887 DOI 10.17487/RFC8200, July 2017, 3888 . 3890 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 3891 Kumar, "Framework for Interface to Network Security 3892 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 3893 . 3895 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3896 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3897 . 3899 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 3900 Access Control Model", STD 91, RFC 8341, 3901 DOI 10.17487/RFC8341, March 2018, 3902 . 3904 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 3905 and R. Wilton, "Network Management Datastore Architecture 3906 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 3907 . 3909 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 3910 Documents Containing YANG Data Models", BCP 216, RFC 8407, 3911 DOI 10.17487/RFC8407, October 2018, 3912 . 3914 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3915 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3916 . 3918 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 3919 and R. Wilton, "YANG Library", RFC 8525, 3920 DOI 10.17487/RFC8525, March 2019, 3921 . 3923 [RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm 3924 Management", RFC 8632, DOI 10.17487/RFC8632, September 3925 2019, . 3927 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 3928 E., and A. Tripathy, "Subscription to YANG Notifications", 3929 RFC 8639, DOI 10.17487/RFC8639, September 2019, 3930 . 3932 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 3933 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 3934 September 2019, . 3936 17.2. Informative References 3938 [I-D.ietf-i2nsf-applicability] 3939 Jeong, J., Hyun, S., Ahn, T., Hares, S., and D. Lopez, 3940 "Applicability of Interfaces to Network Security Functions 3941 to Network-Based Security Services", draft-ietf-i2nsf- 3942 applicability-18 (work in progress), September 2019. 3944 [I-D.ietf-i2nsf-capability] 3945 Xia, L., Strassner, J., Basile, C., and D. Lopez, 3946 "Information Model of NSFs Capabilities", draft-ietf- 3947 i2nsf-capability-05 (work in progress), April 2019. 3949 [I-D.ietf-i2nsf-consumer-facing-interface-dm] 3950 Jeong, J., Chung, C., Ahn, T., Kumar, R., and S. Hares, 3951 "I2NSF Consumer-Facing Interface YANG Data Model", draft- 3952 ietf-i2nsf-consumer-facing-interface-dm-13 (work in 3953 progress), March 2021. 3955 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 3956 Kim, J., Jeong, J., J., J., PARK, P., Hares, S., and Q. 3957 Lin, "I2NSF Network Security Function-Facing Interface 3958 YANG Data Model", draft-ietf-i2nsf-nsf-facing-interface- 3959 dm-12 (work in progress), March 2021. 3961 [I-D.ietf-i2nsf-registration-interface-dm] 3962 Hyun, S., Jeong, J., Roh, T., Wi, S., J., J., and P. PARK, 3963 "I2NSF Registration Interface YANG Data Model", draft- 3964 ietf-i2nsf-registration-interface-dm-10 (work in 3965 progress), February 2021. 3967 [I-D.ietf-netconf-subscribed-notifications] 3968 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 3969 A. Tripathy, "Subscription to YANG Event Notifications", 3970 draft-ietf-netconf-subscribed-notifications-26 (work in 3971 progress), May 2019. 3973 [I-D.ietf-netconf-yang-push] 3974 Clemm, A. and E. Voit, "Subscription to YANG Datastores", 3975 draft-ietf-netconf-yang-push-25 (work in progress), May 3976 2019. 3978 [I-D.yang-i2nsf-security-policy-translation] 3979 Jeong, J., Lingga, P., Yang, J., and C. Chung, "Security 3980 Policy Translation in Interface to Network Security 3981 Functions", draft-yang-i2nsf-security-policy- 3982 translation-08 (work in progress), February 2021. 3984 Appendix A. Changes from draft-ietf-i2nsf-nsf-monitoring-data-model-07 3986 The following changes are made from draft-ietf-i2nsf-nsf-monitoring- 3987 data-model-07: 3989 o This version is revised according to the comments from both Tom 3990 Petch and Andy Bierman. 3992 Authors' Addresses 3994 Jaehoon (Paul) Jeong (editor) 3995 Department of Computer Science and Engineering 3996 Sungkyunkwan University 3997 2066 Seobu-Ro, Jangan-Gu 3998 Suwon, Gyeonggi-Do 16419 3999 Republic of Korea 4001 Phone: +82 31 299 4957 4002 Fax: +82 31 290 7996 4003 EMail: pauljeong@skku.edu 4004 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 4006 Patrick Lingga 4007 Department of Electronic, Electrical and Computer Engineering 4008 Sungkyunkwan University 4009 2066 Seobu-Ro, Jangan-Gu 4010 Suwon, Gyeonggi-Do 16419 4011 Republic of Korea 4013 Phone: +82 31 299 4957 4014 EMail: patricklink@skku.edu 4016 Susan Hares 4017 Huawei 4018 7453 Hickory Hill 4019 Saline, MI 48176 4020 USA 4022 Phone: +1-734-604-0332 4023 EMail: shares@ndzh.com 4024 Liang (Frank) Xia 4025 Huawei 4026 101 Software Avenue, Yuhuatai District 4027 Nanjing, Jiangsu 4028 China 4030 EMail: Frank.xialiang@huawei.com 4032 Henk Birkholz 4033 Fraunhofer Institute for Secure Information Technology 4034 Rheinstrasse 75 4035 Darmstadt 64295 4036 Germany 4038 EMail: henk.birkholz@sit.fraunhofer.de