idnits 2.17.1 draft-ietf-i2nsf-nsf-monitoring-data-model-19.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1347 has weird spacing: '...ty-time yan...' == Line 1425 has weird spacing: '...-number ine...' == Line 1466 has weird spacing: '...-number ine...' -- The document date (23 May 2022) is 701 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 8329 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-messaging' -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-semantics' == Outdated reference: A later version (-32) exists of draft-ietf-i2nsf-capability-data-model-31 == Outdated reference: A later version (-29) exists of draft-ietf-i2nsf-nsf-facing-interface-dm-27 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-tcpm-rfc793bis' == Outdated reference: A later version (-31) exists of draft-ietf-i2nsf-consumer-facing-interface-dm-19 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jeong, Ed. 3 Internet-Draft P. Lingga 4 Intended status: Standards Track Sungkyunkwan University 5 Expires: 24 November 2022 S. Hares 6 L. Xia 7 Huawei 8 H. Birkholz 9 Fraunhofer SIT 10 23 May 2022 12 I2NSF NSF Monitoring Interface YANG Data Model 13 draft-ietf-i2nsf-nsf-monitoring-data-model-19 15 Abstract 17 This document proposes an information model and the corresponding 18 YANG data model of an interface for monitoring Network Security 19 Functions (NSFs) in the Interface to Network Security Functions 20 (I2NSF) framework. If the monitoring of NSFs is performed with the 21 NSF monitoring interface in a standard way, it is possible to detect 22 the indication of malicious activity, anomalous behavior, the 23 potential sign of denial-of-service attacks, or system overload in a 24 timely manner. This monitoring functionality is based on the 25 monitoring information that is generated by NSFs. Thus, this 26 document describes not only an information model for the NSF 27 monitoring interface along with a YANG tree diagram, but also the 28 corresponding YANG data model. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 24 November 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Use Cases for NSF Monitoring Data . . . . . . . . . . . . . . 5 66 4. Classification of NSF Monitoring Data . . . . . . . . . . . . 5 67 4.1. Retention and Emission from NSFs . . . . . . . . . . . . 6 68 4.2. Notifications for Events and Records . . . . . . . . . . 8 69 4.3. Push and Pull for the retrieval of monitoring data from 70 NSFs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5. Basic Information Model for Monitoring Data . . . . . . . . . 9 72 6. Extended Information Model for Monitoring Data . . . . . . . 10 73 6.1. System Alarms . . . . . . . . . . . . . . . . . . . . . . 11 74 6.1.1. Memory Alarm . . . . . . . . . . . . . . . . . . . . 11 75 6.1.2. CPU Alarm . . . . . . . . . . . . . . . . . . . . . . 11 76 6.1.3. Disk (Storage) Alarm . . . . . . . . . . . . . . . . 12 77 6.1.4. Hardware Alarm . . . . . . . . . . . . . . . . . . . 12 78 6.1.5. Interface Alarm . . . . . . . . . . . . . . . . . . . 13 79 6.2. System Events . . . . . . . . . . . . . . . . . . . . . . 13 80 6.2.1. Access Violation . . . . . . . . . . . . . . . . . . 13 81 6.2.2. Configuration Change . . . . . . . . . . . . . . . . 14 82 6.2.3. Session Table Event . . . . . . . . . . . . . . . . . 15 83 6.2.4. Traffic Flows . . . . . . . . . . . . . . . . . . . . 15 84 6.3. NSF Events . . . . . . . . . . . . . . . . . . . . . . . 16 85 6.3.1. DDoS Detection . . . . . . . . . . . . . . . . . . . 17 86 6.3.2. Virus Event . . . . . . . . . . . . . . . . . . . . . 18 87 6.3.3. Intrusion Event . . . . . . . . . . . . . . . . . . . 19 88 6.3.4. Web Attack Event . . . . . . . . . . . . . . . . . . 19 89 6.3.5. VoIP/VoCN Event . . . . . . . . . . . . . . . . . . . 20 90 6.4. System Logs . . . . . . . . . . . . . . . . . . . . . . . 21 91 6.4.1. Access Log . . . . . . . . . . . . . . . . . . . . . 21 92 6.4.2. Resource Utilization Log . . . . . . . . . . . . . . 22 93 6.4.3. User Activity Log . . . . . . . . . . . . . . . . . . 23 94 6.5. NSF Logs . . . . . . . . . . . . . . . . . . . . . . . . 24 95 6.5.1. Deep Packet Inspection Log . . . . . . . . . . . . . 24 96 6.6. System Counter . . . . . . . . . . . . . . . . . . . . . 24 97 6.6.1. Interface Counter . . . . . . . . . . . . . . . . . . 24 98 6.7. NSF Counters . . . . . . . . . . . . . . . . . . . . . . 26 99 6.7.1. Firewall Counter . . . . . . . . . . . . . . . . . . 26 100 6.7.2. Policy Hit Counter . . . . . . . . . . . . . . . . . 27 101 7. YANG Tree Structure of NSF Monitoring YANG Module . . . . . . 28 102 8. YANG Data Model of NSF Monitoring YANG Module . . . . . . . . 34 103 9. I2NSF Event Stream . . . . . . . . . . . . . . . . . . . . . 85 104 10. XML Examples for I2NSF NSF Monitoring . . . . . . . . . . . . 86 105 10.1. I2NSF System Detection Alarm . . . . . . . . . . . . . . 86 106 10.2. I2NSF Interface Counters . . . . . . . . . . . . . . . . 88 107 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89 108 12. Security Considerations . . . . . . . . . . . . . . . . . . . 90 109 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 92 110 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 92 111 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 112 15.1. Normative References . . . . . . . . . . . . . . . . . . 93 113 15.2. Informative References . . . . . . . . . . . . . . . . . 97 114 Appendix A. Changes from 115 draft-ietf-i2nsf-nsf-monitoring-data-model-18 . . . . . . 98 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 98 118 1. Introduction 120 According to [RFC8329], the interface provided by a Network Security 121 Function (NSF) (e.g., Firewall, IPS, or Anti-DDoS function) to enable 122 the collection of monitoring information is referred to as an I2NSF 123 Monitoring Interface. This interface enables the sharing of vital 124 data from the NSFs (e.g., events, records, and counters) to an NSF 125 data collector (e.g., Security Controller) through a variety of 126 mechanisms (e.g., queries and notifications). The monitoring of NSF 127 plays an important role in an overall security framework, if it is 128 done in a timely way. The monitoring information generated by an NSF 129 can be a good, early indication of anomalous behavior or malicious 130 activity, such as denial-of-service (DoS) attacks. 132 This document defines an information model of an NSF monitoring 133 interface that provides visibility into an NSF for the NSF data 134 collector (note that an NSF data collector is defined as an entity to 135 collect NSF monitoring data from an NSF, such as Security 136 Controller). It specifies the information and illustrates the 137 methods that enable an NSF to provide the information required in 138 order to be monitored in a scalable and efficient way via the NSF 139 Monitoring Interface. The information model for the NSF monitoring 140 interface presented in this document is complementary for the 141 security policy provisioning functionality of the NSF-Facing 142 Interface specified in [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 144 This document also defines a YANG [RFC7950] data model for the NSF 145 monitoring interface, which is derived from the information model for 146 the NSF monitoring interface. 148 Note that this document covers a subset of monitoring data for 149 systems and NSFs, which are related to security. 151 2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 [RFC2119] [RFC8174] when, and only when, they appear in all 157 capitals, as shown here. 159 This document uses the terminology described in [RFC8329]. In 160 addition, the following terms are defined in this document: 162 * I2NSF User: An entity that delivers a high-level security policy 163 to the Security Controller and may request monitoring information 164 via the NSF data collector. 166 * Monitoring Information: Relevant data that can be processed to 167 know the status and performance of the network and the NSF. The 168 monitoring information in an I2NSF environment consists of I2NSF 169 Events, I2NSF Records, and I2NSF Counters (see Section 4.1 for the 170 detailed definition). This information is to be delivered to the 171 NSF data collector. 173 * Notification: Unsolicited transmission of monitoring information. 175 * NSF Data Collector: An entity that collects NSF monitoring 176 information from NSFs, such as Security Controller. 178 * Subscription: An agreement initialized by the NSF data collector 179 to receive monitoring information from an NSF. The method to 180 subscribe follows the method by either NETCONF or RESTCONF, 181 explained in [RFC5277] and [RFC8650], respectively. 183 This document follows the guidelines of [RFC8407], uses the common 184 YANG types defined in [RFC6991], and adopts the Network Management 185 Datastore Architecture (NMDA) [RFC8342]. The meaning of the symbols 186 in tree diagrams is defined in [RFC8340]. 188 3. Use Cases for NSF Monitoring Data 190 As mentioned earlier, monitoring plays a critical role in an overall 191 security framework. The monitoring of the NSF provides very valuable 192 information to an NSF data collector (e.g., Security Controller) in 193 maintaining the provisioned security posture. Besides this, there 194 are various other reasons to monitor the NSF as listed below: 196 * The I2NSF User that is the security administrator can configure a 197 policy that is triggered on a specific event occurring in the NSF 198 or the network [RFC8329] 199 [I-D.ietf-i2nsf-consumer-facing-interface-dm]. If an NSF data 200 collector (e.g., Security Controller) detects the specified event, 201 it can configure additional security functions as defined by 202 policies. 204 * The events triggered by an NSF as a result of security policy 205 violation can be used by Security Information and Event Management 206 (SIEM) to detect any suspicious activity in a larger correlation 207 context. 209 * The information (i.e., events, records, and counters) from an NSF 210 can be used to build advanced analytics, such as behavior and 211 predictive models to improve security posture in large 212 deployments. 214 * The NSF data collector can use events from the NSF for achieving 215 high availability. It can take corrective actions such as 216 restarting a failed NSF and horizontally scaling up the NSF. 218 * The information (i.e., events, records, and counters) from the NSF 219 can aid in the root cause analysis of an operational issue, so it 220 can improve debugging. 222 * The records from the NSF can be used to build historical data for 223 operation and business reasons. 225 4. Classification of NSF Monitoring Data 227 In order to maintain a strong security posture, it is not only 228 necessary to configure an NSF's security policies but also to 229 continuously monitor the NSF by checking acquirable and observable 230 data. This enables security administrators to assess the state of 231 the networks in a timely fashion. It is not possible to block all 232 the internal and external threats based on static security posture. 233 A more practical approach is supported by enabling dynamic security 234 measures, for which continuous visibility is required. This document 235 defines a set of monitoring elements and their scopes that can be 236 acquired from an NSF and can be used as NSF monitoring data. In 237 essence, this monitoring data can be leveraged to support constant 238 visibility on multiple levels of granularity and can be consumed by 239 the corresponding functions. 241 Three basic domains of monitoring data originating from a system 242 entity [RFC4949], i.e., an NSF, are discussed in this document. 244 * Retention and Emission from NSFs 246 * Notifications for Events and Records 248 * Push and Pull for the retrieval of monitoring data from NSFs 250 Every system entity creates information about some context with 251 defined I2NSF monitoring data, and so every system entity that 252 provides such information can be an I2NSF component. This 253 information is intended to be consumed by other I2NSF components, 254 which deals with NSF monitoring data in an automated fashion. 256 4.1. Retention and Emission from NSFs 258 A system entity (e.g., NSF) first retains I2NSF monitoring data 259 inside its own system before emitting the information to another 260 I2NSF component (e.g., NSF Data Collector). The I2NSF monitoring 261 information consist of I2NSF Events, I2NSF Records, and I2NSF 262 Counters as follows: 264 I2NSF Event: I2NSF Event is defined as an important occurrence at a 265 particular time, that is, a change in the system being managed or 266 a change in the environment of the system being managed. An I2NSF 267 Event requires immediate attention and should be notified as soon 268 as possible. When used in the context of an (imperative) I2NSF 269 Policy Rule, an I2NSF Event is used to determine whether the 270 Condition clause of that Policy Rule can be evaluated or not. The 271 Alarm Management Framework in [RFC3877] defines an event as 272 something that happens which may be of interest. Examples of an 273 event are a fault, a change in status, crossing a threshold, or an 274 external input to the system. In the I2NSF domain, I2NSF events 275 are created following the definition of an event in the Alarm 276 Management Framework. 278 I2NSF Record: A record is defined as an item of information that is 279 kept to be looked at and used in the future. Typically, records 280 are the information, which is based on operational and 281 informational data (i.e., various changes in system 282 characteristics). They are generated by a system entity (e.g., 283 NSF) at particular instants to be kept without any changes 284 afterward. A set of records has an ordering in time based on when 285 they are generated. Unlike I2NSF Events, records do not require 286 immediate attention but may be useful for visibility and 287 retroactive cyber forensics. Records are typically stored in log- 288 files or databases on a system entity or NSF. The examples of 289 records include user activities, device performance, and network 290 status. They are important for debugging, auditing, and security 291 forensic of a system entity or the network having the system 292 entity. 294 I2NSF Counter: An I2NSF Counter is defined as a specific 295 representation of an information element whose value changes very 296 frequently. Prominent examples are network interface counters for 297 protocol data unit (PDU) amount, byte amount, drop counters, and 298 error counters. Counters are useful in debugging and visibility 299 into operational behavior of a system entity (e.g., NSF). When an 300 NSF data collector asks for the value of a counter, a system 301 entity MUST update the counter information and emit the latest 302 information to the NSF data collector. 304 Retention is defined as the storing of monitoring data in NSFs. The 305 retention of I2NSF monitoring information may be affected by the 306 importance of the data. The importance of the data could be context- 307 dependent, where it may not just be based on the type of data, but 308 may also depend on where it is deployed, e.g., a test lab and 309 testbed. The local policy and configuration will dictate the 310 policies and procedures to review, archive, or purge the collected 311 monitoring data. 313 Emission is defined as the delivery of monitoring data in NSFs to an 314 NSF data collector. The I2NSF monitoring information retained on a 315 system entity (e.g., NSF) may be delivered to a corresponding I2NSF 316 User via an NSF data collector. The information consists of the 317 aggregated records, typically in the form of log-files or databases. 318 For the NSF Monitoring Interface to deliver the information to the 319 NSF data collector, the NSF needs to accommodate standardized 320 delivery protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. 321 The NSF data collector can forward the information to the I2NSF User 322 through standardized delivery protocols (e.g., RESTCONF and NETCONF). 323 The interface for the delivery of Monitoring Data from the NSF data 324 collector to the I2NSF User is out of the scope of this document. 326 4.2. Notifications for Events and Records 328 A specific task of an I2NSF User is to provide I2NSF Policy Rules. 329 The rules of a policy are composed of three clauses: Event, 330 Condition, and Action clauses. In consequence, an I2NSF Event is 331 specified to trigger the evaluation of the Condition clause of the 332 I2NSF Policy Rule. Such an I2NSF Event is defined as an important 333 occurrence at a particular time in the system being managed, and/or 334 in the environment of the system being managed whose concept aligns 335 well with the generic definition of Event from [RFC3877]. 337 Another role of the I2NSF Event is to trigger a notification for 338 monitoring the status of an NSF. A notification is defined in 339 [RFC3877] as an unsolicited transmission of management information. 340 System alarm (called alarm) is defined as a warning related to 341 service degradation in system hardware in Section 6.1. System event 342 (called alert) is defined as a warning about any changes of 343 configuration, any access violation, information about sessions and 344 traffic flows in Section 6.2. Both an alarm and an alert are I2NSF 345 Events that can be delivered as a notification. The model 346 illustrated in this document introduces a complementary type of 347 information that can be a conveyed notification. 349 In I2NSF monitoring, a notification is used to deliver either an 350 event or a record via the I2NSF Monitoring Interface. The difference 351 between the event and record is the timing by which the notifications 352 are emitted. An event is emitted as soon as it happens in order to 353 notify an NSF Data Collector of the problem that needs immediate 354 attention. A record is not emitted immediately to the NSF Data 355 Collector, and it can be emitted periodically to the NSF Data 356 Collector. 358 It is important to note that an NSF Data Collector as a consumer 359 (i.e., observer) of a notification assesses the importance of the 360 notification rather than an NSF as a producer. The producer can 361 include metadata in a notification that supports the observer in 362 assessing its importance (e.g., severity). 364 4.3. Push and Pull for the retrieval of monitoring data from NSFs 366 An important aspect of monitoring information is the freshness of the 367 information. From the perspective of security, it is important to 368 notice changes in the current status of the network. The I2NSF 369 Monitoring Interface provides the means of sending monitored 370 information from the NSFs to an NSF data collector in a timely 371 manner. Monitoring information can be acquired by a client (i.e., 372 NSF data collector) from a server (i.e., NSF) using push [RFC5277] 373 [RFC8641] or pull methods [RFC6241] [RFC8040]. 375 The pull is a query-based method to obtain information from the NSF. 376 In this method, the NSF will remain passive until the information is 377 requested from the NSF data collector. Once a request is accepted 378 (with proper authentication), the NSF MUST update the information 379 before sending it to the NSF data collector. 381 The push is a report-based method to obtain information from the NSF. 382 The report-based method ensures the information can be delivered 383 immediately without any requests. This method is used by the NSF to 384 actively provide information to the NSF data collector. To receive 385 the information, the NSF data collector subscribes to the NSF for the 386 information. 388 These acquisition methods are used for different types of monitoring 389 information. The information that has a high level of urgency (i.e., 390 I2NSF Event) should be provided with the push method, while 391 information that has a lower level of urgency (i.e., I2NSF Record and 392 I2NSF Counter) can be provided with either the pull method or push 393 method. 395 5. Basic Information Model for Monitoring Data 397 As explained in the above section, there is a wealth of data 398 available from NSFs that can be monitored. Firstly, there must be 399 some general information with each monitoring message sent from an 400 NSF that helps a consumer to identify metadata with that message, 401 which are listed as below: 403 * message: The extra detailed description of NSF monitoring data to 404 give an NSF data collector the context information as metadata. 406 * vendor-name: The vendor's name of the NSF that generates the 407 message. 409 * device-model: The model of the device, can be represented by the 410 device model name or serial number. This field is used to 411 identify the model of the device that provides the security 412 service. 414 * software-version: The version of the software used to provide the 415 security service. 417 * nsf-name: The name or IP address of the NSF generating the 418 message. If the given nsf-name is not an IP address, the name can 419 be an arbitrary string including a FQDN (Fully Qualified Domain 420 Name). The name MUST be unique in the scope of management domain 421 for a different NSF to identify the NSF that generates the 422 message. 424 * timestamp: The time when the message was generated. For the 425 notification operations (i.e., System Alarms, System Events, NSF 426 Events, System Logs, and NSF Logs), this is represented by the 427 eventTime of NETCONF event notification [RFC5277] For other 428 operations (i.e., System Counter and NSF Counter), the timestamp 429 MUST be provided separately. The time format used is following 430 the rules in Section 5.6 of [RFC3339]. 432 * language: describes the human language intended for the user, so 433 that it allows a user to verify the language that is used in the 434 notification (i.e., '../message', '/i2nsf-log/i2nsf-nsf-system- 435 access-log/output', and '/i2nsf-log/i2nsf-system-user-activity- 436 log/additional-info/cause'). The attribute is encoded following 437 the rules in Section 2.1 of [RFC5646]. The default language tag 438 is "en-US". 440 6. Extended Information Model for Monitoring Data 442 The extended information model is the specific monitoring data that 443 covers the additional information associated with the detailed 444 information of status and performance of the network and the NSF over 445 the basic information model. The extended information combined with 446 the basic information creates the monitoring information (i.e., I2NSF 447 Event, Record, and Counter). 449 The extended monitoring information has settable characteristics for 450 data collection as follows: 452 * Acquisition method: The method to obtain the message. It can be a 453 "query" or a "subscription". A "query" is a request-based method 454 to acquire the solicited information. A "subscription" is a 455 report-based method that pushes information to the subscriber. 457 * Emission type: The cause type for the message to be emitted. This 458 attribute is used only when the acquisition method is a 459 "subscription" method. The emission type can be either "on- 460 change" or "periodic". An "on-change" message is emitted when an 461 important event happens in the NSF. A "periodic" message is 462 emitted at a certain time interval. The time to periodically emit 463 the message is configurable. 465 * Dampening type: The type of message dampening to stop the rapid 466 transmission of messages. The dampening types are "on-repetition" 467 and "no-dampening". The "on-repetition" type limits the 468 transmitted "on-change" message to one message at a certain 469 interval (e.g., 100 centiseconds). This interval is defined as 470 dampening-period in [RFC8641]. The dampening-period is 471 configurable in the unit of centiseconds. The "no-dampening" type 472 does not limit the transmission for the messages of the same type. 473 In short, "on-repetition" means that the dampening is active and 474 "no-dampening" is inactive. Activating the dampening for an "on- 475 change" type of message is RECOMMENDED to reduce the number of 476 messages generated. 478 Note that the characteristic information is not mandatory to be 479 included in a monitoring message. The information is expected to be 480 stored and may or may not be useful in some ways in the future. In 481 any case, the inclusion of the characteristic information is up to 482 the implementation. 484 6.1. System Alarms 486 System alarms have the following characteristics: 488 * acquisition-method: subscription 490 * emission-type: on-change 492 * dampening-type: on-repetition or no-dampening 494 6.1.1. Memory Alarm 496 The memory is the hardware to store information temporarily or for a 497 short period, i.e., Random Access Memory (RAM). The memory-alarm is 498 emitted when the memory usage exceeds the threshold. The following 499 information should be included in a Memory Alarm: 501 * event-name: memory-alarm. 503 * usage: specifies the amount of memory used in percentage. 505 * threshold: The threshold triggering the alarm in percentage. 507 * severity: The severity level of the message. There are four 508 levels, i.e., critical, high, middle, and low. 510 * message: Simple information as a human readable text string such 511 as "The memory usage exceeded the threshold" or with extra 512 information. 514 6.1.2. CPU Alarm 516 CPU is the Central Processing Unit that executes basic operations of 517 the system. The cpu-alarm is emitted when the CPU usage exceeds the 518 threshold. The following information should be included in a CPU 519 Alarm: 521 * event-name: cpu-alarm. 523 * usage: Specifies the CPU utilization in percentage. 525 * threshold: The threshold triggering the event in percentage. 527 * severity: The severity level of the message. There are four 528 levels, i.e., critical, high, middle, and low. 530 * message: Simple information as a human readable text string such 531 as "The CPU usage exceeded the threshold" or with extra 532 information. 534 6.1.3. Disk (Storage) Alarm 536 Disk or storage is the hardware to store information for a long time, 537 i.e., Hard Disk or Solid-State Drive. The disk-alarm is emitted when 538 the Disk usage exceeds the threshold. The following information 539 should be included in a Disk Alarm: 541 * event-name: disk-alarm. 543 * usage: Specifies the ratio of the used disk space to the whole 544 disk space in terms of percentage. 546 * threshold: The threshold triggering the event in percentage. 548 * severity: The severity level of the message. There are four 549 levels, i.e., critical, high, middle, and low. 551 * message: Simple information as a human readable text string such 552 as "The disk usage exceeded the threshold" or with extra 553 information. 555 6.1.4. Hardware Alarm 557 The hardware-alarm is emitted when a hardware, e.g., CPU, memory, 558 disk, or interface, problem is detected. The following information 559 should be included in a Hardware Alarm: 561 * event-name: hardware-alarm. 563 * component-name: It indicates the hardware component responsible 564 for generating this alarm. 566 * severity: The severity level of the message. There are four 567 levels, i.e., critical, high, middle, and low. 569 * message: Simple information as a human readable text string such 570 as "The hardware component has failed or degraded" or with extra 571 information. 573 6.1.5. Interface Alarm 575 Interface is the network interface for connecting a device with the 576 network. The interface-alarm is emitted when the state of the 577 interface is changed. The following information should be included 578 in an Interface Alarm: 580 * event-name: interface-alarm. 582 * interface-name: The name of the interface. 584 * interface-state: The status of the interface, i.e., down, up (not 585 congested), congested (up but congested), testing, unknown, 586 dormant, not-present, and lower-layer-down. 588 * severity: The severity level of the message. There are four 589 levels, i.e., critical, high, middle, and low. 591 * message: Simple information as a human readable text string such 592 as "The interface is 'interface-state'" or with extra information. 594 6.2. System Events 596 System events (as alerts) have the following characteristics: 598 * acquisition-method: subscription 600 * emission-type: on-change 602 * dampening-type: on-repetition or no-dampening 604 6.2.1. Access Violation 606 The access-violation system event is an event when a user tries to 607 access (read, write, create, or delete) any information or execute 608 commands above their privilege. The following information should be 609 included in this event: 611 * event-name: access-violation. 613 * identity: The information to identify the attempted access 614 violation. The minimum information (extensible) that should be 615 included: 617 1. user: The unique username that attempted access violation. 619 2. group: Group(s) to which a user belongs. A user can belong to 620 multiple groups. 622 3. ip-address: The IP address of the user that triggered the 623 event. 625 4. l4-port-number: The transport layer port number used by the 626 user. 628 * authentication: The method to verify the valid user, i.e., pre- 629 configured-key and certificate-authority. 631 * message: The message as a human readable text string to give the 632 context of the event, such as "Access is denied". 634 6.2.2. Configuration Change 636 A configuration change is a system event when a new configuration is 637 added or an existing configuration is modified. The following 638 information should be included in this event: 640 * event-name: configuration-change. 642 * identity: The information to identify the user that updated the 643 configuration. The minimum information (extensible) that should 644 be included: 646 1. user: The unique username that changes the configuration. 648 2. group: Group(s) to which a user belongs. A user can belong to 649 multiple groups. 651 3. ip-address: The IP address of the user that triggered the 652 event. 654 4. l4-port-number: The transport layer port number used by the 655 user. 657 * authentication: The method to verify the valid user, i.e., pre- 658 configured-key and certificate-authority. 660 * message: The message as a human readable text string to give the 661 context of the event, such as "Configuration is modified", "New 662 configuration is added", or "A configuration has been removed". 664 * changes: Describes the modification that was made to the 665 configuration. The minimum information that must be provided is 666 the name of the policy that has been altered (added, modified, or 667 removed). Other detailed information about the configuration 668 changes is up to the implementation. 670 6.2.3. Session Table Event 672 A session is defined as a connection (i.e., traffic flow) of a data 673 plane (e.g., TCP, UDP, and SCTP). Session Table Event is the event 674 triggered by the session table of an NSF. A session table holds the 675 information of the currently active sessions. The following 676 information should be included in a Session Table Event: 678 * event-name: detection-session-table. 680 * current-session: The number of concurrent sessions. 682 * maximum-session: The maximum number of sessions that the session 683 table can support. 685 * threshold: The threshold (in terms of an allowed number of 686 sessions) triggering the event. 688 * message: The message as a human readable text string to give the 689 context of the event, such as "The number of sessions exceeded the 690 table threshold". 692 6.2.4. Traffic Flows 694 Traffic flows need to be monitored because they might be used for 695 security attacks to the network. The following information should be 696 included in this event: 698 * event-name: traffic-flows. 700 * interface-name: The mnemonic name of the network interface 702 * interface-type: The type of a network interface such as an ingress 703 or egress interface. 705 * src-mac: The source MAC address of the traffic flow. This 706 information may or may not be included depending on the type of 707 traffic flow. For example, the information will be useful and 708 should be included if the traffic flows are traffic flows of Link 709 Layer Discovery Protocol (LLDP) [IEEE-802.1AB], Address Resolution 710 Protocol (ARP) for IPv4 [RFC0826], and Neighbor Discovery Protocol 711 (ND) for IPv6 [RFC4861]. 713 * dst-mac: The destination MAC address of the traffic flow. This 714 information may or may not be included depending on the type of 715 traffic flow. For example, the information will be useful and 716 should be included if the traffic flows are LLDP, ARP for IPv4, or 717 ND for IPv6 traffic flows. 719 * src-ip: The source IPv4 or IPv6 address of the traffic flow. 721 * dst-ip: The destination IPv4 or IPv6 address of the traffic flow. 723 * src-port: The transport layer source port number of the traffic 724 flow. 726 * dst-port: The transport layer destination port number of the 727 traffic flow. 729 * protocol: The protocol of the traffic flow. 731 * measurement-time: The duration of the measurement in seconds for 732 the arrival rate and arrival throughput of packets of a traffic 733 flow. These two metrics (i.e., arrival rate and arrival 734 throughput) are measured over the past measurement duration before 735 now. 737 * arrival-rate: Arrival rate of packets of the traffic flow in 738 packets per second measured over the past "measurement-time". 740 * arrival-throughput: Arrival rate of packets of the traffic flow in 741 bytes per second measured over the past "measurement-time". 743 Note that the NSF Monitoring Interface data model is focused on a 744 generic method to collect the monitoring information of systems and 745 NSFs including traffic flows related to security attacks and system 746 resource usages. On the other hand, IPFIX [RFC7011] is a standard 747 method to collect general information on traffic flows rather than 748 security. 750 6.3. NSF Events 752 The NSF events provide the event that is detected by a specific NSF 753 that supported a certain capability. This section only discusses the 754 monitoring data for the advanced NSFs discussed in 755 [I-D.ietf-i2nsf-capability-data-model]. The NSF events information 756 can be extended to support other types of NSF. NSF events have the 757 following characteristics: 759 * acquisition-method: subscription 760 * emission-type: on-change 762 * dampening-type: on-repetition or no-dampening 764 6.3.1. DDoS Detection 766 The following information should be included in a Denial-of-Service 767 (DoS) or Distributed Denial-of-Service (DDoS) Event: 769 * event-name: detection-ddos. 771 * attack-type: The type of DoS or DDoS Attack, i.e., SYN flood, ACK 772 flood, SYN-ACK flood, FIN/RST flood, TCP Connection flood, UDP 773 flood, ICMP flood, HTTPS flood, HTTP flood, DNS query flood, DNS 774 reply flood, SIP flood, TLS flood, and NTP amplification flood. 775 This can be extended with additional types of DoS or DDoS attack. 777 * attack-src-ip: The IP addresses of the source of the DDoS attack. 778 Note that not all IP addresses should be included but only limited 779 IP addresses are included to conserve the server resources. The 780 listed attacking IP addresses can be an arbitrary sampling of the 781 "top talkers", i.e., the attackers that send the highest amount of 782 traffic. 784 * attack-dst-ip: The destination IPv4 or IPv6 addresses of attack 785 traffic. It can hold multiple IPv4 or IPv6 addresses. 787 * attack-src-port: The transport layer source port numbers of the 788 attack traffic. Note that not all ports will have been seen on 789 all the corresponding source IP addresses. 791 * attack-dst-port: The transport layer destination port numbers that 792 the attack traffic aims at. Note that not all ports will have 793 been seen on all the corresponding destination IP addresses. 795 * start-time: The time stamp indicating when the attack started. 796 The time format used is following the rules in Section 5.6 of 797 [RFC3339]. 799 * end-time: The time stamp indicating when the attack ended. If the 800 attack is still ongoing when sending out the notification, this 801 field can be empty. The time format used is following the rules 802 in Section 5.6 of [RFC3339]. 804 * attack-rate: The packets per second of attack traffic. 806 * attack-throughput: The bytes per second of attack traffic. 808 * rule-name: The name of the I2NSF Policy Rule being triggered. 809 Note that rule-name is used to match a detected NSF event with a 810 policy rule in [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 812 6.3.2. Virus Event 814 This information is used when a virus is detected within a traffic 815 flow or inside a host. Note that "malware" is a more generic word 816 for malicious software, including virus and worm. In the document, 817 "virus" is used to represent "malware" such that they are 818 interchangeable. The following information should be included in a 819 Virus Event: 821 * event-name: detection-virus. 823 * virus-name: Name of the virus. 825 * virus-type: Type of the virus. e.g., trojan, worm, and macro 826 virus. 828 * The following information is used only when the virus is detected 829 within the traffic flow and not yet attacking the host: 831 - dst-ip: The destination IP address of the flow where the virus 832 is found. 834 - src-ip: The source IP address of the flow where the virus is 835 found. 837 - src-port: The source port of the flow where the virus is found. 839 - dst-port: The destination port of the flow where the virus is 840 found. 842 * The following information is used only when the virus is detected 843 within a host system: 845 - host: The name or IP address of the host/device that is 846 infected by the virus. If the given name is not an IP address, 847 the name can be an arbitrary string including a FQDN (Fully 848 Qualified Domain Name). The name MUST be unique in the scope 849 of management domain for identifying the device that has been 850 infected with a virus. 852 - os: The operating system of the host that has the virus. 854 - file-type: The type of file (indicated by the file's suffix, 855 e.g., .exe) virus code is found in (if applicable). 857 - file-name: The name of the file where the virus is hidden. 859 * rule-name: The name of the rule being triggered. 861 Note "host" is used only when the virus is detected within a host 862 itself. Thus, the traffic flow information such as the source and 863 destination IP addresses is not important, so the elements of the 864 traffic flow (i.e., dst-ip, src-ip, src-port, and dst-port) are not 865 specified above. On the other hand, when the virus is detected 866 within a traffic flow and not yet attacking a host, the element of 867 "host" is not specified above. 869 6.3.3. Intrusion Event 871 The following information should be included in an Intrusion Event: 873 * event-name: detection-intrusion. 875 * attack-type: Attack type, e.g., brutal force or buffer overflow. 877 * src-ip: The source IP address of the flow. 879 * dst-ip: The destination IP address of the flow. 881 * src-port: The source port number of the flow. 883 * dst-port: The destination port number of the flow 885 * protocol: The employed transport layer protocol. e.g., TCP or UDP. 886 Note that QUIC protocol [RFC9000] is excluded in the data model as 887 it is not considered in the initial I2NSF documents [RFC8329]. 888 The QUIC traffic should not be treated as generic UDP traffic and 889 will be considered in the future I2NSF documents. 891 * app: The employed application layer protocol. e.g., HTTP or FTP. 893 * rule-name: The name of the I2NSF Policy Rule being triggered. 895 6.3.4. Web Attack Event 897 The following information should be included in a Web Attack Alarm: 899 * event-name: detection-web-attack. 901 * attack-type: Concrete web attack type. e.g., SQL injection, 902 command injection, XSS, or CSRF. 904 * src-ip: The source IP address of the packet. 906 * dst-ip: The destination IP address of the packet. 908 * src-port: The source port number of the packet. 910 * dst-port: The destination port number of the packet. 912 * req-method: The HTTP method of the request. For instance, "PUT" 913 and "GET" in HTTP. 915 * req-target: The HTTP Request Target. 917 * response-code: The HTTP Response status code. 919 * cookies: The HTTP Cookie header field of the request from the user 920 agent. Note that though cookies have many historical infelicities 921 that degrade security and privacy, the Cookie and Set-Cookie 922 header fields are widely used on the Internet [RFC6265]. Thus, 923 the cookies information needs to be kept confidential and is NOT 924 RECOMMENDED to be included in the monitoring data unless the 925 information is absolutely necessary to help to enhance the 926 security of the network. 928 * req-host: The HTTP Host header field of the request. 930 * filtering-type: URL filtering type. e.g., deny-list, allow-list, 931 and unknown. 933 * rule-name: The name of the I2NSF Policy Rule being triggered. 935 6.3.5. VoIP/VoCN Event 937 The following information should be included in a VoIP (Voice over 938 Internet Protocol) and VoCN (Voice over Cellular Network, such as 939 Voice over LTE or 5G) Event: 941 * event-name: detection-voip-vocn 943 * source-voice-id: The detected source voice Call ID for VoIP and 944 VoCN that violates the policy. 946 * destination-voice-id: The destination voice Call ID for VoIP and 947 VoCN that violates the policy. 949 * user-agent: The user agent for VoIP and VoCN that violates the 950 policy. 952 * src-ip: The source IP address of the VoIP/VoCN. 954 * dst-ip: The destination IP address of the VoIP/VoCN. 956 * src-port: The source port number of the VoIP/VoCN. 958 * dst-port: The destination port number of VoIP/VoCN. 960 * rule-name: The name of the I2NSF Policy Rule being triggered. 962 6.4. System Logs 964 System log is a record that is used to monitor the activity of the 965 user on the NSF and the status of the NSF. System logs have the 966 following characteristics: 968 * acquisition-method: subscription or query 970 * emission-type: on-change or periodic 972 * dampening-type: on-repetition or no-dampening 974 6.4.1. Access Log 976 Access logs record administrators' login, logout, and operations on a 977 device. By analyzing them, some security vulnerabilities can be 978 identified. The following information should be included in an 979 operation report: 981 * identity: The information to identify the user. The minimum 982 information (extensible) that should be included: 984 1. user: The unique username that attempted access violation. 986 2. group: Group(s) to which a user belongs. A user can belong to 987 multiple groups. 989 3. ip-address: The IP address of the user that triggered the 990 event. 992 4. l4-port-number: The transport layer port number used by the 993 user. 995 * authentication: The method to verify the valid user, i.e., pre- 996 configured-key and certificate-authority. 998 * operation-type: The operation type that the administrator 999 executed, e.g., login, logout, configuration, and other. 1001 * input: The operation performed by a user after login. The 1002 operation is a command given by a user. 1004 * output: The result after executing the input. 1006 6.4.2. Resource Utilization Log 1008 Running reports record the device system's running status, which is 1009 useful for device monitoring. The following information should be 1010 included in running report: 1012 * system-status: The current system's running status. 1014 * cpu-usage: Specifies the aggregated CPU usage in percentage. 1016 * memory-usage: Specifies the memory usage in percentage. 1018 * disk-id: Specifies the disk ID to identify the storage disk. 1020 * disk-usage: Specifies the disk usage of disk-id in percentage. 1022 * disk-space-left: Specifies the available disk space left of disk- 1023 id in percentage. 1025 * session-number: Specifies total concurrent sessions. 1027 * process-number: Specifies total number of systems processes. 1029 * interface-id: Specifies the interface ID to identify the network 1030 interface. 1032 * in-traffic-rate: The total inbound data plane traffic rate in 1033 packets per second. 1035 * out-traffic-rate: The total outbound data plane traffic rate in 1036 packets per second. 1038 * in-traffic-throughput: The total inbound data plane traffic 1039 throughput in bytes per second. 1041 * out-traffic-throughput: The total outbound data plane traffic 1042 throughput in bytes per second. 1044 Note that "traffic" includes only the data plane since the monitoring 1045 interface focuses on the monitoring of traffic flows for 1046 applications, rather than the control plane. In the document, 1047 "packet" includes a layer-2 frame, so "packet" and "frame" are 1048 interchangeable. Also, note that system resources (e.g., CPU, 1049 memory, disk, and interface) are monitored for the sake of security 1050 in NSFs even though they are common ones to be monitored by a generic 1051 Operations, Administration and Maintenance (OAM) protocol (or 1052 module). 1054 6.4.3. User Activity Log 1056 User activity logs provide visibility into users' online records 1057 (such as login time, online/lockout duration, and login IP addresses) 1058 and the actions that users perform. User activity reports are 1059 helpful to identify exceptions during a user's login and network 1060 access activities. This information should be included in a user's 1061 activity report: 1063 * identity: The information to identify the user. The minimum 1064 information (extensible) that should be included is as follows: 1066 1. user: The unique username that attempted access violation. 1068 2. group: Group(s) to which a user belongs. A user can belong to 1069 multiple groups. 1071 3. ip-address: The IP address of the user that triggered the 1072 event. 1074 4. l4-port-number: The transport layer port number used by the 1075 user. 1077 * authentication: The method to verify the valid user, i.e., pre- 1078 configured-key and certificate-authority. 1080 * online-duration: The duration of a user's activeness (stays in 1081 login) during a session. 1083 * logout-duration: The duration of a user's inactiveness (not in 1084 login) from the last session. 1086 * additional-info: Additional Information for login: 1088 1. type: User activities. e.g., Successful User Login, Failed 1089 Login attempts, User Logout, Successful User Password Change, 1090 Failed User Password Change, User Lockout, and User Unlocking. 1092 2. cause: Cause of a failed user activity. 1094 6.5. NSF Logs 1096 NSF logs have the folowing characteristics: 1098 * acquisition-method: subscription or query 1100 * emission-type: on-change 1102 * dampening-type: on-repetition or no-dampening 1104 6.5.1. Deep Packet Inspection Log 1106 Deep Packet Inspection (DPI) Logs provide statistics of transit 1107 traffic at an NSF such that the traffic includes uploaded and 1108 downloaded files/data, sent/received emails, and blocking/alert 1109 records on websites. It is helpful to learn risky user behaviors and 1110 why access to some URLs is blocked or allowed with an alert record. 1112 * attack-type: DPI action types. e.g., File Blocking, Data 1113 Filtering, and Application Behavior Control. 1115 * src-ip: The source IP address of the flow. 1117 * dst-ip: The destination IP address of the flow. 1119 * src-port: The source port number of the flow. 1121 * dst-port: The destination port number of the flow 1123 * rule-name: The name of the I2NSF Policy Rule being triggered. 1125 * action: Action defined in the file blocking rule, data filtering 1126 rule, or application behavior control rule that traffic matches. 1128 6.6. System Counter 1130 System counter has the following characteristics: 1132 * acquisition-method: subscription or query 1134 * emission-type: periodic 1136 * dampening-type: no-dampening 1138 6.6.1. Interface Counter 1140 Interface counters provide visibility into traffic into and out of an 1141 NSF, and bandwidth usage. 1143 * interface-name: Network interface name configured in NSF. 1145 * protocol: The type of network protocol (e.g., IPv4, IPv6, TCP, and 1146 UDP). If this field is empty, then the counter is used for all 1147 protocols. 1149 * measurement-time: The duration of the measurement in seconds for 1150 the calculation of statistics such as traffic rate and throughput. 1151 The statistic attributes are measured over the past measurement 1152 duration before now. 1154 * in-total-traffic-pkts: Total inbound packets. 1156 * out-total-traffic-pkts: Total outbound packets. 1158 * in-total-traffic-bytes: Total inbound bytes. 1160 * out-total-traffic-bytes: Total outbound bytes. 1162 * in-drop-traffic-pkts: Total inbound drop packets caused by a 1163 policy or hardware/resource error. 1165 * out-drop-traffic-pkts: Total outbound drop packets caused by a 1166 policy or hardware/resource error. 1168 * in-drop-traffic-bytes: Total inbound drop bytes caused by a policy 1169 or hardware/resource error. 1171 * out-drop-traffic-bytes: Total outbound drop bytes caused by a 1172 policy or hardware/resource error. 1174 * total-traffic: The total number of traffic packets (in and out) in 1175 the NSF. 1177 * in-traffic-average-rate: Inbound traffic average rate in packets 1178 per second. 1180 * in-traffic-peak-rate: Inbound traffic peak rate in packets per 1181 second. 1183 * in-traffic-average-throughput: Inbound traffic average throughput 1184 in bytes per second. 1186 * in-traffic-peak-throughput: Inbound traffic peak throughput in 1187 bytes per second. 1189 * out-traffic-average-rate: Outbound traffic average rate in packets 1190 per second. 1192 * out-traffic-peak-rate: Outbound traffic peak rate in packets per 1193 second. 1195 * out-traffic-average-throughput: Outbound traffic average 1196 throughput in bytes per second. 1198 * out-traffic-peak-throughput: Outbound traffic peak throughput in 1199 bytes per second. 1201 * discontinuity-time: The time of the most recent occasion at which 1202 any one or more of the counters suffered a discontinuity. If no 1203 such discontinuities have occurred since the last re- 1204 initialization of the local management subsystem, then this node 1205 contains the time the local management subsystem was re- 1206 initialized. The time format used is following the rules in 1207 Section 5.6 of [RFC3339]. 1209 6.7. NSF Counters 1211 NSF counters have the following characteristics: 1213 * acquisition-method: subscription or query 1215 * emission-type: periodic 1217 * dampening-type: no-dampening 1219 6.7.1. Firewall Counter 1221 Firewall counters provide visibility into traffic signatures and 1222 bandwidth usage that correspond to the policy that is configured in a 1223 firewall. 1225 * policy-name: Security policy name that traffic matches. 1227 * measurement-time: The duration of the measurement in seconds for 1228 the calculation of statistics such as traffic rate and throughput. 1229 The statistic attributes are measured over the past measurement 1230 duration before now. 1232 * in-interface: Inbound interface of traffic. 1234 * out-interface: Outbound interface of traffic. 1236 * total-traffic: The total number of traffic packets (in and out) in 1237 the firewall. 1239 * in-traffic-average-rate: Inbound traffic average rate in packets 1240 per second. 1242 * in-traffic-peak-rate: Inbound traffic peak rate in packets per 1243 second. 1245 * in-traffic-average-throughput: Inbound traffic average throughput 1246 in bytes per second. 1248 * in-traffic-peak-throughput: Inbound traffic peak throughput in 1249 bytes per second. 1251 * out-traffic-average-rate: Outbound traffic average rate in packets 1252 per second. 1254 * out-traffic-peak-rate: Outbound traffic peak rate in packets per 1255 second. 1257 * out-traffic-average-throughput: Outbound traffic average 1258 throughput in bytes per second. 1260 * out-traffic-peak-throughput: Outbound traffic peak throughput in 1261 bytes per second. 1263 * discontinuity-time: The time on the most recent occasion at which 1264 any one or more of the counters suffered a discontinuity. If no 1265 such discontinuities have occurred since the last re- 1266 initialization of the local management subsystem, then this node 1267 contains the time the local management subsystem was re- 1268 initialized. The time format used is following the rules in 1269 Section 5.6 of [RFC3339]. 1271 6.7.2. Policy Hit Counter 1273 Policy hit counters record the security policy that traffic matches 1274 and its hit count. That is, when a packet actually matches a policy, 1275 it should be added to the statistics of a "policy hit counter" of the 1276 policy. The "policy hit counter" provides the "policy-name" that 1277 matches the policy's name in the NSF-Facing Interface YANG data model 1278 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. It can check if policy 1279 configurations are correct or not. 1281 * policy-name: Security policy name that traffic matches. 1283 * hit-times: The number of times that the security policy matches 1284 the specified traffic. 1286 * discontinuity-time: The time on the most recent occasion at which 1287 any one or more of the counters suffered a discontinuity. If no 1288 such discontinuities have occurred since the last re- 1289 initialization of the local management subsystem, then this node 1290 contains the time the local management subsystem was re- 1291 initialized. The time format used is following the rules in 1292 Section 5.6 of [RFC3339]. 1294 7. YANG Tree Structure of NSF Monitoring YANG Module 1296 The tree structure of the NSF monitoring YANG module is provided 1297 below: 1299 module: ietf-i2nsf-monitoring-interface 1300 +--ro i2nsf-counters 1301 | +--ro vendor-name? string 1302 | +--ro device-model? string 1303 | +--ro software-version? string 1304 | +--ro nsf-name union 1305 | +--ro timestamp? yang:date-and-time 1306 | +--ro acquisition-method? identityref 1307 | +--ro emission-type? identityref 1308 | +--ro system-interface* [interface-name] 1309 | | +--ro interface-name if:interface-ref 1310 | | +--ro protocol? identityref 1311 | | +--ro in-total-traffic-pkts? yang:counter64 1312 | | +--ro out-total-traffic-pkts? yang:counter64 1313 | | +--ro in-total-traffic-bytes? uint64 1314 | | +--ro out-total-traffic-bytes? uint64 1315 | | +--ro in-drop-traffic-pkts? yang:counter64 1316 | | +--ro out-drop-traffic-pkts? yang:counter64 1317 | | +--ro in-drop-traffic-bytes? uint64 1318 | | +--ro out-drop-traffic-bytes? uint64 1319 | | +--ro discontinuity-time yang:date-and-time 1320 | | +--ro measurement-time? uint32 1321 | | +--ro total-traffic? yang:counter64 1322 | | +--ro in-traffic-average-rate? uint64 1323 | | +--ro in-traffic-peak-rate? uint64 1324 | | +--ro in-traffic-average-throughput? uint64 1325 | | +--ro in-traffic-peak-throughput? uint64 1326 | | +--ro out-traffic-average-rate? uint64 1327 | | +--ro out-traffic-peak-rate? uint64 1328 | | +--ro out-traffic-average-throughput? uint64 1329 | | +--ro out-traffic-peak-throughput? uint64 1330 | +--ro nsf-firewall* [policy-name] 1331 | | +--ro in-interface? if:interface-ref 1332 | | +--ro out-interface? if:interface-ref 1333 | | +--ro policy-name -> /i2nsfnfi:i2nsf-security-policy/name 1334 | | +--ro discontinuity-time yang:date-and-time 1335 | | +--ro measurement-time? uint32 1336 | | +--ro total-traffic? yang:counter64 1337 | | +--ro in-traffic-average-rate? uint64 1338 | | +--ro in-traffic-peak-rate? uint64 1339 | | +--ro in-traffic-average-throughput? uint64 1340 | | +--ro in-traffic-peak-throughput? uint64 1341 | | +--ro out-traffic-average-rate? uint64 1342 | | +--ro out-traffic-peak-rate? uint64 1343 | | +--ro out-traffic-average-throughput? uint64 1344 | | +--ro out-traffic-peak-throughput? uint64 1345 | +--ro nsf-policy-hits* [policy-name] 1346 | +--ro policy-name -> /i2nsfnfi:i2nsf-security-policy/name 1347 | +--ro discontinuity-time yang:date-and-time 1348 | +--ro hit-times? yang:counter64 1349 +--rw i2nsf-monitoring-configuration 1350 +--rw i2nsf-system-detection-alarm 1351 | +--rw enabled? boolean 1352 | +--rw system-alarm* [alarm-type] 1353 | +--rw alarm-type enumeration 1354 | +--rw threshold? uint8 1355 | +--rw dampening-period? centiseconds 1356 +--rw i2nsf-system-detection-event 1357 | +--rw enabled? boolean 1358 | +--rw dampening-period? centiseconds 1359 +--rw i2nsf-traffic-flows 1360 | +--rw dampening-period? centiseconds 1361 | +--rw enabled? boolean 1362 +--rw i2nsf-nsf-detection-ddos {i2nsf-nsf-detection-ddos}? 1363 | +--rw enabled? boolean 1364 | +--rw dampening-period? centiseconds 1365 +--rw i2nsf-nsf-detection-virus {i2nsf-nsf-detection-virus}? 1366 | +--rw enabled? boolean 1367 | +--rw dampening-period? centiseconds 1368 +--rw i2nsf-nsf-detection-session-table 1369 | +--rw enabled? boolean 1370 | +--rw dampening-period? centiseconds 1371 +--rw i2nsf-nsf-detection-intrusion 1372 {i2nsf-nsf-detection-intrusion}? 1373 | +--rw enabled? boolean 1374 | +--rw dampening-period? centiseconds 1375 +--rw i2nsf-nsf-detection-web-attack 1376 {i2nsf-nsf-detection-web-attack}? 1377 | +--rw enabled? boolean 1378 | +--rw dampening-period? centiseconds 1379 +--rw i2nsf-nsf-detection-voip-vocn 1380 {i2nsf-nsf-detection-voip-vocn}? 1381 | +--rw enabled? boolean 1382 | +--rw dampening-period? centiseconds 1383 +--rw i2nsf-nsf-system-access-log 1384 | +--rw enabled? boolean 1385 | +--rw dampening-period? centiseconds 1386 +--rw i2nsf-system-res-util-log 1387 | +--rw enabled? boolean 1388 | +--rw dampening-period? centiseconds 1389 +--rw i2nsf-system-user-activity-log 1390 | +--rw enabled? boolean 1391 | +--rw dampening-period? centiseconds 1392 +--rw i2nsf-nsf-log-dpi {i2nsf-nsf-log-dpi}? 1393 | +--rw enabled? boolean 1394 | +--rw dampening-period? centiseconds 1395 +--rw i2nsf-counter 1396 +--rw period? uint16 1398 notifications: 1399 +---n i2nsf-event 1400 | +--ro vendor-name? string 1401 | +--ro device-model? string 1402 | +--ro software-version? string 1403 | +--ro nsf-name union 1404 | +--ro message? string 1405 | +--ro language? string 1406 | +--ro acquisition-method? identityref 1407 | +--ro emission-type? identityref 1408 | +--ro dampening-type? identityref 1409 | +--ro (sub-event-type)? 1410 | +--:(i2nsf-system-detection-alarm) 1411 | | +--ro i2nsf-system-detection-alarm 1412 | | +--ro alarm-category? identityref 1413 | | +--ro component-name? string 1414 | | +--ro interface-name? if:interface-ref 1415 | | +--ro interface-state? enumeration 1416 | | +--ro severity? severity 1417 | | +--ro usage? uint8 1418 | | +--ro threshold? uint8 1419 | +--:(i2nsf-system-detection-event) 1420 | | +--ro i2nsf-system-detection-event 1421 | | +--ro event-category? identityref 1422 | | +--ro user string 1423 | | +--ro group* string 1424 | | +--ro ip-address inet:ip-address-no-zone 1425 | | +--ro l4-port-number inet:port-number 1426 | | +--ro authentication? identityref 1427 | | +--ro changes* [policy-name] 1428 | | +--ro policy-name 1429 -> /i2nsfnfi:i2nsf-security-policy/name 1431 | +--:(i2nsf-traffic-flows) 1432 | | +--ro i2nsf-traffic-flows 1433 | | +--ro interface-name? if:interface-ref 1434 | | +--ro interface-type? enumeration 1435 | | +--ro src-mac? yang:mac-address 1436 | | +--ro dst-mac? yang:mac-address 1437 | | +--ro src-ip? inet:ip-address-no-zone 1438 | | +--ro dst-ip? inet:ip-address-no-zone 1439 | | +--ro protocol? identityref 1440 | | +--ro src-port? inet:port-number 1441 | | +--ro dst-port? inet:port-number 1442 | | +--ro measurement-time? uint32 1443 | | +--ro arrival-rate? uint64 1444 | | +--ro arrival-throughput? uint64 1445 | +--:(i2nsf-nsf-detection-session-table) 1446 | +--ro i2nsf-nsf-detection-session-table 1447 | +--ro current-session? uint32 1448 | +--ro maximum-session? uint32 1449 | +--ro threshold? uint32 1450 +---n i2nsf-log 1451 | +--ro vendor-name? string 1452 | +--ro device-model? string 1453 | +--ro software-version? string 1454 | +--ro nsf-name union 1455 | +--ro message? string 1456 | +--ro language? string 1457 | +--ro acquisition-method? identityref 1458 | +--ro emission-type? identityref 1459 | +--ro dampening-type? identityref 1460 | +--ro (sub-logs-type)? 1461 | +--:(i2nsf-nsf-system-access-log) 1462 | | +--ro i2nsf-nsf-system-access-log 1463 | | +--ro user string 1464 | | +--ro group* string 1465 | | +--ro ip-address inet:ip-address-no-zone 1466 | | +--ro l4-port-number inet:port-number 1467 | | +--ro authentication? identityref 1468 | | +--ro operation-type? operation-type 1469 | | +--ro input? string 1470 | | +--ro output? string 1471 | +--:(i2nsf-system-res-util-log) 1472 | | +--ro i2nsf-system-res-util-log 1473 | | +--ro system-status? enumeration 1474 | | +--ro cpu-usage? uint8 1475 | | +--ro memory-usage? uint8 1476 | | +--ro disks* [disk-id] 1477 | | | +--ro disk-id string 1478 | | | +--ro disk-usage? uint8 1479 | | | +--ro disk-space-left? uint8 1480 | | +--ro session-num? uint32 1481 | | +--ro process-num? uint32 1482 | | +--ro interface* [interface-id] 1483 | | +--ro interface-id string 1484 | | +--ro in-traffic-rate? uint64 1485 | | +--ro out-traffic-rate? uint64 1486 | | +--ro in-traffic-throughput? uint64 1487 | | +--ro out-traffic-throughput? uint64 1488 | +--:(i2nsf-system-user-activity-log) 1489 | | +--ro i2nsf-system-user-activity-log 1490 | | +--ro user string 1491 | | +--ro group* string 1492 | | +--ro ip-address inet:ip-address-no-zone 1493 | | +--ro l4-port-number inet:port-number 1494 | | +--ro authentication? identityref 1495 | | +--ro online-duration? uint32 1496 | | +--ro logout-duration? uint32 1497 | | +--ro additional-info 1498 | | +--ro type? enumeration 1499 | | +--ro cause? string 1500 | +--:(i2nsf-nsf-log-dpi) {i2nsf-nsf-log-dpi}? 1501 | +--ro i2nsf-nsf-log-dpi 1502 | +--ro attack-type? identityref 1503 | +--ro src-ip? inet:ip-address-no-zone 1504 | +--ro src-port? inet:port-number 1505 | +--ro dst-ip? inet:ip-address-no-zone 1506 | +--ro dst-port? inet:port-number 1507 | +--ro rule-name 1508 -> /i2nsfnfi:i2nsf-security-policy/rules/name 1509 | +--ro action* identityref 1510 +---n i2nsf-nsf-event 1511 +--ro vendor-name? string 1512 +--ro device-model? string 1513 +--ro software-version? string 1514 +--ro nsf-name union 1515 +--ro message? string 1516 +--ro language? string 1517 +--ro acquisition-method? identityref 1518 +--ro emission-type? identityref 1519 +--ro dampening-type? identityref 1520 +--ro (sub-event-type)? 1521 +--:(i2nsf-nsf-detection-ddos) {i2nsf-nsf-detection-ddos}? 1522 | +--ro i2nsf-nsf-detection-ddos 1523 | +--ro attack-type? identityref 1524 | +--ro start-time yang:date-and-time 1525 | +--ro end-time? yang:date-and-time 1526 | +--ro attack-src-ip* inet:ip-address-no-zone 1527 | +--ro attack-dst-ip* inet:ip-address-no-zone 1528 | +--ro attack-src-port* inet:port-number 1529 | +--ro attack-dst-port* inet:port-number 1530 | +--ro rule-name 1531 -> /i2nsfnfi:i2nsf-security-policy/rules/name 1532 | +--ro attack-rate? uint64 1533 | +--ro attack-throughput? uint64 1534 +--:(i2nsf-nsf-detection-virus) 1535 {i2nsf-nsf-detection-virus}? 1536 | +--ro i2nsf-nsf-detection-virus 1537 | +--ro src-ip? inet:ip-address-no-zone 1538 | +--ro src-port? inet:port-number 1539 | +--ro dst-ip? inet:ip-address-no-zone 1540 | +--ro dst-port? inet:port-number 1541 | +--ro rule-name 1542 -> /i2nsfnfi:i2nsf-security-policy/rules/name 1543 | +--ro virus-name? string 1544 | +--ro virus-type? identityref 1545 | +--ro host? union 1546 | +--ro file-type? string 1547 | +--ro file-name? string 1548 | +--ro os? string 1549 +--:(i2nsf-nsf-detection-intrusion) 1550 {i2nsf-nsf-detection-intrusion}? 1551 | +--ro i2nsf-nsf-detection-intrusion 1552 | +--ro src-ip? inet:ip-address-no-zone 1553 | +--ro src-port? inet:port-number 1554 | +--ro dst-ip? inet:ip-address-no-zone 1555 | +--ro dst-port? inet:port-number 1556 | +--ro rule-name 1557 -> /i2nsfnfi:i2nsf-security-policy/rules/name 1558 | +--ro protocol? identityref 1559 | +--ro app? identityref 1560 | +--ro attack-type? identityref 1561 +--:(i2nsf-nsf-detection-web-attack) 1562 {i2nsf-nsf-detection-web-attack}? 1563 | +--ro i2nsf-nsf-detection-web-attack 1564 | +--ro src-ip? inet:ip-address-no-zone 1565 | +--ro src-port? inet:port-number 1566 | +--ro dst-ip? inet:ip-address-no-zone 1567 | +--ro dst-port? inet:port-number 1568 | +--ro rule-name 1569 -> /i2nsfnfi:i2nsf-security-policy/rules/name 1570 | +--ro attack-type? identityref 1571 | +--ro req-method? identityref 1572 | +--ro req-target? string 1573 | +--ro filtering-type* identityref 1574 | +--ro cookies? string 1575 | +--ro req-host? string 1576 | +--ro response-code? string 1577 +--:(i2nsf-nsf-detection-voip-vocn) 1578 {i2nsf-nsf-detection-voip-vocn}? 1579 +--ro i2nsf-nsf-detection-voip-vocn 1580 +--ro src-ip? inet:ip-address-no-zone 1581 +--ro src-port? inet:port-number 1582 +--ro dst-ip? inet:ip-address-no-zone 1583 +--ro dst-port? inet:port-number 1584 +--ro rule-name 1585 -> /i2nsfnfi:i2nsf-security-policy/rules/name 1586 +--ro source-voice-id* string 1587 +--ro destination-voice-id* string 1588 +--ro user-agent* string 1590 Figure 1: NSF Monitoring YANG Module Tree 1592 8. YANG Data Model of NSF Monitoring YANG Module 1594 This section describes a YANG module of I2NSF NSF Monitoring. The 1595 data model provided in this document uses identities to be used to 1596 get information of the monitored of an NSF's monitoring data. Every 1597 identity used in the document gives information or status about the 1598 current situation of an NSF. This YANG module imports from 1599 [RFC6991], [RFC8343], and [I-D.ietf-i2nsf-nsf-facing-interface-dm], 1600 and makes references to [RFC0768] [RFC0791] [RFC0792] [RFC0826] 1601 [RFC0854] [RFC1939] [RFC0959] [RFC2595] [RFC4340] [RFC4443] [RFC4861] 1602 [RFC5321] [RFC5646] [RFC6242] [RFC6265] [RFC8200] [RFC8641] [RFC9051] 1603 [I-D.ietf-httpbis-http2bis] [I-D.ietf-httpbis-messaging] 1604 [I-D.ietf-httpbis-semantics] [I-D.ietf-tcpm-rfc793bis] 1605 [I-D.ietf-tsvwg-rfc4960-bis] [IANA-HTTP-Status-Code] [IEEE-802.1AB] 1607 file "ietf-i2nsf-monitoring-interface@2022-05-23.yang" 1608 module ietf-i2nsf-monitoring-interface { 1609 yang-version 1.1; 1610 namespace 1611 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-monitoring-interface"; 1612 prefix 1613 i2nsfmi; 1614 import ietf-inet-types { 1615 prefix inet; 1616 reference 1617 "Section 4 of RFC 6991"; 1618 } 1619 import ietf-yang-types { 1620 prefix yang; 1621 reference 1622 "Section 3 of RFC 6991"; 1623 } 1624 import ietf-i2nsf-nsf-facing-interface { 1625 prefix i2nsfnfi; 1626 reference 1627 "Section 4.1 of draft-ietf-i2nsf-nsf-facing-interface-dm-28"; 1628 } 1629 import ietf-interfaces { 1630 prefix if; 1631 reference 1632 "Section 5 of RFC 8343"; 1633 } 1634 organization 1635 "IETF I2NSF (Interface to Network Security Functions) 1636 Working Group"; 1637 contact 1638 "WG Web: 1639 WG List: 1641 Editor: Jaehoon Paul Jeong 1642 1644 Editor: Patrick Lingga 1645 "; 1647 description 1648 "This module is a YANG module for I2NSF NSF Monitoring. 1650 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1651 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1652 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this 1653 document are to be interpreted as described in BCP 14 1654 (RFC 2119) (RFC 8174) when, and only when, they appear 1655 in all capitals, as shown here. 1657 Copyright (c) 2022 IETF Trust and the persons identified as 1658 authors of the code. All rights reserved. 1660 Redistribution and use in source and binary forms, with or 1661 without modification, is permitted pursuant to, and subject 1662 to the license terms contained in, the Revised BSD License 1663 set forth in Section 4.c of the IETF Trust's 1664 Legal Provisions Relating to IETF Documents 1665 (https://trustee.ietf.org/license-info). 1667 This version of this YANG module is part of RFC XXXX 1668 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 1669 for full legal notices."; 1671 revision "2022-05-23" { 1672 description "Latest revision"; 1673 reference 1674 "RFC XXXX: I2NSF NSF Monitoring Interface YANG Data Model"; 1676 // RFC Ed.: replace XXXX with an actual RFC number and remove 1677 // this note. 1678 } 1680 /* 1681 * Typedefs 1682 */ 1684 typedef severity { 1685 type enumeration { 1686 enum critical { 1687 description 1688 "The 'critical' severity level indicates that 1689 an immediate corrective action is required. 1690 A 'critical' severity is reported when a service 1691 becomes totally out of service and must be restored."; 1692 } 1693 enum high { 1694 description 1695 "The 'high' severity level indicates that 1696 an urgent corrective action is required. 1697 A 'high' severity is reported when there is 1698 a severe degradation in the capability of the 1699 service and its full capability must be restored."; 1700 } 1701 enum middle { 1702 description 1703 "The 'middle' severity level indicates the 1704 existence of a non-service-affecting fault 1705 condition and corrective action should be done 1706 to prevent a more serious fault. The 'middle' 1707 severity is reported when the detected problem 1708 is not degrading the capability of the service, but 1709 some service degradation might happen if not 1710 prevented."; 1711 } 1712 enum low { 1713 description 1714 "The 'low' severity level indicates the detection 1715 of a potential fault before any effect is observed. 1716 The 'low' severity is reported when an action should 1717 be done before a fault happen."; 1718 } 1720 } 1721 description 1722 "An indicator representing severity levels. The severity 1723 levels starting from the highest are critical, high, middle, 1724 and low."; 1725 } 1727 typedef operation-type { 1728 type enumeration { 1729 enum login { 1730 description 1731 "The operation type is Login."; 1732 } 1733 enum logout { 1734 description 1735 "The operation type is Logout."; 1736 } 1737 enum configuration { 1738 description 1739 "The operation type is Configuration. The configuration 1740 operation includes the command for writing a new 1741 configuration and modifying an existing configuration."; 1742 } 1743 enum other { 1744 description 1745 "The operation type is Other operation. This other 1746 includes all operations done by a user except login, 1747 logout, and configuration."; 1748 } 1749 } 1750 description 1751 "The type of operation done by a user during a session. 1752 The user operation is not considering their privileges."; 1753 } 1755 typedef login-role { 1756 type enumeration { 1757 enum administrator { 1758 description 1759 "Administrator (i.e., Superuser)'s login role. 1760 Non-restricted role."; 1761 } 1762 enum user { 1763 description 1764 "User login role. Semi-restricted role, some data and 1765 configurations are available but confidential or important 1766 data and configuration are restricted."; 1767 } 1768 enum guest { 1769 description 1770 "Guest login role. Restricted role, only few read data are 1771 available and write configurations are restricted."; 1772 } 1773 } 1774 description 1775 "The privilege level of the user account."; 1776 } 1778 typedef centiseconds { 1779 type uint32; 1780 description 1781 "A period of time, measured in units of 0.01 seconds."; 1782 } 1784 /* 1785 * Identity 1786 */ 1788 identity characteristics { 1789 description 1790 "Base identity for monitoring information 1791 characteristics"; 1792 } 1793 identity acquisition-method { 1794 base characteristics; 1795 description 1796 "The type of acquisition-method. It can be multiple 1797 types at once."; 1798 } 1799 identity subscription { 1800 base acquisition-method; 1801 description 1802 "The acquisition-method type is subscription."; 1803 } 1804 identity query { 1805 base acquisition-method; 1806 description 1807 "The acquisition-method type is query."; 1808 } 1809 identity emission-type { 1810 base characteristics; 1811 description 1812 "The type of emission-type."; 1813 } 1814 identity periodic { 1815 base emission-type; 1816 description 1817 "The emission-type type is periodic."; 1818 } 1819 identity on-change { 1820 base emission-type; 1821 description 1822 "The emission-type type is on-change."; 1823 } 1824 identity dampening-type { 1825 base characteristics; 1826 description 1827 "The type of message dampening to stop the rapid transmission 1828 of messages, such as on-repetition and no-dampening."; 1829 } 1830 identity no-dampening { 1831 base dampening-type; 1832 description 1833 "The dampening-type is no-dampening. No-dampening type does 1834 not limit the transmission for the messages of the same 1835 type."; 1836 } 1837 identity on-repetition { 1838 base dampening-type; 1839 description 1840 "The dampening-type is on-repetition. On-repetition type limits 1841 the transmitted on-change message to one message at a certain 1842 interval."; 1843 } 1845 identity authentication-mode { 1846 description 1847 "The authentication mode for a user to connect to the NSF, 1848 e.g., pre-configured-key and certificate-authority"; 1849 } 1850 identity pre-configured-key { 1851 base authentication-mode; 1852 description 1853 "The pre-configured-key is an authentication using a key 1854 authentication."; 1855 } 1856 identity certificate-authority { 1857 base authentication-mode; 1858 description 1859 "The certificate-authority (CA) is an authentication using a 1860 digital certificate."; 1861 } 1863 identity event { 1864 description 1865 "Base identity for I2NSF events."; 1866 } 1868 identity system-event { 1869 base event; 1870 description 1871 "Identity for system event"; 1872 } 1874 identity system-alarm { 1875 base event; 1876 description 1877 "Base identity for detectable system alarm types"; 1878 } 1880 identity memory-alarm { 1881 base system-alarm; 1882 description 1883 "Memory is the hardware to store information temporarily or for 1884 a short period, i.e., Random Access Memory (RAM). A 1885 memory-alarm is emitted when the memory usage is exceeding 1886 the threshold."; 1887 } 1888 identity cpu-alarm { 1889 base system-alarm; 1890 description 1891 "CPU is the Central Processing Unit that executes basic 1892 operations of the system. A cpu-alarm is emitted when the CPU 1893 usage is exceeding a threshold."; 1894 } 1895 identity disk-alarm { 1896 base system-alarm; 1897 description 1898 "Disk or storage is the hardware to store information for a 1899 long period, i.e., Hard Disk and Solid-State Drive. A 1900 disk-alarm is emitted when the disk usage is exceeding a 1901 threshold."; 1902 } 1903 identity hardware-alarm { 1904 base system-alarm; 1905 description 1906 "A hardware alarm is emitted when a hardware failure (e.g., 1907 CPU, memory, disk, or interface) is detected. A hardware 1908 failure is a malfunction within the electronic circuits or 1909 electromechanical components of the hardware that makes it 1910 unusable."; 1911 } 1912 identity interface-alarm { 1913 base system-alarm; 1914 description 1915 "Interface is the network interface for connecting a device 1916 with the network. The interface-alarm is emitted when the 1917 state of the interface is changed."; 1918 } 1920 identity access-violation { 1921 base system-event; 1922 description 1923 "Access-violation system event is an event when a user tries 1924 to access (read, write, create, or delete) any information or 1925 execute commands above their privilege (i.e., not-conformant 1926 with the access profile)."; 1927 } 1928 identity configuration-change { 1929 base system-event; 1930 description 1931 "The configuration-change system event is an event when a user 1932 adds a new configuration or modify an existing configuration 1933 (write configuration)."; 1934 } 1936 identity attack-type { 1937 description 1938 "The root ID of attack-based notification 1939 in the notification taxonomy"; 1940 } 1941 identity nsf-attack-type { 1942 base attack-type; 1943 description 1944 "This ID is intended to be used 1945 in the context of NSF event."; 1946 } 1948 identity virus-type { 1949 base nsf-attack-type; 1950 description 1951 "The type of virus. It can be multiple types at once. 1952 This attack type is associated with a detected 1953 system-log virus-attack."; 1954 } 1955 identity trojan { 1956 base virus-type; 1957 description 1958 "The virus type is a trojan. Trojan is able to disguise the 1959 intent of the files or programs to misleads the users."; 1961 } 1962 identity worm { 1963 base virus-type; 1964 description 1965 "The virus type is a worm. Worm can self-replicate and 1966 spread through the network automatically."; 1967 } 1968 identity macro { 1969 base virus-type; 1970 description 1971 "The virus type is a macro virus. Macro causes a series of 1972 threats automatically after the program is executed."; 1973 } 1974 identity boot-sector { 1975 base virus-type; 1976 description 1977 "The virus type is a boot sector virus. Boot sector is a virus 1978 that infects the core of the computer, affecting the startup 1979 process."; 1980 } 1981 identity polymorphic { 1982 base virus-type; 1983 description 1984 "The virus type is a polymorphic virus. Polymorphic can 1985 modify its version when it replicates, making it hard to 1986 detect."; 1987 } 1988 identity overwrite { 1989 base virus-type; 1990 description 1991 "The virus type is an overwrite virus. Overwrite can remove 1992 existing software and replace it with malicious code by 1993 overwriting it."; 1994 } 1995 identity resident { 1996 base virus-type; 1997 description 1998 "The virus-type is a resident virus. Resident saves itself in 1999 the computer's memory and infects other files and software."; 2000 } 2001 identity non-resident { 2002 base virus-type; 2003 description 2004 "The virus-type is a non-resident virus. Non-resident attaches 2005 directly to an executable file and enters the device when 2006 executed."; 2007 } 2008 identity multipartite { 2009 base virus-type; 2010 description 2011 "The virus-type is a multipartite virus. Multipartite attacks 2012 both the boot sector and executables files of a computer."; 2013 } 2014 identity spacefiller { 2015 base virus-type; 2016 description 2017 "The virus-type is a spacefiller virus. Spacefiller fills empty 2018 spaces of a file or software with malicious code."; 2019 } 2021 identity intrusion-attack-type { 2022 base nsf-attack-type; 2023 description 2024 "The attack type is associated with a detected 2025 system-log intrusion."; 2026 } 2027 identity brute-force { 2028 base intrusion-attack-type; 2029 description 2030 "The intrusion type is brute-force."; 2031 } 2032 identity buffer-overflow { 2033 base intrusion-attack-type; 2034 description 2035 "The intrusion type is buffer-overflow."; 2036 } 2037 identity web-attack-type { 2038 base nsf-attack-type; 2039 description 2040 "The attack type is associated with a detected 2041 system-log web-attack."; 2042 } 2043 identity command-injection { 2044 base web-attack-type; 2045 description 2046 "The detected web attack type is command injection."; 2047 } 2048 identity xss { 2049 base web-attack-type; 2050 description 2051 "The detected web attack type is Cross Site Scripting (XSS)."; 2052 } 2053 identity csrf { 2054 base web-attack-type; 2055 description 2056 "The detected web attack type is Cross Site Request Forgery."; 2058 } 2060 identity ddos-type { 2061 base nsf-attack-type; 2062 description 2063 "Base identity for detectable flood types"; 2064 } 2065 identity syn-flood { 2066 base ddos-type; 2067 description 2068 "A SYN flood is detected."; 2069 } 2070 identity ack-flood { 2071 base ddos-type; 2072 description 2073 "An ACK flood is detected."; 2074 } 2075 identity syn-ack-flood { 2076 base ddos-type; 2077 description 2078 "A SYN-ACK flood is detected."; 2079 } 2080 identity fin-rst-flood { 2081 base ddos-type; 2082 description 2083 "A FIN-RST flood is detected."; 2084 } 2085 identity tcp-con-flood { 2086 base ddos-type; 2087 description 2088 "A TCP connection flood is detected."; 2089 } 2090 identity udp-flood { 2091 base ddos-type; 2092 description 2093 "A UDP flood is detected."; 2094 } 2095 identity icmpv4-flood { 2096 base ddos-type; 2097 description 2098 "An ICMPv4 flood is detected."; 2099 } 2100 identity icmpv6-flood { 2101 base ddos-type; 2102 description 2103 "An ICMPv6 flood is detected."; 2104 } 2105 identity http-flood { 2106 base ddos-type; 2107 description 2108 "An HTTP flood is detected."; 2109 } 2110 identity https-flood { 2111 base ddos-type; 2112 description 2113 "An HTTPS flood is detected."; 2114 } 2115 identity dns-query-flood { 2116 base ddos-type; 2117 description 2118 "A Domain Name System (DNS) query flood is detected."; 2119 } 2120 identity dns-reply-flood { 2121 base ddos-type; 2122 description 2123 "A Domain Name System (DNS) reply flood is detected."; 2124 } 2125 identity sip-flood { 2126 base ddos-type; 2127 description 2128 "A Session Initiation Protocol (SIP) flood is detected."; 2129 } 2130 identity tls-flood { 2131 base ddos-type; 2132 description 2133 "A Transport Layer Security (TLS) flood is detected"; 2134 } 2135 identity ntp-amp-flood { 2136 base ddos-type; 2137 description 2138 "A Network Time Protocol (NTP) amplification is detected"; 2139 } 2141 identity req-method { 2142 description 2143 "A set of request types in HTTP (if applicable)."; 2144 } 2145 identity put { 2146 base req-method; 2147 description 2148 "The detected request type is PUT."; 2149 reference 2150 "draft-ietf-httpbis-semantics-19: HTTP Semantics 2151 - Request Method PUT"; 2152 } 2153 identity post { 2154 base req-method; 2155 description 2156 "The detected request type is POST."; 2157 reference 2158 "draft-ietf-httpbis-semantics-19: HTTP Semantics 2159 - Request Method POST"; 2160 } 2161 identity get { 2162 base req-method; 2163 description 2164 "The detected request type is GET."; 2165 reference 2166 "draft-ietf-httpbis-semantics-19: HTTP Semantics 2167 - Request Method GET"; 2168 } 2169 identity head { 2170 base req-method; 2171 description 2172 "The detected request type is HEAD."; 2173 reference 2174 "draft-ietf-httpbis-semantics-19: HTTP Semantics 2175 - Request Method HEAD"; 2176 } 2177 identity delete { 2178 base req-method; 2179 description 2180 "The detected request type is DELETE."; 2181 reference 2182 "draft-ietf-httpbis-semantics-19: HTTP Semantics 2183 - Request Method DELETE"; 2184 } 2185 identity connect { 2186 base req-method; 2187 description 2188 "The detected request type is CONNECT."; 2189 reference 2190 "draft-ietf-httpbis-semantics-19: HTTP Semantics 2191 - Request Method CONNECT"; 2192 } 2193 identity options { 2194 base req-method; 2195 description 2196 "The detected request type is OPTIONS."; 2197 reference 2198 "draft-ietf-httpbis-semantics-19: HTTP Semantics 2199 - Request Method OPTIONS"; 2200 } 2201 identity trace { 2202 base req-method; 2203 description 2204 "The detected request type is TRACE."; 2205 reference 2206 "draft-ietf-httpbis-semantics-19: HTTP Semantics 2207 - Request Method TRACE"; 2208 } 2210 identity filter-type { 2211 description 2212 "The type of filter used to detect an attack, 2213 for example, a web-attack. It can be applicable to 2214 more than web-attacks."; 2215 } 2216 identity allow-list { 2217 base filter-type; 2218 description 2219 "The applied filter type is an allow list. This filter blocks 2220 all connection except the specified list."; 2221 } 2222 identity deny-list { 2223 base filter-type; 2224 description 2225 "The applied filter type is a deny list. This filter opens all 2226 connection except the specified list."; 2227 } 2228 identity unknown-filter { 2229 base filter-type; 2230 description 2231 "The applied filter is unknown."; 2232 } 2234 identity dpi-type { 2235 description 2236 "Base identity for the type of Deep Packet Inspection (DPI)."; 2237 } 2238 identity file-blocking { 2239 base dpi-type; 2240 description 2241 "DPI for preventing the specified file types from flowing 2242 in the network."; 2243 } 2244 identity data-filtering { 2245 base dpi-type; 2246 description 2247 "DPI for preventing sensitive information (e.g., Credit 2248 Card Number or Social Security Numbers) leaving a 2249 protected network."; 2251 } 2252 identity application-behavior-control { 2253 base dpi-type; 2254 description 2255 "DPI for filtering packet based on the application or 2256 network behavior analysis to identify malicious or 2257 unusual activity."; 2258 } 2260 identity protocol { 2261 description 2262 "An identity used to enable type choices in leaves 2263 and leaf-lists with respect to protocol metadata. This is used 2264 to identify the type of protocol that goes through the NSF."; 2265 } 2266 identity ip { 2267 base protocol; 2268 description 2269 "General IP protocol type."; 2270 reference 2271 "RFC 791: Internet Protocol 2272 RFC 8200: Internet Protocol, Version 6 (IPv6)"; 2273 } 2274 identity ipv4 { 2275 base ip; 2276 description 2277 "IPv4 protocol type."; 2278 reference 2279 "RFC 791: Internet Protocol"; 2280 } 2281 identity ipv6 { 2282 base ip; 2283 description 2284 "IPv6 protocol type."; 2285 reference 2286 "RFC 8200: Internet Protocol, Version 6 (IPv6)"; 2287 } 2288 identity icmp { 2289 base protocol; 2290 description 2291 "Base identity for ICMPv4 and ICMPv6 condition capability"; 2292 reference 2293 "RFC 792: Internet Control Message Protocol 2294 RFC 4443: Internet Control Message Protocol (ICMPv6) 2295 for the Internet Protocol Version 6 (IPv6) Specification 2296 - ICMPv6"; 2297 } 2298 identity icmpv4 { 2299 base icmp; 2300 description 2301 "ICMPv4 protocol type."; 2302 reference 2303 "RFC 791: Internet Protocol 2304 RFC 792: Internet Control Message Protocol"; 2305 } 2306 identity icmpv6 { 2307 base icmp; 2308 description 2309 "ICMPv6 protocol type."; 2310 reference 2311 "RFC 8200: Internet Protocol, Version 6 (IPv6) 2312 RFC 4443: Internet Control Message Protocol (ICMPv6) 2313 for the Internet Protocol Version 6 (IPv6) 2314 Specification"; 2315 } 2316 identity transport-protocol { 2317 base protocol; 2318 description 2319 "Base identity for Layer 4 protocol condition capabilities, 2320 e.g., TCP, UDP, SCTP, DCCP, and ICMP"; 2321 } 2322 identity tcp { 2323 base transport-protocol; 2324 description 2325 "TCP protocol type."; 2326 reference 2327 "draft-ietf-tcpm-rfc793bis-25: Transmission Control Protocol 2328 (TCP) Specification"; 2329 } 2330 identity udp { 2331 base transport-protocol; 2332 description 2333 "UDP protocol type."; 2334 reference 2335 "RFC 768: User Datagram Protocol"; 2336 } 2337 identity sctp { 2338 base transport-protocol; 2339 description 2340 "Identity for SCTP condition capabilities"; 2341 reference 2342 "draft-ietf-tsvwg-rfc4960-bis-18: Stream Control Transmission 2343 Protocol"; 2344 } 2345 identity dccp { 2346 base transport-protocol; 2347 description 2348 "Identity for DCCP condition capabilities"; 2349 reference 2350 "RFC 4340: Datagram Congestion Control Protocol"; 2351 } 2352 identity application-protocol { 2353 base protocol; 2354 description 2355 "Base identity for Application protocol. Note that a subset of 2356 application protocols (e.g., HTTP, HTTPS, FTP, POP3, and 2357 IMAP) are handled in this YANG module, rather than all 2358 the existing application protocols."; 2359 } 2360 identity http { 2361 base application-protocol; 2362 description 2363 "The identity for Hypertext Transfer Protocol version 1.1 2364 (HTTP/1.1)."; 2365 reference 2366 "draft-ietf-httpbis-semantics-19: HTTP Semantics 2367 draft-ietf-httpbis-messaging-19: HTTP/1.1"; 2368 } 2369 identity https { 2370 base application-protocol; 2371 description 2372 "The identity for Hypertext Transfer Protocol version 1.1 2373 (HTTP/1.1) over TLS."; 2374 reference 2375 "draft-ietf-httpbis-semantics-19: HTTP Semantics 2376 draft-ietf-httpbis-messaging-19: HTTP/1.1"; 2377 } 2378 identity http2 { 2379 base application-protocol; 2380 description 2381 "The identity for Hypertext Transfer Protocol version 2 2382 (HTTP/2)."; 2383 reference 2384 "draft-ietf-httpbis-http2bis-07: HTTP/2"; 2385 } 2386 identity https2 { 2387 base application-protocol; 2388 description 2389 "The identity for Hypertext Transfer Protocol version 2 2390 (HTTP/2) over TLS."; 2391 reference 2392 "draft-ietf-httpbis-http2bis-07: HTTP/2"; 2393 } 2394 identity ftp { 2395 base application-protocol; 2396 description 2397 "FTP protocol type."; 2398 reference 2399 "RFC 959: File Transfer Protocol"; 2400 } 2401 identity ssh { 2402 base application-protocol; 2403 description 2404 "SSH protocol type."; 2405 reference 2406 "RFC 6242: Using the NETCONF Protocol over Secure Shell (SSH)"; 2407 } 2408 identity telnet { 2409 base application-protocol; 2410 description 2411 "The identity for telnet."; 2412 reference 2413 "RFC 854: Telnet Protocol"; 2414 } 2415 identity smtp { 2416 base application-protocol; 2417 description 2418 "The identity for smtp."; 2419 reference 2420 "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; 2421 } 2422 identity pop3 { 2423 base application-protocol; 2424 description 2425 "The identity for Post Office Protocol 3 (POP3)."; 2426 reference 2427 "RFC 1939: Post Office Protocol - Version 3 (POP3)"; 2428 } 2429 identity pop3s { 2430 base application-protocol; 2431 description 2432 "The identity for Post Office Protocol 3 (POP3) over TLS"; 2433 reference 2434 "RFC 1939: Post Office Protocol - Version 3 (POP3) 2435 RFC 2595: Using TLS with IMAP, POP3 and ACAP"; 2436 } 2437 identity imap { 2438 base application-protocol; 2439 description 2440 "The identity for Internet Message Access Protocol (IMAP)."; 2441 reference 2442 "RFC 9051: Internet Message Access Protocol (IMAP) - Version 2443 4rev2"; 2444 } 2445 identity imaps { 2446 base application-protocol; 2447 description 2448 "The identity for Internet Message Access Protocol (IMAP) over 2449 TLS"; 2450 reference 2451 "RFC 9051: Internet Message Access Protocol (IMAP) - Version 2452 4rev2 2453 RFC 2595: Using TLS with IMAP, POP3 and ACAP"; 2454 } 2456 /* 2457 * Grouping 2458 */ 2460 grouping timestamp { 2461 description 2462 "Grouping for identifying the time of the message."; 2463 leaf timestamp { 2464 type yang:date-and-time; 2465 description 2466 "Specify the time of a message being delivered."; 2467 } 2468 } 2470 grouping message { 2471 description 2472 "A set of common monitoring data that is needed 2473 as the basic information."; 2474 leaf message { 2475 type string; 2476 description 2477 "This is a freetext annotation for 2478 monitoring a notification's content."; 2479 } 2480 leaf language { 2481 type string { 2482 pattern '(([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})' 2483 + '{0,2})?|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})?' 2484 + '(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}' 2485 + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WY-Za-wy-z]' 2486 + '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]' 2487 + '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|' 2488 + '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-' 2489 + '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-' 2490 + '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-' 2491 + '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]' 2492 + '|[Ii]-[Hh][Aa][Kk]|' 2493 + '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|' 2494 + '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|' 2495 + '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|' 2496 + '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|' 2497 + '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|' 2498 + '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-' 2499 + '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-' 2500 + '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-' 2501 + '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|' 2502 + '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-' 2503 + '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|' 2504 + '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-' 2505 + '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-' 2506 + '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))'; 2507 } 2508 default "en-US"; 2509 description 2510 "The value in this field indicates the language tag 2511 used for the human readable fields (i.e., '../message', 2512 '/i2nsf-log/i2nsf-nsf-system-access-log/output', and 2513 '/i2nsf-log/i2nsf-system-user-activity-log/additional-info 2514 /cause'). 2515 The attribute is encoded following the rules in Section 2.1 2516 in RFC 5646. The default language tag is 'en-US'"; 2517 reference 2518 "RFC 5646: Tags for Identifying Languages"; 2519 } 2520 } 2522 grouping common-monitoring-data { 2523 description 2524 "A set of common monitoring data that is needed 2525 as the basic information."; 2527 leaf vendor-name { 2528 type string; 2529 description 2530 "The name of the NSF vendor. The string is unrestricted to 2531 identify the provider or vendor of the NSF."; 2532 } 2533 leaf device-model { 2534 type string; 2535 description 2536 "The model of the device, can be represented by the 2537 device model name or serial number. This field is used to 2538 identify the model of the device that provides the security 2539 service."; 2540 } 2541 leaf software-version { 2542 type string; 2543 description 2544 "The version of the software used to provide the security 2545 service"; 2546 } 2547 leaf nsf-name { 2548 type union { 2549 type string; 2550 type inet:ip-address-no-zone; 2551 } 2552 mandatory true; 2553 description 2554 "The name or IP address of the NSF generating the message. 2555 If the given nsf-name is not an IP address, the name can be 2556 an arbitrary string including a FQDN (Fully Qualified Domain 2557 Name). The name MUST be unique in the scope of management 2558 domain for a different NSF to identify the NSF that 2559 generates the message."; 2560 } 2561 } 2562 grouping characteristics { 2563 description 2564 "A set of characteristics of a monitoring information."; 2565 leaf acquisition-method { 2566 type identityref { 2567 base acquisition-method; 2568 } 2569 description 2570 "The acquisition-method for characteristics"; 2571 } 2572 leaf emission-type { 2573 when "derived-from-or-self(../acquisition-method, " 2574 + "'i2nsfmi:subscription')"; 2575 type identityref { 2576 base emission-type; 2577 } 2578 description 2579 "The emission-type for characteristics. This attribute is 2580 used only when the acquisition-method is a 'subscription'"; 2581 } 2582 } 2583 grouping characteristics-extended { 2584 description 2585 "An extended characteristics for the monitoring information."; 2586 uses characteristics; 2587 leaf dampening-type { 2588 type identityref { 2589 base dampening-type; 2590 } 2591 description 2592 "The dampening-type for characteristics"; 2593 } 2594 } 2595 grouping i2nsf-system-alarm-type-content { 2596 description 2597 "A set of contents for alarm type notification."; 2598 leaf usage { 2599 type uint8 { 2600 range "0..100"; 2601 } 2602 units "percent"; 2603 description 2604 "Specifies the used percentage"; 2605 } 2606 leaf threshold { 2607 type uint8 { 2608 range "0..100"; 2609 } 2610 units "percent"; 2611 description 2612 "The threshold percentage triggering the alarm or 2613 the event"; 2614 } 2615 } 2616 grouping i2nsf-system-event-type-content { 2617 description 2618 "System event metadata associated with system events 2619 caused by user activity. This can be extended to provide 2620 additional information."; 2621 leaf user { 2622 type string; 2623 mandatory true; 2624 description 2625 "The name of a user"; 2626 } 2627 leaf-list group { 2628 type string; 2629 min-elements 1; 2630 description 2631 "The group(s) to which a user belongs."; 2632 } 2633 leaf ip-address { 2634 type inet:ip-address-no-zone; 2635 mandatory true; 2636 description 2637 "The IPv4 or IPv6 address of a user that trigger the 2638 event."; 2639 } 2640 leaf l4-port-number { 2641 type inet:port-number; 2642 mandatory true; 2643 description 2644 "The transport layer port number used by the user."; 2645 } 2646 leaf authentication { 2647 type identityref { 2648 base authentication-mode; 2649 } 2650 description 2651 "The authentication-mode of a user."; 2652 } 2653 } 2654 grouping i2nsf-nsf-event-type-content { 2655 description 2656 "A set of common IPv4 or IPv6-related NSF event 2657 content elements"; 2658 leaf dst-ip { 2659 type inet:ip-address-no-zone; 2660 description 2661 "The destination IPv4 or IPv6 address of the packet"; 2662 } 2663 leaf dst-port { 2664 type inet:port-number; 2665 description 2666 "The destination port of the packet"; 2667 } 2668 leaf rule-name { 2669 type leafref { 2670 path 2671 "/i2nsfnfi:i2nsf-security-policy" 2672 +"/i2nsfnfi:rules/i2nsfnfi:name"; 2673 } 2674 mandatory true; 2675 description 2676 "The name of the I2NSF Policy Rule being triggered"; 2677 } 2678 } 2679 grouping i2nsf-nsf-event-type-content-extend { 2680 description 2681 "A set of extended common IPv4 or IPv6 related NSF 2682 event content elements"; 2684 leaf src-ip { 2685 type inet:ip-address-no-zone; 2686 description 2687 "The source IPv4 or IPv6 address of the packet or flow"; 2688 } 2689 leaf src-port { 2690 type inet:port-number; 2691 description 2692 "The source port of the packet or flow"; 2693 } 2694 uses i2nsf-nsf-event-type-content; 2695 } 2696 grouping action { 2697 description 2698 "A grouping for action."; 2699 leaf-list action { 2700 type identityref { 2701 base i2nsfnfi:ingress-action; 2702 } 2703 description 2704 "Action type: pass, drop, reject, mirror, or rate limit"; 2705 } 2706 } 2707 grouping attack-rates { 2708 description 2709 "A set of traffic rates for monitoring attack traffic 2710 data"; 2711 leaf attack-rate { 2712 type uint64; 2713 units "pps"; 2714 description 2715 "The average packets per second (pps) rate of attack 2716 traffic"; 2717 } 2718 leaf attack-throughput { 2719 type uint64; 2720 units "Bps"; 2721 description 2722 "The average bytes per second (Bps) throughput of attack 2723 traffic"; 2724 } 2725 } 2726 grouping traffic-rates { 2727 description 2728 "A set of traffic rates for statistics data"; 2729 leaf discontinuity-time { 2730 type yang:date-and-time; 2731 mandatory true; 2732 description 2733 "The time on the most recent occasion at which any one or 2734 more of the counters suffered a discontinuity. 2735 If no such discontinuities have occurred since the last 2736 re-initialization of the local management subsystem, then 2737 this node contains the time the local management subsystem 2738 was re-initialized."; 2739 } 2740 leaf measurement-time { 2741 type uint32; 2742 units "seconds"; 2743 description 2744 "The time of the measurement in seconds for the 2745 calculation of statistics such as traffic rate and 2746 throughput. The statistic attributes are measured over 2747 the past measurement duration before now."; 2748 } 2749 leaf total-traffic { 2750 type yang:counter64; 2751 units "packets"; 2752 description 2753 "The total number of traffic packets (in and out) in the 2754 NSF."; 2755 } 2756 leaf in-traffic-average-rate { 2757 type uint64; 2758 units "pps"; 2759 description 2760 "Inbound traffic average rate in packets per second (pps). 2761 The average is calculated from the start of the NSF service 2762 until the generation of this record."; 2763 } 2764 leaf in-traffic-peak-rate { 2765 type uint64; 2766 units "pps"; 2767 description 2768 "Inbound traffic peak rate in packets per second (pps)."; 2769 } 2770 leaf in-traffic-average-throughput { 2771 type uint64; 2772 units "Bps"; 2773 description 2774 "Inbound traffic average throughput in bytes per second 2775 (Bps). The average is calculated from the start of the NSF 2776 service until the generation of this record."; 2777 } 2778 leaf in-traffic-peak-throughput { 2779 type uint64; 2780 units "Bps"; 2781 description 2782 "Inbound traffic peak throughput in bytes per second (Bps)."; 2783 } 2784 leaf out-traffic-average-rate { 2785 type uint64; 2786 units "pps"; 2787 description 2788 "Outbound traffic average rate in packets per second (pps). 2789 The average is calculated from the start of the NSF service 2790 until the generation of this record."; 2791 } 2792 leaf out-traffic-peak-rate { 2793 type uint64; 2794 units "pps"; 2795 description 2796 "Outbound traffic peak rate in packets per second (pps)."; 2797 } 2798 leaf out-traffic-average-throughput { 2799 type uint64; 2800 units "Bps"; 2801 description 2802 "Outbound traffic average throughput in bytes per second 2803 (Bps). The average is calculated from the start of the NSF 2804 service until the generation of this record."; 2805 } 2806 leaf out-traffic-peak-throughput { 2807 type uint64; 2808 units "Bps"; 2809 description 2810 "Outbound traffic peak throughput in bytes per second 2811 (Bps)."; 2812 } 2813 } 2814 grouping i2nsf-system-counter-type-content { 2815 description 2816 "A set of counters for an interface traffic data."; 2817 leaf interface-name { 2818 type if:interface-ref; 2819 description 2820 "Network interface name configured in an NSF"; 2821 reference 2822 "RFC 8343: A YANG Data Model for Interface Management"; 2823 } 2824 leaf protocol { 2825 type identityref { 2826 base protocol; 2827 } 2828 description 2829 "The type of network protocol for the interface counter. 2830 If this field is empty, then the counter includes all 2831 protocols (e.g., IPv4, IPv6, TCP, and UDP)"; 2832 } 2833 leaf in-total-traffic-pkts { 2834 type yang:counter64; 2835 description 2836 "Total inbound packets"; 2837 } 2838 leaf out-total-traffic-pkts { 2839 type yang:counter64; 2840 description 2841 "Total outbound packets"; 2842 } 2843 leaf in-total-traffic-bytes { 2844 type uint64; 2845 units "bytes"; 2846 description 2847 "Total inbound bytes"; 2848 } 2849 leaf out-total-traffic-bytes { 2850 type uint64; 2851 units "bytes"; 2852 description 2853 "Total outbound bytes"; 2854 } 2855 leaf in-drop-traffic-pkts { 2856 type yang:counter64; 2857 description 2858 "Total inbound drop packets"; 2859 } 2860 leaf out-drop-traffic-pkts { 2861 type yang:counter64; 2862 description 2863 "Total outbound drop packets"; 2864 } 2865 leaf in-drop-traffic-bytes { 2866 type uint64; 2867 units "bytes"; 2868 description 2869 "Total inbound drop bytes"; 2870 } 2871 leaf out-drop-traffic-bytes { 2872 type uint64; 2873 units "bytes"; 2874 description 2875 "Total outbound drop bytes"; 2877 } 2878 uses traffic-rates; 2879 } 2881 grouping i2nsf-nsf-counters-type-content { 2882 description 2883 "A set of contents of a policy in an NSF."; 2884 leaf policy-name { 2885 type leafref { 2886 path 2887 "/i2nsfnfi:i2nsf-security-policy" 2888 +"/i2nsfnfi:name"; 2889 } 2890 mandatory true; 2891 description 2892 "The name of the policy being triggered"; 2893 } 2894 } 2896 grouping enable-notification { 2897 description 2898 "A grouping for enabling or disabling notification"; 2899 leaf enabled { 2900 type boolean; 2901 default "true"; 2902 description 2903 "Enables or Disables the notification. 2904 If 'true', then the notification is enabled. 2905 If 'false, then the notification is disabled."; 2906 } 2907 } 2909 grouping dampening { 2910 description 2911 "A grouping for dampening period of notification."; 2912 leaf dampening-period { 2913 type centiseconds; 2914 default "0"; 2915 description 2916 "Specifies the minimum interval between the assembly of 2917 successive update records for a single receiver of a 2918 subscription. Whenever subscribed objects change and 2919 a dampening-period interval (which may be zero) has 2920 elapsed since the previous update record creation for 2921 a receiver, any subscribed objects and properties 2922 that have changed since the previous update record 2923 will have their current values marshalled and placed 2924 in a new update record. But if the subscribed objects change 2925 when the dampening-period is active, it should update the 2926 record without sending the notification until the dampening- 2927 period is finished. If multiple changes happen during the 2928 active dampening-period, it should update the record with 2929 the latest data. And at the end of the dampening-period, it 2930 should send the record as a notification with the latest 2931 updated record and restart the countdown."; 2932 reference 2933 "RFC 8641: Subscription to YANG Notifications for 2934 Datastore Updates - Section 5."; 2935 } 2936 } 2938 /* 2939 * Feature Nodes 2940 */ 2942 feature i2nsf-nsf-detection-ddos { 2943 description 2944 "This feature means it supports I2NSF nsf-detection-ddos 2945 notification"; 2946 } 2947 feature i2nsf-nsf-detection-virus { 2948 description 2949 "This feature means it supports I2NSF nsf-detection-virus 2950 notification"; 2951 } 2952 feature i2nsf-nsf-detection-intrusion { 2953 description 2954 "This feature means it supports I2NSF nsf-detection-intrusion 2955 notification"; 2956 } 2957 feature i2nsf-nsf-detection-web-attack { 2958 description 2959 "This feature means it supports I2NSF nsf-detection-web-attack 2960 notification"; 2961 } 2962 feature i2nsf-nsf-detection-voip-vocn { 2963 description 2964 "This feature means it supports I2NSF nsf-detection-voip-vocn 2965 notification"; 2966 } 2967 feature i2nsf-nsf-log-dpi { 2968 description 2969 "This feature means it supports I2NSF nsf-log-dpi 2970 notification"; 2971 } 2972 /* 2973 * Notification nodes 2974 */ 2976 notification i2nsf-event { 2977 description 2978 "Notification for I2NSF Event. This notification provides 2979 general information that can be supported by most types of 2980 NSFs."; 2982 uses common-monitoring-data; 2983 uses message; 2984 uses characteristics-extended; 2986 choice sub-event-type { 2987 description 2988 "This choice must be augmented with cases for each allowed 2989 sub-event. Only 1 sub-event will be instantiated in each 2990 i2nsf-event message. Each case is expected to define one 2991 container with all the sub-event fields."; 2992 case i2nsf-system-detection-alarm { 2993 container i2nsf-system-detection-alarm { 2994 description 2995 "This notification is sent, when a system alarm 2996 is detected."; 2997 leaf alarm-category { 2998 type identityref { 2999 base system-alarm; 3000 } 3001 description 3002 "The alarm category for 3003 system-detection-alarm notification"; 3004 } 3005 leaf component-name { 3006 type string; 3007 description 3008 "The hardware component responsible for generating 3009 the message. Applicable for Hardware Failure 3010 Alarm."; 3011 } 3012 leaf interface-name { 3013 when "derived-from-or-self(../alarm-category, " 3014 + "'i2nsfmi:interface-alarm')"; 3015 type if:interface-ref; 3016 description 3017 "The interface name responsible for generating 3018 the message. Applicable for Network Interface 3019 Failure Alarm."; 3021 reference 3022 "RFC 8343: A YANG Data Model for Interface Management"; 3023 } 3024 leaf interface-state { 3025 when "derived-from-or-self(../alarm-category, " 3026 + "'i2nsfmi:interface-alarm')"; 3027 type enumeration { 3028 enum up { 3029 value 1; 3030 description 3031 "The interface state is up and not congested. 3032 The interface is ready to pass packets."; 3033 } 3034 enum down { 3035 value 2; 3036 description 3037 "The interface state is down, i.e., does not pass 3038 any packets."; 3039 } 3040 enum congested { 3041 value 3; 3042 description 3043 "The interface state is up but congested."; 3044 } 3045 enum testing { 3046 value 4; 3047 description 3048 "In some test mode. No operational packets can 3049 be passed."; 3050 } 3051 enum unknown { 3052 value 5; 3053 description 3054 "Status cannot be determined for some reason."; 3055 } 3056 enum dormant { 3057 value 6; 3058 description 3059 "Waiting for some external event."; 3060 } 3061 enum not-present { 3062 value 7; 3063 description 3064 "Some component (typically hardware) is missing."; 3065 } 3066 enum lower-layer-down { 3067 value 8; 3068 description 3069 "Down due to state of lower-layer interface(s)."; 3070 } 3071 } 3072 description 3073 "The state of the interface. Applicable for Network 3074 Interface Failure Alarm."; 3075 reference 3076 "RFC 8343: A YANG Data Model for Interface Management - 3077 Operational States"; 3078 } 3079 leaf severity { 3080 type severity; 3081 description 3082 "The severity of the alarm such as critical, high, 3083 middle, and low."; 3084 } 3085 uses i2nsf-system-alarm-type-content; 3086 } 3087 } 3089 case i2nsf-system-detection-event { 3090 container i2nsf-system-detection-event { 3091 description 3092 "This notification is sent when an event in the system is 3093 detected, such as access violation and configuration 3094 change"; 3095 leaf event-category { 3096 type identityref { 3097 base system-event; 3098 } 3099 description 3100 "The event category for system-detection-event"; 3101 } 3102 uses i2nsf-system-event-type-content; 3103 list changes { 3104 when "derived-from-or-self(../event-category, " 3105 + "'i2nsfmi:configuration-change')"; 3106 key policy-name; 3107 description 3108 "Describes the modification that was made to the 3109 configuration. This list is only applicable when the 3110 event is 'configuration-change'. 3111 The minimum information that must be provided is the 3112 name of the policy that has been altered (added, 3113 modified, or removed). 3114 This list can be extended with the detailed 3115 information about the specific changes made to the 3116 configuration based on the implementation."; 3118 leaf policy-name { 3119 type leafref { 3120 path 3121 "/i2nsfnfi:i2nsf-security-policy" 3122 +"/i2nsfnfi:name"; 3123 } 3124 description 3125 "The name of the policy configuration that has been 3126 added, modified, or removed."; 3127 } 3128 } 3129 } 3130 } 3132 case i2nsf-traffic-flows { 3133 container i2nsf-traffic-flows { 3134 description 3135 "This notification is sent to inform about the traffic 3136 flows."; 3137 leaf interface-name { 3138 type if:interface-ref; 3139 description 3140 "The mnemonic name of the network interface"; 3141 } 3142 leaf interface-type { 3143 type enumeration { 3144 enum ingress { 3145 description 3146 "The corresponding interface-name indicates an 3147 ingress interface."; 3148 } 3149 enum egress { 3150 description 3151 "The corresponding interface-name indicates an 3152 egress interface."; 3153 } 3154 } 3155 description 3156 "The type of a network interface such as an ingress or 3157 egress interface."; 3158 } 3159 leaf src-mac { 3160 type yang:mac-address; 3161 description 3162 "The source MAC address of the traffic flow. This 3163 information may or may not be included depending on 3164 the type of traffic flow. For example, the information 3165 will be useful and should be included if the traffic 3166 flows are traffic flows of Link Layer Discovery 3167 Protocol (LLDP), Address Resolution Protocol (ARP) for 3168 IPv4, and Neighbor Discovery Protocol (ND) for IPv6."; 3169 reference 3170 "IEEE-802.1AB: IEEE Standard for Local and metropolitan 3171 area networks - Station and Media Access Control 3172 Connectivity Discovery - Link Layer Discovery Protocol 3173 (LLDP) 3174 RFC 826: An Ethernet Address Resolution Protocol - 3175 Address Resolution Protocol (ARP) 3176 RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 3177 Neighbor Discovery Protocol (ND)"; 3178 } 3179 leaf dst-mac { 3180 type yang:mac-address; 3181 description 3182 "The destination MAC address of the traffic flow. This 3183 information may or may not be included depending on 3184 the type of traffic flow. For example, the information 3185 will be useful and should be included if the traffic 3186 flows are traffic flows of Link Layer Discovery 3187 Protocol (LLDP), Address Resolution Protocol (ARP) for 3188 IPv4, and Neighbor Discovery Protocol (ND) for IPv6."; 3189 reference 3190 "IEEE-802.1AB: IEEE Standard for Local and metropolitan 3191 area networks - Station and Media Access Control 3192 Connectivity Discovery - Link Layer Discovery Protocol 3193 (LLDP) 3194 RFC 826: An Ethernet Address Resolution Protocol - 3195 Address Resolution Protocol (ARP) 3196 RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - 3197 Neighbor Discovery Protocol (ND)"; 3198 } 3199 leaf src-ip { 3200 type inet:ip-address-no-zone; 3201 description 3202 "The source IPv4 or IPv6 address of the traffic flow"; 3203 } 3204 leaf dst-ip { 3205 type inet:ip-address-no-zone; 3206 description 3207 "The destination IPv4 or IPv6 address of the traffic 3208 flow"; 3209 } 3210 leaf protocol { 3211 type identityref { 3212 base protocol; 3213 } 3214 description 3215 "The protocol type of a traffic flow"; 3216 } 3217 leaf src-port { 3218 type inet:port-number; 3219 description 3220 "The transport layer source port number of the flow"; 3221 } 3222 leaf dst-port { 3223 type inet:port-number; 3224 description 3225 "The transport layer destination port number of the 3226 flow"; 3227 } 3228 leaf measurement-time { 3229 type uint32; 3230 units "seconds"; 3231 description 3232 "The duration of the measurement in seconds for the 3233 arrival rate and arrival throughput of packets of a 3234 traffic flow. These two metrics (i.e., arrival rate 3235 and arrival throughput) are measured over the past 3236 measurement duration before now."; 3237 } 3238 leaf arrival-rate { 3239 type uint64; 3240 units "pps"; 3241 description 3242 "The arrival rate of packets of the traffic flow in 3243 packets per second measured over the past 3244 'measurement-time'."; 3245 } 3246 leaf arrival-throughput { 3247 type uint64; 3248 units "Bps"; 3249 description 3250 "The arrival rate of packets of the traffic flow in 3251 bytes per second measured over the past 3252 'measurement-time'."; 3253 } 3254 } 3255 } 3257 case i2nsf-nsf-detection-session-table { 3258 container i2nsf-nsf-detection-session-table { 3259 description 3260 "This notification is sent, when a session table 3261 event is detected."; 3263 leaf current-session { 3264 type uint32; 3265 description 3266 "The number of concurrent sessions"; 3267 } 3268 leaf maximum-session { 3269 type uint32; 3270 description 3271 "The maximum number of sessions that the session 3272 table can support"; 3273 } 3274 leaf threshold { 3275 type uint32; 3276 description 3277 "The threshold triggering the event"; 3278 } 3279 } 3280 } 3281 } 3282 } 3284 notification i2nsf-log { 3285 description 3286 "Notification for I2NSF log. The notification is generated 3287 from the logs of the NSF."; 3289 uses common-monitoring-data; 3290 uses message; 3291 uses characteristics-extended; 3293 choice sub-logs-type { 3294 description 3295 "This choice must be augmented with cases for each allowed 3296 sub-logs. Only 1 sub-event will be instantiated in each 3297 i2nsf-logs message. Each case is expected to define one 3298 container with all the sub-logs fields."; 3299 case i2nsf-nsf-system-access-log { 3300 container i2nsf-nsf-system-access-log { 3301 description 3302 "The notification is sent, if there is a new system 3303 log entry about a system access event."; 3304 uses i2nsf-system-event-type-content; 3305 leaf operation-type { 3306 type operation-type; 3307 description 3308 "The operation type that the user executes"; 3309 } 3310 leaf input { 3311 type string; 3312 description 3313 "The operation performed by a user after login. The 3314 operation is a command given by a user."; 3315 } 3316 leaf output { 3317 type string; 3318 description 3319 "The result in text format after executing the 3320 input."; 3321 } 3322 } 3323 } 3325 case i2nsf-system-res-util-log { 3326 container i2nsf-system-res-util-log { 3327 description 3328 "This notification is sent, if there is a new log 3329 entry representing resource utilization updates."; 3330 leaf system-status { 3331 type enumeration { 3332 enum running { 3333 description 3334 "The system is active and running the security 3335 service."; 3336 } 3337 enum waiting { 3338 description 3339 "The system is active but waiting for an event to 3340 provide the security service."; 3341 } 3342 enum inactive { 3343 description 3344 "The system is inactive and not running the 3345 security service."; 3346 } 3347 } 3348 description 3349 "The current system's running status"; 3350 } 3351 leaf cpu-usage { 3352 type uint8; 3353 units "percent"; 3354 description 3355 "Specifies the relative percentage of CPU utilization 3356 with respect to platform resources"; 3357 } 3358 leaf memory-usage { 3359 type uint8; 3360 units "percent"; 3361 description 3362 "Specifies the percentage of memory usage."; 3363 } 3364 list disks { 3365 key disk-id; 3366 description 3367 "Disk is the hardware to store information for a 3368 long period, i.e., Hard Disk or Solid-State Drive."; 3369 leaf disk-id { 3370 type string; 3371 description 3372 "The ID of the storage disk. It is a free form 3373 identifier to identify the storage disk."; 3374 } 3375 leaf disk-usage { 3376 type uint8; 3377 units "percent"; 3378 description 3379 "Specifies the percentage of disk usage"; 3380 } 3381 leaf disk-space-left { 3382 type uint8; 3383 units "percent"; 3384 description 3385 "Specifies the percentage of disk space left"; 3386 } 3387 } 3388 leaf session-num { 3389 type uint32; 3390 description 3391 "The total number of sessions"; 3392 } 3393 leaf process-num { 3394 type uint32; 3395 description 3396 "The total number of processes"; 3397 } 3398 list interface { 3399 key interface-id; 3400 description 3401 "The network interface for connecting a device 3402 with the network."; 3403 leaf interface-id { 3404 type string; 3405 description 3406 "The ID of the network interface. It is a free form 3407 identifier to identify the network interface."; 3408 } 3409 leaf in-traffic-rate { 3410 type uint64; 3411 units "pps"; 3412 description 3413 "The total inbound traffic rate in packets per 3414 second"; 3415 } 3416 leaf out-traffic-rate { 3417 type uint64; 3418 units "pps"; 3419 description 3420 "The total outbound traffic rate in packets per 3421 second"; 3422 } 3423 leaf in-traffic-throughput { 3424 type uint64; 3425 units "Bps"; 3426 description 3427 "The total inbound traffic throughput in bytes per 3428 second"; 3429 } 3430 leaf out-traffic-throughput { 3431 type uint64; 3432 units "Bps"; 3433 description 3434 "The total outbound traffic throughput in bytes per 3435 second"; 3436 } 3437 } 3438 } 3439 } 3441 case i2nsf-system-user-activity-log { 3442 container i2nsf-system-user-activity-log { 3443 description 3444 "This notification is sent, if there is a new user 3445 activity log entry."; 3446 uses i2nsf-system-event-type-content; 3447 leaf online-duration { 3448 type uint32; 3449 units "seconds"; 3450 description 3451 "The duration of a user's activeness (stays in login) 3452 during a session."; 3453 } 3454 leaf logout-duration { 3455 type uint32; 3456 units "seconds"; 3457 description 3458 "The duration of a user's inactiveness (not in login) 3459 from the last session."; 3460 } 3461 container additional-info { 3462 leaf type { 3463 type enumeration { 3464 enum successful-login { 3465 description 3466 "The user has succeeded in login."; 3467 } 3468 enum failed-login { 3469 description 3470 "The user has failed in login (e.g., wrong 3471 password)"; 3472 } 3473 enum logout { 3474 description 3475 "The user has succeeded in logout"; 3476 } 3477 enum successful-password-changed { 3478 description 3479 "The password has been changed successfully"; 3480 } 3481 enum failed-password-changed { 3482 description 3483 "The attempt to change password has failed"; 3484 } 3485 enum lock { 3486 description 3487 "The user has been locked. A locked user cannot 3488 login."; 3489 } 3490 enum unlock { 3491 description 3492 "The user has been unlocked."; 3493 } 3494 } 3495 description 3496 "User activities, e.g., Successful User Login, 3497 Failed Login attempts, User Logout, Successful User 3498 Password Change, Failed User Password Change, User 3499 Lockout, User Unlocking, and Unknown."; 3500 } 3501 leaf cause { 3502 type string; 3503 description 3504 "The cause of a failed user activity related to the 3505 type of user activity. For example, when the 'type' 3506 is failed-login, the value of this attribute can be 3507 'Failed login attempt due to wrong password 3508 entry'."; 3509 } 3510 description 3511 "The additional information about user activity."; 3512 } 3513 } 3514 } 3515 case i2nsf-nsf-log-dpi { 3516 if-feature "i2nsf-nsf-log-dpi"; 3517 container i2nsf-nsf-log-dpi { 3518 description 3519 "This notification is sent, if there is a new DPI 3520 event in the NSF log."; 3521 leaf attack-type { 3522 type identityref { 3523 base dpi-type; 3524 } 3525 description 3526 "The type of the DPI"; 3527 } 3528 uses i2nsf-nsf-event-type-content-extend; 3529 uses action; 3530 } 3531 } 3532 } 3533 } 3535 notification i2nsf-nsf-event { 3536 description 3537 "Notification for I2NSF NSF Event. This notification provides 3538 specific information that can only be provided by an NSF 3539 that supports additional features (e.g., DDoS attack 3540 detection)."; 3542 uses common-monitoring-data; 3543 uses message; 3544 uses characteristics-extended; 3546 choice sub-event-type { 3547 description 3548 "This choice must be augmented with cases for each allowed 3549 sub-event. Only 1 sub-event will be instantiated in each 3550 i2nsf-event message. Each case is expected to define one 3551 container with all the sub-event fields."; 3552 case i2nsf-nsf-detection-ddos { 3553 if-feature "i2nsf-nsf-detection-ddos"; 3554 container i2nsf-nsf-detection-ddos { 3555 description 3556 "This notification is sent, when a specific flood type 3557 is detected."; 3558 leaf attack-type { 3559 type identityref { 3560 base ddos-type; 3561 } 3562 description 3563 "Any one of Syn flood, ACK flood, SYN-ACK flood, 3564 FIN/RST flood, TCP Connection flood, UDP flood, 3565 ICMP (i.e., ICMPv4 or ICMPv6) flood, HTTP flood, 3566 HTTPS flood, DNS query flood, DNS reply flood, SIP 3567 flood, etc."; 3568 } 3569 leaf start-time { 3570 type yang:date-and-time; 3571 mandatory true; 3572 description 3573 "The time stamp indicating when the attack started"; 3574 } 3575 leaf end-time { 3576 type yang:date-and-time; 3577 description 3578 "The time stamp indicating when the attack ended. If 3579 the attack is still undergoing when sending out the 3580 notification, this field can be omitted."; 3581 } 3582 leaf-list attack-src-ip { 3583 type inet:ip-address-no-zone; 3584 description 3585 "The source IPv4 or IPv6 addresses of attack 3586 traffic. It can hold multiple IPv4 or IPv6 3587 addresses. Note that all IP addresses should not be 3588 included, but only limited IP addresses are included 3589 to conserve the server resources. The listed attacking 3590 IP addresses can be an arbitrary sampling of the 3591 'top talkers', i.e., the attackers that send the 3592 highest amount of traffic."; 3593 } 3594 leaf-list attack-dst-ip { 3595 type inet:ip-address-no-zone; 3596 description 3597 "The destination IPv4 or IPv6 addresses of attack 3598 traffic. It can hold multiple IPv4 or IPv6 3599 addresses."; 3600 } 3601 leaf-list attack-src-port { 3602 type inet:port-number; 3603 description 3604 "The transport-layer source ports of the DDoS attack. 3605 Note that not all ports will have been seen on all the 3606 corresponding source IP addresses."; 3607 } 3608 leaf-list attack-dst-port { 3609 type inet:port-number; 3610 description 3611 "The transport-layer destination ports of the DDoS 3612 attack. Note that not all ports will have been seen 3613 on all the corresponding destination IP addresses."; 3614 } 3615 leaf rule-name { 3616 type leafref { 3617 path 3618 "/i2nsfnfi:i2nsf-security-policy" 3619 +"/i2nsfnfi:rules/i2nsfnfi:name"; 3620 } 3621 mandatory true; 3622 description 3623 "The name of the I2NSF Policy Rule being triggered"; 3624 } 3626 uses attack-rates; 3627 } 3628 } 3629 case i2nsf-nsf-detection-virus { 3630 if-feature "i2nsf-nsf-detection-virus"; 3631 container i2nsf-nsf-detection-virus { 3632 description 3633 "This notification is sent, when a virus is detected."; 3634 uses i2nsf-nsf-event-type-content-extend; 3635 leaf virus-name { 3636 type string; 3637 description 3638 "The name of the detected virus"; 3639 } 3640 leaf virus-type { 3641 type identityref { 3642 base virus-type; 3643 } 3644 description 3645 "The virus type of the detected virus"; 3646 } 3647 leaf host { 3648 type union { 3649 type string; 3650 type inet:ip-address-no-zone; 3651 } 3652 description 3653 "The name or IP address of the host/device. This is 3654 used to identify the host/device that is infected by 3655 the virus. If the given name is not an IP address, the 3656 name can be an arbitrary string including a FQDN 3657 (Fully Qualified Domain Name). The name MUST be unique 3658 in the scope of management domain for identifying the 3659 device that has been infected with a virus."; 3660 } 3661 leaf file-type { 3662 type string; 3663 description 3664 "The type of a file (indicated by the file's suffix, 3665 e.g., .exe) where virus code is found (if 3666 applicable)."; 3667 } 3668 leaf file-name { 3669 type string; 3670 description 3671 "The name of file virus code is found in (if 3672 applicable)."; 3673 } 3674 leaf os { 3675 type string; 3676 description 3677 "The operating system of the device."; 3678 } 3679 } 3680 } 3681 case i2nsf-nsf-detection-intrusion { 3682 if-feature "i2nsf-nsf-detection-intrusion"; 3683 container i2nsf-nsf-detection-intrusion { 3684 description 3685 "This notification is sent, when an intrusion event 3686 is detected."; 3687 uses i2nsf-nsf-event-type-content-extend; 3688 leaf protocol { 3689 type identityref { 3690 base transport-protocol; 3691 } 3692 description 3693 "The transport protocol type for 3694 nsf-detection-intrusion notification"; 3696 } 3697 leaf app { 3698 type identityref { 3699 base application-protocol; 3700 } 3701 description 3702 "The employed application layer protocol"; 3703 } 3704 leaf attack-type { 3705 type identityref { 3706 base intrusion-attack-type; 3707 } 3708 description 3709 "The sub attack type for intrusion attack"; 3710 } 3711 } 3712 } 3713 case i2nsf-nsf-detection-web-attack { 3714 if-feature "i2nsf-nsf-detection-web-attack"; 3715 container i2nsf-nsf-detection-web-attack { 3716 description 3717 "This notification is sent, when an attack event is 3718 detected."; 3719 uses i2nsf-nsf-event-type-content-extend; 3720 leaf attack-type { 3721 type identityref { 3722 base web-attack-type; 3723 } 3724 description 3725 "Concrete web attack type, e.g., SQL injection, 3726 command injection, XSS, and CSRF."; 3727 } 3728 leaf req-method { 3729 type identityref { 3730 base req-method; 3731 } 3732 description 3733 "The HTTP method of the request, e.g., PUT or GET."; 3734 reference 3735 "draft-ietf-httpbis-semantics-19: HTTP Semantics - 3736 Request Methods"; 3737 } 3738 leaf req-target { 3739 type string; 3740 description 3741 "The HTTP Request Target. This field can be filled in 3742 the format of origin-form, absolute-form, 3743 authority-form, or asterisk-form"; 3745 reference 3746 "draft-ietf-httpbis-messaging-19: HTTP/1.1 - Request 3747 Target"; 3748 } 3749 leaf-list filtering-type { 3750 type identityref { 3751 base filter-type; 3752 } 3753 description 3754 "URL filtering type, e.g., deny-list, allow-list, 3755 and Unknown"; 3756 } 3757 leaf cookies { 3758 type string; 3759 description 3760 "The HTTP Cookies header field of the request from 3761 the user agent. Note that though cookies have many 3762 historical infelicities that degrade security and 3763 privacy, the Cookie and Set-Cookie header fields are 3764 widely used on the Internet. Thus, the cookie 3765 information needs to be kept confidential and is NOT 3766 RECOMMENDED to be included in the monitoring data 3767 unless the information is absolutely necessary to help 3768 to enhance the security of the network."; 3769 reference 3770 "RFC 6265: HTTP State Management Mechanism - Cookie"; 3771 } 3772 leaf req-host { 3773 type string; 3774 description 3775 "The HTTP Host header field of the request"; 3776 reference 3777 "draft-ietf-httpbis-semantics-19: HTTP Semantics - Host"; 3778 } 3779 leaf response-code { 3780 type string; 3781 description 3782 "The HTTP Response status code"; 3783 reference 3784 "IANA Website: Hypertext Transfer Protocol (HTTP) 3785 Status Code Registry"; 3786 } 3787 } 3788 } 3789 case i2nsf-nsf-detection-voip-vocn { 3790 if-feature "i2nsf-nsf-detection-voip-vocn"; 3791 container i2nsf-nsf-detection-voip-vocn { 3792 description 3793 "This notification is sent, when a VoIP/VoCN violation 3794 is detected."; 3795 uses i2nsf-nsf-event-type-content-extend; 3796 leaf-list source-voice-id { 3797 type string; 3798 description 3799 "The detected source voice ID for VoIP and VoCN that 3800 violates the security policy."; 3801 } 3802 leaf-list destination-voice-id { 3803 type string; 3804 description 3805 "The detected destination voice ID for VoIP and VoCN 3806 that violates the security policy."; 3807 } 3808 leaf-list user-agent { 3809 type string; 3810 description 3811 "The detected user-agent for VoIP and VoCN that 3812 violates the security policy."; 3813 } 3814 } 3815 } 3816 } 3817 } 3818 /* 3819 * Data nodes 3820 */ 3821 container i2nsf-counters { 3822 config false; 3823 description 3824 "The state data representing continuous value changes of 3825 information elements that occur very frequently. The value 3826 should be calculated from the start of the service of the 3827 NSF."; 3829 uses common-monitoring-data; 3830 uses timestamp; 3831 uses characteristics; 3833 list system-interface { 3834 key interface-name; 3835 description 3836 "Interface counters provide the visibility of traffic into 3837 and out of an NSF, and bandwidth usage."; 3838 uses i2nsf-system-counter-type-content; 3839 } 3840 list nsf-firewall { 3841 key policy-name; 3842 description 3843 "Firewall counters provide visibility into traffic signatures 3844 and bandwidth usage that correspond to the policy that is 3845 configured in a firewall."; 3846 leaf in-interface { 3847 type if:interface-ref; 3848 description 3849 "Inbound interface of the traffic"; 3850 } 3851 leaf out-interface { 3852 type if:interface-ref; 3853 description 3854 "Outbound interface of the traffic"; 3855 } 3856 uses i2nsf-nsf-counters-type-content; 3857 uses traffic-rates; 3858 } 3859 list nsf-policy-hits { 3860 key policy-name; 3861 description 3862 "Policy hit counters record the number of hits that traffic 3863 packets match a security policy. It can check if policy 3864 configurations are correct or not."; 3865 uses i2nsf-nsf-counters-type-content; 3866 leaf discontinuity-time { 3867 type yang:date-and-time; 3868 mandatory true; 3869 description 3870 "The time on the most recent occasion at which any one or 3871 more of the counters suffered a discontinuity. If no such 3872 discontinuities have occurred since the last 3873 re-initialization of the local management subsystem, then 3874 this node contains the time the local management subsystem 3875 was re-initialized."; 3876 } 3877 leaf hit-times { 3878 type yang:counter64; 3879 description 3880 "The number of times that the security policy matches the 3881 specified traffic."; 3882 } 3883 } 3884 } 3886 container i2nsf-monitoring-configuration { 3887 description 3888 "The container for configuring I2NSF monitoring."; 3890 container i2nsf-system-detection-alarm { 3891 description 3892 "The container for configuring I2NSF system-detection-alarm 3893 notification"; 3894 uses enable-notification; 3895 list system-alarm { 3896 key alarm-type; 3897 description 3898 "Configuration for system alarm (i.e., CPU, Memory, and 3899 Disk Usage)"; 3900 leaf alarm-type { 3901 type enumeration { 3902 enum cpu { 3903 description 3904 "To configure the CPU usage threshold to trigger the 3905 cpu-alarm"; 3906 } 3907 enum memory { 3908 description 3909 "To configure the Memory usage threshold to trigger 3910 the memory-alarm"; 3911 } 3912 enum disk { 3913 description 3914 "To configure the Disk (storage) usage threshold to 3915 trigger the disk-alarm"; 3916 } 3917 } 3918 description 3919 "Type of alarm to be configured. The three alarm-types 3920 defined here are used to configure the threshold of the 3921 monitoring notification. The threshold is used to 3922 determine when the notification should be sent. 3923 The other two alarms defined in the module (i.e., 3924 hardware-alarm and interface-alarm) do not use any 3925 threshold value to create a notification. These alarms 3926 detect a failure or a change of state to create a 3927 notification."; 3928 } 3929 leaf threshold { 3930 type uint8 { 3931 range "1..100"; 3932 } 3933 units "percent"; 3934 description 3935 "The configuration for threshold percentage to trigger 3936 the alarm. The alarm will be triggered if the usage 3937 is exceeded the threshold."; 3939 } 3940 uses dampening; 3941 } 3942 } 3943 container i2nsf-system-detection-event { 3944 description 3945 "The container for configuring I2NSF system-detection-event 3946 notification"; 3947 uses enable-notification; 3948 uses dampening; 3949 } 3950 container i2nsf-traffic-flows { 3951 description 3952 "The container for configuring I2NSF traffic-flows 3953 notification"; 3954 uses dampening; 3955 uses enable-notification; 3956 } 3957 container i2nsf-nsf-detection-ddos { 3958 if-feature "i2nsf-nsf-detection-ddos"; 3959 description 3960 "The container for configuring I2NSF nsf-detection-ddos 3961 notification"; 3962 uses enable-notification; 3963 uses dampening; 3964 } 3965 container i2nsf-nsf-detection-virus { 3966 if-feature "i2nsf-nsf-detection-virus"; 3967 description 3968 "The container for configuring I2NSF nsf-detection-virus 3969 notification"; 3970 uses enable-notification; 3971 uses dampening; 3972 } 3973 container i2nsf-nsf-detection-session-table { 3974 description 3975 "The container for configuring I2NSF nsf-detection-session- 3976 table notification"; 3977 uses enable-notification; 3978 uses dampening; 3979 } 3980 container i2nsf-nsf-detection-intrusion { 3981 if-feature "i2nsf-nsf-detection-intrusion"; 3982 description 3983 "The container for configuring I2NSF nsf-detection-intrusion 3984 notification"; 3985 uses enable-notification; 3986 uses dampening; 3988 } 3989 container i2nsf-nsf-detection-web-attack { 3990 if-feature "i2nsf-nsf-detection-web-attack"; 3991 description 3992 "The container for configuring I2NSF nsf-detection-web-attack 3993 notification"; 3994 uses enable-notification; 3995 uses dampening; 3996 } 3997 container i2nsf-nsf-detection-voip-vocn { 3998 if-feature "i2nsf-nsf-detection-voip-vocn"; 3999 description 4000 "The container for configuring I2NSF nsf-detection-voip-vocn 4001 notification"; 4002 uses enable-notification; 4003 uses dampening; 4004 } 4005 container i2nsf-nsf-system-access-log { 4006 description 4007 "The container for configuring I2NSF system-access-log 4008 notification"; 4009 uses enable-notification; 4010 uses dampening; 4011 } 4012 container i2nsf-system-res-util-log { 4013 description 4014 "The container for configuring I2NSF system-res-util-log 4015 notification"; 4016 uses enable-notification; 4017 uses dampening; 4018 } 4019 container i2nsf-system-user-activity-log { 4020 description 4021 "The container for configuring I2NSF system-user-activity-log 4022 notification"; 4023 uses enable-notification; 4024 uses dampening; 4025 } 4026 container i2nsf-nsf-log-dpi { 4027 if-feature "i2nsf-nsf-log-dpi"; 4028 description 4029 "The container for configuring I2NSF nsf-log-dpi 4030 notification"; 4031 uses enable-notification; 4032 uses dampening; 4033 } 4034 container i2nsf-counter { 4035 description 4036 "This is used to configure the counters 4037 for monitoring an NSF"; 4038 leaf period { 4039 type uint16; 4040 units "minutes"; 4041 default 0; 4042 description 4043 "The configuration for the period interval of reporting 4044 the counter. If 0, then the counter period is disabled. 4045 If value is not 0, then the counter will be reported 4046 following the period value."; 4047 } 4048 } 4049 } 4050 } 4051 4053 Figure 2: Data Model of Monitoring 4055 9. I2NSF Event Stream 4057 This section discusses the NETCONF event stream for an I2NSF NSF 4058 Monitoring subscription. The YANG module in this document supports 4059 "ietf-subscribed-notifications" YANG module [RFC8639] for 4060 subscription. The reserved event stream name for this document is 4061 "I2NSF-Monitoring". The NETCONF Server (e.g., an NSF) MUST support 4062 "I2NSF-Monitoring" event stream for an NSF data collector (e.g., 4063 Security Controller). The "I2NSF-Monitoring" event stream contains 4064 all I2NSF events described in this document. 4066 The following XML example shows the capabilities of the event streams 4067 generated by an NSF (e.g., "NETCONF" and "I2NSF-Monitoring" event 4068 streams) for the subscription of an NSF data collector. Refer to 4069 [RFC5277] for more detailed explanation of Event Streams. The XML 4070 examples in this document follow the line breaks as per [RFC8792]. 4072 4073 4075 4076 4077 4078 4079 NETCONF 4080 Default NETCONF Event Stream 4081 false 4082 4083 4084 I2NSF-Monitoring 4085 I2NSF Monitoring Event Stream 4086 true 4087 4088 2021-04-29T09:37:39+00:00 4089 4090 4091 4092 4093 4094 4096 Figure 3: Example of NETCONF Server supporting I2NSF-Monitoring 4097 Event Stream 4099 10. XML Examples for I2NSF NSF Monitoring 4101 This section shows XML examples of I2NSF NSF Monitoring data 4102 delivered via Monitoring Interface from an NSF. The XML examples are 4103 following the guidelines from [RFC6241] [RFC7950]. 4105 10.1. I2NSF System Detection Alarm 4107 The following example shows an alarm triggered by Memory Usage on the 4108 server; this example XML file is delivered by an NSF to an NSF data 4109 collector: 4111 4112 4114 2021-04-29T07:43:52.181088+00:00 4115 4117 subscription 4118 on-change 4119 on-repetition 4120 en-US 4121 4122 memory-alarm 4123 91 4124 90 4125 Memory Usage Exceeded the Threshold 4126 time_based_firewall 4127 high 4128 4129 4130 4132 Figure 4: Example of I2NSF System Detection Alarm triggered by 4133 Memory Usage 4135 The XML data above shows: 4137 1. The NSF that sends the information is named 4138 "time_based_firewall". 4140 2. The memory usage of the NSF triggered the alarm. 4142 3. The monitoring information is received by subscription method. 4144 4. The monitoring information is emitted "on-change". 4146 5. The monitoring information is dampened "on-repetition". 4148 6. The memory usage of the NSF is 91 percent. 4150 7. The memory threshold to trigger the alarm is 90 percent. 4152 8. The severity level of the notification is high. 4154 10.2. I2NSF Interface Counters 4156 To get the I2NSF system interface counters information by query, 4157 NETCONF Client (e.g., NSF data collector) needs to initiate GET 4158 connection with NETCONF Server (e.g., NSF). The following XML file 4159 can be used to get the state data and filter the information. 4161 4162 4163 4164 4166 4167 4168 4169 4170 4171 4173 Figure 5: XML Example for NETCONF GET with System Interface Filter 4175 The following XML file shows the reply from the NETCONF Server (e.g., 4176 NSF): 4178 4179 4181 4182 4184 query 4185 4186 4187 2021-04-29T08:43:52.181088+00:00 4188 4189 ens3 4190 549050 4191 814956 4192 0 4193 5078 4194 time_based_firewall 4195 4196 4197 4198 2021-04-29T08:43:52.181088+00:00 4199 4200 lo 4201 48487 4202 48487 4203 0 4204 0 4205 time_based_firewall 4206 4207 4208 4209 4211 Figure 6: Example of I2NSF System Interface Counters XML Information 4213 11. IANA Considerations 4215 This document requests IANA to register the following URI in the 4216 "IETF XML Registry" [RFC3688]: 4218 URI: urn:ietf:params:xml:ns:yang:ietf-i2nsf-monitoring-interface 4219 Registrant Contact: The IESG. 4220 XML: N/A; the requested URI is an XML namespace. 4222 This document requests IANA to register the following YANG module in 4223 the "YANG Module Names" registry [RFC7950][RFC8525]: 4225 name: ietf-i2nsf-monitoring-interface 4226 namespace: urn:ietf:params:xml:ns:yang:ietf-i2nsf-monitoring-interface 4227 prefix: i2nsfmi 4228 reference: RFC XXXX 4230 // RFC Ed.: replace XXXX with an actual RFC number and remove 4231 // this note. 4233 12. Security Considerations 4235 The YANG module described in this document defines a schema for data 4236 that is designed to be accessed via network management protocols such 4237 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 4238 is the secure transport layer, and the required secure transport is 4239 Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, 4240 and the required secure transport is TLS [RFC8446]. 4242 The NETCONF access control model [RFC8341] provides a means of 4243 restricting access by specific NETCONF or RESTCONF users to a 4244 preconfigured subset of all available NETCONF or RESTCONF protocol 4245 operations and content. 4247 All data nodes defined in the YANG module which can be created, 4248 modified and deleted (i.e., config true, which is the default) are 4249 considered sensitive as they all could potentially impact security 4250 monitoring and mitigation activities. Write operations (e.g., edit- 4251 config) applied to these data nodes without proper protection could 4252 result in missed alarms or incorrect alarms information being 4253 returned to the NSF data collector. The following are threats that 4254 need to be considered and mitigated: 4256 Compromised NSF with valid credentials: It can send falsified 4257 information to the NSF data collector to mislead detection or 4258 mitigation activities; and/or to hide activity. Currently, there 4259 is no in-framework mechanism to mitigate this and it is an issue 4260 for all monitoring infrastructures. It is important to keep 4261 confidential information from unauthorized persons to mitigate the 4262 possibility of compromising the NSF with this information. 4264 Compromised NSF data collector with valid credentials: It has 4265 visibility to all collected security alarms; the entire detection 4266 and mitigation infrastructure may be suspect. It is important to 4267 keep confidential information from unauthorized persons to 4268 mitigate the possibility of compromising the NSF with this 4269 information. 4271 Impersonating NSF: This involves a system trying to send false 4272 information while imitating an NSF; client authentication would 4273 help the NSF data collector to identify this invalid NSF in the 4274 "push" model (NSF-to-collector), while the "pull" model 4275 (collector-to-NSF) should already be addressed with the 4276 authentication. 4278 Impersonating NSF data collector: This is a rogue NSF data collector 4279 with which a legitimate NSF is tricked into communicating; for 4280 "push" model (NSF-to-collector), it is important to have valid 4281 credentials, without which it should not work; for "pull" model 4282 (collector-to-NSF), mutual authentication should be used to 4283 mitigate the threat. 4285 In addition, to defend against the DDoS attack caused by a lot of 4286 NSFs sending massive notifications to the NSF data collector, the 4287 rate limiting or similar mechanisms should be considered in both an 4288 NSF and NSF data collector, whether in advance or just in the process 4289 of DDoS attack. 4291 All of the readable data nodes in this YANG module may be considered 4292 sensitive in some network environments. These data nodes represent 4293 information consistent with the logging commonly performed in network 4294 and security operations. They may reveal the specific configuration 4295 of a network; vulnerabilities in specific systems; and the deployed 4296 security controls and their relative efficacy in detecting or 4297 mitigating an attack. To an attacker, this information could inform 4298 how to (further) compromise the network, evade detection, or confirm 4299 whether they have been observed by the network operator. 4301 Additionally, many of the data nodes in this YANG module such as 4302 containers "i2nsf-system-user-activity-log", "i2nsf-system-detection- 4303 event", and "i2nsf-nsf-detection-voip-vocn" are privacy sensitive. 4304 They may describe specific or aggregate user activity including 4305 associating user names with specific IP addresses; or users with 4306 specific network usage. They may also describe the specific commands 4307 that were run by users and the resulting output. Any sensitive 4308 information in that command input or output will be visible to the 4309 NSF data collector and potentially other entities, and care must be 4310 taken to protect the confidentiality of such data from unauthorized 4311 parties. 4313 13. Acknowledgments 4315 This document is a product by the I2NSF Working Group (WG) including 4316 WG Chairs (i.e., Linda Dunbar and Yoav Nir) and Diego Lopez. This 4317 document took advantage of the review and comments from the following 4318 people: Roman Danyliw, Tim Bray (IANA), Kyle Rose (TSV-ART), Dale R. 4319 Worley (Gen-ART), Melinda Shore (SecDir), Valery Smyslov (ART-ART), 4320 and Tom Petch. The authors sincerely appreciate their sincere 4321 efforts and kind help. 4323 This work was supported by Institute of Information & Communications 4324 Technology Planning & Evaluation (IITP) grant funded by the Korea 4325 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 4326 Security Intelligence Technology Development for the Customized 4327 Security Service Provisioning). This work was supported in part by 4328 the IITP (2020-0-00395, Standard Development of Blockchain based 4329 Network Management Automation Technology). This work was supported 4330 in part by the MSIT under the Information Technology Research Center 4331 (ITRC) support program (IITP-2021-2017-0-01633) supervised by the 4332 IITP. 4334 14. Contributors 4336 The following are co-authors of this document: 4338 Chaehong Chung - Department of Electronic, Electrical and Computer 4339 Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, 4340 Gyeonggi-do 16419, Republic of Korea, Email: darkhong@skku.edu 4342 Jinyong (Tim) Kim - Department of Electronic, Electrical and Computer 4343 Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, 4344 Gyeonggi-do 16419, Republic of Korea, Email: timkim@skku.edu 4346 Dongjin Hong - Department of Electronic, Electrical and Computer 4347 Engineering, Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, 4348 Gyeonggi-do 16419, Republic of Korea, Email: dong.jin@skku.edu 4350 Dacheng Zhang - Huawei, Email: dacheng.zhang@huawei.com 4352 Yi Wu - Aliababa Group, Email: anren.wy@alibaba-inc.com 4354 Rakesh Kumar - Juniper Networks, 1133 Innovation Way, Sunnyvale, CA 4355 94089, USA, Email: rkkumar@juniper.net 4357 Anil Lohiya - Juniper Networks, Email: alohiya@juniper.net 4359 15. References 4360 15.1. Normative References 4362 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 4363 DOI 10.17487/RFC0768, August 1980, 4364 . 4366 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 4367 DOI 10.17487/RFC0791, September 1981, 4368 . 4370 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 4371 RFC 792, DOI 10.17487/RFC0792, September 1981, 4372 . 4374 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 4375 Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 4376 1983, . 4378 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 4379 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 4380 . 4382 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 4383 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 4384 . 4386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4387 Requirement Levels", BCP 14, RFC 2119, 4388 DOI 10.17487/RFC2119, March 1997, 4389 . 4391 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 4392 RFC 2595, DOI 10.17487/RFC2595, June 1999, 4393 . 4395 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 4396 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 4397 . 4399 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 4400 DOI 10.17487/RFC3688, January 2004, 4401 . 4403 [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management 4404 Information Base (MIB)", RFC 3877, DOI 10.17487/RFC3877, 4405 September 2004, . 4407 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 4408 Congestion Control Protocol (DCCP)", RFC 4340, 4409 DOI 10.17487/RFC4340, March 2006, 4410 . 4412 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 4413 Control Message Protocol (ICMPv6) for the Internet 4414 Protocol Version 6 (IPv6) Specification", STD 89, 4415 RFC 4443, DOI 10.17487/RFC4443, March 2006, 4416 . 4418 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 4419 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, 4420 . 4422 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 4423 DOI 10.17487/RFC5321, October 2008, 4424 . 4426 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 4427 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 4428 September 2009, . 4430 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 4431 and A. Bierman, Ed., "Network Configuration Protocol 4432 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 4433 . 4435 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 4436 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 4437 . 4439 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 4440 DOI 10.17487/RFC6265, April 2011, 4441 . 4443 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 4444 RFC 6991, DOI 10.17487/RFC6991, July 2013, 4445 . 4447 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 4448 "Specification of the IP Flow Information Export (IPFIX) 4449 Protocol for the Exchange of Flow Information", STD 77, 4450 RFC 7011, DOI 10.17487/RFC7011, September 2013, 4451 . 4453 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 4454 RFC 7950, DOI 10.17487/RFC7950, August 2016, 4455 . 4457 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 4458 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 4459 . 4461 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4462 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4463 May 2017, . 4465 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 4466 (IPv6) Specification", STD 86, RFC 8200, 4467 DOI 10.17487/RFC8200, July 2017, 4468 . 4470 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 4471 Kumar, "Framework for Interface to Network Security 4472 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 4473 . 4475 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 4476 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 4477 . 4479 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 4480 Access Control Model", STD 91, RFC 8341, 4481 DOI 10.17487/RFC8341, March 2018, 4482 . 4484 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 4485 and R. Wilton, "Network Management Datastore Architecture 4486 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 4487 . 4489 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 4490 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 4491 . 4493 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 4494 Documents Containing YANG Data Models", BCP 216, RFC 8407, 4495 DOI 10.17487/RFC8407, October 2018, 4496 . 4498 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 4499 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 4500 . 4502 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 4503 and R. Wilton, "YANG Library", RFC 8525, 4504 DOI 10.17487/RFC8525, March 2019, 4505 . 4507 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 4508 E., and A. Tripathy, "Subscription to YANG Notifications", 4509 RFC 8639, DOI 10.17487/RFC8639, September 2019, 4510 . 4512 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 4513 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 4514 September 2019, . 4516 [RFC8650] Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and 4517 A. Bierman, "Dynamic Subscription to YANG Events and 4518 Datastores over RESTCONF", RFC 8650, DOI 10.17487/RFC8650, 4519 November 2019, . 4521 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 4522 Multiplexed and Secure Transport", RFC 9000, 4523 DOI 10.17487/RFC9000, May 2021, 4524 . 4526 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message 4527 Access Protocol (IMAP) - Version 4rev2", RFC 9051, 4528 DOI 10.17487/RFC9051, August 2021, 4529 . 4531 [I-D.ietf-httpbis-http2bis] 4532 Thomson, M. and C. Benfield, "HTTP/2", Work in Progress, 4533 Internet-Draft, draft-ietf-httpbis-http2bis-07, 24 January 4534 2022, . 4537 [I-D.ietf-httpbis-messaging] 4538 Fielding, R. T., Nottingham, M., and J. Reschke, 4539 "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- 4540 httpbis-messaging-19, 12 September 2021, 4541 . 4544 [I-D.ietf-httpbis-semantics] 4545 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 4546 Semantics", Work in Progress, Internet-Draft, draft-ietf- 4547 httpbis-semantics-19, 12 September 2021, 4548 . 4551 [I-D.ietf-i2nsf-capability-data-model] 4552 Hares, S., Jeong, J. P., Kim, J. T., Moskowitz, R., and Q. 4553 Lin, "I2NSF Capability YANG Data Model", Work in Progress, 4554 Internet-Draft, draft-ietf-i2nsf-capability-data-model-31, 4555 14 May 2022, . 4558 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 4559 Kim, J. T., Jeong, J. P., Park, J., Hares, S., and Q. Lin, 4560 "I2NSF Network Security Function-Facing Interface YANG 4561 Data Model", Work in Progress, Internet-Draft, draft-ietf- 4562 i2nsf-nsf-facing-interface-dm-27, 14 May 2022, 4563 . 4566 [I-D.ietf-tcpm-rfc793bis] 4567 Eddy, W. M., "Transmission Control Protocol (TCP) 4568 Specification", Work in Progress, Internet-Draft, draft- 4569 ietf-tcpm-rfc793bis-28, 7 March 2022, 4570 . 4573 [I-D.ietf-tsvwg-rfc4960-bis] 4574 Stewart, R. R., Tüxen, M., and K. E. E. Nielsen, "Stream 4575 Control Transmission Protocol", Work in Progress, 4576 Internet-Draft, draft-ietf-tsvwg-rfc4960-bis-19, 5 4577 February 2022, . 4580 15.2. Informative References 4582 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 4583 Converting Network Protocol Addresses to 48.bit Ethernet 4584 Address for Transmission on Ethernet Hardware", STD 37, 4585 RFC 826, DOI 10.17487/RFC0826, November 1982, 4586 . 4588 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 4589 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 4590 DOI 10.17487/RFC4861, September 2007, 4591 . 4593 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 4594 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 4595 . 4597 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, 4598 "Handling Long Lines in Content of Internet-Drafts and 4599 RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, 4600 . 4602 [I-D.ietf-i2nsf-consumer-facing-interface-dm] 4603 Jeong, J. P., Chung, C., Ahn, T., Kumar, R., and S. Hares, 4604 "I2NSF Consumer-Facing Interface YANG Data Model", Work in 4605 Progress, Internet-Draft, draft-ietf-i2nsf-consumer- 4606 facing-interface-dm-19, 18 May 2022, 4607 . 4610 [IANA-HTTP-Status-Code] 4611 Internet Assigned Numbers Authority (IANA), "Hypertext 4612 Transfer Protocol (HTTP) Status Code Registry", September 4613 2018, . 4616 [IEEE-802.1AB] 4617 Institute of Electrical and Electronics Engineers, "IEEE 4618 Standard for Local and metropolitan area networks - 4619 Station and Media Access Control Connectivity Discovery", 4620 March 2016, 4621 . 4623 Appendix A. Changes from draft-ietf-i2nsf-nsf-monitoring-data-model-18 4625 The following changes are made from draft-ietf-i2nsf-nsf-monitoring- 4626 data-model-18: 4628 * The YANG module's prefix is updated from 'nsfmi' to 'i2nsfmi'. 4630 * The YANG module's name is updated from 'ietf-i2nsf-nsf-monitoring' 4631 to 'ietf-i2nsf-monitoring-interface'. 4633 Authors' Addresses 4635 Jaehoon Paul Jeong (editor) 4636 Department of Computer Science and Engineering 4637 Sungkyunkwan University 4638 2066 Seobu-Ro, Jangan-Gu 4639 Suwon 4640 Gyeonggi-Do 4641 16419 4642 Republic of Korea 4643 Phone: +82 31 299 4957 4644 Email: pauljeong@skku.edu 4645 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 4647 Patrick Lingga 4648 Department of Electrical and Computer Engineering 4649 Sungkyunkwan University 4650 2066 Seobu-Ro, Jangan-Gu 4651 Suwon 4652 Gyeonggi-Do 4653 16419 4654 Republic of Korea 4655 Phone: +82 31 299 4957 4656 Email: patricklink@skku.edu 4658 Susan Hares 4659 Huawei 4660 7453 Hickory Hill 4661 Saline, MI 48176 4662 United States of America 4663 Phone: +1-734-604-0332 4664 Email: shares@ndzh.com 4666 Liang Frank Xia 4667 Huawei 4668 101 Software Avenue, Yuhuatai District 4669 Nanjing 4670 Jiangsu, 4671 China 4672 Email: Frank.xialiang@huawei.com 4674 Henk Birkholz 4675 Fraunhofer Institute for Secure Information Technology 4676 Rheinstrasse 75 4677 64295 Darmstadt 4678 Germany 4679 Email: henk.birkholz@sit.fraunhofer.de