idnits 2.17.1 draft-ietf-i2nsf-nsf-monitoring-data-model-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 24, 2019) is 1709 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Downref: Normative reference to an Historic RFC: RFC 6587 == Outdated reference: A later version (-31) exists of draft-ietf-i2nsf-consumer-facing-interface-dm-05 == Outdated reference: A later version (-29) exists of draft-ietf-i2nsf-nsf-facing-interface-dm-06 == Outdated reference: A later version (-26) exists of draft-ietf-i2nsf-registration-interface-dm-04 == Outdated reference: A later version (-08) exists of draft-yang-i2nsf-nfv-architecture-05 == Outdated reference: A later version (-16) exists of draft-yang-i2nsf-security-policy-translation-03 -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group J. Jeong 3 Internet-Draft C. Chung 4 Intended status: Standards Track Sungkyunkwan University 5 Expires: January 25, 2020 S. Hares 6 L. Xia 7 Huawei 8 H. Birkholz 9 Fraunhofer SIT 10 July 24, 2019 12 I2NSF NSF Monitoring YANG Data Model 13 draft-ietf-i2nsf-nsf-monitoring-data-model-01 15 Abstract 17 This document describes an information model and the corresponding 18 YANG data model for monitoring Network Security Functions (NSFs) in 19 the Interface to Network Security Functions (I2NSF) framework. If 20 the monitoring of NSFs is performed in a comprehensive way, it is 21 possible to detect malicious activity, anomalous behavior, and the 22 potential sign of denial of service attacks in a timely manner. This 23 monitoring functionality is based on the monitoring information that 24 is generated by NSFs. Thus, this document describes not only an 25 information model for monitoring NSFs along with a YANG data diagram, 26 but also the corresponding YANG data model for monitoring NSFs. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 25, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 65 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.3. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Use Cases for NSF Monitoring Data . . . . . . . . . . . . . . 4 68 4. Classification of NSF Monitoring Data . . . . . . . . . . . . 5 69 4.1. Retention and Emission . . . . . . . . . . . . . . . . . 6 70 4.2. Notifications and Events . . . . . . . . . . . . . . . . 7 71 4.3. Unsolicited Poll and Solicited Push . . . . . . . . . . . 8 72 4.4. I2NSF Monitoring Terminology for Retained Information . . 8 73 5. Conveyance of NSF Monitoring Information . . . . . . . . . . 9 74 5.1. Information Types and Acquisition Methods . . . . . . . . 10 75 6. Basic Information Model for All Monitoring Data . . . . . . . 10 76 7. Extended Information Model for Monitoring Data . . . . . . . 11 77 7.1. System Alarm . . . . . . . . . . . . . . . . . . . . . . 11 78 7.1.1. Memory Alarm . . . . . . . . . . . . . . . . . . . . 11 79 7.1.2. CPU Alarm . . . . . . . . . . . . . . . . . . . . . . 12 80 7.1.3. Disk Alarm . . . . . . . . . . . . . . . . . . . . . 12 81 7.1.4. Hardware Alarm . . . . . . . . . . . . . . . . . . . 12 82 7.1.5. Interface Alarm . . . . . . . . . . . . . . . . . . . 13 83 7.2. System Events . . . . . . . . . . . . . . . . . . . . . . 13 84 7.2.1. Access Violation . . . . . . . . . . . . . . . . . . 13 85 7.2.2. Configuration Change . . . . . . . . . . . . . . . . 14 86 7.3. System Log . . . . . . . . . . . . . . . . . . . . . . . 14 87 7.3.1. Access Logs . . . . . . . . . . . . . . . . . . . . . 14 88 7.3.2. Resource Utilization Logs . . . . . . . . . . . . . . 15 89 7.3.3. User Activity Logs . . . . . . . . . . . . . . . . . 15 90 7.4. System Counters . . . . . . . . . . . . . . . . . . . . . 16 91 7.4.1. Interface counters . . . . . . . . . . . . . . . . . 16 92 7.5. NSF Events . . . . . . . . . . . . . . . . . . . . . . . 17 93 7.5.1. DDoS Event . . . . . . . . . . . . . . . . . . . . . 17 94 7.5.2. Session Table Event . . . . . . . . . . . . . . . . . 18 95 7.5.3. Virus Event . . . . . . . . . . . . . . . . . . . . . 18 96 7.5.4. Intrusion Event . . . . . . . . . . . . . . . . . . . 19 97 7.5.5. Botnet Event . . . . . . . . . . . . . . . . . . . . 20 98 7.5.6. Web Attack Event . . . . . . . . . . . . . . . . . . 21 99 7.6. NSF Logs . . . . . . . . . . . . . . . . . . . . . . . . 21 100 7.6.1. DDoS Logs . . . . . . . . . . . . . . . . . . . . . . 22 101 7.6.2. Virus Logs . . . . . . . . . . . . . . . . . . . . . 22 102 7.6.3. Intrusion Logs . . . . . . . . . . . . . . . . . . . 23 103 7.6.4. Botnet Logs . . . . . . . . . . . . . . . . . . . . . 23 104 7.6.5. DPI Logs . . . . . . . . . . . . . . . . . . . . . . 23 105 7.6.6. Vulnerability Scanning Logs . . . . . . . . . . . . . 24 106 7.6.7. Web Attack Logs . . . . . . . . . . . . . . . . . . . 25 107 7.7. NSF Counters . . . . . . . . . . . . . . . . . . . . . . 25 108 7.7.1. Firewall counters . . . . . . . . . . . . . . . . . . 25 109 7.7.2. Policy Hit Counters . . . . . . . . . . . . . . . . . 26 110 8. NSF Monitoring Management in I2NSF . . . . . . . . . . . . . 27 111 9. Tree Structure . . . . . . . . . . . . . . . . . . . . . . . 28 112 10. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 36 113 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 114 12. Security Considerations . . . . . . . . . . . . . . . . . . . 72 115 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 116 13.1. Normative References . . . . . . . . . . . . . . . . . . 72 117 13.2. Informative References . . . . . . . . . . . . . . . . . 74 118 Appendix A. Changes from draft-ietf-i2nsf-nsf-monitoring-data- 119 model-00 . . . . . . . . . . . . . . . . . . . . . . 76 120 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 76 121 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 76 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 124 1. Introduction 126 According to [I-D.ietf-i2nsf-terminology], the interface provided by 127 Network Security Functions (NSFs) (e.g., Firewall, IPS, Anti-DDoS, or 128 Anti-Virus function) to administrative entities (e.g., Security 129 Controller) to enable remote management (i.e., configuring and 130 monitoring) is referred to as an I2NSF NSF-Facing Interface 131 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. Monitoring procedures 132 intent to acquire vital types of data with respect to NSFs, (e.g., 133 alarms, records, and counters) via data in motion (e.g., queries, 134 notifications, and events). The monitoring of NSF plays an important 135 role in an overall security framework, if it is done in a timely and 136 comprehensive way. The monitoring information generated by an NSF 137 can be a good, early indication of anomalous behavior or malicious 138 activity, such as denial of service attacks (DoS). 140 This document defines a comprehensive NSF monitoring information 141 model that provides visibility for an NSF for Security Controller. 142 It specifies the information and illustrates the methods that enable 143 an NSF to provide the information required in order to be monitored 144 in a scalable and efficient way via the NSF-Facing Interface. The 145 information model for monitoring presented in this document is a 146 complementary information model to the information model for the 147 security policy provisioning functionality of the NSF-Facing 148 Interface specified in [I-D.ietf-i2nsf-capability]. 150 This document also defines a YANG [RFC7950] data model for monitoring 151 NSFs, which is derived from the information model for NSF monitoring. 153 2. Terminology 155 2.1. Requirements Notation 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119] [RFC8174]. 161 2.2. Definitions 163 The terms, which are used in this document, are defined in the I2NSF 164 terminology document [I-D.ietf-i2nsf-terminology] [RFC8329]. 166 2.3. YANG 168 This document follows the guidelines of [RFC6087], uses the common 169 YANG types defined in [RFC6991], and adopts the Network Management 170 Datastore Architecture (NMDA) [RFC8342]. The meaning of the symbols 171 in tree diagrams is defined in [RFC8340]. 173 3. Use Cases for NSF Monitoring Data 175 As mentioned earlier, monitoring plays a critical role in an overall 176 security framework. The monitoring of the NSF provides very valuable 177 information to the security controller in maintaining the provisioned 178 security posture. Besides this, there are various other reasons to 179 monitor the NSF as listed below: 181 o The security administrator with I2NSF User can configure a policy 182 that is triggered on a specific event occurring in the NSF or the 183 network [RFC8329] [I-D.ietf-i2nsf-consumer-facing-interface-dm]. 184 If a security controller detects the specified event, it 185 configures additional security functions as defined by policies. 187 o The events triggered by an NSF as a result of security policy 188 violation can be used by Security Information and Event Management 189 (SIEM) to detect any suspicious activity in a larger correlation 190 context. 192 o The events and activity logs from an NSF can be used to build 193 advanced analytics, such as behavior and predictive models to 194 improve security posture in large deployments. 196 o The security controller can use events from the NSF for achieving 197 high availability. It can take corrective actions such as 198 restarting a failed NSF and horizontally scaling up the NSF. 200 o The events and activity logs from the NSF can aid in the root 201 cause analysis of an operational issue, so it can improve 202 debugging. 204 o The activity logs from the NSF can be used to build historical 205 data for operational and business reasons. 207 4. Classification of NSF Monitoring Data 209 In order to maintain a strong security posture, it is not only 210 necessary not only to configure an NSF's security policies but also 211 to continuously monitor the NSF by consuming acquirable and 212 observable information. This enables security administrators to 213 assess the state of the network topology in a timely fashion. It is 214 not possible to block all the internal and external threats based on 215 static security posture. A more practical approach is supported by 216 enabling dynamic security measures, for which continuous visibility 217 is required. This document defines a set of information elements 218 (and their scope) that can be acquired from an NSF and can be used as 219 NSF monitoring information. In essence, these types of monitoring 220 information can be leveraged to support constant visibility on 221 multiple levels of granularity and can be consumed by the 222 corresponding functions. 224 Three basic domains about the monitoring information originating from 225 a system entity [RFC4949] or an NSF are highlighted in this document. 227 o Retention and Emission 229 o Notifications and Events 231 o Unsolicited Poll and Solicited Push 233 The Alarm Management Framework in [RFC3877] defines an Event as 234 something that happens which may be of interest. It defines a fault 235 as a change in status, crossing a threshold, or an external input to 236 the system. In the I2NSF domain, I2NSF events 237 [I-D.ietf-i2nsf-terminology] are created and the scope of the Alarm 238 Management Framework's Events is still applicable due to its broad 239 definition. The model presented in this document elaborates on the 240 workflow of creating I2NSF events in the context of NSF monitoring 241 and on the way initial I2NSF events are created. 243 As with I2NSF components, every generic system entity can include a 244 set of capabilities [I-D.ietf-i2nsf-terminology] that creates 245 information about the context, composition, configuration, state or 246 behavior of that system entity. This information is intended to be 247 provided to other consumers of information and in the scope of this 248 document, which deals with NSF information monitoring in an automated 249 fashion. 251 4.1. Retention and Emission 253 Typically, a system entity populates standardized interface, such as 254 SNMP, NETCONF, RESTCONF or CoMI to provide and emit created 255 information directly via NSF-Facing Interface 256 [I-D.ietf-i2nsf-terminology]. Alternatively, the created information 257 is retained inside the system entity (or a hierarchy of system 258 entities in a composite device) via records or counters that are not 259 exposed directly via NSF-Facing Interfaces. 261 Information emitted via standardized interfaces can be consumed by an 262 I2NSF User [I-D.ietf-i2nsf-terminology] that includes the capability 263 to consume information not only via an I2NSF Interface(e.g., 264 [I-D.ietf-i2nsf-consumer-facing-interface-dm]) but also via 265 interfaces complementary to the standardized interfaces a generic 266 system entity provides. 268 Information retained on a system entity requires a corresponding 269 I2NSF User to access aggregated records of information, typically in 270 the form of log-files or databases. There are ways to aggregate 271 records originating from different system entities over a network, 272 for examples via Syslog Protocol [RFC5424] or Syslog over TCP 273 [RFC6587]. But even if records are conveyed, the result is the same 274 kind of retention in form of a bigger aggregate of records on another 275 system entity. 277 An I2NSF User is required to process fresh [RFC4949] records created 278 by I2NSF Functions in order to provide them to other I2NSF Components 279 via the corresponding I2NSF Interfaces in a timely manner. This 280 process is effectively based on homogenizing functions, which can 281 access and convert specific kinds of records into information that 282 can be provided and emitted via I2NSF interfaces. 284 When retained or emitted, the information required to support 285 monitoring processes has to be processed by an I2NSF User at some 286 point in the workflow. Typical locations of these I2NSF Users are: 288 o a system entity that creates the information 290 o a system entity that retains an aggregation of records 292 o an I2NSF Component that includes the capabilities of using 293 standardized interfaces provided by other system entities that are 294 not I2NSF Components 296 o an I2NSF Component that creates the information 298 4.2. Notifications and Events 300 A specific task of I2NSF User is to process I2NSF Policy Rules 301 [I-D.ietf-i2nsf-terminology]. The rules of a policy are composed of 302 three clauses: Events, Conditions, and Actions. In consequence, an 303 I2NSF Event is specified to trigger an I2NSF Policy Rule. Such an 304 I2NSF Event is defined as any important occurrence over time in the 305 system being managed, and/or in the environment of the system being 306 managed in [I-D.ietf-i2nsf-terminology], which aligns well with the 307 generic definition of Event from [RFC3877]. 309 The model illustrated in this document introduces a complementary 310 type of information that can be a conveyed notification. 312 Notification: An occurrence of a change of context, composition, 313 configuration, state or behavior of a system entity that can be 314 directly or indirectly observed by an I2NSF User and can be used 315 as input for an event-clause in I2NSF Policy Rules. 317 A notification is similar to an I2NSF Event with the exception 318 that it is created by a system entity that is not an I2NSF 319 Component and that its importance is yet to be assessed. 320 Semantically, a notification is not an I2NSF Event in the context 321 of I2NSF, although they can potentially use the exact same 322 information or data model. In respect to [RFC3877], a 323 Notification is a specific subset of events, because they convey 324 information about something that happens which may be of interest. 325 In consequence, Notifications may contain information with very 326 low expressiveness or relevance. Hence, additional post- 327 processing functions, such as aggregation, correlation or simple 328 anomaly detection, might have to be employed to satisfy a level of 329 expressiveness that is required for an event-clause of an I2NSF 330 Policy Rule. 332 It is important to note that the consumer of a notification (the 333 observer) assesses the importance of a notification and not the 334 producer. The producer can include metadata in a notification that 335 supports the observer in assessing the importance (even metadata 336 about severity), but the deciding entity is an I2NSF User. 338 4.3. Unsolicited Poll and Solicited Push 340 The freshness of the monitored information depends on the acquisition 341 method. Ideally, an I2NSF User is accessing every relevant 342 information about the I2NSF Component and is emitting I2NSF Events to 343 a monitor entity(e.g., Security Controller and I2NSF User) NSF 344 timely. Publication of events via a pubsub/broker model, peer-2-peer 345 meshes, or static defined channels are only a few examples on how a 346 solicited push of I2NSF Events can be facilitated. The actual 347 mechanic implemented by an I2NSF Component is out of the scope of 348 this document. 350 Often, the corresponding management interfaces have to be queried in 351 intervals or on-demand if required by an I2NSF Policy rule. In some 352 cases, a collection of information has to be conducted via login 353 mechanics provided by a system entity. Accessing records of 354 information via this kind of unsolicited polls can introduce a 355 significant latency in regard to the freshness of the monitored 356 information. The actual definition of intervals implemented by an 357 I2NSF Component is also out of scope of this document. 359 4.4. I2NSF Monitoring Terminology for Retained Information 361 Records: Unlike information emitted via notifications and events, 362 records do not require immediate attention from an analyst but may 363 be useful for visibility and retroactive cyber forensic. 364 Depending on the record format, there are different qualities in 365 regard to structure and detail. Records are typically stored in 366 log-files or databases on a system entity or NSF. Records in the 367 form of log-files usually include less structures but potentially 368 more detailed information in regard to the changes of a system 369 entity's characteristics. In contrast, databases often use more 370 strict schemas or data models, therefore enforcing a better 371 structure. However, they inhibit storing information that do not 372 match those models ("closed world assumption"). Records can be 373 continuously processed by I2NSF Agents that act as I2NSF Producer 374 and emit events via functions specifically tailored to a certain 375 type of record. Typically, records are information generated 376 either by an NSF or a system entity about operational and 377 informational data, or various changes in system characteristics, 378 such as user activities, network/traffic status, and network 379 activity. They are important for debugging, auditing and security 380 forensic. 382 Counters: A specific representation of continuous value changes of 383 information elements that potentially occur in high frequency. 384 Prominent example are network interface counters, e.g., PDU amount 385 or byte amount, drop counters, and error counters. Counters are 386 useful in debugging and visibility into operational behavior of an 387 NSF. An I2NSF Agent that observes the progression of counters can 388 act as an I2NSF Producer and emit events in respect to I2NSF 389 Policy Rules. 391 5. Conveyance of NSF Monitoring Information 393 As per the use cases of NSF monitoring data, information needs to be 394 conveyed to various I2NSF Consumers based on requirements imposed by 395 I2NSF Capabilities and workflows. There are multiple aspects to be 396 considered in regard to the emission of monitoring information to 397 requesting parties as listed below: 399 o Pull-Push Model: A set of data can be pushed by an NSF to a 400 requesting party or pulled by a requesting party from an NSF. 401 Specific types of information might need both the models at the 402 same time if there are multiple I2NSF Consumers with varying 403 requirements. In general, any I2NSF Event including a high 404 severity assessment is considered to be of great importance and 405 should be processed as soon as possible (push-model). Records, in 406 contrast, are typically not as critical (pull-model). The I2NSF 407 Architecture does not mandate a specific scheme for each type of 408 information and is therefore out of scope of this document. 410 o Pub-Sub Model: In order for an I2NSF Provider to push monitoring 411 information to multiple appropriate I2NSF Consumers, a 412 subscription can be maintained by both I2NSF Components. 413 Discovery of available monitoring information can be supported by 414 an I2NSF Controller that takes the role of a broker and therefore 415 includes I2NSF Capabilities that support registration. 417 o Export Frequency: Monitoring information can be emitted 418 immediately upon generation by an NSF to requesting I2NSF 419 Consumers or can be pushed periodically. The frequency of 420 exporting the data depends upon its size and timely usefulness. 421 It is out of the scope of I2NSF and left to each NSF 422 implementation. 424 o Authentication: There may be a need for authentication between an 425 I2NSF Producer of monitoring information and its corresponding 426 I2NSF Consumer to ensure that critical information remains 427 confidential. Authentication in the scope of I2NSF can also 428 require its corresponding content authorization. This may be 429 necessary, for example, if an NSF emits monitoring information to 430 an I2NSF Consumer outside its administrative domain. The I2NSF 431 Architecture does not mandate when and how specific authentication 432 has to be implemented. 434 o Data-Transfer Model: Monitoring information can be pushed by an 435 NSF using a connection-less model that does require a persistent 436 connection or streamed over a persistent connection. An 437 appropriate model depends on the I2NSF Consumer requirements and 438 the semantics of the information to be conveyed. 440 o Data Model and Interaction Model for Data in Motion: There are a 441 lot of transport mechanisms such as IP, UDP, and TCP. There are 442 also open source implementations for specific set of data such as 443 systems counter, e.g. IPFIX [RFC7011] and NetFlow [RFC3954]. The 444 I2NSF does not mandate any specific method for a given data set, 445 so it is up to each implementation. 447 5.1. Information Types and Acquisition Methods 449 In this document, most defined information types defined benefit from 450 high visibility with respect to value changes, e.g., alarms and 451 records. In contrast, values that change monotonically in a 452 continuous way do not benefit from this high visibility. On the 453 contrary, emitting each change would result in a useless amount of 454 value updates. Hence, values, such as counter, are best acquired in 455 periodic intervals. 457 The mechanisms provided by YANG Push [I-D.ietf-netconf-yang-push] and 458 YANG Subscribed Notifications 459 [I-D.ietf-netconf-subscribed-notifications] address exactly these set 460 of requirements. YANG also enables semantically well-structured 461 information, as well as subscriptions to datastores or event streams 462 - by changes or periodically. 464 In consequence, this information model in this document is intended 465 to support data models used in solicited or unsolicited event streams 466 that potentially are facilitated by a subscription mechanism. A 467 subset of information elements defined in the information model 468 address this domain of application. 470 6. Basic Information Model for All Monitoring Data 472 As explained in the above section, there is a wealth of data 473 available from the NSF that can be monitored. Firstly, there must be 474 some general information with each monitoring message sent from an 475 NSF that helps a consumer to identify meta data with that message, 476 which are listed as below: 478 o message_version: It indicates the version of the data format and 479 is a two-digit decimal numeral starting from 01. 481 o message_type: Event, Alert, Alarm, Log, Counter, etc. 483 o time_stamp: It indicates the time when the message is generated. 485 o vendor_name: The name of the NSF vendor. 487 o NSF_name: The name (or IP) of the NSF generating the message. 489 o Module_name: The module name outputting the message. 491 o Severity: It indicates the level of the logs. There are total 492 eight levels, from 0 to 7. The smaller the numeral is, the higher 493 the severity is. 495 7. Extended Information Model for Monitoring Data 497 This section covers the additional information associated with the 498 system messages. The extended information model is only for the 499 structured data such as alarm. Any unstructured data is specified 500 with basic information model only. 502 7.1. System Alarm 504 Characteristics: 506 o acquisition_method: subscription 508 o emission_type: on-change 510 o dampening_type: no-dampening 512 7.1.1. Memory Alarm 514 The following information should be included in a Memory Alarm: 516 o event_name: MEM_USAGE_ALARM 518 o module_name: It indicates the NSF module responsible for 519 generating this alarm. 521 o usage: specifies the amount of memory used. 523 o threshold: The threshold triggering the alarm 525 o severity: The severity of the alarm such as critical, high, 526 medium, low 528 o message: The memory usage exceeded the threshold 530 7.1.2. CPU Alarm 532 The following information should be included in a CPU Alarm: 534 o event_name: CPU_USAGE_ALARM 536 o usage: Specifies the amount of CPU used. 538 o threshold: The threshold triggering the event 540 o severity: The severity of the alarm such as critical, high, 541 medium, low 543 o message: The CPU usage exceeded the threshold. 545 7.1.3. Disk Alarm 547 The following information should be included in a Disk Alarm: 549 o event_name: DISK_USAGE_ALARM 551 o usage: Specifies the amount of disk space used. 553 o threshold: The threshold triggering the event 555 o severity: The severity of the alarm such as critical, high, 556 medium, low 558 o message: The disk usage exceeded the threshold. 560 7.1.4. Hardware Alarm 562 The following information should be included in a Hardware Alarm: 564 o event_name: HW_FAILURE_ALARM 566 o component_name: It indicates the HW component responsible for 567 generating this alarm. 569 o threshold: The threshold triggering the alarm 570 o severity: The severity of the alarm such as critical, high, 571 medium, low 573 o message: The HW component has failed or degraded. 575 7.1.5. Interface Alarm 577 The following information should be included in an Interface Alarm: 579 o event_name: IFNET_STATE_ALARM 581 o interface_Name: The name of interface 583 o interface_state: UP, DOWN, CONGESTED 585 o threshold: The threshold triggering the event 587 o severity: The severity of the alarm such as critical, high, 588 medium, low 590 o message: Current interface state 592 7.2. System Events 594 Characteristics: 596 o acquisition_method: subscription 598 o emission_type: on-change 600 o dampening_type: on-repetition 602 7.2.1. Access Violation 604 The following information should be included in this event: 606 o event_name: ACCESS_DENIED 608 o user: Name of a user 610 o group: Group to which a user belongs 612 o login_ip_address: Login IP address of a user 614 o authentication_mode: User authentication mode. e.g., Local 615 Authentication, Third-Party Server Authentication, Authentication 616 Exemption, Single Sign-On (SSO) Authentication 618 o message: access is denied. 620 7.2.2. Configuration Change 622 The following information should be included in this event: 624 o event_name: CONFIG_CHANGE 626 o user: Name of a user 628 o group: Group to which a user belongs 630 o login_ip_address: Login IP address of a user 632 o authentication_mode: User authentication mode. e.g., Local 633 Authentication, Third-Party Server Authentication, Authentication 634 Exemption, SSO Authentication 636 o message: Configuration is modified. 638 7.3. System Log 640 Characteristics: 642 o acquisition_method: subscription 644 o emission_type: on-change 646 o dampening_type: on-repetition 648 7.3.1. Access Logs 650 Access logs record administrators' login, logout, and operations on a 651 device. By analyzing them, security vulnerabilities can be 652 identified. The following information should be included in an 653 operation report: 655 o Administrator: Administrator that operates on the device 657 o login_ip_address: IP address used by an administrator to log in 659 o login_mode: Specifies the administrator logs in mode e.g. root, 660 user 662 o operation_type: The operation type that the administrator execute, 663 e.g., login, logout, and configuration. 665 o result: Command execution result 666 o content: Operation performed by an administrator after login. 668 7.3.2. Resource Utilization Logs 670 Running reports record the device system's running status, which is 671 useful for device monitoring. The following information should be 672 included in running report: 674 o system_status: The current system's running status 676 o CPU_usage: Specifies the CPU usage. 678 o memory_usage: Specifies the memory usage. 680 o disk_usage: Specifies the disk usage. 682 o disk_left: Specifies the available disk space left. 684 o session_number: Specifies total concurrent sessions. 686 o process_number: Specifies total number of systems processes. 688 o in_traffic_rate: The total inbound traffic rate in pps 690 o out_traffic_rate: The total outbound traffic rate in pps 692 o in_traffic_speed: The total inbound traffic speed in bps 694 o out_traffic_speed: The total outbound traffic speed in bps 696 7.3.3. User Activity Logs 698 User activity logs provide visibility into users' online records 699 (such as login time, online/lockout duration, and login IP addresses) 700 and the actions that users perform. User activity reports are 701 helpful to identify exceptions during a user's login and network 702 access activities. 704 o user: Name of a user 706 o group: Group to which a user belongs 708 o login_ip_address: Login IP address of a user 710 o authentication_mode: User authentication mode. e.g., Local 711 Authentication, Third-Party Server Authentication, Authentication 712 Exemption, SSO Authentication 714 o access_mode: User access mode. e.g., PPP, SVN, LOCAL 716 o online_duration: Online duration 718 o lockout_duration: Lockout duration 720 o type: User activities. e.g., Successful User Login, Failed Login 721 attempts, User Logout, Successful User Password Change, Failed 722 User Password Change, User Lockout, User Unlocking, Unknown 724 o cause: Cause of a failed user activity 726 7.4. System Counters 728 Characteristics: 730 o acquisition_method: subscription or query 732 o emission_type: periodical 734 o dampening_type: none 736 7.4.1. Interface counters 738 Interface counters provide visibility into traffic into and out of an 739 NSF, and bandwidth usage. 741 o interface_name: Network interface name configured in NSF 743 o in_total_traffic_pkts: Total inbound packets 745 o out_total_traffic_pkts: Total outbound packets 747 o in_total_traffic_bytes: Total inbound bytes 749 o out_total_traffic_bytes: Total outbound bytes 751 o in_drop_traffic_pkts: Total inbound drop packets 753 o out_drop_traffic_pkts: Total outbound drop packets 755 o in_drop_traffic_bytes: Total inbound drop bytes 757 o out_drop_traffic_bytes: Total outbound drop bytes 759 o in_traffic_ave_rate: Inbound traffic average rate in pps 761 o in_traffic_peak_rate: Inbound traffic peak rate in pps 762 o in_traffic_ave_speed: Inbound traffic average speed in bps 764 o in_traffic_peak_speed: Inbound traffic peak speed in bps 766 o out_traffic_ave_rate: Outbound traffic average rate in pps 768 o out_traffic_peak_rate: Outbound traffic peak rate in pps 770 o out_traffic_ave_speed: Outbound traffic average speed in bps 772 o out_traffic_peak_speed: Outbound traffic peak speed in bps 774 7.5. NSF Events 776 Characteristics: 778 o acquisition_method: subscription 780 o emission_type: on-change 782 o dampening_type: none 784 7.5.1. DDoS Event 786 The following information should be included in a DDoS Event: 788 o event_name: SEC_EVENT_DDoS 790 o sub_attack_type: Any one of SYN flood, ACK flood, SYN-ACK flood, 791 FIN/RST flood, TCP Connection flood, UDP flood, ICMP flood, HTTPS 792 flood, HTTP flood, DNS query flood, DNS reply flood, SIP flood, 793 and etc. 795 o dst_ip: The IP address of a victim under attack 797 o dst_port: The port number that the attack traffic aims at. 799 o start_time: The time stamp indicating when the attack started 801 o end_time: The time stamp indicating when the attack ended. If the 802 attack is still undergoing when sending out the alarm, this field 803 can be empty. 805 o attack_rate: The PPS of attack traffic 807 o attack_speed: the bps of attack traffic 809 o rule_id: The ID of the rule being triggered 810 o rule_name: The name of the rule being triggered 812 o profile: Security profile that traffic matches. 814 7.5.2. Session Table Event 816 The following information should be included in a Session 817 Table Event: 819 o event_name: SESSION_USAGE_HIGH 821 o current: The number of concurrent sessions 823 o max: The maximum number of sessions that the session table can 824 support 826 o threshold: The threshold triggering the event 828 o message: The number of session table exceeded the threshold. 830 7.5.3. Virus Event 832 The following information should be included in a Virus Event: 834 o event_Name: SEC_EVENT_VIRUS 836 o virus_type: Type of the virus. e.g., trojan, worm, macro virus 837 type 839 o virus_name: Name of the virus 841 o dst_ip: The destination IP address of the packet where the virus 842 is found 844 o src_ip: The source IP address of the packet where the virus is 845 found 847 o src_port: The source port of the packet where the virus is found 849 o dst_port: The destination port of the packet where the virus is 850 found 852 o src_zone: The source security zone of the packet where the virus 853 is found 855 o dst_zone: The destination security zone of the packet where the 856 virus is found 858 o file_type: The type of the file where the virus is hided within 860 o file_name: The name of the file where the virus is hided within 862 o virus_info: The brief introduction of the virus 864 o raw_info: The information describing the packet triggering the 865 event. 867 o rule_id: The ID of the rule being triggered 869 o rule_name: The name of the rule being triggered 871 o profile: Security profile that traffic matches. 873 7.5.4. Intrusion Event 875 The following information should be included in an Intrusion Event: 877 o event_name: The name of event. e.g., SEC_EVENT_Intrusion 879 o sub_attack_type: Attack type, e.g., brutal force and buffer 880 overflow 882 o src_ip: The source IP address of the packet 884 o dst_ip: The destination IP address of the packet 886 o src_port:The source port number of the packet 888 o dst_port: The destination port number of the packet 890 o src_zone: The source security zone of the packet 892 o dst_zone: The destination security zone of the packet 894 o protocol: The employed transport layer protocol. e.g.,TCP and UDP 896 o app: The employed application layer protocol. e.g.,HTTP and FTP 898 o rule_id: The ID of the rule being triggered 900 o rule_name: The name of the rule being triggered 902 o profile: Security profile that traffic matches 904 o intrusion_info: Simple description of intrusion 905 o raw_info: The information describing the packet triggering the 906 event 908 7.5.5. Botnet Event 910 The following information should be included in a Botnet Event: 912 o event_name: The name of event. e.g., SEC_EVENT_Botnet 914 o botnet_name: The name of the detected botnet 916 o src_ip: The source IP address of the packet 918 o dst_ip: The destination IP address of the packet 920 o src_port: The source port number of the packet 922 o dst_port: The destination port number of the packet 924 o src_zone: The source security zone of the packet 926 o dst_zone: The destination security zone of the packet 928 o protocol: The employed transport layer protocol. e.g.,TCP and UDP 930 o app: The employed application layer protocol. e.g.,HTTP and FTP 932 o role: The role of the communicating parties within the botnet: 934 1. The packet from the zombie host to the attacker 936 2. The packet from the attacker to the zombie host 938 3. The packet from the IRC/WEB server to the zombie host 940 4. The packet from the zombie host to the IRC/WEB server 942 5. The packet from the attacker to the IRC/WEB server 944 6. The packet from the IRC/WEB server to the attacker 946 7. The packet from the zombie host to the victim 948 o botnet_info: Simple description of Botnet 950 o rule_id: The ID of the rule being triggered 952 o rule_name: The name of the rule being triggered 953 o profile: Security profile that traffic matches 955 o raw_info: The information describing the packet triggering the 956 event. 958 7.5.6. Web Attack Event 960 The following information should be included in a Web Attack Alarm: 962 o event_name: The name of event. e.g., SEC_EVENT_WebAttack 964 o sub_attack_type: Concrete web attack type. e.g., SQL injection, 965 command injection, XSS, CSRF 967 o src_ip: The source IP address of the packet 969 o dst_ip: The destination IP address of the packet 971 o src_port: The source port number of the packet 973 o dst_port: The destination port number of the packet 975 o src_zone: The source security zone of the packet 977 o dst_zone: The destination security zone of the packet 979 o req_method: The method of requirement. For instance, "PUT" and 980 "GET" in HTTP 982 o req_url: Requested URL 984 o url_category: Matched URL category 986 o filtering_type: URL filtering type. e.g., Blacklist, Whitelist, 987 User-Defined, Predefined, Malicious Category, and Unknown 989 o rule_id: The ID of the rule being triggered 991 o rule_name: The name of the rule being triggered 993 o profile: Security profile that traffic matches 995 7.6. NSF Logs 997 Characteristics: 999 o acquisition_method: subscription 1000 o emission_type: on-change 1002 o dampening_type: on_repetition 1004 7.6.1. DDoS Logs 1006 Besides the fields in a DDoS Alarm, the following information should 1007 be included in a DDoS Logs: 1009 o attack_type: DDoS 1011 o attack_ave_rate: The average pps of the attack traffic within the 1012 recorded time 1014 o attack_ave_speed: The average bps of the attack traffic within the 1015 recorded time 1017 o attack_pkt_num: The number of attack packets within the recorded 1018 time 1020 o attack_src_ip: The source IP addresses of attack traffics. If 1021 there are a large number of IP addresses, then pick a certain 1022 number of resources according to different rules. 1024 o action: Actions against DDoS attacks. e.g., Allow, Alert, Block, 1025 Discard, Declare, Block-ip, and Block-service. 1027 7.6.2. Virus Logs 1029 Besides the fields in a Virus Alarm, the following information should 1030 be included in a Virus Logs: 1032 o attack_type: Virus 1034 o protocol: The transport layer protocol 1036 o app: The name of the application layer protocol 1038 o times: The time of detecting the virus 1040 o action: The actions dealing with the virus. e.g., alert and block 1042 o os: The OS that the virus will affect. e.g., all, android, ios, 1043 unix, and windows 1045 7.6.3. Intrusion Logs 1047 Besides the fields in an Intrusion Alarm, the following information 1048 should be included in an Intrusion Logs: 1050 o attack_type: Intrusion 1052 o times: The times of intrusions happened in the recorded time 1054 o os: The OS that the intrusion will affect. e.g., all, android, 1055 ios, unix, and windows 1057 o action: The actions dealing with the intrusions. e.g., Allow, 1058 Alert, Block, Discard, Declare, Block-ip, and Block-service 1060 o attack_rate: NUM the pps of attack traffic 1062 o attack_speed: NUM the bps of attack traffic 1064 7.6.4. Botnet Logs 1066 Besides the fields in a Botnet Alarm, the following information 1067 should be included in a Botnet Logs: 1069 o attack_type: Botnet 1071 o botnet_pkt_num:The number of the packets sent to or from the 1072 detected botnet 1074 o action: The actions dealing with the detected packets. e.g., 1075 Allow, Alert, Block, Discard, Declare, Block-ip, and Block- 1076 service. 1078 o os: The OS that the attack aims at. e.g., all, android, ios, unix, 1079 and windows. 1081 7.6.5. DPI Logs 1083 DPI Logs provide statistics on uploaded and downloaded files and 1084 data, sent and received emails, and alert and block records on 1085 websites. It is helpful to learn risky user behaviors and why access 1086 to some URLs is blocked or allowed with an alert record. 1088 o type: DPI action types. e.g., File Blocking, Data Filtering, and 1089 Application Behavior Control 1091 o file_name: The file name 1092 o file_type: The file type 1094 o src_zone: Source security zone of traffic 1096 o dst_zone: Destination security zone of traffic 1098 o src_region: Source region of traffic 1100 o dst_region: Destination region of traffic 1102 o src_ip: Source IP address of traffic 1104 o src_user: User who generates traffic 1106 o dst_ip: Destination IP address of traffic 1108 o src_port: Source port of traffic 1110 o dst_port: Destination port of traffic 1112 o protocol: Protocol type of traffic 1114 o app: Application type of traffic 1116 o policy_id: Security policy id that traffic matches 1118 o policy_name: Security policy name that traffic matches 1120 o action: Action defined in the file blocking rule, data filtering 1121 rule, or application behavior control rule that traffic matches. 1123 7.6.6. Vulnerability Scanning Logs 1125 Vulnerability scanning logs record the victim host and its related 1126 vulnerability information that should to be fixed. The following 1127 information should be included in the report: 1129 o victim_ip: IP address of the victim host which has vulnerabilities 1131 o vulnerability_id: The vulnerability id 1133 o vulnerability_level: The vulnerability level. e.g., high, middle, 1134 and low 1136 o OS: The operating system of the victim host 1138 o service: The service which has vulnerability in the victim host 1139 o protocol: The protocol type. e.g., TCP and UDP 1141 o port: The port number 1143 o vulnerability_info: The information about the vulnerability 1145 o fix_suggestion: The fix suggestion to the vulnerability. 1147 7.6.7. Web Attack Logs 1149 Besides the fields in a Web Attack Alarm, the following information 1150 should be included in a Web Attack Report: 1152 o attack_type: Web Attack 1154 o rsp_code: Response code 1156 o req_clientapp: The client application 1158 o req_cookies: Cookies 1160 o req_host: The domain name of the requested host 1162 o raw_info: The information describing the packet triggering the 1163 event. 1165 7.7. NSF Counters 1167 Characteristics: 1169 o acquisition_method: subscription or query 1171 o emission_type: periodical 1173 o dampening_type: none 1175 7.7.1. Firewall counters 1177 Firewall counters provide visibility into traffic signatures, 1178 bandwidth usage, and how the configured security and bandwidth 1179 policies have been applied. 1181 o src_zone: Source security zone of traffic 1183 o dst_zone: Destination security zone of traffic 1185 o src_region: Source region of traffic 1186 o dst_region: Destination region of traffic 1188 o src_ip: Source IP address of traffic 1190 o src_user: User who generates traffic 1192 o dst_ip: Destination IP address of traffic 1194 o src_port: Source port of traffic 1196 o dst_port: Destination port of traffic 1198 o protocol: Protocol type of traffic 1200 o app: Application type of traffic 1202 o policy_id: Security policy id that traffic matches 1204 o policy_name: Security policy name that traffic matches 1206 o in_interface: Inbound interface of traffic 1208 o out_interface: Outbound interface of traffic 1210 o total_traffic: Total traffic volume 1212 o in_traffic_ave_rate: Inbound traffic average rate in pps 1214 o in_traffic_peak_rate: Inbound traffic peak rate in pps 1216 o in_traffic_ave_speed: Inbound traffic average speed in bps 1218 o in_traffic_peak_speed: Inbound traffic peak speed in bps 1220 o out_traffic_ave_rate: Outbound traffic average rate in pps 1222 o out_traffic_peak_rate: Outbound traffic peak rate in pps 1224 o out_traffic_ave_speed: Outbound traffic average speed in bps 1226 o out_traffic_peak_speed: Outbound traffic peak speed in bps. 1228 7.7.2. Policy Hit Counters 1230 Policy Hit Counters record the security policy that traffic matches 1231 and its hit count. It can check if policy configurations are 1232 correct. 1234 o src_zone: Source security zone of traffic 1236 o dst_zone: Destination security zone of traffic 1238 o src_region: Source region of the traffic 1240 o dst_region: Destination region of the traffic 1242 o src_ip: Source IP address of traffic 1244 o src_user: User who generates traffic 1246 o dst_ip: Destination IP address of traffic 1248 o src_port: Source port of traffic 1250 o dst_port: Destination port of traffic 1252 o protocol: Protocol type of traffic 1254 o app: Application type of traffic 1256 o policy_id: Security policy id that traffic matches 1258 o policy_name: Security policy name that traffic matches 1260 o hit_times: The hit times that the security policy matches the 1261 specified traffic. 1263 8. NSF Monitoring Management in I2NSF 1265 A standard model for monitoring data is required for an administrator 1266 to check the monitoring data generated by an NSF. The administrator 1267 can check the monitoring data through the following process. When 1268 the NSF monitoring data that is under the standard format is 1269 generated, the NSF forwards it to the security controller. The 1270 security controller delivers it to I2NSF Consumer or Developer's 1271 Management System (DMS) so that the administrator can know the state 1272 of the I2NSF framework. 1274 In order to communicate with other components, an I2NSF framework 1275 [RFC8329] requires the interfaces. The three main interfaces in 1276 I2NSF framework are used for sending monitoring data as follows: 1278 o I2NSF Consumer-Facing Interface 1279 [I-D.ietf-i2nsf-consumer-facing-interface-dm]: When an I2NSF User 1280 makes a security policy and forwards it to the Security Controller 1281 via Consumer-Facing Interface, it can specify the threat-feed for 1282 threat prevention, the custom list, the malicious code scan group, 1283 and the event map group. They can be used as an event to be 1284 monitored by an NSF. 1286 o I2NSF Registration Interface 1287 [I-D.ietf-i2nsf-registration-interface-dm]: The Network Functions 1288 Virtualization (NFV) architecture provides the lifecycle 1289 management of a Virtual Network Function (VNF) via the Ve-Vnfm 1290 interface. The role of Ve-Vnfm is to request VNF lifecycle 1291 management (e.g., the instantiation and de-instantiation of an 1292 NSF, and load balancing among NSFs), exchange configuration 1293 information, and exchange status information for a network 1294 service. In the I2NSF framework, the DMS manages data about 1295 resource states and network traffic for the lifecycle management 1296 of an NSF. Therefore, the generated monitoring data from NSFs are 1297 delivered from the Security Controller to the DMS via Registration 1298 Interface. These data are delivered from the DMS to the VNF 1299 Manager in the Management and Orchestration (MANO) in the NFV 1300 system [I-D.yang-i2nsf-nfv-architecture]. 1302 o I2NSF NSF-Facing Interface 1303 [I-D.ietf-i2nsf-nsf-facing-interface-dm]: After a high-level 1304 security policy from I2NSF User is translated by security policy 1305 translator [I-D.yang-i2nsf-security-policy-translation] in the 1306 Security Controller, the translated security policy (i.e., low- 1307 level policy) is applied to an NSF via NSF-Facing Interface. The 1308 monitoring data model specifies the list of events that can 1309 trigger Event-Condition-Action (ECA) policies via NSF-Facing 1310 Interface. 1312 9. Tree Structure 1314 The tree structure of the NSF monitoring YANG module is provided 1315 below: 1317 module: ietf-i2nsf-monitor 1318 +--rw counters 1319 +--rw system-interface 1320 | +--rw acquisition-method? identityref 1321 | +--rw emission-type? identityref 1322 | +--rw dampening-type? identityref 1323 | +--rw interface-name? string 1324 | +--rw in-total-traffic-pkts? uint32 1325 | +--rw out-total-traffic-pkts? uint32 1326 | +--rw in-total-traffic-bytes? uint32 1327 | +--rw out-total-traffic-bytes? uint32 1328 | +--rw in-drop-traffic-pkts? uint32 1329 | +--rw out-drop-traffic-pkts? uint32 1330 | +--rw in-drop-traffic-bytes? uint32 1331 | +--rw out-drop-traffic-bytes? uint32 1332 | +--rw total-traffic? uint32 1333 | +--rw in-traffic-ave-rate? uint32 1334 | +--rw in-traffic-peak-rate? uint32 1335 | +--rw in-traffic-ave-speed? uint32 1336 | +--rw in-traffic-peak-speed? uint32 1337 | +--rw out-traffic-ave-rate? uint32 1338 | +--rw out-traffic-peak-rate? uint32 1339 | +--rw out-traffic-ave-speed? uint32 1340 | +--rw out-traffic-peak-speed? uint32 1341 | +--rw message? string 1342 | +--rw time-stamp? yang:date-and-time 1343 | +--rw vendor-name? string 1344 | +--rw nsf-name? string 1345 | +--rw module-name? string 1346 | +--rw severity? severity 1347 +--rw nsf-firewall 1348 | +--rw acquisition-method? identityref 1349 | +--rw emission-type? identityref 1350 | +--rw dampening-type? identityref 1351 | +--rw src-ip? inet:ipv4-address 1352 | +--rw dst-ip? inet:ipv4-address 1353 | +--rw src-port? inet:port-number 1354 | +--rw dst-port? inet:port-number 1355 | +--rw src-zone? string 1356 | +--rw dst-zone? string 1357 | +--rw src-region? string 1358 | +--rw dst-region? string 1359 | +--rw policy-id? uint8 1360 | +--rw policy-name? string 1361 | +--rw src-user? string 1362 | +--rw protocol? identityref 1363 | +--rw app? string 1364 | +--rw total-traffic? uint32 1365 | +--rw in-traffic-ave-rate? uint32 1366 | +--rw in-traffic-peak-rate? uint32 1367 | +--rw in-traffic-ave-speed? uint32 1368 | +--rw in-traffic-peak-speed? uint32 1369 | +--rw out-traffic-ave-rate? uint32 1370 | +--rw out-traffic-peak-rate? uint32 1371 | +--rw out-traffic-ave-speed? uint32 1372 | +--rw out-traffic-peak-speed? uint32 1373 +--rw nsf-policy-hits 1374 +--rw acquisition-method? identityref 1375 +--rw emission-type? identityref 1376 +--rw dampening-type? identityref 1377 +--rw src-ip? inet:ipv4-address 1378 +--rw dst-ip? inet:ipv4-address 1379 +--rw src-port? inet:port-number 1380 +--rw dst-port? inet:port-number 1381 +--rw src-zone? string 1382 +--rw dst-zone? string 1383 +--rw src-region? string 1384 +--rw dst-region? string 1385 +--rw policy-id? uint8 1386 +--rw policy-name? string 1387 +--rw src-user? string 1388 +--rw protocol? identityref 1389 +--rw app? string 1390 +--rw message? string 1391 +--rw time-stamp? yang:date-and-time 1392 +--rw vendor-name? string 1393 +--rw nsf-name? string 1394 +--rw module-name? string 1395 +--rw severity? severity 1396 +--rw hit-times? uint32 1398 notifications: 1399 +---n system-detection-alarm 1400 | +--ro alarm-category? identityref 1401 | +--ro acquisition-method? identityref 1402 | +--ro emission-type? identityref 1403 | +--ro dampening-type? identityref 1404 | +--ro usage? uint8 1405 | +--ro threshold? uint8 1406 | +--ro message? string 1407 | +--ro time-stamp? yang:date-and-time 1408 | +--ro vendor-name? string 1409 | +--ro nsf-name? string 1410 | +--ro module-name? string 1411 | +--ro severity? severity 1412 +---n system-detection-event 1413 | +--ro event-category? identityref 1414 | +--ro acquisition-method? identityref 1415 | +--ro emission-type? identityref 1416 | +--ro dampening-type? identityref 1417 | +--ro user string 1418 | +--ro group string 1419 | +--ro login-ip-addr inet:ipv4-address 1420 | +--ro authentication? identityref 1421 | +--ro message? string 1422 | +--ro time-stamp? yang:date-and-time 1423 | +--ro vendor-name? string 1424 | +--ro nsf-name? string 1425 | +--ro module-name? string 1426 | +--ro severity? severity 1427 +---n nsf-detection-flood 1428 | +--ro event-name? identityref 1429 | +--ro dst-ip? inet:ipv4-address 1430 | +--ro dst-port? inet:port-number 1431 | +--ro rule-id uint8 1432 | +--ro rule-name string 1433 | +--ro profile? string 1434 | +--ro raw-info? string 1435 | +--ro sub-attack-type? identityref 1436 | +--ro start-time yang:date-and-time 1437 | +--ro end-time yang:date-and-time 1438 | +--ro attack-rate? uint32 1439 | +--ro attack-speed? uint32 1440 | +--ro message? string 1441 | +--ro time-stamp? yang:date-and-time 1442 | +--ro vendor-name? string 1443 | +--ro nsf-name? string 1444 | +--ro module-name? string 1445 | +--ro severity? severity 1446 +---n nsf-detection-session-table 1447 | +--ro current-session? uint8 1448 | +--ro maximum-session? uint8 1449 | +--ro threshold? uint8 1450 | +--ro message? string 1451 | +--ro time-stamp? yang:date-and-time 1452 | +--ro vendor-name? string 1453 | +--ro nsf-name? string 1454 | +--ro module-name? string 1455 | +--ro severity? severity 1456 +---n nsf-detection-virus 1457 | +--ro src-ip? inet:ipv4-address 1458 | +--ro dst-ip? inet:ipv4-address 1459 | +--ro src-port? inet:port-number 1460 | +--ro dst-port? inet:port-number 1461 | +--ro src-zone? string 1462 | +--ro dst-zone? string 1463 | +--ro rule-id uint8 1464 | +--ro rule-name string 1465 | +--ro profile? string 1466 | +--ro raw-info? string 1467 | +--ro virus? identityref 1468 | +--ro virus-name? string 1469 | +--ro file-type? string 1470 | +--ro file-name? string 1471 | +--ro message? string 1472 | +--ro time-stamp? yang:date-and-time 1473 | +--ro vendor-name? string 1474 | +--ro nsf-name? string 1475 | +--ro module-name? string 1476 | +--ro severity? severity 1477 +---n nsf-detection-intrusion 1478 | +--ro src-ip? inet:ipv4-address 1479 | +--ro dst-ip? inet:ipv4-address 1480 | +--ro src-port? inet:port-number 1481 | +--ro dst-port? inet:port-number 1482 | +--ro src-zone? string 1483 | +--ro dst-zone? string 1484 | +--ro rule-id uint8 1485 | +--ro rule-name string 1486 | +--ro profile? string 1487 | +--ro raw-info? string 1488 | +--ro protocol? identityref 1489 | +--ro app? string 1490 | +--ro sub-attack-type? identityref 1491 | +--ro message? string 1492 | +--ro time-stamp? yang:date-and-time 1493 | +--ro vendor-name? string 1494 | +--ro nsf-name? string 1495 | +--ro module-name? string 1496 | +--ro severity? severity 1497 +---n nsf-detection-botnet 1498 | +--ro src-ip? inet:ipv4-address 1499 | +--ro dst-ip? inet:ipv4-address 1500 | +--ro src-port? inet:port-number 1501 | +--ro dst-port? inet:port-number 1502 | +--ro src-zone? string 1503 | +--ro dst-zone? string 1504 | +--ro rule-id uint8 1505 | +--ro rule-name string 1506 | +--ro profile? string 1507 | +--ro raw-info? string 1508 | +--ro attack-type? identityref 1509 | +--ro protocol? identityref 1510 | +--ro botnet-name? string 1511 | +--ro role? string 1512 | +--ro message? string 1513 | +--ro time-stamp? yang:date-and-time 1514 | +--ro vendor-name? string 1515 | +--ro nsf-name? string 1516 | +--ro module-name? string 1517 | +--ro severity? severity 1518 +---n nsf-detection-web-attack 1519 | +--ro src-ip? inet:ipv4-address 1520 | +--ro dst-ip? inet:ipv4-address 1521 | +--ro src-port? inet:port-number 1522 | +--ro dst-port? inet:port-number 1523 | +--ro src-zone? string 1524 | +--ro dst-zone? string 1525 | +--ro rule-id uint8 1526 | +--ro rule-name string 1527 | +--ro profile? string 1528 | +--ro raw-info? string 1529 | +--ro sub-attack-type? identityref 1530 | +--ro request-method? identityref 1531 | +--ro req-uri? string 1532 | +--ro uri-category? string 1533 | +--ro filtering-type* identityref 1534 | +--ro message? string 1535 | +--ro time-stamp? yang:date-and-time 1536 | +--ro vendor-name? string 1537 | +--ro nsf-name? string 1538 | +--ro module-name? string 1539 | +--ro severity? severity 1540 +---n system-access-log 1541 | +--ro login-ip inet:ipv4-address 1542 | +--ro administrator? string 1543 | +--ro login-mode? login-mode 1544 | +--ro operation-type? operation-type 1545 | +--ro result? string 1546 | +--ro content? string 1547 | +--ro acquisition-method? identityref 1548 | +--ro emission-type? identityref 1549 | +--ro dampening-type? identityref 1550 +---n system-res-util-log 1551 | +--ro system-status? string 1552 | +--ro cpu-usage? uint8 1553 | +--ro memory-usage? uint8 1554 | +--ro disk-usage? uint8 1555 | +--ro disk-left? uint8 1556 | +--ro session-num? uint8 1557 | +--ro process-num? uint8 1558 | +--ro in-traffic-rate? uint32 1559 | +--ro out-traffic-rate? uint32 1560 | +--ro in-traffic-speed? uint32 1561 | +--ro out-traffic-speed? uint32 1562 | +--ro acquisition-method? identityref 1563 | +--ro emission-type? identityref 1564 | +--ro dampening-type? identityref 1565 +---n system-user-activity-log 1566 | +--ro acquisition-method? identityref 1567 | +--ro emission-type? identityref 1568 | +--ro dampening-type? identityref 1569 | +--ro user string 1570 | +--ro group string 1571 | +--ro login-ip-addr inet:ipv4-address 1572 | +--ro authentication? identityref 1573 | +--ro access? identityref 1574 | +--ro online-duration? string 1575 | +--ro logout-duration? string 1576 | +--ro additional-info? string 1577 +---n nsf-log-ddos 1578 | +--ro attack-type? identityref 1579 | +--ro attack-ave-rate? uint32 1580 | +--ro attack-ave-speed? uint32 1581 | +--ro attack-pkt-num? uint32 1582 | +--ro attack-src-ip? inet:ipv4-address 1583 | +--ro action? log-action 1584 | +--ro acquisition-method? identityref 1585 | +--ro emission-type? identityref 1586 | +--ro dampening-type? identityref 1587 | +--ro message? string 1588 | +--ro time-stamp? yang:date-and-time 1589 | +--ro vendor-name? string 1590 | +--ro nsf-name? string 1591 | +--ro module-name? string 1592 | +--ro severity? severity 1593 +---n nsf-log-virus 1594 | +--ro attack-type? identityref 1595 | +--ro action? log-action 1596 | +--ro os? string 1597 | +--ro time yang:date-and-time 1598 | +--ro acquisition-method? identityref 1599 | +--ro emission-type? identityref 1600 | +--ro dampening-type? identityref 1601 | +--ro message? string 1602 | +--ro time-stamp? yang:date-and-time 1603 | +--ro vendor-name? string 1604 | +--ro nsf-name? string 1605 | +--ro module-name? string 1606 | +--ro severity? severity 1607 +---n nsf-log-intrusion 1608 | +--ro attack-type? identityref 1609 | +--ro action? log-action 1610 | +--ro time yang:date-and-time 1611 | +--ro attack-rate? uint32 1612 | +--ro attack-speed? uint32 1613 | +--ro acquisition-method? identityref 1614 | +--ro emission-type? identityref 1615 | +--ro dampening-type? identityref 1616 | +--ro message? string 1617 | +--ro time-stamp? yang:date-and-time 1618 | +--ro vendor-name? string 1619 | +--ro nsf-name? string 1620 | +--ro module-name? string 1621 | +--ro severity? severity 1622 +---n nsf-log-botnet 1623 | +--ro attack-type? identityref 1624 | +--ro action? log-action 1625 | +--ro botnet-pkt-num? uint8 1626 | +--ro os? string 1627 | +--ro acquisition-method? identityref 1628 | +--ro emission-type? identityref 1629 | +--ro dampening-type? identityref 1630 | +--ro message? string 1631 | +--ro time-stamp? yang:date-and-time 1632 | +--ro vendor-name? string 1633 | +--ro nsf-name? string 1634 | +--ro module-name? string 1635 | +--ro severity? severity 1636 +---n nsf-log-dpi 1637 | +--ro attack-type? dpi-type 1638 | +--ro acquisition-method? identityref 1639 | +--ro emission-type? identityref 1640 | +--ro dampening-type? identityref 1641 | +--ro src-ip? inet:ipv4-address 1642 | +--ro dst-ip? inet:ipv4-address 1643 | +--ro src-port? inet:port-number 1644 | +--ro dst-port? inet:port-number 1645 | +--ro src-zone? string 1646 | +--ro dst-zone? string 1647 | +--ro src-region? string 1648 | +--ro dst-region? string 1649 | +--ro policy-id? uint8 1650 | +--ro policy-name? string 1651 | +--ro src-user? string 1652 | +--ro protocol? identityref 1653 | +--ro app? string 1654 | +--ro message? string 1655 | +--ro time-stamp? yang:date-and-time 1656 | +--ro vendor-name? string 1657 | +--ro nsf-name? string 1658 | +--ro module-name? string 1659 | +--ro severity? severity 1660 +---n nsf-log-vuln-scan 1661 | +--ro vulnerability-id? uint8 1662 | +--ro victim-ip? inet:ipv4-address 1663 | +--ro protocol? identityref 1664 | +--ro port-num? inet:port-number 1665 | +--ro level? severity 1666 | +--ro os? string 1667 | +--ro vulnerability-info? string 1668 | +--ro fix-suggestion? string 1669 | +--ro service? string 1670 | +--ro acquisition-method? identityref 1671 | +--ro emission-type? identityref 1672 | +--ro dampening-type? identityref 1673 | +--ro message? string 1674 | +--ro time-stamp? yang:date-and-time 1675 | +--ro vendor-name? string 1676 | +--ro nsf-name? string 1677 | +--ro module-name? string 1678 | +--ro severity? severity 1679 +---n nsf-log-web-attack 1680 +--ro attack-type? identityref 1681 +--ro rsp-code? string 1682 +--ro req-clientapp? string 1683 +--ro req-cookies? string 1684 +--ro req-host? string 1685 +--ro raw-info? string 1686 +--ro acquisition-method? identityref 1687 +--ro emission-type? identityref 1688 +--ro dampening-type? identityref 1689 +--ro message? string 1690 +--ro time-stamp? yang:date-and-time 1691 +--ro vendor-name? string 1692 +--ro nsf-name? string 1693 +--ro module-name? string 1694 +--ro severity? severity 1696 Figure 1: Information Model for NSF Monitoring 1698 10. YANG Data Model 1700 This section introduces a YANG data model for the information model 1701 of the NSF monitoring information model. 1703 file "ietf-i2nsf-monitor@2019-07-23.yang" 1704 module ietf-i2nsf-monitor { 1705 yang-version 1.1; 1706 namespace 1707 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-monitor"; 1708 prefix 1709 iim; 1710 import ietf-inet-types{ 1711 prefix inet; 1712 reference 1713 "Section 4 of RFC 6991"; 1715 } 1716 import ietf-yang-types { 1717 prefix yang; 1718 reference 1719 "Section 3 of RFC 6991"; 1720 } 1721 organization 1722 "IETF I2NSF (Interface to Network Security Functions) 1723 Working Group"; 1724 contact 1725 "WG Web: 1726 WG List: 1728 WG Chair: Linda Dunbar 1729 1731 Editor: Jaehoon Paul Jeong 1732 1734 Editor: Chaehong Chung 1735 "; 1737 description 1738 "This module is a YANG module for monitoring NSFs. 1740 Copyright (c) 2018 IETF Trust and the persons identified as 1741 authors of the code. All rights reserved. 1743 Redistribution and use in source and binary forms, with or 1744 without modification, is permitted pursuant to, and subject 1745 to the license terms contained in, the Simplified BSD License 1746 set forth in Section 4.c of the IETF Trust's Legal Provisions 1747 Relating to IETF Documents 1748 (http://trustee.ietf.org/license-info). 1750 This version of this YANG module is part of RFC 6087; see 1751 the RFC itself for full legal notices."; 1753 revision "2019-07-23" { 1754 description "First revision"; 1755 reference 1756 "RFC XXXX: I2NSF NSF Monitoring YANG Data Model"; 1757 } 1759 typedef severity { 1760 type enumeration { 1761 enum high { 1762 description 1763 "high-level"; 1764 } 1765 enum middle { 1766 description 1767 "middle-level"; 1768 } 1769 enum low { 1770 description 1771 "low-level"; 1772 } 1773 } 1774 description 1775 "An indicator representing severity"; 1776 } 1777 typedef log-action { 1778 type enumeration { 1779 enum allow { 1780 description 1781 "If action is allowed"; 1782 } 1783 enum alert { 1784 description 1785 "If action is alert"; 1786 } 1787 enum block { 1788 description 1789 "If action is block"; 1790 } 1791 enum discard { 1792 description 1793 "If action is discarded"; 1794 } 1795 enum declare { 1796 description 1797 "If action is declared"; 1798 } 1799 enum block-ip { 1800 description 1801 "If action is block-ip"; 1802 } 1803 enum block-service{ 1804 description 1805 "If action is block-service"; 1806 } 1807 } 1808 description 1809 "This is used for protocol"; 1810 } 1811 typedef dpi-type{ 1812 type enumeration { 1813 enum file-blocking{ 1814 description 1815 "DPI for blocking file"; 1816 } 1817 enum data-filtering{ 1818 description 1819 "DPI for filtering data"; 1820 } 1821 enum application-behavior-control{ 1822 description 1823 "DPI for controlling application behavior"; 1824 } 1825 } 1826 description 1827 "This is used for dpi type"; 1828 } 1829 typedef operation-type{ 1830 type enumeration { 1831 enum login{ 1832 description 1833 "Login operation"; 1834 } 1835 enum logout{ 1836 description 1837 "Logout operation"; 1838 } 1839 enum configuration{ 1840 description 1841 "Configuration operation"; 1842 } 1843 } 1844 description 1845 "An indicator representing operation-type"; 1846 } 1847 typedef login-mode{ 1848 type enumeration { 1849 enum root{ 1850 description 1851 "Root login-mode"; 1852 } 1853 enum user{ 1854 description 1855 "User login-mode"; 1856 } 1857 enum guest{ 1858 description 1859 "Guest login-mode"; 1860 } 1861 } 1862 description 1863 "An indicator representing login-mode"; 1864 } 1866 identity characteristics { 1867 description 1868 "Base identity for monitoring information 1869 characteristics"; 1870 } 1871 identity acquisition-method { 1872 base characteristics; 1873 description 1874 "The type of acquisition-method. Can be multiple 1875 types at once."; 1876 } 1877 identity subscription { 1878 base acquisition-method; 1879 description 1880 "The acquisition-method type is subscription"; 1881 } 1882 identity query { 1883 base acquisition-method; 1884 description 1885 "The acquisition-method type is query"; 1886 } 1887 identity emission-type { 1888 base characteristics; 1889 description 1890 "The type of emission-type."; 1891 } 1892 identity periodical { 1893 base emission-type; 1894 description 1895 "The emission-type type is periodical."; 1896 } 1897 identity on-change { 1898 base emission-type; 1899 description 1900 "The emission-type type is on-change."; 1901 } 1902 identity dampening-type { 1903 base characteristics; 1904 description 1905 "The type of dampening-type."; 1906 } 1907 identity no-dampening { 1908 base dampening-type; 1909 description 1910 "The dampening-type is no-dampening."; 1911 } 1912 identity on-repetition { 1913 base dampening-type; 1914 description 1915 "The dampening-type is on-repetition."; 1916 } 1917 identity none { 1918 base dampening-type; 1919 description 1920 "The dampening-type is none."; 1921 } 1923 identity authentication-mode { 1924 description 1925 "User authentication mode types: 1926 e.g., Local Authentication, 1927 Third-Party Server Authentication, 1928 Authentication Exemption, or Single Sign-On (SSO) 1929 Authentication."; 1930 } 1931 identity local-authentication { 1932 base authentication-mode; 1933 description 1934 "Authentication-mode : local authentication."; 1935 } 1936 identity third-party-server-authentication { 1937 base authentication-mode; 1938 description 1939 "If authentication-mode is 1940 third-part-server-authentication"; 1941 } 1942 identity exemption-authentication { 1943 base authentication-mode; 1944 description 1945 "If authentication-mode is 1946 exemption-authentication"; 1947 } 1948 identity sso-authentication { 1949 base authentication-mode; 1950 description 1951 "If authentication-mode is 1952 sso-authentication"; 1953 } 1954 identity alarm-type { 1955 description 1956 "Base identity for detectable alarm types"; 1957 } 1958 identity MEM-USAGE-ALARM { 1959 base alarm-type; 1960 description 1961 "A memory alarm is alerted"; 1962 } 1963 identity CPU-USAGE-ALARM { 1964 base alarm-type; 1965 description 1966 "A CPU alarm is alerted"; 1967 } 1968 identity DISK-USAGE-ALARM { 1969 base alarm-type; 1970 description 1971 "A disk alarm is alerted"; 1972 } 1973 identity HW-FAILURE-ALARM { 1974 base alarm-type; 1975 description 1976 "A hardware alarm is alerted"; 1977 } 1978 identity IFNET-STATE-ALARM { 1979 base alarm-type; 1980 description 1981 "An interface alarm is alerted"; 1982 } 1983 identity event-type { 1984 description 1985 "Base identity for detectable event types"; 1986 } 1987 identity ACCESS-DENIED { 1988 base event-type; 1989 description 1990 "The system event is access-denied."; 1991 } 1992 identity CONFIG-CHANGE { 1993 base event-type; 1994 description 1995 "The system event is config-change."; 1996 } 1998 identity flood-type { 1999 description 2000 "Base identity for detectable flood types"; 2001 } 2002 identity syn-flood { 2003 base flood-type; 2004 description 2005 "A SYN flood is detected"; 2006 } 2007 identity ack-flood { 2008 base flood-type; 2009 description 2010 "An ACK flood is detected"; 2011 } 2012 identity syn-ack-flood { 2013 base flood-type; 2014 description 2015 "An SYN-ACK flood is detected"; 2016 } 2017 identity fin-rst-flood { 2018 base flood-type; 2019 description 2020 "A FIN-RST flood is detected"; 2021 } 2022 identity tcp-con-flood { 2023 base flood-type; 2024 description 2025 "A TCP connection flood is detected"; 2026 } 2027 identity udp-flood { 2028 base flood-type; 2029 description 2030 "A UDP flood is detected"; 2031 } 2032 identity icmp-flood { 2033 base flood-type; 2034 description 2035 "An ICMP flood is detected"; 2036 } 2037 identity https-flood { 2038 base flood-type; 2039 description 2040 "A HTTPS flood is detected"; 2041 } 2042 identity http-flood { 2043 base flood-type; 2044 description 2045 "A HTTP flood is detected"; 2046 } 2047 identity dns-reply-flood { 2048 base flood-type; 2049 description 2050 "A DNS reply flood is detected"; 2051 } 2052 identity dns-query-flood { 2053 base flood-type; 2054 description 2055 "A DNS query flood is detected"; 2056 } 2057 identity sip-flood { 2058 base flood-type; 2059 description 2060 "A SIP flood is detected"; 2061 } 2063 identity nsf-event-name { 2064 description 2065 "Base identity for detectable nsf event types"; 2066 } 2067 identity SEC-EVENT-DDOS { 2068 base nsf-event-name; 2069 description 2070 "The nsf event is sec-event-ddos."; 2071 } 2072 identity SESSION-USAGE-HIGH { 2073 base nsf-event-name; 2074 description 2075 "The nsf event is session-usage-high"; 2076 } 2077 identity SEC-EVENT-VIRUS { 2078 base nsf-event-name; 2079 description 2080 "The nsf event is sec-event-virus"; 2081 } 2082 identity SEC-EVENT-INTRUSION { 2083 base nsf-event-name; 2084 description 2085 "The nsf event is sec-event-intrusion"; 2086 } 2087 identity SEC-EVENT-BOTNET { 2088 base nsf-event-name; 2089 description 2090 "The nsf event is sec-event-botnet"; 2091 } 2092 identity SEC-EVENT-WEBATTACK { 2093 base nsf-event-name; 2094 description 2095 "The nsf event is sec-event-webattack"; 2096 } 2097 identity attack-type { 2098 description 2099 "The root ID of attack-based notification 2100 in the notification taxonomy"; 2101 } 2102 identity system-attack-type { 2103 base attack-type; 2104 description 2105 "This ID is intended to be used 2106 in the context of system events"; 2107 } 2108 identity nsf-attack-type { 2109 base attack-type; 2110 description 2111 "This ID is intended to be used 2112 in the context of nsf event"; 2113 } 2114 identity botnet-attack-type { 2115 base nsf-attack-type; 2116 description 2117 "This is an ID stub limited to indicating 2118 that this attack type is botnet. 2119 The usual semantic and taxonomy is missing 2120 and name is used."; 2121 } 2122 identity virus-type { 2123 base nsf-attack-type; 2124 description 2125 "The type of virus. Can be multiple types at once. 2126 This attack type is associated with a detected 2127 system-log virus-attack"; 2128 } 2129 identity trojan { 2130 base virus-type; 2131 description 2132 "The detected virus type is trojan"; 2133 } 2134 identity worm { 2135 base virus-type; 2136 description 2137 "The detected virus type is worm"; 2138 } 2139 identity macro { 2140 base virus-type; 2141 description 2142 "The detected virus type is macro"; 2143 } 2144 identity intrusion-attack-type { 2145 base nsf-attack-type; 2146 description 2147 "The attack type is associated with 2148 a detected system-log intrusion"; 2149 } 2150 identity brute-force { 2151 base intrusion-attack-type; 2152 description 2153 "The intrusion type is brute-force"; 2154 } 2155 identity buffer-overflow { 2156 base intrusion-attack-type; 2157 description 2158 "The intrusion type is buffer-overflow"; 2159 } 2160 identity web-attack-type { 2161 base nsf-attack-type; 2162 description 2163 "The attack type associated with 2164 a detected system-log web-attack"; 2165 } 2166 identity command-injection { 2167 base web-attack-type; 2168 description 2169 "The detected web attack type is command injection"; 2170 } 2171 identity xss { 2172 base web-attack-type; 2173 description 2174 "The detected web attack type is XSS"; 2175 } 2176 identity csrf { 2177 base web-attack-type; 2178 description 2179 "The detected web attack type is CSRF"; 2180 } 2181 identity ddos-attack-type { 2182 base nsf-attack-type; 2183 description 2184 "The attack type is associated with a detected 2185 nsf-log event"; 2186 } 2188 identity req-method { 2189 description 2190 "A set of request types (if applicable). 2191 For instance, PUT or GET in HTTP"; 2192 } 2193 identity put-req { 2194 base req-method; 2195 description 2196 "The detected request type is PUT"; 2197 } 2198 identity get-req { 2199 base req-method; 2200 description 2201 "The detected request type is GET"; 2202 } 2204 identity filter-type { 2205 description 2206 "The type of filter used to detect, for example, 2207 a web-attack. Can be applicable to more than 2208 web-attacks. Can be more than one type."; 2209 } 2210 identity whitelist { 2211 base filter-type; 2212 description 2213 "The applied filter type is whitelist"; 2214 } 2215 identity blacklist { 2216 base filter-type; 2217 description 2218 "The applied filter type is blacklist"; 2219 } 2220 identity user-defined { 2221 base filter-type; 2222 description 2223 "The applied filter type is user-defined"; 2224 } 2225 identity balicious-category { 2226 base filter-type; 2227 description 2228 "The applied filter is balicious category"; 2229 } 2230 identity unknown-filter { 2231 base filter-type; 2232 description 2233 "The applied filter is unknown"; 2234 } 2236 identity access-mode { 2237 description 2238 "Base identity for detectable access mode."; 2239 } 2240 identity ppp { 2241 base access-mode; 2242 description 2243 "Access-mode : ppp"; 2244 } 2245 identity svn { 2246 base access-mode; 2247 description 2248 "Access-mode : svn"; 2249 } 2250 identity local { 2251 base access-mode; 2252 description 2253 "Access-mode : local"; 2254 } 2256 identity protocol-type { 2257 description 2258 "An identity used to enable type choices in leaves 2259 and leaflists wrt protocol metadata."; 2260 } 2261 identity tcp { 2262 base ipv4; 2263 base ipv6; 2264 description 2265 "TCP protocol type."; 2266 reference 2267 "RFC 793: Transmission Control Protocol"; 2268 } 2269 identity udp { 2270 base ipv4; 2271 base ipv6; 2272 description 2273 "UDP protocol type."; 2274 reference 2275 "RFC 768: User Datagram Protocol"; 2276 } 2277 identity icmp { 2278 base ipv4; 2279 base ipv6; 2280 description 2281 "General ICMP protocol type."; 2282 reference 2283 "RFC 792: Internet Control Message Protocol"; 2284 } 2285 identity icmpv4 { 2286 base ipv4; 2287 description 2288 "ICMPv4 protocol type."; 2289 } 2290 identity icmpv6 { 2291 base ipv6; 2292 description 2293 "ICMPv6 protocol type."; 2294 } 2295 identity ip { 2296 base protocol-type; 2297 description 2298 "General IP protocol type."; 2299 reference 2300 "RFC 791: Internet Protocol 2301 RFC 2460: Internet Protocol, Version 6 (IPv6)"; 2302 } 2303 identity ipv4 { 2304 base ip; 2305 description 2306 "IPv4 protocol type."; 2307 reference 2308 "RFC 791: Internet Protocol"; 2309 } 2310 identity ipv6 { 2311 base ip; 2312 description 2313 "IPv6 protocol type."; 2314 reference 2315 "RFC 2460: Internet Protocol, Version 6 (IPv6)"; 2316 } 2317 identity http { 2318 base tcp; 2319 description 2320 "HTPP protocol type."; 2321 reference 2322 "RFC 2616: Hypertext Transfer Protocol"; 2323 } 2324 identity ftp { 2325 base tcp; 2326 description 2327 "FTP protocol type."; 2328 reference 2329 "RFC 959: File Transfer Protocol"; 2330 } 2331 grouping common-monitoring-data { 2332 description 2333 "The data set of common monitoring"; 2334 leaf message { 2335 type string; 2336 description 2337 "This is a freetext annotation of 2338 monitoring notification content"; 2339 } 2340 leaf time-stamp { 2341 type yang:date-and-time; 2342 description 2343 "Indicates the time of message generation"; 2344 } 2345 leaf vendor-name { 2346 type string; 2347 description 2348 "The name of the NSF vendor"; 2349 } 2350 leaf nsf-name { 2351 type string; 2352 description 2353 "The name (or IP) of the NSF 2354 generating the message"; 2355 } 2356 leaf module-name { 2357 type string; 2358 description 2359 "The module name outputting the message"; 2360 } 2361 leaf severity { 2362 type severity; 2363 description 2364 "The severity of the alarm such 2365 as critical, high, middle, low."; 2366 } 2367 } 2368 grouping characteristics{ 2369 description 2370 "A set of monitoring information characteristics"; 2371 leaf acquisition-method { 2372 type identityref { 2373 base acquisition-method; 2374 } 2375 description 2376 "The acquisition-method for characteristics"; 2377 } 2378 leaf emission-type { 2379 type identityref { 2380 base emission-type; 2381 } 2382 description 2383 "The emission-type for characteristics"; 2384 } 2385 leaf dampening-type { 2386 type identityref { 2387 base dampening-type; 2388 } 2389 description 2390 "The dampening-type for characteristics"; 2391 } 2392 } 2393 grouping i2nsf-system-alarm-type-content { 2394 description 2395 "A set of system alarm type contents"; 2396 leaf usage { 2397 type uint8; 2398 description 2399 "specifies the amount of usage"; 2400 } 2401 leaf threshold { 2402 type uint8; 2403 description 2404 "The threshold triggering the alarm or the event"; 2405 } 2406 } 2407 grouping i2nsf-system-event-type-content { 2408 description 2409 "System event metadata associated 2410 with system events caused by user activity."; 2411 leaf user { 2412 type string; 2413 mandatory true; 2414 description 2415 "Name of a user"; 2416 } 2417 leaf group { 2418 type string; 2419 mandatory true; 2420 description 2421 "Group to which a user belongs."; 2422 } 2423 leaf login-ip-addr { 2424 type inet:ipv4-address; 2425 mandatory true; 2426 description 2427 "Login IP address of a user."; 2428 } 2429 leaf authentication { 2430 type identityref { 2431 base authentication-mode; 2432 } 2433 description 2434 "The authentication-mode for authentication"; 2435 } 2436 } 2437 grouping i2nsf-nsf-event-type-content-extend { 2438 description 2439 "A set of common IPv4-related NSF event 2440 content elements"; 2441 leaf src-ip { 2442 type inet:ipv4-address; 2443 description 2444 "The source IP address of the packet"; 2445 } 2446 leaf dst-ip { 2447 type inet:ipv4-address; 2448 description 2449 "The destination IP address of the packet"; 2450 } 2451 leaf src-port { 2452 type inet:port-number; 2453 description 2454 "The source port of the packet"; 2455 } 2456 leaf dst-port { 2457 type inet:port-number; 2458 description 2459 "The destination port of the packet"; 2460 } 2461 leaf src-zone { 2462 type string; 2463 description 2464 "The source security zone of the packet"; 2465 } 2466 leaf dst-zone { 2467 type string; 2468 description 2469 "The destination security zone of the packet"; 2470 } 2471 leaf rule-id { 2472 type uint8; 2473 mandatory true; 2474 description 2475 "The ID of the rule being triggered"; 2476 } 2477 leaf rule-name { 2478 type string; 2479 mandatory true; 2480 description 2481 "The name of the rule being triggered"; 2483 } 2484 leaf profile { 2485 type string; 2486 description 2487 "Security profile that traffic matches."; 2488 } 2489 leaf raw-info { 2490 type string; 2491 description 2492 "The information describing the packet 2493 triggering the event."; 2494 } 2495 } 2496 grouping i2nsf-nsf-event-type-content { 2497 description 2498 "A set of common IPv4-related NSF event 2499 content elements"; 2500 leaf dst-ip { 2501 type inet:ipv4-address; 2502 description 2503 "The destination IP address of the packet"; 2504 } 2505 leaf dst-port { 2506 type inet:port-number; 2507 description 2508 "The destination port of the packet"; 2509 } 2510 leaf rule-id { 2511 type uint8; 2512 mandatory true; 2513 description 2514 "The ID of the rule being triggered"; 2515 } 2516 leaf rule-name { 2517 type string; 2518 mandatory true; 2519 description 2520 "The name of the rule being triggered"; 2521 } 2522 leaf profile { 2523 type string; 2524 description 2525 "Security profile that traffic matches."; 2526 } 2527 leaf raw-info { 2528 type string; 2529 description 2530 "The information describing the packet 2531 triggering the event."; 2532 } 2533 } 2534 grouping traffic-rates { 2535 description 2536 "A set of traffic rates 2537 for statistics data"; 2538 leaf total-traffic { 2539 type uint32; 2540 description 2541 "Total traffic"; 2542 } 2543 leaf in-traffic-ave-rate { 2544 type uint32; 2545 description 2546 "Inbound traffic average rate in pps"; 2547 } 2548 leaf in-traffic-peak-rate { 2549 type uint32; 2550 description 2551 "Inbound traffic peak rate in pps"; 2552 } 2553 leaf in-traffic-ave-speed { 2554 type uint32; 2555 description 2556 "Inbound traffic average speed in bps"; 2557 } 2558 leaf in-traffic-peak-speed { 2559 type uint32; 2560 description 2561 "Inbound traffic peak speed in bps"; 2562 } 2563 leaf out-traffic-ave-rate { 2564 type uint32; 2565 description 2566 "Outbound traffic average rate in pps"; 2567 } 2568 leaf out-traffic-peak-rate { 2569 type uint32; 2570 description 2571 "Outbound traffic peak rate in pps"; 2572 } 2573 leaf out-traffic-ave-speed { 2574 type uint32; 2575 description 2576 "Outbound traffic average speed in bps"; 2577 } 2578 leaf out-traffic-peak-speed { 2579 type uint32; 2580 description 2581 "Outbound traffic peak speed in bps"; 2582 } 2583 } 2584 grouping i2nsf-system-counter-type-content{ 2585 description 2586 "A set of system counter type contents"; 2587 leaf interface-name { 2588 type string; 2589 description 2590 "Network interface name configured in NSF"; 2591 } 2592 leaf in-total-traffic-pkts { 2593 type uint32; 2594 description 2595 "Total inbound packets"; 2596 } 2597 leaf out-total-traffic-pkts { 2598 type uint32; 2599 description 2600 "Total outbound packets"; 2601 } 2602 leaf in-total-traffic-bytes { 2603 type uint32; 2604 description 2605 "Total inbound bytes"; 2606 } 2607 leaf out-total-traffic-bytes { 2608 type uint32; 2609 description 2610 "Total outbound bytes"; 2611 } 2612 leaf in-drop-traffic-pkts { 2613 type uint32; 2614 description 2615 "Total inbound drop packets"; 2616 } 2617 leaf out-drop-traffic-pkts { 2618 type uint32; 2619 description 2620 "Total outbound drop packets"; 2621 } 2622 leaf in-drop-traffic-bytes { 2623 type uint32; 2624 description 2625 "Total inbound drop bytes"; 2626 } 2627 leaf out-drop-traffic-bytes { 2628 type uint32; 2629 description 2630 "Total outbound drop bytes"; 2631 } 2632 uses traffic-rates; 2633 } 2634 grouping i2nsf-nsf-counters-type-content{ 2635 description 2636 "A set of nsf counters type contents"; 2637 leaf src-ip { 2638 type inet:ipv4-address; 2639 description 2640 "The source IP address of the packet"; 2641 } 2642 leaf dst-ip { 2643 type inet:ipv4-address; 2644 description 2645 "The destination IP address of the packet"; 2646 } 2647 leaf src-port { 2648 type inet:port-number; 2649 description 2650 "The source port of the packet"; 2651 } 2652 leaf dst-port { 2653 type inet:port-number; 2654 description 2655 "The destination port of the packet"; 2656 } 2657 leaf src-zone { 2658 type string; 2659 description 2660 "The source security zone of the packet"; 2661 } 2662 leaf dst-zone { 2663 type string; 2664 description 2665 "The destination security zone of the packet"; 2666 } 2667 leaf src-region { 2668 type string; 2669 description 2670 "Source region of the traffic"; 2671 } 2672 leaf dst-region{ 2673 type string; 2674 description 2675 "Destination region of the traffic"; 2676 } 2677 leaf policy-id { 2678 type uint8; 2679 description 2680 "The ID of the policy being triggered"; 2681 } 2682 leaf policy-name { 2683 type string; 2684 description 2685 "The name of the policy being triggered"; 2686 } 2687 leaf src-user{ 2688 type string; 2689 description 2690 "User who generates traffic"; 2691 } 2692 leaf protocol { 2693 type identityref { 2694 base protocol-type; 2695 } 2696 description 2697 "Protocol type of traffic"; 2698 } 2699 leaf app { 2700 type string; 2701 description 2702 "Application type of traffic"; 2703 } 2704 } 2706 notification system-detection-alarm { 2707 description 2708 "This notification is sent, when a system alarm 2709 is detected."; 2710 leaf alarm-category { 2711 type identityref { 2712 base alarm-type; 2713 } 2714 description 2715 "The alarm category for 2716 system-detection-alarm notification"; 2717 } 2718 uses characteristics; 2719 uses i2nsf-system-alarm-type-content; 2720 uses common-monitoring-data; 2721 } 2722 notification system-detection-event { 2723 description 2724 "This notification is sent, when a security-sensitive 2725 authentication action fails."; 2726 leaf event-category { 2727 type identityref { 2728 base event-type; 2729 } 2730 description 2731 "The event category for system-detection-event"; 2732 } 2733 uses characteristics; 2734 uses i2nsf-system-event-type-content; 2735 uses common-monitoring-data; 2736 } 2737 notification nsf-detection-flood { 2738 description 2739 "This notification is sent, 2740 when a specific flood type is detected"; 2741 leaf event-name { 2742 type identityref { 2743 base SEC-EVENT-DDOS; 2744 } 2745 description 2746 "The event name for nsf-detection-flood"; 2747 } 2748 uses i2nsf-nsf-event-type-content; 2749 leaf sub-attack-type { 2750 type identityref { 2751 base flood-type; 2752 } 2753 description 2754 "Any one of Syn flood, ACK flood, SYN-ACK flood, 2755 FIN/RST flood, TCP Connection flood, UDP flood, 2756 Icmp flood, HTTPS flood, HTTP flood, DNS query flood, 2757 DNS reply flood, SIP flood, etc."; 2758 } 2759 leaf start-time { 2760 type yang:date-and-time; 2761 mandatory true; 2762 description 2763 "The time stamp indicating when the attack started"; 2764 } 2765 leaf end-time { 2766 type yang:date-and-time; 2767 mandatory true; 2768 description 2769 "The time stamp indicating when the attack ended"; 2770 } 2771 leaf attack-rate { 2772 type uint32; 2773 description 2774 "The PPS rate of attack traffic"; 2775 } 2776 leaf attack-speed { 2777 type uint32; 2778 description 2779 "The BPS speed of attack traffic"; 2780 } 2781 uses common-monitoring-data; 2782 } 2783 notification nsf-detection-session-table { 2784 description 2785 "This notification is sent, when a session table 2786 event is detected"; 2787 leaf current-session { 2788 type uint8; 2789 description 2790 "The number of concurrent sessions"; 2791 } 2792 leaf maximum-session { 2793 type uint8; 2794 description 2795 "The maximum number of sessions that the session 2796 table can support"; 2797 } 2798 leaf threshold { 2799 type uint8; 2800 description 2801 "The threshold triggering the event"; 2802 } 2803 uses common-monitoring-data; 2804 } 2805 notification nsf-detection-virus { 2806 description 2807 "This notification is sent, when a virus is detected"; 2808 uses i2nsf-nsf-event-type-content-extend; 2809 leaf virus { 2810 type identityref { 2811 base virus-type; 2812 } 2813 description 2814 "The virus type for nsf-detection-virus notification"; 2815 } 2816 leaf virus-name { 2817 type string; 2818 description 2819 "The name of the detected virus"; 2820 } 2822 leaf file-type { 2823 type string; 2824 description 2825 "The type of file virus code 2826 is found in (if applicable)."; 2827 } 2828 leaf file-name { 2829 type string; 2830 description 2831 "The name of file virus code 2832 is found in (if applicable)."; 2833 } 2834 uses common-monitoring-data; 2835 } 2836 notification nsf-detection-intrusion { 2837 description 2838 "This notification is sent, when an intrusion event 2839 is detected."; 2840 uses i2nsf-nsf-event-type-content-extend; 2841 leaf protocol { 2842 type identityref { 2843 base protocol-type; 2844 } 2845 description 2846 "The protocol type for 2847 nsf-detection-intrusion notification"; 2848 } 2849 leaf app { 2850 type string; 2851 description 2852 "The employed application layer protocol"; 2853 } 2854 leaf sub-attack-type { 2855 type identityref { 2856 base intrusion-attack-type; 2857 } 2858 description 2859 "The sub attack type for intrusion attack"; 2860 } 2861 uses common-monitoring-data; 2862 } 2863 notification nsf-detection-botnet { 2864 description 2865 "This notification is sent, when a botnet event is 2866 detected"; 2868 uses i2nsf-nsf-event-type-content-extend; 2869 leaf attack-type { 2870 type identityref { 2871 base botnet-attack-type; 2872 } 2873 description 2874 "The attack type for botnet attack"; 2875 } 2876 leaf protocol { 2877 type identityref { 2878 base protocol-type; 2879 } 2880 description 2881 "The protocol type for nsf-detection-botnet notification"; 2882 } 2883 leaf botnet-name { 2884 type string; 2885 description 2886 "The name of the detected botnet"; 2887 } 2888 leaf role { 2889 type string; 2890 description 2891 "The role of the communicating 2892 parties within the botnet"; 2893 } 2894 uses common-monitoring-data; 2895 } 2896 notification nsf-detection-web-attack { 2897 description 2898 "This notification is sent, when an attack event is 2899 detected"; 2900 uses i2nsf-nsf-event-type-content-extend; 2901 leaf sub-attack-type { 2902 type identityref { 2903 base web-attack-type; 2904 } 2905 description 2906 "Concrete web attack type, e.g., sql injection, 2907 command injection, XSS, CSRF"; 2908 } 2909 leaf request-method { 2910 type identityref { 2911 base req-method; 2912 } 2913 description 2914 "The method of requirement. For instance, PUT or 2915 GET in HTTP"; 2917 } 2918 leaf req-uri { 2919 type string; 2920 description 2921 "Requested URI"; 2922 } 2923 leaf uri-category { 2924 type string; 2925 description 2926 "Matched URI category"; 2927 } 2928 leaf-list filtering-type { 2929 type identityref { 2930 base filter-type; 2931 } 2932 description 2933 "URL filtering type, e.g., Blacklist, Whitelist, 2934 User-Defined, Predefined, Malicious Category, 2935 Unknown"; 2936 } 2937 uses common-monitoring-data; 2938 } 2939 notification system-access-log { 2940 description 2941 "The notification is sent, if there is 2942 a new system log entry about 2943 a system access event"; 2944 leaf login-ip { 2945 type inet:ipv4-address; 2946 mandatory true; 2947 description 2948 "Login IP address of a user"; 2949 } 2950 leaf administrator { 2951 type string; 2952 description 2953 "Administrator that maintains the device"; 2954 } 2955 leaf login-mode { 2956 type login-mode; 2957 description 2958 "Specifies the administrator log-in mode"; 2959 } 2960 leaf operation-type { 2961 type operation-type; 2962 description 2963 "The operation type that the administrator executes"; 2964 } 2965 leaf result { 2966 type string; 2967 description 2968 "Command execution result"; 2969 } 2970 leaf content { 2971 type string; 2972 description 2973 "The Operation performed by an administrator 2974 after login"; 2975 } 2976 uses characteristics; 2977 } 2978 notification system-res-util-log { 2979 description 2980 "This notification is sent, if there is 2981 a new log entry representing resource 2982 utilization updates."; 2983 leaf system-status { 2984 type string; 2985 description 2986 "The current systems 2987 running status"; 2988 } 2989 leaf cpu-usage { 2990 type uint8; 2991 description 2992 "Specifies the relative amount of 2993 cpu usage wrt platform resources"; 2994 } 2995 leaf memory-usage { 2996 type uint8; 2997 description 2998 "Specifies the amount of memory usage"; 2999 } 3000 leaf disk-usage { 3001 type uint8; 3002 description 3003 "Specifies the amount of disk usage"; 3004 } 3005 leaf disk-left { 3006 type uint8; 3007 description 3008 "Specifies the amount of disk left"; 3009 } 3010 leaf session-num { 3011 type uint8; 3012 description 3013 "The total number of sessions"; 3014 } 3015 leaf process-num { 3016 type uint8; 3017 description 3018 "The total number of process"; 3019 } 3020 leaf in-traffic-rate { 3021 type uint32; 3022 description 3023 "The total inbound traffic rate in pps"; 3024 } 3025 leaf out-traffic-rate { 3026 type uint32; 3027 description 3028 "The total outbound traffic rate in pps"; 3029 } 3030 leaf in-traffic-speed { 3031 type uint32; 3032 description 3033 "The total inbound traffic speed in bps"; 3034 } 3035 leaf out-traffic-speed { 3036 type uint32; 3037 description 3038 "The total outbound traffic speed in bps"; 3039 } 3040 uses characteristics; 3041 } 3042 notification system-user-activity-log { 3043 description 3044 "This notification is sent, if there is 3045 a new user activity log entry"; 3046 uses characteristics; 3047 uses i2nsf-system-event-type-content; 3048 leaf access { 3049 type identityref { 3050 base access-mode; 3051 } 3052 description 3053 "The access type for 3054 system-user-activity-log notification"; 3055 } 3056 leaf online-duration { 3057 type string; 3058 description 3059 "Online duration"; 3060 } 3061 leaf logout-duration { 3062 type string; 3063 description 3064 "Lockout duration"; 3065 } 3066 leaf additional-info { 3067 type string; 3068 description 3069 "User activities. e.g., Successful 3070 User Login, Failed Login attempts, 3071 User Logout, Successful User 3072 Password Change, Failed User 3073 Password Change, User Lockout, 3074 User Unlocking, Unknown"; 3075 } 3076 } 3077 notification nsf-log-ddos { 3078 description 3079 "This notification is sent, if there is 3080 a new DDoS event log entry in the nsf log"; 3081 leaf attack-type { 3082 type identityref { 3083 base ddos-attack-type; 3084 } 3085 description 3086 "The ddos attack type for 3087 nsf-log-ddos notification"; 3088 } 3089 leaf attack-ave-rate { 3090 type uint32; 3091 description 3092 "The ave PPS of attack traffic"; 3093 } 3094 leaf attack-ave-speed { 3095 type uint32; 3096 description 3097 "the ave bps of attack traffic"; 3098 } 3099 leaf attack-pkt-num { 3100 type uint32; 3101 description 3102 "the number of attack packets"; 3103 } 3104 leaf attack-src-ip { 3105 type inet:ipv4-address; 3106 description 3107 "The source IP addresses of attack 3108 traffics. If there are a large 3109 amount of IP addresses, then 3110 pick a certain number of resources 3111 according to different rules."; 3112 } 3113 leaf action { 3114 type log-action; 3115 description 3116 "Action type: allow, alert, 3117 block, discard, declare, 3118 block-ip, block-service"; 3119 } 3120 uses characteristics; 3121 uses common-monitoring-data; 3122 } 3123 notification nsf-log-virus { 3124 description 3125 "This notification is sent, if there is 3126 a new virus event log entry in the nsf log"; 3127 leaf attack-type { 3128 type identityref { 3129 base virus-type; 3130 } 3131 description 3132 "The virus type for nsf-log-virus notification"; 3133 } 3134 leaf action { 3135 type log-action; 3136 description 3137 "Action type: allow, alert, 3138 block, discard, declare, 3139 block-ip, block-service"; 3140 } 3141 leaf os{ 3142 type string; 3143 description 3144 "simple os information"; 3145 } 3146 leaf time { 3147 type yang:date-and-time; 3148 mandatory true; 3149 description 3150 "Indicate the time when the message 3151 is generated"; 3152 } 3153 uses characteristics; 3154 uses common-monitoring-data; 3155 } 3156 notification nsf-log-intrusion { 3157 description 3158 "This notification is sent, if there is 3159 a new intrusion event log entry in the nsf log"; 3160 leaf attack-type { 3161 type identityref { 3162 base intrusion-attack-type; 3163 } 3164 description 3165 "The intrusion attack type for 3166 nsf-log-intrusion notification"; 3167 } 3168 leaf action { 3169 type log-action; 3170 description 3171 "Action type: allow, alert, 3172 block, discard, declare, 3173 block-ip, block-service"; 3174 } 3175 leaf time { 3176 type yang:date-and-time; 3177 mandatory true; 3178 description 3179 "Indicate the time when the message 3180 is generated"; 3181 } 3182 leaf attack-rate { 3183 type uint32; 3184 description 3185 "The PPS of attack traffic"; 3186 } 3187 leaf attack-speed { 3188 type uint32; 3189 description 3190 "The bps of attack traffic"; 3191 } 3192 uses characteristics; 3193 uses common-monitoring-data; 3194 } 3195 notification nsf-log-botnet { 3196 description 3197 "This notification is sent, if there is 3198 a new botnet event log in the nsf log"; 3199 leaf attack-type { 3200 type identityref { 3201 base botnet-attack-type; 3202 } 3203 description 3204 "The botnet attack type for 3205 nsf-log-botnet notification"; 3206 } 3207 leaf action { 3208 type log-action; 3209 description 3210 "Action type: allow, alert, 3211 block, discard, declare, 3212 block-ip, block-service"; 3213 } 3214 leaf botnet-pkt-num{ 3215 type uint8; 3216 description 3217 "The number of the packets sent to 3218 or from the detected botnet"; 3219 } 3220 leaf os{ 3221 type string; 3222 description 3223 "simple os information"; 3224 } 3225 uses characteristics; 3226 uses common-monitoring-data; 3227 } 3228 notification nsf-log-dpi { 3229 description 3230 "This notification is sent, if there is 3231 a new dpi event in the nsf log"; 3232 leaf attack-type { 3233 type dpi-type; 3234 description 3235 "The type of the dpi"; 3236 } 3237 uses characteristics; 3238 uses i2nsf-nsf-counters-type-content; 3239 uses common-monitoring-data; 3240 } 3241 notification nsf-log-vuln-scan { 3242 description 3243 "This notification is sent, if there is 3244 a new vulnerability-scan report in the nsf log"; 3245 leaf vulnerability-id { 3246 type uint8; 3247 description 3248 "The vulnerability id"; 3249 } 3250 leaf victim-ip { 3251 type inet:ipv4-address; 3252 description 3253 "IP address of the victim host 3254 which has vulnerabilities"; 3255 } 3256 leaf protocol { 3257 type identityref { 3258 base protocol-type; 3259 } 3260 description 3261 "The protocol type for 3262 nsf-log-vuln-scan notification"; 3263 } 3264 leaf port-num { 3265 type inet:port-number; 3266 description 3267 "The port number"; 3268 } 3269 leaf level { 3270 type severity; 3271 description 3272 "The vulnerability severity"; 3273 } 3274 leaf os { 3275 type string; 3276 description 3277 "simple os information"; 3278 } 3279 leaf vulnerability-info { 3280 type string; 3281 description 3282 "The information about the vulnerability"; 3283 } 3284 leaf fix-suggestion { 3285 type string; 3286 description 3287 "The fix suggestion to the vulnerability"; 3288 } 3289 leaf service { 3290 type string; 3291 description 3292 "The service which has vulnerability in the victim host"; 3293 } 3294 uses characteristics; 3295 uses common-monitoring-data; 3296 } 3297 notification nsf-log-web-attack { 3298 description 3299 "This notification is sent, if there is 3300 a new web-attack event in the nsf log"; 3302 leaf attack-type { 3303 type identityref { 3304 base web-attack-type; 3305 } 3306 description 3307 "The web attack type for 3308 nsf-log-web-attack notification"; 3309 } 3310 leaf rsp-code { 3311 type string; 3312 description 3313 "Response code"; 3314 } 3315 leaf req-clientapp { 3316 type string; 3317 description 3318 "The client application"; 3319 } 3320 leaf req-cookies { 3321 type string; 3322 description 3323 "Cookies"; 3324 } 3325 leaf req-host { 3326 type string; 3327 description 3328 "The domain name of the requested host"; 3329 } 3330 leaf raw-info { 3331 type string; 3332 description 3333 "The information describing 3334 the packet triggering the event."; 3335 } 3336 uses characteristics; 3337 uses common-monitoring-data; 3338 } 3339 container counters { 3340 description 3341 "This is probably better covered by an import 3342 as this will not be notifications. 3343 Counter are not very suitable as telemetry, maybe 3344 via periodic subscriptions, which would still 3345 violate principle of least surprise."; 3346 container system-interface { 3347 description 3348 "The system counter type is interface counter"; 3349 uses characteristics; 3350 uses i2nsf-system-counter-type-content; 3351 uses common-monitoring-data; 3352 } 3353 container nsf-firewall { 3354 description 3355 "The nsf counter type is firewall counter"; 3356 uses characteristics; 3357 uses i2nsf-nsf-counters-type-content; 3358 uses traffic-rates; 3359 } 3360 container nsf-policy-hits { 3361 description 3362 "The counters of policy hit"; 3363 uses characteristics; 3364 uses i2nsf-nsf-counters-type-content; 3365 uses common-monitoring-data; 3366 leaf hit-times { 3367 type uint32; 3368 description 3369 "The hit times for policy"; 3370 } 3371 } 3372 } 3373 } 3374 3376 Figure 2: Data Model of Monitoring 3378 11. IANA Considerations 3380 This document requests IANA to register the following URI in the 3381 "IETF XML Registry" [RFC3688]: 3383 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-monitor 3384 Registrant Contact: The IESG. 3385 XML: N/A; the requested URI is an XML namespace. 3387 This document requests IANA to register the following YANG module in 3388 the "YANG Module Names" registry [RFC6020][RFC7950]. 3390 name: ietf-i2nsf-monitor 3391 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-monitor 3392 prefix: iim 3393 reference: RFC XXXX 3395 12. Security Considerations 3397 The YANG module described in this document defines a schema for data 3398 that is designed to be accessed via network management protocols such 3399 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 3400 is the secure transport layer, and the mandatory-to-implement secure 3401 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 3402 is HTTPS, and the mandatory-to-implement secure transport is TLS 3403 [RFC8446]. 3405 The NETCONF access control model [RFC8341] provides the means to 3406 restrict access for particular NETCONF or RESTCONF users to a 3407 preconfigured subset of all available NETCONF or RESTCONF protocol 3408 operations and content. 3410 All data nodes defined in the YANG module which can be created, 3411 modified and deleted (i.e., config true, which is the default) are 3412 considered sensitive. Write operations (e.g., edit-config) applied 3413 to these data nodes without proper protection can negatively affect 3414 framework operations. The monitoring YANG module should be protected 3415 by the secure communication channel, to ensure its confidentiality 3416 and integrity. In another side, the NSF and security controller can 3417 all be faked, which lead to undesirable results (i.e., leakage of an 3418 NSF's important operational information, and faked NSF sending false 3419 information to mislead security controller). The mutual 3420 authentication is essential to protected against this kind of attack. 3421 The current mainstream security technologies (i.e., TLS, DTLS, IPSEC, 3422 and X.509 PKI) can be employed appropriately to provide the above 3423 security functions. 3425 In addition, to defend against the DDoS attack caused by a lot of 3426 NSFs sending massive notifications to the security controller, the 3427 rate limiting or similar mechanisms should be considered in an NSF 3428 and security controller, whether in advance or just in the process of 3429 DDoS attack. 3431 13. References 3433 13.1. Normative References 3435 [I-D.ietf-netconf-subscribed-notifications] 3436 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 3437 A. Tripathy, "Subscription to YANG Event Notifications", 3438 draft-ietf-netconf-subscribed-notifications-26 (work in 3439 progress), May 2019. 3441 [I-D.ietf-netconf-yang-push] 3442 Clemm, A. and E. Voit, "Subscription to YANG Datastores", 3443 draft-ietf-netconf-yang-push-25 (work in progress), May 3444 2019. 3446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3447 Requirement Levels", BCP 14, RFC 2119, 3448 DOI 10.17487/RFC2119, March 1997, 3449 . 3451 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3452 DOI 10.17487/RFC3688, January 2004, 3453 . 3455 [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management 3456 Information Base (MIB)", RFC 3877, DOI 10.17487/RFC3877, 3457 September 2004, . 3459 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 3460 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 3461 . 3463 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 3464 DOI 10.17487/RFC5424, March 2009, 3465 . 3467 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 3468 the Network Configuration Protocol (NETCONF)", RFC 6020, 3469 DOI 10.17487/RFC6020, October 2010, 3470 . 3472 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3473 and A. Bierman, Ed., "Network Configuration Protocol 3474 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3475 . 3477 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 3478 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 3479 . 3481 [RFC6587] Gerhards, R. and C. Lonvick, "Transmission of Syslog 3482 Messages over TCP", RFC 6587, DOI 10.17487/RFC6587, April 3483 2012, . 3485 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 3486 RFC 6991, DOI 10.17487/RFC6991, July 2013, 3487 . 3489 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 3490 "Specification of the IP Flow Information Export (IPFIX) 3491 Protocol for the Exchange of Flow Information", STD 77, 3492 RFC 7011, DOI 10.17487/RFC7011, September 2013, 3493 . 3495 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3496 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3497 . 3499 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3500 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 3501 . 3503 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3504 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3505 May 2017, . 3507 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 3508 Access Control Model", STD 91, RFC 8341, 3509 DOI 10.17487/RFC8341, March 2018, 3510 . 3512 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 3513 and R. Wilton, "Network Management Datastore Architecture 3514 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 3515 . 3517 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3518 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3519 . 3521 13.2. Informative References 3523 [I-D.ietf-i2nsf-capability] 3524 Xia, L., Strassner, J., Basile, C., and D. Lopez, 3525 "Information Model of NSFs Capabilities", draft-ietf- 3526 i2nsf-capability-05 (work in progress), April 2019. 3528 [I-D.ietf-i2nsf-consumer-facing-interface-dm] 3529 Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares, 3530 "I2NSF Consumer-Facing Interface YANG Data Model", draft- 3531 ietf-i2nsf-consumer-facing-interface-dm-05 (work in 3532 progress), June 2019. 3534 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 3535 Kim, J., Jeong, J., J., J., PARK, P., Hares, S., and Q. 3536 Lin, "I2NSF Network Security Function-Facing Interface 3537 YANG Data Model", draft-ietf-i2nsf-nsf-facing-interface- 3538 dm-06 (work in progress), June 2019. 3540 [I-D.ietf-i2nsf-registration-interface-dm] 3541 Hyun, S., Jeong, J., Roh, T., Wi, S., J., J., and P. PARK, 3542 "I2NSF Registration Interface YANG Data Model", draft- 3543 ietf-i2nsf-registration-interface-dm-04 (work in 3544 progress), June 2019. 3546 [I-D.ietf-i2nsf-terminology] 3547 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 3548 Birkholz, "Interface to Network Security Functions (I2NSF) 3549 Terminology", draft-ietf-i2nsf-terminology-08 (work in 3550 progress), July 2019. 3552 [I-D.yang-i2nsf-nfv-architecture] 3553 Yang, H., Kim, Y., Jeong, J., and J. Kim, "I2NSF on the 3554 NFV Reference Architecture", draft-yang-i2nsf-nfv- 3555 architecture-05 (work in progress), July 2019. 3557 [I-D.yang-i2nsf-security-policy-translation] 3558 Yang, J., Jeong, J., and J. Kim, "Security Policy 3559 Translation in Interface to Network Security Functions", 3560 draft-yang-i2nsf-security-policy-translation-03 (work in 3561 progress), March 2019. 3563 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 3564 Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, 3565 . 3567 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 3568 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, 3569 January 2011, . 3571 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 3572 Kumar, "Framework for Interface to Network Security 3573 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 3574 . 3576 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3577 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3578 . 3580 Appendix A. Changes from draft-ietf-i2nsf-nsf-monitoring-data-model-00 3582 The following changes are made from draft-ietf-i2nsf-nsf-monitoring- 3583 data-model-00: 3585 o In Section 2.1, Requirements Notation is updated. 3587 o In Section 2.2, the reference [RFC8329] is added. 3589 o In Section 2.3, the reference [RFC8342] is added. 3591 o In Section 11, the reference [RFC6020] is added. 3593 o Many editorial errors have been corrected. 3595 Appendix B. Acknowledgments 3597 This work was supported by Institute of Information & Communications 3598 Technology Planning & Evaluation (IITP) grant funded by the Korea 3599 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 3600 Security Intelligence Technology Development for the Customized 3601 Security Service Provisioning). 3603 This work was supported in part by the MSIT, Korea, under the ITRC 3604 (Information Technology Research Center) support program (IITP- 3605 2019-2017-0-01633) supervised by the IITP. 3607 Appendix C. Contributors 3609 This document is made by the group effort of I2NSF working group. 3610 Many people actively contributed to this document. The following are 3611 considered co-authors: 3613 o Jinyong Tim Kim (Sungkyunkwan University) 3615 o Dongjin Hong (Sungkyunkwan University) 3617 o Dacheng Zhang (Huawei) 3619 o Yi Wu (Aliababa Group) 3621 o Rakesh Kumar (Juniper Networks) 3623 o Anil Lohiya (Juniper Networks) 3625 Authors' Addresses 3627 Jaehoon Paul Jeong 3628 Department of Computer Science and Engineering 3629 Sungkyunkwan University 3630 2066 Seobu-Ro, Jangan-Gu 3631 Suwon, Gyeonggi-Do 16419 3632 Republic of Korea 3634 Phone: +82 31 299 4957 3635 Fax: +82 31 290 7996 3636 EMail: pauljeong@skku.edu 3637 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 3639 Chaehong Chung 3640 Department of Electronic, Electrical and Computer Engineering 3641 Sungkyunkwan University 3642 2066 Seobu-Ro, Jangan-Gu 3643 Suwon, Gyeonggi-Do 16419 3644 Republic of Korea 3646 Phone: +82 10 8541 7158 3647 EMail: darkhong@skku.edu 3649 Susan Hares 3650 Huawei 3651 7453 Hickory Hill 3652 Saline, MI 48176 3653 USA 3655 Phone: +1-734-604-0332 3656 EMail: shares@ndzh.com 3658 Liang Xia (Frank) 3659 Huawei 3660 101 Software Avenue, Yuhuatai District 3661 Nanjing, Jiangsu 3662 China 3664 EMail: Frank.xialiang@huawei.com 3665 Henk Birkholz 3666 Fraunhofer Institute for Secure Information Technology 3667 Rheinstrasse 75 3668 Darmstadt 64295 3669 Germany 3671 EMail: henk.birkholz@sit.fraunhofer.de