idnits 2.17.1 draft-ietf-i2nsf-nsf-monitoring-data-model-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 16 instances of too long lines in the document, the longest one being 24 characters in excess of 72. 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 (March 31, 2021) is 1112 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 3785, but no explicit reference was found in the text == Unused Reference: 'RFC8641' is defined on line 3896, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2nsf-capability' is defined on line 3908, 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-12 == Outdated reference: A later version (-29) exists of draft-ietf-i2nsf-nsf-facing-interface-dm-10 == Outdated reference: A later version (-26) exists of draft-ietf-i2nsf-registration-interface-dm-09 == Outdated reference: A later version (-16) exists of draft-yang-i2nsf-security-policy-translation-07 Summary: 8 errors (**), 0 flaws (~~), 9 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 2, 2021 S. Hares 6 L. Xia 7 Huawei 8 H. Birkholz 9 Fraunhofer SIT 10 March 31, 2021 12 I2NSF NSF Monitoring Interface YANG Data Model 13 draft-ietf-i2nsf-nsf-monitoring-data-model-07 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 2, 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 . . . . . . . . . . . . . . . . . . . . . 73 109 12. XML Examples for I2NSF NSF Monitoring . . . . . . . . . . . . 74 110 12.1. I2NSF System Detection Alarm . . . . . . . . . . . . . . 74 111 12.2. I2NSF Interface Counters . . . . . . . . . . . . . . . . 76 112 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 113 14. Security Considerations . . . . . . . . . . . . . . . . . . . 78 114 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79 115 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 79 116 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 117 17.1. Normative References . . . . . . . . . . . . . . . . . . 80 118 17.2. Informative References . . . . . . . . . . . . . . . . . 83 119 Appendix A. Changes from draft-ietf-i2nsf-nsf-monitoring-data- 120 model-06 . . . . . . . . . . . . . . . . . . . . . . 85 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85 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 [RFC0768] 1562 [RFC0791][RFC0792][RFC0793][RFC0956][RFC2616][RFC4443][RFC8200][RFC86 1563 41]. 1565 file "ietf-i2nsf-nsf-monitoring@2021-03-31.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 } 1586 organization 1587 "IETF I2NSF (Interface to Network Security Functions) 1588 Working Group"; 1589 contact 1590 "WG Web: 1591 WG List: 1593 Editor: Jaehoon Paul Jeong 1594 1596 Editor: Patrick Lingga 1597 "; 1599 description 1600 "This module is a YANG module for I2NSF NSF Monitoring. 1602 Copyright (c) 2021 IETF Trust and the persons identified as 1603 authors of the code. All rights reserved. 1605 Redistribution and use in source and binary forms, with or 1606 without modification, is permitted pursuant to, and subject to 1607 the license terms contained in, the Simplified BSD License set 1608 forth in Section 4.c of the IETF Trust's Legal Provisions 1609 Relating to IETF Documents 1610 (https://trustee.ietf.org/license-info). 1612 This version of this YANG module is part of RFC XXXX 1613 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 1614 for full legal notices."; 1616 revision "2021-03-31" { 1617 description "Initial revision"; 1618 reference 1619 "RFC XXXX: I2NSF NSF Monitoring YANG Data Model"; 1621 // RFC Ed.: replace XXXX with an actual RFC number and remove 1622 // this note. 1623 } 1625 /* 1626 * Typedefs 1627 */ 1629 typedef severity { 1630 type enumeration { 1631 enum critical { 1632 description 1633 "The 'critical' severity level indicates that 1634 an immediate corrective action is required. 1635 A 'critical' severity is reported when a service 1636 becomes totally out of service and must be restored."; 1637 } 1638 enum high { 1639 description 1640 "The 'high' severity level indicates that 1641 an urgent corrective action is required. 1642 A 'high' severity is reported when there is 1643 a severe degradation in the capability of the 1644 service and its full capability must be restored."; 1645 } 1646 enum middle { 1647 description 1648 "The 'middle' severity level indicates the 1649 existence of a non-service-affecting fault 1650 condition and corrective action should be done 1651 to prevent a more serious fault. The 'middle' 1652 severity is reported when the detected problem 1653 is not degrading the capability of the service but 1654 might happen if not prevented."; 1655 } 1656 enum low { 1657 description 1658 "The 'low' severity level indicates the detection 1659 of a potential fault before any effect is felt. 1660 The 'low' severity is reported when an action should 1661 be done before a fault happen."; 1662 } 1663 } 1664 description 1665 "An indicator representing severity level. The severity level 1666 starting from the highest are critical, high, middle, and 1667 low."; 1668 reference 1669 "RFC 8632: A YANG Data Model for Alarm Management - 1670 The severity levels are defined."; 1671 } 1673 typedef log-action { 1674 type enumeration { 1675 enum allow { 1676 description 1677 "If action is allowed"; 1678 } 1679 enum alert { 1680 description 1681 "If action is alert"; 1682 } 1683 enum block { 1684 description 1685 "If action is block"; 1686 } 1687 enum discard { 1688 description 1689 "If action is discarded"; 1690 } 1691 enum declare { 1692 description 1693 "If action is declared"; 1694 } 1695 enum block-ip { 1696 description 1697 "If action is block-ip"; 1698 } 1699 enum block-service{ 1700 description 1701 "If action is block-service"; 1702 } 1703 } 1704 description 1705 "The type representing action for logging."; 1706 } 1708 typedef dpi-type{ 1709 type enumeration { 1710 enum file-blocking{ 1711 description 1712 "DPI for blocking file"; 1713 } 1714 enum data-filtering{ 1715 description 1716 "DPI for filtering data"; 1717 } 1718 enum application-behavior-control{ 1719 description 1720 "DPI for controlling application behavior"; 1721 } 1722 } 1723 description 1724 "The type of deep packet inspection."; 1725 } 1727 typedef operation-type{ 1728 type enumeration { 1729 enum login{ 1730 description 1731 "Login operation"; 1732 } 1733 enum logout{ 1734 description 1735 "Logout operation"; 1736 } 1737 enum configuration{ 1738 description 1739 "Configuration operation"; 1740 } 1741 } 1742 description 1743 "The type of operation done by a user 1744 during a session."; 1745 } 1747 typedef login-mode{ 1748 type enumeration { 1749 enum root{ 1750 description 1751 "Root login-mode"; 1752 } 1753 enum user{ 1754 description 1755 "User login-mode"; 1756 } 1757 enum guest{ 1758 description 1759 "Guest login-mode"; 1760 } 1761 } 1762 description 1763 "The authorization login-mode done by a user."; 1764 } 1766 /* 1767 * Identity 1768 */ 1770 identity characteristics { 1771 description 1772 "Base identity for monitoring information 1773 characteristics"; 1774 } 1775 identity acquisition-method { 1776 base characteristics; 1777 description 1778 "The type of acquisition-method. It can be multiple 1779 types at once."; 1780 } 1781 identity subscription { 1782 base acquisition-method; 1783 description 1784 "The acquisition-method type is subscription."; 1785 } 1786 identity query { 1787 base acquisition-method; 1788 description 1789 "The acquisition-method type is query."; 1790 } 1791 identity emission-type { 1792 base characteristics; 1793 description 1794 "The type of emission-type."; 1795 } 1796 identity periodical { 1797 base emission-type; 1798 description 1799 "The emission-type type is periodical."; 1800 } 1801 identity on-change { 1802 base emission-type; 1803 description 1804 "The emission-type type is on-change."; 1806 } 1807 identity dampening-type { 1808 base characteristics; 1809 description 1810 "The type of dampening-type."; 1811 } 1812 identity no-dampening { 1813 base dampening-type; 1814 description 1815 "The dampening-type is no-dampening."; 1816 } 1817 identity on-repetition { 1818 base dampening-type; 1819 description 1820 "The dampening-type is on-repetition."; 1821 } 1822 identity none { 1823 base dampening-type; 1824 description 1825 "The dampening-type is none."; 1826 } 1827 identity authentication-mode { 1828 description 1829 "User authentication mode types: 1830 e.g., Local Authentication, 1831 Third-Party Server Authentication, 1832 Authentication Exemption, or Single Sign-On (SSO) 1833 Authentication."; 1834 } 1835 identity local-authentication { 1836 base authentication-mode; 1837 description 1838 "Authentication-mode : local authentication."; 1839 } 1840 identity third-party-server-authentication { 1841 base authentication-mode; 1842 description 1843 "If authentication-mode is 1844 third-party-server-authentication"; 1845 } 1846 identity exemption-authentication { 1847 base authentication-mode; 1848 description 1849 "If authentication-mode is 1850 exemption-authentication"; 1851 } 1852 identity sso-authentication { 1853 base authentication-mode; 1854 description 1855 "If authentication-mode is 1856 sso-authentication"; 1857 } 1858 identity alarm-type { 1859 description 1860 "Base identity for detectable alarm types"; 1861 } 1862 identity mem-usage-alarm { 1863 base alarm-type; 1864 description 1865 "A memory alarm is alerted."; 1866 } 1867 identity cpu-usage-alarm { 1868 base alarm-type; 1869 description 1870 "A CPU alarm is alerted."; 1871 } 1872 identity disk-usage-alarm { 1873 base alarm-type; 1874 description 1875 "A disk alarm is alerted."; 1876 } 1877 identity hw-failure-alarm { 1878 base alarm-type; 1879 description 1880 "A hardware alarm is alerted."; 1881 } 1882 identity ifnet-state-alarm { 1883 base alarm-type; 1884 description 1885 "An interface alarm is alerted."; 1886 } 1887 identity event-type { 1888 description 1889 "Base identity for detectable event types"; 1890 } 1891 identity access-denied { 1892 base event-type; 1893 description 1894 "The system event is access-denied."; 1895 } 1896 identity config-change { 1897 base event-type; 1898 description 1899 "The system event is config-change."; 1900 } 1901 identity attack-type { 1902 description 1903 "The root ID of attack-based notification 1904 in the notification taxonomy"; 1905 } 1906 identity system-attack-type { 1907 base attack-type; 1908 description 1909 "This ID is intended to be used 1910 in the context of system events."; 1911 } 1912 identity nsf-attack-type { 1913 base attack-type; 1914 description 1915 "This ID is intended to be used 1916 in the context of NSF event."; 1917 } 1918 identity botnet-attack-type { 1919 base nsf-attack-type; 1920 description 1921 "This indicates that this attack type is botnet. 1922 The usual semantic and taxonomy is missing 1923 and a name is used."; 1924 } 1925 identity virus-type { 1926 base nsf-attack-type; 1927 description 1928 "The type of virus. It caan be multiple types at once. 1929 This attack type is associated with a detected 1930 system-log virus-attack."; 1931 } 1932 identity trojan { 1933 base virus-type; 1934 description 1935 "The detected virus type is trojan."; 1936 } 1937 identity worm { 1938 base virus-type; 1939 description 1940 "The detected virus type is worm."; 1941 } 1942 identity macro { 1943 base virus-type; 1944 description 1945 "The detected virus type is macro."; 1946 } 1947 identity intrusion-attack-type { 1948 base nsf-attack-type; 1949 description 1950 "The attack type is associated with a detected 1951 system-log intrusion."; 1952 } 1953 identity brute-force { 1954 base intrusion-attack-type; 1955 description 1956 "The intrusion type is brute-force."; 1957 } 1958 identity buffer-overflow { 1959 base intrusion-attack-type; 1960 description 1961 "The intrusion type is buffer-overflow."; 1962 } 1963 identity web-attack-type { 1964 base nsf-attack-type; 1965 description 1966 "The attack type is associated with a detected 1967 system-log web-attack."; 1968 } 1969 identity command-injection { 1970 base web-attack-type; 1971 description 1972 "The detected web attack type is command injection."; 1973 } 1974 identity xss { 1975 base web-attack-type; 1976 description 1977 "The detected web attack type is XSS."; 1978 } 1979 identity csrf { 1980 base web-attack-type; 1981 description 1982 "The detected web attack type is CSRF."; 1983 } 1984 identity flood-type { 1985 base nsf-attack-type; 1986 description 1987 "Base identity for detectable flood types"; 1988 } 1989 identity syn-flood { 1990 base flood-type; 1991 description 1992 "A SYN flood is detected."; 1993 } 1994 identity ack-flood { 1995 base flood-type; 1996 description 1997 "An ACK flood is detected."; 1999 } 2000 identity syn-ack-flood { 2001 base flood-type; 2002 description 2003 "A SYN-ACK flood is detected."; 2004 } 2005 identity fin-rst-flood { 2006 base flood-type; 2007 description 2008 "A FIN-RST flood is detected."; 2009 } 2010 identity tcp-con-flood { 2011 base flood-type; 2012 description 2013 "A TCP connection flood is detected."; 2014 } 2015 identity udp-flood { 2016 base flood-type; 2017 description 2018 "A UDP flood is detected."; 2019 } 2020 identity icmp-flood { 2021 base flood-type; 2022 description 2023 "Either an ICMPv4 or ICMPv6 flood is detected."; 2024 } 2025 identity icmpv4-flood { 2026 base flood-type; 2027 description 2028 "An ICMPv4 flood is detected."; 2029 } 2030 identity icmpv6-flood { 2031 base flood-type; 2032 description 2033 "An ICMPv6 flood is detected."; 2034 } 2035 identity http-flood { 2036 base flood-type; 2037 description 2038 "An HTTP flood is detected."; 2039 } 2040 identity https-flood { 2041 base flood-type; 2042 description 2043 "An HTTPS flood is detected."; 2044 } 2045 identity dns-query-flood { 2046 base flood-type; 2047 description 2048 "A DNS query flood is detected."; 2049 } 2050 identity dns-reply-flood { 2051 base flood-type; 2052 description 2053 "A DNS reply flood is detected."; 2054 } 2055 identity sip-flood { 2056 base flood-type; 2057 description 2058 "An SIP flood is detected."; 2059 } 2061 identity req-method { 2062 description 2063 "A set of request types (if applicable). 2064 For instance, PUT or GET in HTTP."; 2065 } 2066 identity put-req { 2067 base req-method; 2068 description 2069 "The detected request type is PUT."; 2070 } 2071 identity get-req { 2072 base req-method; 2073 description 2074 "The detected request type is GET."; 2075 } 2076 identity filter-type { 2077 description 2078 "The type of filter used to detect an attack, 2079 for example, a web-attack. It can be applicable to 2080 more than web-attacks. It can be more than one type."; 2081 } 2082 identity whitelist { 2083 base filter-type; 2084 description 2085 "The applied filter type is whitelist."; 2086 } 2087 identity blacklist { 2088 base filter-type; 2089 description 2090 "The applied filter type is blacklist."; 2091 } 2092 identity user-defined { 2093 base filter-type; 2094 description 2095 "The applied filter type is user-defined."; 2096 } 2097 identity malicious-category { 2098 base filter-type; 2099 description 2100 "The applied filter is malicious category."; 2101 } 2102 identity unknown-filter { 2103 base filter-type; 2104 description 2105 "The applied filter is unknown."; 2106 } 2108 identity access-mode { 2109 description 2110 "Base identity for detectable access mode."; 2111 } 2112 identity ppp { 2113 base access-mode; 2114 description 2115 "Access-mode: ppp"; 2116 } 2117 identity svn { 2118 base access-mode; 2119 description 2120 "Access-mode: svn"; 2121 } 2122 identity local { 2123 base access-mode; 2124 description 2125 "Access-mode: local"; 2126 } 2128 identity protocol-type { 2129 description 2130 "An identity used to enable type choices in leaves 2131 and leaflists with respect to protocol metadata."; 2132 } 2133 identity tcp { 2134 base ipv4; 2135 base ipv6; 2136 description 2137 "TCP protocol type."; 2138 reference 2139 "RFC 793: Transmission Control Protocol"; 2140 } 2141 identity udp { 2142 base ipv4; 2143 base ipv6; 2144 description 2145 "UDP protocol type."; 2146 reference 2147 "RFC 768: User Datagram Protocol"; 2148 } 2149 identity icmp { 2150 base ipv4; 2151 base ipv6; 2152 description 2153 "General ICMP protocol type."; 2154 reference 2155 "RFC 792: Internet Control Message Protocol 2156 RFC 4443: Internet Control Message Protocol 2157 (ICMPv6) for the Internet Protocol Version 6 2158 (IPv6) Specification"; 2159 } 2160 identity icmpv4 { 2161 base ipv4; 2162 description 2163 "ICMPv4 protocol type."; 2164 reference 2165 "RFC 791: Internet Protocol 2166 RFC 792: Internet Control Message Protocol"; 2167 } 2168 identity icmpv6 { 2169 base ipv6; 2170 description 2171 "ICMPv6 protocol type."; 2172 reference 2173 "RFC 8200: Internet Protocol, Version 6 (IPv6) 2174 RFC 4443: Internet Control Message Protocol (ICMPv6) 2175 for the Internet Protocol Version 6 (IPv6) 2176 Specification"; 2177 } 2178 identity ip { 2179 base protocol-type; 2180 description 2181 "General IP protocol type."; 2182 reference 2183 "RFC 791: Internet Protocol 2184 RFC 8200: Internet Protocol, Version 6 (IPv6)"; 2185 } 2186 identity ipv4 { 2187 base ip; 2188 description 2189 "IPv4 protocol type."; 2190 reference 2191 "RFC 791: Internet Protocol"; 2192 } 2193 identity ipv6 { 2194 base ip; 2195 description 2196 "IPv6 protocol type."; 2197 reference 2198 "RFC 8200: Internet Protocol, Version 6 (IPv6)"; 2199 } 2200 identity http { 2201 base tcp; 2202 description 2203 "HTPP protocol type."; 2204 reference 2205 "RFC 2616: Hypertext Transfer Protocol"; 2206 } 2207 identity ftp { 2208 base tcp; 2209 description 2210 "FTP protocol type."; 2211 reference 2212 "RFC 959: File Transfer Protocol"; 2213 } 2215 /* 2216 * Grouping 2217 */ 2219 grouping common-monitoring-data { 2220 description 2221 "A set of common monitoring data that is needed 2222 as the basic information."; 2223 leaf message { 2224 type string; 2225 description 2226 "This is a freetext annotation for 2227 monitoring a notification's content."; 2228 } 2229 leaf vendor-name { 2230 type string; 2231 description 2232 "The name of the NSF vendor"; 2233 } 2234 leaf nsf-name { 2235 type string; 2236 description 2237 "The name (or IP) of the NSF generating the message."; 2238 } 2239 leaf severity { 2240 type severity; 2241 description 2242 "The severity of the alarm such as critical, high, 2243 middle, low."; 2244 } 2245 } 2246 grouping characteristics { 2247 description 2248 "A set of characteristics of a notification."; 2249 leaf acquisition-method { 2250 type identityref { 2251 base acquisition-method; 2252 } 2253 description 2254 "The acquisition-method for characteristics"; 2255 } 2256 leaf emission-type { 2257 type identityref { 2258 base emission-type; 2259 } 2260 description 2261 "The emission-type for characteristics"; 2262 } 2263 leaf dampening-type { 2264 type identityref { 2265 base dampening-type; 2266 } 2267 description 2268 "The dampening-type for characteristics"; 2269 } 2270 } 2271 grouping i2nsf-system-alarm-type-content { 2272 description 2273 "A set of contents for alarm type notification."; 2274 leaf usage { 2275 type uint8 { 2276 range "0..100"; 2277 } 2278 units "percent"; 2279 description 2280 "Specifies the used percentage"; 2281 } 2282 leaf threshold { 2283 type uint8 { 2284 range "0..100"; 2285 } 2286 units "percent"; 2287 description 2288 "The threshold percentage triggering the alarm or 2289 the event"; 2290 } 2291 } 2292 grouping i2nsf-system-event-type-content { 2293 description 2294 "System event metadata associated with system events 2295 caused by user activity."; 2296 leaf user { 2297 type string; 2298 mandatory true; 2299 description 2300 "The name of a user"; 2301 } 2302 leaf group { 2303 type string; 2304 mandatory true; 2305 description 2306 "The group to which a user belongs."; 2307 } 2308 leaf login-ip-addr { 2309 type inet:ip-address; 2310 mandatory true; 2311 description 2312 "The login IPv4 (or IPv6) address of a user."; 2313 } 2314 leaf authentication { 2315 type identityref { 2316 base authentication-mode; 2317 } 2318 description 2319 "The authentication-mode for authentication"; 2320 } 2321 } 2322 grouping i2nsf-nsf-event-type-content { 2323 description 2324 "A set of common IPv4 (or IPv6)-related NSF event 2325 content elements"; 2326 leaf dst-ip { 2327 type inet:ip-address; 2328 description 2329 "The destination IPv4 (IPv6) address of the packet"; 2330 } 2331 leaf dst-port { 2332 type inet:port-number; 2333 description 2334 "The destination port of the packet"; 2336 } 2337 leaf rule-name { 2338 type leafref { 2339 path 2340 "/nsfi:i2nsf-security-policy/nsfi:system-policy/nsfi:rules/nsfi:rule-name"; 2341 } 2342 mandatory true; 2343 description 2344 "The name of the rule being triggered"; 2345 } 2346 leaf raw-info { 2347 type string; 2348 description 2349 "The information describing the packet 2350 triggering the event."; 2351 } 2352 } 2353 grouping i2nsf-nsf-event-type-content-extend { 2354 description 2355 "A set of extended common IPv4 (or IPv6)-related NSF 2356 event content elements"; 2357 uses i2nsf-nsf-event-type-content; 2358 leaf src-ip { 2359 type inet:ip-address; 2360 description 2361 "The source IPv4 (or IPv6) address of the packet"; 2362 } 2363 leaf src-port { 2364 type inet:port-number; 2365 description 2366 "The source port of the packet"; 2367 } 2368 leaf src-zone { 2369 type string { 2370 length "1..100"; 2371 pattern "[0-9a-zA-Z ]*"; 2372 } 2373 description 2374 "The source security zone of the packet"; 2375 } 2376 leaf dst-zone { 2377 type string { 2378 length "1..100"; 2379 pattern "[0-9a-zA-Z ]*"; 2380 } 2381 description 2382 "The destination security zone of the packet"; 2383 } 2385 } 2386 grouping log-action { 2387 description 2388 "A grouping for logging action."; 2389 leaf action { 2390 type log-action; 2391 description 2392 "Action type: allow, alert, block, discard, declare, 2393 block-ip, block-service"; 2394 } 2395 } 2396 grouping attack-rates { 2397 description 2398 "A set of traffic rates for monitoring attack traffic 2399 data"; 2400 leaf attack-rate { 2401 type uint32; 2402 units "pps"; 2403 description 2404 "The PPS rate of attack traffic"; 2405 } 2406 leaf attack-speed { 2407 type uint32; 2408 units "bps"; 2409 description 2410 "The BPS speed of attack traffic"; 2411 } 2412 } 2413 grouping traffic-rates { 2414 description 2415 "A set of traffic rates for statistics data"; 2416 leaf total-traffic { 2417 type yang:counter32; 2418 description 2419 "Total traffic"; 2420 } 2421 leaf in-traffic-average-rate { 2422 type uint32; 2423 units "pps"; 2424 description 2425 "Inbound traffic average rate in packets per second (pps)"; 2426 } 2427 leaf in-traffic-peak-rate { 2428 type uint32; 2429 units "pps"; 2430 description 2431 "Inbound traffic peak rate in packets per second (pps)"; 2432 } 2433 leaf in-traffic-average-speed { 2434 type uint32; 2435 units "bps"; 2436 description 2437 "Inbound traffic average speed in bits per second (bps)"; 2438 } 2439 leaf in-traffic-peak-speed { 2440 type uint32; 2441 units "bps"; 2442 description 2443 "Inbound traffic peak speed in bits per second (bps)"; 2444 } 2445 leaf out-traffic-average-rate { 2446 type uint32; 2447 units "pps"; 2448 description 2449 "Outbound traffic average rate in packets per second (pps)"; 2450 } 2451 leaf out-traffic-peak-rate { 2452 type uint32; 2453 units "pps"; 2454 description 2455 "Outbound traffic peak rate in packets per Second (pps)"; 2456 } 2457 leaf out-traffic-average-speed { 2458 type uint32; 2459 units "bps"; 2460 description 2461 "Outbound traffic average speed in bits per second (bps)"; 2462 } 2463 leaf out-traffic-peak-speed { 2464 type uint32; 2465 units "bps"; 2466 description 2467 "Outbound traffic peak speed in bits per second (bps)"; 2468 } 2469 } 2470 grouping i2nsf-system-counter-type-content{ 2471 description 2472 "A set of counters for an interface traffic data."; 2473 leaf interface-name { 2474 type string; 2475 description 2476 "Network interface name configured in an NSF"; 2477 } 2478 leaf in-total-traffic-pkts { 2479 type yang:counter32; 2480 description 2481 "Total inbound packets"; 2482 } 2483 leaf out-total-traffic-pkts { 2484 type yang:counter32; 2485 description 2486 "Total outbound packets"; 2487 } 2488 leaf in-total-traffic-bytes { 2489 type uint64; 2490 units "bytes"; 2491 description 2492 "Total inbound bytes"; 2493 } 2494 leaf out-total-traffic-bytes { 2495 type uint64; 2496 units "bytes"; 2497 description 2498 "Total outbound bytes"; 2499 } 2500 leaf in-drop-traffic-pkts { 2501 type yang:counter32; 2502 description 2503 "Total inbound drop packets"; 2504 } 2505 leaf out-drop-traffic-pkts { 2506 type yang:counter32; 2507 description 2508 "Total outbound drop packets"; 2509 } 2510 leaf in-drop-traffic-bytes { 2511 type uint64; 2512 units "bytes"; 2513 description 2514 "Total inbound drop bytes"; 2515 } 2516 leaf out-drop-traffic-bytes { 2517 type uint64; 2518 units "bytes"; 2519 description 2520 "Total outbound drop bytes"; 2521 } 2522 uses traffic-rates; 2523 } 2524 grouping i2nsf-nsf-counters-type-content{ 2525 description 2526 "A set of contents of a policy in an NSF."; 2527 leaf policy-name { 2528 type leafref { 2529 path 2530 "/nsfi:i2nsf-security-policy/nsfi:system-policy/nsfi:system-policy-name"; 2531 } 2532 mandatory true; 2533 description 2534 "The name of the policy being triggered"; 2535 } 2536 leaf src-user{ 2537 type string; 2538 description 2539 "User who generates the policy"; 2540 } 2541 } 2543 grouping enable-notification { 2544 description 2545 "A grouping for enabling or disabling notification"; 2546 leaf enabled { 2547 type boolean; 2548 default "true"; 2549 description 2550 "Enables or Disables the notification. 2551 If 'true', then the notification is enabled. 2552 If 'false, then the notification is disabled."; 2553 } 2554 } 2556 grouping dampening { 2557 description 2558 "A grouping for dampening period of notification."; 2559 leaf dampening-period { 2560 type uint32; 2561 units "centiseconds"; 2562 default "0"; 2563 description 2564 "Specifies the minimum interval between the assembly of 2565 successive update records for a single receiver of a 2566 subscription. Whenever subscribed objects change and 2567 a dampening-period interval (which may be zero) has 2568 elapsed since the previous update record creation for 2569 a receiver, any subscribed objects and properties 2570 that have changed since the previous update record 2571 will have their current values marshalled and placed 2572 in a new update record."; 2573 reference 2574 "RFC 8641: Subscription to YANG Notifications for 2575 Datastore Updates - Section 5."; 2576 } 2578 } 2580 /* 2581 * Feature Nodes 2582 */ 2584 feature i2nsf-nsf-detection-ddos { 2585 description 2586 "This feature means it supports I2NSF nsf-detection-ddos 2587 notification"; 2588 } 2589 feature i2nsf-nsf-detection-virus { 2590 description 2591 "This feature means it supports I2NSF nsf-detection-virus 2592 notification"; 2593 } 2594 feature i2nsf-nsf-detection-intrusion { 2595 description 2596 "This feature means it supports I2NSF nsf-detection-intrusion 2597 notification"; 2598 } 2599 feature i2nsf-nsf-detection-botnet { 2600 description 2601 "This feature means it supports I2NSF nsf-detection-botnet 2602 notification"; 2603 } 2604 feature i2nsf-nsf-detection-web-attack { 2605 description 2606 "This feature means it supports I2NSF nsf-detection-web-attack 2607 notification"; 2608 } 2609 feature i2nsf-nsf-log-dpi { 2610 description 2611 "This feature means it supports I2NSF nsf-log-dpi 2612 notification"; 2613 } 2614 feature i2nsf-nsf-log-vuln-scan { 2615 description 2616 "This feature means it supports I2NSF nsf-log-vuln-scan 2617 notification"; 2618 } 2620 /* 2621 * Notification nodes 2622 */ 2624 notification i2nsf-event { 2625 description 2626 "Notification for I2NSF Event."; 2627 choice sub-event-type { 2628 description 2629 "This choice must be augmented with cases for each allowed 2630 sub-event. Only 1 sub-event will be instantiated in each 2631 i2nsf-event message. Each case is expected to define one 2632 container with all the sub-event fields."; 2633 case i2nsf-system-detection-alarm { 2634 container i2nsf-system-detection-alarm{ 2635 description 2636 "This notification is sent, when a system alarm 2637 is detected."; 2638 leaf alarm-category { 2639 type identityref { 2640 base alarm-type; 2641 } 2642 description 2643 "The alarm category for 2644 system-detection-alarm notification"; 2645 } 2646 leaf component-name { 2647 type string; 2648 description 2649 "The hardware component responsible for generating 2650 the message. Applicable for Hardware Failure 2651 Alarm."; 2652 } 2653 leaf interface-name { 2654 type string; 2655 description 2656 "The interface name responsible for generating 2657 the message. Applicable for Network Interface 2658 Failure Alarm."; 2659 } 2660 leaf interface-state { 2661 type enumeration { 2662 enum down { 2663 description 2664 "The interface state is down."; 2665 } 2666 enum up { 2667 description 2668 "The interface state is up."; 2669 } 2670 enum congested { 2671 description 2672 "The interface state is congested."; 2673 } 2674 } 2675 description 2676 "The state of the interface (i.e., up, down, congested). 2677 Applicable for Network Interface Failure Alarm."; 2678 } 2679 uses characteristics; 2680 uses i2nsf-system-alarm-type-content; 2681 uses common-monitoring-data; 2682 } 2683 } 2685 case i2nsf-system-detection-event { 2686 container i2nsf-system-detection-event { 2687 description 2688 "This notification is sent when a security-sensitive 2689 authentication action fails."; 2690 leaf event-category { 2691 type identityref { 2692 base event-type; 2693 } 2694 description 2695 "The event category for system-detection-event"; 2696 } 2697 uses characteristics; 2698 uses i2nsf-system-event-type-content; 2699 uses common-monitoring-data; 2700 } 2701 } 2703 case i2nsf-traffic-flows { 2704 container i2nsf-traffic-flows { 2705 description 2706 "This notification is sent to inform about the traffic 2707 flows."; 2708 leaf src-ip { 2709 type inet:ip-address; 2710 description 2711 "The source IPv4 (or IPv6) address of the packet"; 2712 } 2713 leaf dst-ip { 2714 type inet:ip-address; 2715 description 2716 "The destination IPv4 (or IPv6) address of the packet"; 2717 } 2718 leaf protocol { 2719 type identityref { 2720 base protocol-type; 2721 } 2722 description 2723 "The protocol type for nsf-detection-intrusion 2724 notification"; 2725 } 2726 leaf src-port { 2727 type inet:port-number; 2728 description 2729 "The source port of the packet"; 2730 } 2731 leaf dst-port { 2732 type inet:port-number; 2733 description 2734 "The destination port of the packet"; 2735 } 2736 leaf arrival-rate { 2737 type uint32; 2738 units "pps"; 2739 description 2740 "The arrival rate of the packet in packets 2741 per second"; 2742 } 2743 uses characteristics; 2744 uses common-monitoring-data; 2745 } 2746 } 2748 case i2nsf-nsf-detection-session-table { 2749 container i2nsf-nsf-detection-session-table { 2750 description 2751 "This notification is sent, when a session table 2752 event is detected."; 2753 leaf current-session { 2754 type uint32; 2755 description 2756 "The number of concurrent sessions"; 2757 } 2758 leaf maximum-session { 2759 type uint32; 2760 description 2761 "The maximum number of sessions that the session 2762 table can support"; 2763 } 2764 leaf threshold { 2765 type uint32; 2766 description 2767 "The threshold triggering the event"; 2769 } 2770 uses common-monitoring-data; 2771 } 2772 } 2773 } 2774 } 2776 notification i2nsf-log { 2777 description 2778 "Notification for I2NSF log. The notification is generated 2779 from the logs of the NSF."; 2780 choice sub-logs-type { 2781 description 2782 "This choice must be augmented with cases for each allowed 2783 sub-logs. Only 1 sub-event will be instantiated in each 2784 i2nsf-logs message. Each case is expected to define one 2785 container with all the sub-logs fields."; 2786 case i2nsf-nsf-system-access-log { 2787 container i2nsf-nsf-system-access-log { 2788 description 2789 "The notification is sent, if there is a new system 2790 log entry about a system access event."; 2791 leaf login-ip { 2792 type inet:ip-address; 2793 mandatory true; 2794 description 2795 "Login IP address of a user"; 2796 } 2797 leaf administrator { 2798 type string; 2799 description 2800 "Administrator that maintains the device"; 2801 } 2802 leaf login-mode { 2803 type login-mode; 2804 description 2805 "Specifies the administrator log-in mode"; 2806 } 2807 leaf operation-type { 2808 type operation-type; 2809 description 2810 "The operation type that the administrator executes"; 2811 } 2812 leaf result { 2813 type string; 2814 description 2815 "Command execution result"; 2816 } 2817 leaf content { 2818 type string; 2819 description 2820 "The Operation performed by an administrator after 2821 login"; 2822 } 2823 uses characteristics; 2824 uses common-monitoring-data; 2825 } 2826 } 2828 case i2nsf-system-res-util-log { 2829 container i2nsf-system-res-util-log { 2830 description 2831 "This notification is sent, if there is a new log 2832 entry representing resource utilization updates."; 2833 leaf system-status { 2834 type string; 2835 description 2836 "The current systems running status"; 2837 } 2838 leaf cpu-usage { 2839 type uint8; 2840 description 2841 "Specifies the relative size of CPU usage with 2842 respect to platform resources"; 2843 } 2844 leaf memory-usage { 2845 type uint8; 2846 description 2847 "Specifies the size of memory usage."; 2848 } 2849 leaf disk-usage { 2850 type uint8; 2851 description 2852 "Specifies the size of disk usage"; 2853 } 2854 leaf disk-left { 2855 type uint8; 2856 description 2857 "Specifies the size of disk left"; 2858 } 2859 leaf session-num { 2860 type uint8; 2861 description 2862 "The total number of sessions"; 2863 } 2864 leaf process-num { 2865 type uint8; 2866 description 2867 "The total number of process"; 2868 } 2869 leaf in-traffic-rate { 2870 type uint32; 2871 units "pps"; 2872 description 2873 "The total inbound traffic rate in pps"; 2874 } 2875 leaf out-traffic-rate { 2876 type uint32; 2877 units "pps"; 2878 description 2879 "The total outbound traffic rate in pps"; 2880 } 2881 leaf in-traffic-speed { 2882 type uint32; 2883 units "bps"; 2884 description 2885 "The total inbound traffic speed in bps"; 2886 } 2887 leaf out-traffic-speed { 2888 type uint32; 2889 units "bps"; 2890 description 2891 "The total outbound traffic speed in bps"; 2892 } 2893 uses characteristics; 2894 uses common-monitoring-data; 2895 } 2896 } 2898 case i2nsf-system-user-activity-log { 2899 container i2nsf-system-user-activity-log { 2900 description 2901 "This notification is sent, if there is a new user 2902 activity log entry."; 2903 uses characteristics; 2904 uses i2nsf-system-event-type-content; 2905 uses common-monitoring-data; 2906 leaf access { 2907 type identityref { 2908 base access-mode; 2909 } 2910 description 2911 "The access type for system-user-activity-log 2912 notification"; 2914 } 2915 leaf online-duration { 2916 type string; 2917 description 2918 "Online duration"; 2919 } 2920 leaf logout-duration { 2921 type string; 2922 description 2923 "Lockout duration"; 2924 } 2925 leaf additional-info { 2926 type string; 2927 description 2928 "User activities, e.g., Successful User Login, 2929 Failed Login attempts, User Logout, Successful User 2930 Password Change, Failed User Password Change, User 2931 Lockout, User Unlocking, and Unknown."; 2932 } 2933 } 2934 } 2935 } 2936 } 2938 notification i2nsf-nsf-event { 2939 description 2940 "Notification for I2NSF NSF Event. This notification is 2941 used for a specific NSF that supported such feature."; 2942 choice sub-event-type { 2943 description 2944 "This choice must be augmented with cases for each allowed 2945 sub-event. Only 1 sub-event will be instantiated in each 2946 i2nsf-event message. Each case is expected to define one 2947 container with all the sub-event fields."; 2948 case i2nsf-nsf-detection-ddos { 2949 if-feature "i2nsf-nsf-detection-ddos"; 2950 container i2nsf-nsf-detection-ddos { 2951 description 2952 "This notification is sent, when a specific flood type 2953 is detected."; 2954 uses i2nsf-nsf-event-type-content; 2955 leaf attack-type { 2956 type identityref { 2957 base flood-type; 2958 } 2959 description 2960 "Any one of Syn flood, ACK flood, SYN-ACK flood, 2961 FIN/RST flood, TCP Connection flood, UDP flood, 2962 ICMP (i.e., ICMPv4 or ICMPv6) flood, HTTP flood, 2963 HTTPS flood, DNS query flood, DNS reply flood, SIP 2964 flood, etc."; 2965 } 2966 leaf start-time { 2967 type yang:date-and-time; 2968 mandatory true; 2969 description 2970 "The time stamp indicating when the attack started"; 2971 } 2972 leaf end-time { 2973 type yang:date-and-time; 2974 mandatory true; 2975 description 2976 "The time stamp indicating when the attack ended"; 2977 } 2978 leaf attack-src-ip { 2979 type inet:ip-address; 2980 description 2981 "The source IPv4 (or IPv6) addresses of attack 2982 traffic. If there are a large number of IPv4 2983 (or IPv6) addresses, then pick a certain number 2984 of resources according to different rules."; 2985 } 2986 leaf attack-dst-ip { 2987 type inet:ip-address; 2988 description 2989 "The destination IPv4 (or IPv6) addresses of attack 2990 traffic. If there are a large number of IPv4 2991 (or IPv6) addresses, then pick a certain number 2992 of resources according to different rules."; 2993 } 2994 uses attack-rates; 2995 uses log-action; 2996 uses characteristics; 2997 uses common-monitoring-data; 2998 } 2999 } 3000 case i2nsf-nsf-detection-virus { 3001 if-feature "i2nsf-nsf-detection-virus"; 3002 container i2nsf-nsf-detection-virus { 3003 description 3004 "This notification is sent, when a virus is detected."; 3005 uses i2nsf-nsf-event-type-content-extend; 3006 leaf virus { 3007 type identityref { 3008 base virus-type; 3009 } 3011 description 3012 "The virus type for nsf-detection-virus notification"; 3013 } 3014 leaf virus-name { 3015 type string; 3016 description 3017 "The name of the detected virus"; 3018 } 3019 leaf file-type { 3020 type string; 3021 description 3022 "The type of file virus code is found in (if 3023 applicable)."; 3024 } 3025 leaf file-name { 3026 type string; 3027 description 3028 "The name of file virus code is found in (if 3029 applicable)."; 3030 } 3031 leaf os { 3032 type string; 3033 description 3034 "Simple OS information"; 3035 } 3036 uses log-action; 3037 uses characteristics; 3038 uses common-monitoring-data; 3039 } 3040 } 3041 case i2nsf-nsf-detection-intrusion { 3042 if-feature "i2nsf-nsf-detection-intrusion"; 3043 container i2nsf-nsf-detection-intrusion { 3044 description 3045 "This notification is sent, when an intrusion event 3046 is detected."; 3047 uses i2nsf-nsf-event-type-content-extend; 3048 leaf protocol { 3049 type identityref { 3050 base protocol-type; 3051 } 3052 description 3053 "The protocol type for nsf-detection-intrusion 3054 notification"; 3055 } 3056 leaf app { 3057 type string; 3058 description 3059 "The employed application layer protocol"; 3060 } 3061 leaf attack-type { 3062 type identityref { 3063 base intrusion-attack-type; 3064 } 3065 description 3066 "The sub attack type for intrusion attack"; 3067 } 3068 uses log-action; 3069 uses attack-rates; 3070 uses characteristics; 3071 uses common-monitoring-data; 3072 } 3073 } 3074 case i2nsf-nsf-detection-botnet { 3075 if-feature "i2nsf-nsf-detection-botnet"; 3076 container i2nsf-nsf-detection-botnet { 3077 description 3078 "This notification is sent, when a botnet event is 3079 detected."; 3080 uses i2nsf-nsf-event-type-content-extend; 3081 leaf attack-type { 3082 type identityref { 3083 base botnet-attack-type; 3084 } 3085 description 3086 "The attack type for botnet attack"; 3087 } 3088 leaf protocol { 3089 type identityref { 3090 base protocol-type; 3091 } 3092 description 3093 "The protocol type for nsf-detection-botnet notification"; 3094 } 3095 leaf botnet-name { 3096 type string; 3097 description 3098 "The name of the detected botnet"; 3099 } 3100 leaf role { 3101 type string; 3102 description 3103 "The role of the communicating 3104 parties within the botnet"; 3105 } 3106 uses log-action; 3107 leaf botnet-pkt-num{ 3108 type uint8; 3109 description 3110 "The number of the packets sent to or from the detected botnet"; 3111 } 3112 leaf os{ 3113 type string; 3114 description 3115 "Simple OS information"; 3116 } 3117 uses characteristics; 3118 uses common-monitoring-data; 3119 } 3120 } 3121 case i2nsf-nsf-detection-web-attack { 3122 if-feature "i2nsf-nsf-detection-web-attack"; 3123 container i2nsf-nsf-detection-web-attack { 3124 description 3125 "This notification is sent, when an attack event is 3126 detected."; 3127 uses i2nsf-nsf-event-type-content-extend; 3128 leaf attack-type { 3129 type identityref { 3130 base web-attack-type; 3131 } 3132 description 3133 "Concrete web attack type, e.g., SQL injection, 3134 command injection, XSS, and CSRF."; 3135 } 3136 leaf request-method { 3137 type identityref { 3138 base req-method; 3139 } 3140 description 3141 "The method of requirement. For instance, PUT or 3142 GET in HTTP."; 3143 } 3144 leaf req-uri { 3145 type string; 3146 description 3147 "Requested URI"; 3148 } 3149 leaf uri-category { 3150 type string; 3151 description 3152 "Matched URI category"; 3153 } 3154 leaf-list filtering-type { 3155 type identityref { 3156 base filter-type; 3157 } 3158 description 3159 "URL filtering type, e.g., Blacklist, Whitelist, 3160 User-Defined, Predefined, Malicious Category, 3161 and Unknown"; 3162 } 3163 leaf rsp-code { 3164 type string; 3165 description 3166 "Response code"; 3167 } 3168 leaf req-clientapp { 3169 type string; 3170 description 3171 "The client application"; 3172 } 3173 leaf req-cookies { 3174 type string; 3175 description 3176 "Cookies"; 3177 } 3178 leaf req-host { 3179 type string; 3180 description 3181 "The domain name of the requested host"; 3182 } 3183 uses characteristics; 3184 uses log-action; 3185 uses common-monitoring-data; 3186 } 3187 } 3188 case i2nsf-nsf-log-vuln-scan { 3189 if-feature "i2nsf-nsf-log-vuln-scan"; 3190 container i2nsf-nsf-log-vuln-scan { 3191 description 3192 "This notification is sent, if there is a new 3193 vulnerability-scan report in the NSF log."; 3194 leaf vulnerability-id { 3195 type uint8; 3196 description 3197 "The vulnerability ID"; 3198 } 3199 leaf victim-ip { 3200 type inet:ip-address; 3201 description 3202 "IPv4 (or IPv6) address of the victim host which 3203 has vulnerabilities"; 3204 } 3205 leaf protocol { 3206 type identityref { 3207 base protocol-type; 3208 } 3209 description 3210 "The protocol type for nsf-log-vuln-scan 3211 notification"; 3212 } 3213 leaf port-num { 3214 type inet:port-number; 3215 description 3216 "The port number"; 3217 } 3218 leaf level { 3219 type severity; 3220 description 3221 "The vulnerability severity"; 3222 } 3223 leaf os { 3224 type string; 3225 description 3226 "simple OS information"; 3227 } 3228 leaf vulnerability-info { 3229 type string; 3230 description 3231 "The information about the vulnerability"; 3232 } 3233 leaf fix-suggestion { 3234 type string; 3235 description 3236 "The fix suggestion to the vulnerability"; 3237 } 3238 leaf service { 3239 type string; 3240 description 3241 "The service which has vulnerability in the victim 3242 host"; 3243 } 3244 uses characteristics; 3245 uses common-monitoring-data; 3246 } 3247 } 3248 case i2nsf-nsf-log-dpi { 3249 if-feature "i2nsf-nsf-log-dpi"; 3250 container i2nsf-nsf-log-dpi { 3251 description 3252 "This notification is sent, if there is a new DPI 3253 event in the NSF log."; 3254 leaf attack-type { 3255 type dpi-type; 3256 description 3257 "The type of the DPI"; 3258 } 3259 uses characteristics; 3260 uses i2nsf-nsf-counters-type-content; 3261 uses common-monitoring-data; 3262 } 3263 } 3264 } 3265 } 3266 /* 3267 * Data nodes 3268 */ 3269 container i2nsf-counters { 3270 config false; 3271 description 3272 "This is probably better covered by an import as this 3273 will not be notifications. Counters are not very 3274 suitable as telemetry, maybe via periodic 3275 subscriptions, which would still violate the principle 3276 of least surprise."; 3277 list system-interface { 3278 key interface-name; 3279 description 3280 "Interface counters provide the visibility of traffic into and 3281 out of an NSF, and bandwidth usage."; 3282 uses characteristics; 3283 uses i2nsf-system-counter-type-content; 3284 uses common-monitoring-data; 3285 } 3286 list nsf-firewall { 3287 key policy-name; 3288 description 3289 "Firewall counters provide the visibility of traffic signatures, 3290 bandwidth usage, and how the configured security and bandwidth 3291 policies have been applied."; 3292 uses characteristics; 3293 uses i2nsf-nsf-counters-type-content; 3294 uses traffic-rates; 3295 uses common-monitoring-data; 3296 } 3297 list nsf-policy-hits { 3298 key policy-name; 3299 description 3300 "Policy Hit Counters record the number of hits that traffic 3301 packets match a security policy. It can check if policy 3302 configurations are correct or not."; 3303 uses characteristics; 3304 uses i2nsf-nsf-counters-type-content; 3305 uses common-monitoring-data; 3306 leaf hit-times { 3307 type yang:counter32; 3308 description 3309 "The number of times a policy is hit"; 3310 } 3311 } 3312 } 3314 container i2nsf-monitoring-configuration { 3315 description 3316 "The container for configuring I2NSF monitoring."; 3317 container i2nsf-system-detection-alarm { 3318 description 3319 "The container for configuring I2NSF system-detection-alarm 3320 notification"; 3321 uses enable-notification; 3322 list system-alarm { 3323 key alarm-type; 3324 description 3325 "Configuration for system alarm (i.e., CPU, Memory, 3326 and Disk Usage)"; 3327 leaf alarm-type { 3328 type enumeration { 3329 enum CPU { 3330 description 3331 "To configure the CPU usage threshold to trigger the 3332 CPU-USAGE-ALARM"; 3333 } 3334 enum Memory { 3335 description 3336 "To configure the Memory usage threshold to trigger the 3337 MEM-USAGE-ALARM"; 3338 } 3339 enum Disk { 3340 description 3341 "To configure the Disk (storage) usage threshold to 3342 trigger the DISK-USAGE-ALARM"; 3343 } 3344 } 3345 description 3346 "Type of alarm to be configured"; 3348 } 3349 leaf threshold { 3350 type uint8 { 3351 range "1..100"; 3352 } 3353 units "percent"; 3354 description 3355 "The configuration for threshold percentage to trigger 3356 the alarm. The alarm will be triggered if the usage 3357 is exceeded the threshold."; 3358 } 3359 uses dampening; 3360 } 3361 } 3362 container i2nsf-system-detection-event { 3363 description 3364 "The container for configuring I2NSF system-detection-event 3365 notification"; 3366 uses enable-notification; 3367 uses dampening; 3368 } 3369 container i2nsf-traffic-flows { 3370 description 3371 "The container for configuring I2NSF traffic-flows 3372 notification"; 3373 uses dampening; 3374 uses enable-notification; 3375 } 3376 container i2nsf-nsf-detection-ddos { 3377 if-feature "i2nsf-nsf-detection-ddos"; 3378 description 3379 "The container for configuring I2NSF nsf-detection-ddos 3380 notification"; 3381 uses enable-notification; 3382 uses dampening; 3383 } 3384 container i2nsf-nsf-detection-session-table-configuration { 3385 description 3386 "The container for configuring I2NSF nsf-detection-session-table 3387 notification"; 3388 uses enable-notification; 3389 uses dampening; 3390 } 3391 container i2nsf-nsf-detection-virus { 3392 if-feature "i2nsf-nsf-detection-virus"; 3393 description 3394 "The container for configuring I2NSF nsf-detection-virus 3395 notification"; 3397 uses enable-notification; 3398 uses dampening; 3399 } 3400 container i2nsf-nsf-detection-intrusion { 3401 if-feature "i2nsf-nsf-detection-intrusion"; 3402 description 3403 "The container for configuring I2NSF nsf-detection-intrusion 3404 notification"; 3405 uses enable-notification; 3406 uses dampening; 3407 } 3408 container i2nsf-nsf-detection-botnet { 3409 if-feature "i2nsf-nsf-detection-botnet"; 3410 description 3411 "The container for configuring I2NSF nsf-detection-botnet 3412 notification"; 3413 uses enable-notification; 3414 uses dampening; 3415 } 3416 container i2nsf-nsf-detection-web-attack { 3417 if-feature "i2nsf-nsf-detection-web-attack"; 3418 description 3419 "The container for configuring I2NSF nsf-detection-web-attack 3420 notification"; 3421 uses enable-notification; 3422 uses dampening; 3423 } 3424 container i2nsf-nsf-system-access-log { 3425 description 3426 "The container for configuring I2NSF system-access-log 3427 notification"; 3428 uses enable-notification; 3429 uses dampening; 3430 } 3431 container i2nsf-system-res-util-log { 3432 description 3433 "The container for configuring I2NSF system-res-util-log 3434 notification"; 3435 uses enable-notification; 3436 uses dampening; 3437 } 3438 container i2nsf-system-user-activity-log { 3439 description 3440 "The container for configuring I2NSF system-user-activity-log 3441 notification"; 3442 uses enable-notification; 3443 uses dampening; 3444 } 3445 container i2nsf-nsf-log-dpi { 3446 if-feature "i2nsf-nsf-log-dpi"; 3447 description 3448 "The container for configuring I2NSF nsf-log-dpi 3449 notification"; 3450 uses enable-notification; 3451 uses dampening; 3452 } 3453 container i2nsf-nsf-log-vuln-scan { 3454 if-feature "i2nsf-nsf-log-vuln-scan"; 3455 description 3456 "The container for configuring I2NSF nsf-log-vuln-scan 3457 notification"; 3458 uses enable-notification; 3459 uses dampening; 3460 } 3461 container i2nsf-counter { 3462 description 3463 "This is used to configure the counters 3464 for monitoring an NSF"; 3465 leaf period { 3466 type uint16; 3467 units "minutes"; 3468 default 0; 3469 description 3470 "The configuration for the period interval of reporting 3471 the counter. If 0, then the counter period is disabled. 3472 If value is not 0, then the counter will be reported 3473 following the period value."; 3474 } 3475 } 3476 } 3477 } 3478 3480 Figure 2: Data Model of Monitoring 3482 11. I2NSF Event Stream 3484 This section discusses the NETCONF event stream for I2NSF NSF 3485 Monitoring subscription. The YANG module in this document supports 3486 "ietf-subscribed-notifications" YANG module [RFC8639] for 3487 subscription. The reserved event stream name for this document is 3488 "I2NSF-Monitoring". The NETCONF Server (e.g., an NSF) MUST support 3489 "I2NSF-Monitoring" event stream for an NSF data collector (e.g., 3490 Security Controller and NSF data analyzer). The "I2NSF-Monitoring" 3491 event stream contains all I2NSF events described in this document. 3492 The following example shows the capabilities of the event streams of 3493 an NSF (e.g., "NETCONF" and "I2NSF-Monitoring" event streams) by the 3494 subscription of an NSF data collector; note that this example XML 3495 file is delivered by an NSF to an NSF data collector: 3497 3498 3499 3500 3501 3502 3503 NETCONF 3504 Default NETCONF Event Stream 3505 false 3506 3507 3508 I2NSF-Monitoring 3509 I2NSF Monitoring Event Stream 3510 true 3511 2021-03-31T09:37:39+00:00 3512 3513 3514 3515 3516 3518 Figure 3: Example of NETCONF Server supporting I2NSF-Monitoring Event 3519 Stream 3521 12. XML Examples for I2NSF NSF Monitoring 3523 This section shows the XML examples of I2NSF NSF Monitoring data 3524 delivered via Monitoring Interface from an NSF. 3526 12.1. I2NSF System Detection Alarm 3528 The following example shows an alarm triggered by Memory Usage of the 3529 server; note that this example XML file is delivered by an NSF to an 3530 NSF data collector: 3532 3533 3534 2021-03-31T07:43:52.181088+00:00 3535 3536 3537 3538 nsfmi:mem-usage-alarm 3539 3540 3541 nsfmi:subscription 3542 3543 3544 nsfmi:on-change 3545 3546 3547 nsfmi:on-repetition 3548 3549 91 3550 90 3551 Memory Usage Exceeded The Threshold 3552 time_based_firewall 3553 high 3554 3555 3556 3558 Figure 4: Example of I2NSF System Detection Alarm triggered by Memory 3559 Usage 3561 The XML data above shows: 3563 1. The NSF that sends the information is named 3564 "time_based_firewall". 3566 2. The memory usage of the NSF triggered the alarm. 3568 3. The monitoring information is received by subscription method. 3570 4. The monitoring information is emitted "on-change". 3572 5. The monitoring information is dampened "on-repetition". 3574 6. The memory usage of the NSF is 91 percent. 3576 7. The memory threshold to trigger the alarm is 90 percent. 3578 8. The severity level of the notification is high. 3580 12.2. I2NSF Interface Counters 3582 To get the I2NSF system interface counters information by query, 3583 NETCONF Client (e.g., NSF data collector) needs to initiate GET 3584 connection with NETCONF Server (e.g., NSF). The following XML file 3585 can be used to get the state data and filter the information. 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3598 Figure 5: XML Example for NETCONF GET with System Interface Filter 3600 The following XML file shows the reply from the NETCONF Server (e.g., 3601 NSF): 3603 3604 3605 3606 3607 3608 ens3 3609 3610 nsfmi:query 3611 3612 549050 3613 814956 3614 0 3615 5078 3616 time_based_firewall 3617 3618 3619 lo 3620 3621 nsfmi:query 3622 3623 48487 3624 48487 3625 0 3626 0 3627 time_based_firewall 3628 3629 3630 3631 3633 Figure 6: Example of I2NSF System Interface Counters XML Information 3635 13. IANA Considerations 3637 This document requests IANA to register the following URI in the 3638 "IETF XML Registry" [RFC3688]: 3640 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring 3641 Registrant Contact: The IESG. 3642 XML: N/A; the requested URI is an XML namespace. 3644 This document requests IANA to register the following YANG module in 3645 the "YANG Module Names" registry [RFC7950][RFC8525]: 3647 name: ietf-i2nsf-nsf-monitoring 3648 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring 3649 prefix: nsfmi 3650 reference: RFC XXXX 3652 // RFC Ed.: replace XXXX with an actual RFC number and remove 3653 // this note. 3655 14. Security Considerations 3657 The YANG module described in this document defines a schema for data 3658 that is designed to be accessed via network management protocols such 3659 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 3660 is the secure transport layer, and the mandatory-to-implement secure 3661 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 3662 is HTTPS, and the mandatory-to-implement secure transport is TLS 3663 [RFC8446]. 3665 The NETCONF access control model [RFC8341] provides the means to 3666 restrict access for particular NETCONF or RESTCONF users to a 3667 preconfigured subset of all available NETCONF or RESTCONF protocol 3668 operations and content. 3670 All data nodes defined in the YANG module which can be created, 3671 modified and deleted (i.e., config true, which is the default) are 3672 considered sensitive. Write operations (e.g., edit-config) applied 3673 to these data nodes without proper protection can negatively affect 3674 framework operations. The monitoring YANG module should be protected 3675 by the secure communication channel, to ensure its confidentiality 3676 and integrity. In another side, the NSF and NSF data collector can 3677 all be faked, which lead to undesirable results (i.e., leakage of an 3678 NSF's important operational information, and faked NSF sending false 3679 information to mislead the NSF data collector). The mutual 3680 authentication is essential to protected against this kind of attack. 3681 The current mainstream security technologies (i.e., TLS, DTLS, IPsec, 3682 and X.509 PKI) can be employed appropriately to provide the above 3683 security functions. 3685 In addition, to defend against the DDoS attack caused by a lot of 3686 NSFs sending massive notifications to the NSF data collector, the 3687 rate limiting or similar mechanisms should be considered in both an 3688 NSF and NSF data collector, whether in advance or just in the process 3689 of DDoS attack. 3691 15. Acknowledgments 3693 This work was supported by Institute of Information & Communications 3694 Technology Planning & Evaluation (IITP) grant funded by the Korea 3695 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 3696 Security Intelligence Technology Development for the Customized 3697 Security Service Provisioning). This work was supported in part by 3698 the IITP (2020-0-00395, Standard Development of Blockchain based 3699 Network Management Automation Technology). This work was supported 3700 in part by the MSIT under the Information Technology Research Center 3701 (ITRC) support program (IITP-2020-2017-0-01633) supervised by the 3702 IITP. 3704 16. Contributors 3706 This document is made by the group effort of I2NSF working group. 3707 Many people actively contributed to this document. The authors 3708 sincerely appreciate their contributions. 3710 The following are co-authors of this document: 3712 Chaehong Chung 3713 Department of Electronic, Electrical and Computer Engineering 3714 Sungkyunkwan University 3715 2066 Seo-ro Jangan-gu 3716 Suwon, Gyeonggi-do 16419 3717 Republic of Korea 3719 EMail: darkhong@skku.edu 3721 Jinyong (Tim) Kim 3722 Department of Electronic, Electrical and Computer Engineering 3723 Sungkyunkwan University 3724 2066 Seo-ro Jangan-gu 3725 Suwon, Gyeonggi-do 16419 3726 Republic of Korea 3728 EMail: timkim@skku.edu 3730 Dongjin Hong 3731 Department of Electronic, Electrical and Computer Engineering 3732 Sungkyunkwan University 3733 2066 Seo-ro Jangan-gu 3734 Suwon, Gyeonggi-do 16419 3735 Republic of Korea 3736 EMail: dong.jin@skku.edu 3738 Dacheng Zhang 3739 Huawei 3741 EMail: dacheng.zhang@huawei.com 3743 Yi Wu 3744 Aliababa Group 3746 EMail: anren.wy@alibaba-inc.com 3748 Rakesh Kumar 3749 Juniper Networks 3750 1133 Innovation Way 3751 Sunnyvale, CA 94089 3752 USA 3754 EMail: rkkumar@juniper.net 3756 Anil Lohiya 3757 Juniper Networks 3759 EMail: alohiya@juniper.net 3761 17. References 3763 17.1. Normative References 3765 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3766 DOI 10.17487/RFC0768, August 1980, 3767 . 3769 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3770 DOI 10.17487/RFC0791, September 1981, 3771 . 3773 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3774 RFC 792, DOI 10.17487/RFC0792, September 1981, 3775 . 3777 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 3778 RFC 793, DOI 10.17487/RFC0793, September 1981, 3779 . 3781 [RFC0956] Mills, D., "Algorithms for synchronizing network clocks", 3782 RFC 956, DOI 10.17487/RFC0956, September 1985, 3783 . 3785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3786 Requirement Levels", BCP 14, RFC 2119, 3787 DOI 10.17487/RFC2119, March 1997, 3788 . 3790 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3791 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3792 Transfer Protocol -- HTTP/1.1", RFC 2616, 3793 DOI 10.17487/RFC2616, June 1999, 3794 . 3796 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3797 DOI 10.17487/RFC3688, January 2004, 3798 . 3800 [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management 3801 Information Base (MIB)", RFC 3877, DOI 10.17487/RFC3877, 3802 September 2004, . 3804 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 3805 Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, 3806 . 3808 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3809 Control Message Protocol (ICMPv6) for the Internet 3810 Protocol Version 6 (IPv6) Specification", STD 89, 3811 RFC 4443, DOI 10.17487/RFC4443, March 2006, 3812 . 3814 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 3815 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 3816 . 3818 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 3819 DOI 10.17487/RFC5424, March 2009, 3820 . 3822 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3823 and A. Bierman, Ed., "Network Configuration Protocol 3824 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3825 . 3827 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 3828 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 3829 . 3831 [RFC6587] Gerhards, R. and C. Lonvick, "Transmission of Syslog 3832 Messages over TCP", RFC 6587, DOI 10.17487/RFC6587, April 3833 2012, . 3835 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3836 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3837 . 3839 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 3840 "Specification of the IP Flow Information Export (IPFIX) 3841 Protocol for the Exchange of Flow Information", STD 77, 3842 RFC 7011, DOI 10.17487/RFC7011, September 2013, 3843 . 3845 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3846 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3847 . 3849 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3850 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 3851 . 3853 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3854 (IPv6) Specification", STD 86, RFC 8200, 3855 DOI 10.17487/RFC8200, July 2017, 3856 . 3858 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 3859 Kumar, "Framework for Interface to Network Security 3860 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 3861 . 3863 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3864 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3865 . 3867 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 3868 Access Control Model", STD 91, RFC 8341, 3869 DOI 10.17487/RFC8341, March 2018, 3870 . 3872 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 3873 and R. Wilton, "Network Management Datastore Architecture 3874 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 3875 . 3877 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 3878 Documents Containing YANG Data Models", BCP 216, RFC 8407, 3879 DOI 10.17487/RFC8407, October 2018, 3880 . 3882 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3883 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3884 . 3886 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 3887 and R. Wilton, "YANG Library", RFC 8525, 3888 DOI 10.17487/RFC8525, March 2019, 3889 . 3891 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 3892 E., and A. Tripathy, "Subscription to YANG Notifications", 3893 RFC 8639, DOI 10.17487/RFC8639, September 2019, 3894 . 3896 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 3897 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 3898 September 2019, . 3900 17.2. Informative References 3902 [I-D.ietf-i2nsf-applicability] 3903 Jeong, J., Hyun, S., Ahn, T., Hares, S., and D. Lopez, 3904 "Applicability of Interfaces to Network Security Functions 3905 to Network-Based Security Services", draft-ietf-i2nsf- 3906 applicability-18 (work in progress), September 2019. 3908 [I-D.ietf-i2nsf-capability] 3909 Xia, L., Strassner, J., Basile, C., and D. Lopez, 3910 "Information Model of NSFs Capabilities", draft-ietf- 3911 i2nsf-capability-05 (work in progress), April 2019. 3913 [I-D.ietf-i2nsf-consumer-facing-interface-dm] 3914 Jeong, J., Chung, C., Ahn, T., Kumar, R., and S. Hares, 3915 "I2NSF Consumer-Facing Interface YANG Data Model", draft- 3916 ietf-i2nsf-consumer-facing-interface-dm-12 (work in 3917 progress), September 2020. 3919 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 3920 Kim, J., Jeong, J., J., J., PARK, P., Hares, S., and Q. 3921 Lin, "I2NSF Network Security Function-Facing Interface 3922 YANG Data Model", draft-ietf-i2nsf-nsf-facing-interface- 3923 dm-10 (work in progress), August 2020. 3925 [I-D.ietf-i2nsf-registration-interface-dm] 3926 Hyun, S., Jeong, J., Roh, T., Wi, S., J., J., and P. PARK, 3927 "I2NSF Registration Interface YANG Data Model", draft- 3928 ietf-i2nsf-registration-interface-dm-09 (work in 3929 progress), August 2020. 3931 [I-D.ietf-netconf-subscribed-notifications] 3932 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 3933 A. Tripathy, "Subscription to YANG Event Notifications", 3934 draft-ietf-netconf-subscribed-notifications-26 (work in 3935 progress), May 2019. 3937 [I-D.ietf-netconf-yang-push] 3938 Clemm, A. and E. Voit, "Subscription to YANG Datastores", 3939 draft-ietf-netconf-yang-push-25 (work in progress), May 3940 2019. 3942 [I-D.yang-i2nsf-security-policy-translation] 3943 Jeong, J., Yang, J., Chung, C., and J. Kim, "Security 3944 Policy Translation in Interface to Network Security 3945 Functions", draft-yang-i2nsf-security-policy- 3946 translation-07 (work in progress), November 2020. 3948 Appendix A. Changes from draft-ietf-i2nsf-nsf-monitoring-data-model-06 3950 The following changes are made from draft-ietf-i2nsf-nsf-monitoring- 3951 data-model-06: 3953 o This version is revised according to the comments of Andy Bierman 3954 who is a YANG doctor. 3956 o This version updates its title as "I2NSF NSF Monitoring Interface 3957 YANG Data Model". It clarifies the NSF Monitoring Interface to 3958 deliver NSF monitoring data to an NSF data collector (e.g., 3959 Security Controller and NSF data analyzer). 3961 o This version adds an attack destination IP address for DDoS-attack 3962 event to provide I2NSF Analyser with more information about the 3963 destination of DDoS-attack packets. 3965 o This version supports a notification for monitoring traffic flows. 3967 Authors' Addresses 3969 Jaehoon (Paul) Jeong (editor) 3970 Department of Computer Science and Engineering 3971 Sungkyunkwan University 3972 2066 Seobu-Ro, Jangan-Gu 3973 Suwon, Gyeonggi-Do 16419 3974 Republic of Korea 3976 Phone: +82 31 299 4957 3977 Fax: +82 31 290 7996 3978 EMail: pauljeong@skku.edu 3979 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 3981 Patrick Lingga 3982 Department of Electronic, Electrical and Computer Engineering 3983 Sungkyunkwan University 3984 2066 Seobu-Ro, Jangan-Gu 3985 Suwon, Gyeonggi-Do 16419 3986 Republic of Korea 3988 Phone: +82 31 299 4957 3989 EMail: patricklink@skku.edu 3990 Susan Hares 3991 Huawei 3992 7453 Hickory Hill 3993 Saline, MI 48176 3994 USA 3996 Phone: +1-734-604-0332 3997 EMail: shares@ndzh.com 3999 Liang (Frank) Xia 4000 Huawei 4001 101 Software Avenue, Yuhuatai District 4002 Nanjing, Jiangsu 4003 China 4005 EMail: Frank.xialiang@huawei.com 4007 Henk Birkholz 4008 Fraunhofer Institute for Secure Information Technology 4009 Rheinstrasse 75 4010 Darmstadt 64295 4011 Germany 4013 EMail: henk.birkholz@sit.fraunhofer.de