idnits 2.17.1 draft-zhang-i2nsf-info-model-monitoring-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 24, 2018) is 2004 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-core-yang-cbor' is defined on line 1263, but no explicit reference was found in the text == Unused Reference: 'RFC4765' is defined on line 1290, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2nsf-framework' is defined on line 1315, but no explicit reference was found in the text == Unused Reference: 'I-D.xia-i2nsf-capability-interface-im' is defined on line 1327, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-07 == Outdated reference: A later version (-26) exists of draft-ietf-netconf-subscribed-notifications-17 == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-20 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-06 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Xia 3 Internet-Draft D. Zhang 4 Intended status: Experimental Huawei 5 Expires: April 27, 2019 Y. Wu 6 Aliababa Group 7 R. Kumar 8 A. Lohiya 9 Juniper Networks 10 H. Birkholz 11 Fraunhofer SIT 12 October 24, 2018 14 An Information Model for the Monitoring of Network Security Functions 15 (NSF) 16 draft-zhang-i2nsf-info-model-monitoring-07 18 Abstract 20 The Network Security Functions (NSF) NSF-facing interface exists 21 between the Service Provider's management system (or Security 22 Controller) and the NSF to enforce security policy provisioning and 23 network security status monitoring. This document focuses on the 24 monitoring part and defines the corresponding information model for 25 it. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 27, 2019. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 65 3. Use cases for NSF Monitoring Data . . . . . . . . . . . . . . 4 66 4. Classification of NSF Monitoring Data . . . . . . . . . . . . 5 67 4.1. Retention and Emission . . . . . . . . . . . . . . . . . 5 68 4.2. Notifications and Events . . . . . . . . . . . . . . . . 6 69 4.3. Unsolicited Poll and Solicited Push . . . . . . . . . . . 7 70 4.4. I2NSF Monitoring Terminology for Retained Information . . 8 71 5. Conveyance of NSF Monitoring Information . . . . . . . . . . 8 72 5.1. Information Types and Acquisition Methods . . . . . . . . 9 73 6. Basic Information Model for All Monitoring Data . . . . . . . 10 74 7. Extended Information Model for Monitoring Data . . . . . . . 10 75 7.1. System Alarm . . . . . . . . . . . . . . . . . . . . . . 11 76 7.1.1. Memory Alarm . . . . . . . . . . . . . . . . . . . . 11 77 7.1.2. CPU Alarm . . . . . . . . . . . . . . . . . . . . . . 11 78 7.1.3. Disk Alarm . . . . . . . . . . . . . . . . . . . . . 11 79 7.1.4. Hardware Alarm . . . . . . . . . . . . . . . . . . . 12 80 7.1.5. Interface Alarm . . . . . . . . . . . . . . . . . . . 12 81 7.2. System Events . . . . . . . . . . . . . . . . . . . . . . 12 82 7.2.1. Access Violation . . . . . . . . . . . . . . . . . . 13 83 7.2.2. Configuration Change . . . . . . . . . . . . . . . . 13 84 7.3. System Log . . . . . . . . . . . . . . . . . . . . . . . 13 85 7.3.1. Access Logs . . . . . . . . . . . . . . . . . . . . . 14 86 7.3.2. Resource Utilization Logs . . . . . . . . . . . . . . 14 87 7.3.3. User Activity Logs . . . . . . . . . . . . . . . . . 15 88 7.4. System Counters . . . . . . . . . . . . . . . . . . . . . 15 89 7.4.1. Interface counters . . . . . . . . . . . . . . . . . 15 90 7.5. NSF Events . . . . . . . . . . . . . . . . . . . . . . . 16 91 7.5.1. DDoS Event . . . . . . . . . . . . . . . . . . . . . 16 92 7.5.2. Session Table Event . . . . . . . . . . . . . . . . . 17 93 7.5.3. Virus Event . . . . . . . . . . . . . . . . . . . . . 17 94 7.5.4. Intrusion Event . . . . . . . . . . . . . . . . . . . 18 95 7.5.5. Botnet Event . . . . . . . . . . . . . . . . . . . . 19 96 7.5.6. Web Attack Event . . . . . . . . . . . . . . . . . . 20 98 7.6. NSF Logs . . . . . . . . . . . . . . . . . . . . . . . . 21 99 7.6.1. DDoS Logs . . . . . . . . . . . . . . . . . . . . . . 21 100 7.6.2. Virus Logs . . . . . . . . . . . . . . . . . . . . . 22 101 7.6.3. Intrusion Logs . . . . . . . . . . . . . . . . . . . 22 102 7.6.4. Botnet Logs . . . . . . . . . . . . . . . . . . . . . 22 103 7.6.5. DPI Logs . . . . . . . . . . . . . . . . . . . . . . 23 104 7.6.6. Vulnerabillity Scanning Logs . . . . . . . . . . . . 24 105 7.6.7. Web Attack Logs . . . . . . . . . . . . . . . . . . . 24 106 7.7. NSF Counters . . . . . . . . . . . . . . . . . . . . . . 25 107 7.7.1. Firewall counters . . . . . . . . . . . . . . . . . . 25 108 7.7.2. Policy Hit Counters . . . . . . . . . . . . . . . . . 26 109 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 110 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 111 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 112 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 113 10.2. Informative References . . . . . . . . . . . . . . . . . 28 114 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 29 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 117 1. Introduction 119 According to [I-D.ietf-i2nsf-terminology], the interface provided by 120 an NSF (e.g., FW, IPS, Anti-DDOS, or Anti-Virus function) to 121 administrative entities (e.g., NMS, security controller) to enable 122 remote management (i.e. configuring and monitoring) is referred to as 123 an "I2NSF NSF-Facing Interface". Monitoring procedures intent to 124 acquire vital types of data at rest with respect to NSF, e.g. alarms, 125 records, or counters, via data in motion, e.g. queries, 126 notifications, or events. The monitoring of NSF plays an important 127 role in the overall security framework, if done in a timely and 128 comprehensive way. The monitoring information generated by an NSF 129 can very well be an early indication of anomalous behavior or 130 malicious activity, such as denial of service attacks. 132 This draft defines a comprehensive NSF monitoring information model 133 that provides visibility into NSF. This document will not go into 134 the design details of NSF-Facing Interfaces. Instead, it is focused 135 on specifying the information and illustrates the methods that enable 136 NSF to provide the information required in order to be monitored in a 137 scalable and efficient way via the NSF-Facing Interface. The 138 information model for monitoring presented in this document is a 139 complement to the information model for the security policy 140 provisioning part of the NSF-Facing Interface specified in 141 [I-D.xibassnez-i2nsf-capability]. 143 2. Terminology 145 2.1. Key Words 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 2.2. Definition of Terms 153 This document uses the terms defined in [I-D.ietf-i2nsf-terminology]. 155 3. Use cases for NSF Monitoring Data 157 As mentioned earlier, monitoring plays a critical role in the overall 158 security framework. The monitoring of the NSF provides very valuable 159 information to the security controller in maintaining the provisioned 160 security posture. Besides this, there are various other reasons to 161 monitor the NSF as listed below: 163 o The security administrator can configure a policy that is 164 triggered on a specific event occurring in the NSF or the network. 165 If a security controller detects the specified event, it 166 configures additional security functions as defined by policies. 168 o The events triggered by NSF as a result of security policy 169 violation can be used by SIEM to detect any suspicious activity in 170 a larger correlation context. 172 o The events and activity logs from NSF can be used to build 173 advanced analytics, such as behavior and predictive models to 174 improve security posture in large deplyoments. 176 o The security controller can use events from the NSF for achieving 177 high availability. It can take corrective actions such as 178 restarting a failed NSF, horizontally scaling the NSF, etc. 180 o The events and activity logs from the NSF can aid in the root 181 cause analysis of an operational issue - therefore improve 182 debugging. 184 o The activity logs from the NSF can be used to build historical 185 data for operational and business reasons. 187 4. Classification of NSF Monitoring Data 189 In order to maintain a strong security posture, it is not only 190 necessary to configure NSF security policies but also to continuously 191 monitor NSF by consuming acquirable and therefore observable 192 information. This enables security admins to assess the state of the 193 network topology in a timely fashion. It is not possible to block 194 all the internal and external threats based on static security 195 posture. A more practical approach is supported by enabling dynamic 196 security measures - for which continuous visibility is required. 197 This draft defines a set of information elements (and their scope) 198 that can be acquired from NSF and can be used as monitoring 199 information. In essence, these types of monitoring information can 200 be leveraged to support constant visibility on multiple levels of 201 granularity and can be consumed by corresponding functions. 203 Three basic domains about the monitoring of information originating 204 from a system entity [RFC4949] or a NSF are highlighted in this 205 document. 207 o Retention and Emission 209 o Notifications and Events 211 o Unsolicited Poll and Solicited Push 213 The Alarm Management Framework in [RFC3877] defines an Event as 214 "something that happens which may be of interest. A fault, a change 215 in status, crossing a threshold, or an external input to the system, 216 for example." In the I2NSF domain, I2NSF events 217 [I-D.ietf-i2nsf-terminology] are created and the scope of the Alarm 218 Management Framework Events is still applicable due to its broad 219 definition. The model presented in this document elaborates on the 220 work-flow of creating I2NSF events in the context of NSF monitoring 221 and on how initial I2NSF events are created. 223 As with I2NSF components, every generic system entity can include a 224 set of capabilities [I-D.ietf-i2nsf-terminology] that creates 225 information about the context, composition, configuration, state or 226 behavior of that system entity. This information is intended to be 227 provided to other consumers of informations--and in the scope of this 228 document, to monitor that information in an automated fashion. 230 4.1. Retention and Emission 232 Typically, a system entity populates standardized interface, such as 233 SNMP, NETCONF, RESTCONF or CoMI to provide and emit created 234 information directly via NSF-Facing Interfaces 236 [I-D.ietf-i2nsf-terminology]. Alternatively, the created information 237 is retained inside the system entity (or hierarchy of system entities 238 in a composite device) via records or counters that are not exposed 239 directly via NSF-Facing Interfaces. 241 Information emitted via standardized interfaces can be consumed by an 242 I2NSF Agent [I-D.ietf-i2nsf-terminology] that includes the capability 243 to consume information not only via I2NSF Interfaces but also via 244 interfaces complementary to the standardized interfaces a generic 245 system entity provides. 247 Information retained on a system entity requires a corresponding 248 I2NSF Agent to access aggregated records of information, typically in 249 the form of logfiles or databases. There are ways to aggregate 250 records originating from different system entities over a network, 251 for examples via Syslog [RFC5424] or Syslog over TCP [RFC6587]. But 252 even if records are conveyed, the result is the same kind of 253 retention in form of a bigger aggregate of records on another system 254 entity. 256 An I2NSF Agent is required to process fresh [RFC4949] records created 257 by I2NSF Functions in order to provide them to other I2NSF Components 258 via corresponding I2NSF Interfaces timely. This process is 259 effectively based on homogenizing functions that can access and 260 convert specific kinds of records into information that can be 261 provided and emitted via I2NSF interfaces. 263 Retained or emitted, the information required to support monitoring 264 processes has to be processed by an I2NSF Agent at some point in the 265 work-flow. Typical locations of these I2NSF Agents are: 267 o a system entity that creates the information 269 o a system entity that retains an aggregation of records 271 o an I2NSF Component that includes the capabilities of using 272 standardized interfaces provided by other system entities that are 273 not I2NSF Components 275 o an I2NSF Component that creates the information 277 4.2. Notifications and Events 279 A specific task of I2NSF Agents is to process I2NSF Policy Rules 280 [I-D.ietf-i2nsf-terminology]. Rules are composed of three clauses: 281 Events, Conditions, and Actions. In consequence, an I2NSF Event is 282 required to trigger an I2NSF Policy Rule. "An I2NSF Event is defined 283 as any important occurrence in time of a change in the system being 284 managed, and/or in the environment of the system being managed." 285 [I-D.ietf-i2nsf-terminology], which aligns well with the generic 286 definition of Event from [RFC3877]. 288 The model illustrated in this document introduces a complementary 289 type of information that can be conveyed--notification. 291 Notification: An occurrence of a change of context, composition, 292 configuration, state or behavior of a system entity that can be 293 directly or indirectly observed by an I2NSF Agent and can be used 294 as input for an event-clause in I2NSF Policy Rules. 296 A notification is similar to an I2NSF Event with the exception 297 that it is created by a system entity that is not an I2NSF 298 Component and that its importances is yet to be assessed. 299 Semantically, a notification is not an I2NSF Event in the context 300 of I2NSF, although they can potentially use the exact same 301 information or data model. In respect to [RFC3877], a 302 Notification is a specific subset of events, because they convey 303 information about "something that happens which may be of 304 interest". In consequence, Notifications may contain information 305 with very low expressiveness or relevance. Hence, additional 306 post-processing functions, such as aggregation, correlation or 307 simple anomaly detection, might have to be employed to satisfy a 308 level of expressiveness that is required for an event-clause of an 309 I2NSF Policy Rule. 311 It is important to note that the consumer of a notification (the 312 observer) assesses the importance of a notification and not the 313 producer. The producer can include metadata in a notification that 314 supports the observer in assessing the importance (even metadata 315 about severity), but the deciding entity is an I2NSF Agent. 317 4.3. Unsolicited Poll and Solicited Push 319 The freshness of the monitored information depends on the acquisition 320 method. Ideally, an I2NSF Agent is accessing every relevant 321 information about the I2NSF Component and is emitting I2NSF Events to 322 a monitoring NSF timely. Publication of events via a pubsub/broker 323 model, peer-2-peer meshes, or static defined channels are only a few 324 examples on how a solicited push of I2NSF Events can be facilitated. 325 The actual mechanic implemented by an I2NSF Component is out of the 326 scope of this document. 328 Often, corresponding management interfaces have to be queried in 329 intervals or on-demand if required by an I2NSF Policy rule. In some 330 cases, a collection of information has to be conducted via login 331 mechanics provided by a system entity. Accessing records of 332 information via this kind of unsolicited polls can introduce a 333 significant latency in regard to the freshness of the monitored 334 information. The actual definition of intervals implemented by an 335 I2NSF Component is also out of scope of this document. 337 4.4. I2NSF Monitoring Terminology for Retained Information 339 Records: Unlike information emitted via notifications and events, 340 records do not require immediate attention from an analyst but may 341 be useful for visibility and retroactive cyber forensic. 342 Depending on the record format, there are different qualities in 343 regard to structure and detail. Records are typically stored in 344 logfiles or databases on a system entity or NSF. Records in the 345 form of logfiles usually include less structures but potentially 346 more detailed information in regard to changes of an system 347 entity's characteristics. In contrast, databases often use more 348 strict schemas or data models, therefore enforcing a better 349 structure, but inhibit storing information that do not match those 350 models ('closed world assumption'). Records can be continuously 351 processed by I2NSF Agents that act as I2NSF Producer and emit 352 events via functions specifically tailored to a certain type of 353 record. Typically, records are information generated by NSF or 354 system entity about their operational and informational data, or 355 various changes in system characteristics, such as user 356 activities, network/traffic status, network activity, etc. They 357 are important for debugging, auditing and security forensic. 359 Counters: A specific representation of continuous value changes of 360 information elements that potentially occur in high frequency. A 361 prominent example are network interface counters, e.g. PDU amount 362 or byte amount, drop counters, error counters etc. Counters are 363 useful in debugging and visibility into operational behavior of 364 the NSF. An I2NSF Agent that observes the progression of counters 365 can act as an I2NSF Producer and emit events in respect to I2NSF 366 Policy Rules. 368 5. Conveyance of NSF Monitoring Information 370 As per the use cases of NSF monitoring data, information needs to be 371 conveyed to various I2NSF Consumers based on requirements imposed by 372 I2NSF Capabilities and work-flows. There are multiple aspects to be 373 considered in regard to emission of monitoring information to 374 requesting parties as listed below: 376 o Pull-Push Model: A set of data can be pushed by a NSF to the 377 requesting party or pulled by the requesting party from a NSF. 378 Specific types of information might need both the models at the 379 same time if there are multiple I2NSF Consumers with varying 380 requirements. In general, any I2NSF Event including a high 381 severity assessment is considered to be of great importance and 382 should be processed as soon as possible (push-model). Records, in 383 contrast, are typically not as critical (pull-model). The I2NSF 384 Architecture does not mandate a specific scheme for each type of 385 information and is therefore out of scope of this document. 387 o Pub-Sub Model: In order for an I2NSF Provider to push monitoring 388 information to multiple appropriate I2NSF Consumers, a 389 subscription can be maintained by both I2NSF Components. 390 Discovery of available monitoring information can be supported by 391 an I2NSF Controller that takes on the role of a broker and 392 therefore includes I2NSF Capabilities that support registration. 394 o Export Frequency: Monitoring information can be emitted 395 immediately upon generation by a NSF to requesting I2NSF Consumers 396 or can be pushed periodically. The frequency of exporting the 397 data depends upon its size and timely usefulness. It is out of 398 the scope of I2NSF and left to each NSF implementation. 400 o Authentication: There may be a need for authentication between 401 I2NSF Producer of monitoring information and corresponding I2NSF 402 Consumer to ensure that critical information remains confidential. 403 Authentication in the scope of I2NSF can also require a 404 corresponding content authorization. This may be necessary, for 405 example, if a NSF emits monitoring information to I2NSF Consumer 406 outside its administrative domain. The I2NSF Architecture does 407 not mandate when and how specific authentication has to be 408 implemented. 410 o Data-Transfer Model: Monitoring information can be pushed by NSF 411 using a connection-less model that does require a persistent 412 connection or streamed over a persistent connection. An 413 appropriate model depends on the I2NSF Consumer requirements and 414 the semantics of the information to be conveyed. 416 o Data Model and Interaction Model for Data in Motion: There are a 417 lot of transport mechanisms such as IP, UDP, TCP. There are also 418 open source implementations for specific set of data such as 419 systems counter, e.g. IPFIX [RFC7011] or NetFlow [RFC3954]. The 420 I2NSF does not mandate any specific method for a given data set, 421 it is up to each implementation. 423 5.1. Information Types and Acquisition Methods 425 In this document most information types defined, benefit from high 426 visibility with respect to value changes, e.g. alarms or records. In 427 contrast, values that change monotonically in a continuous way do not 428 benefit from this high visibility. On the contrary, emitting each 429 change would result in a useless amount of value updates. Hence, 430 values, such as counter, are best acquired in periodic intervals. 432 The mechanism provided by YANG Push [I-D.ietf-netconf-yang-push] and 433 YANG Subscribed Notifications 434 [I-D.ietf-netconf-subscribed-notifications] address exactly these set 435 of requirements. YANG also enables semantically well-structured 436 information, as well as subscriptions to datatores or event streams - 437 on-change or periodically. 439 In consequence, this information model is intended to support data 440 models used in solicited or unsolicited event streams that 441 potentially are facilitated by subscription mechanism. A subset of 442 information elements defined in the information model address this 443 domain of application. 445 6. Basic Information Model for All Monitoring Data 447 As explained in the above section, there is a wealth of data 448 available from the NSF that can be monitored. Firstly, there must be 449 some general information with each monitoring message sent from an 450 NSF that helps consumer in identifying meta data with that message, 451 which are listed as below: 453 o message_version: Indicate the version of the data format and is a 454 two-digit decimal numeral starting from 01 456 o message_type: Event, Alert, Alarm, Log, Counter, etc 458 o time_stamp: Indicate the time when the message is generated 460 o vendor_name: The name of the NSF vendor 462 o NSF_name: The name (or IP) of the NSF generating the message 464 o Module_name: The module name outputting the message 466 o Severity: Indicates the level of the logs. There are total eight 467 levels, from 0 to 7. The smaller the numeral is, the higher the 468 severity is. 470 7. Extended Information Model for Monitoring Data 472 This section covers the additional information associated with the 473 system messages. The extended information model is only for the 474 structured data such as alarm. Any unstructured data is specified 475 with basic information model only. 477 7.1. System Alarm 479 Characteristics: 481 o acquisition_method: subscription 483 o emission_type: on-change 485 o dampening_type: no-dampening 487 7.1.1. Memory Alarm 489 The following information should be included in a Memory Alarm: 491 o event_name: 'MEM_USAGE_ALARM' 493 o module_name: Indicate the NSF module responsible for generating 494 this alarm 496 o usage: specifies the amount of memory used 498 o threshold: The threshold triggering the alarm 500 o severity: The severity of the alarm such as critical, high, 501 medium, low 503 o message: 'The memory usage exceeded the threshold' 505 7.1.2. CPU Alarm 507 The following information should be included in a CPU Alarm: 509 o event_name: 'CPU_USAGE_ALARM' 511 o usage: Specifies the amount of CPU used 513 o threshold: The threshold triggering the event 515 o severity: The severity of the alarm such as critical, high, 516 medium, low 518 o message: 'The CPU usage exceeded the threshold' 520 7.1.3. Disk Alarm 522 The following information should be included in a Disk Alarm: 524 o event_name: 'DISK_USAGE_ALARM' 525 o usage: Specifies the amount of disk space used 527 o threshold: The threshold triggering the event 529 o severity: The severity of the alarm such as critical, high, 530 medium, low 532 o message: 'The disk usage exceeded the threshold' 534 7.1.4. Hardware Alarm 536 The following information should be included in a Hardware Alarm: 538 o event_name: 'HW_FAILURE_ALARM' 540 o component_name: Indicate the HW component responsible for 541 generating this alarm 543 o threshold: The threshold triggering the alarm 545 o severity: The severity of the alarm such as critical, high, 546 medium, low 548 o message: 'The HW component has failed or degraded' 550 7.1.5. Interface Alarm 552 The following information should be included in a Interface Alarm: 554 o event_name: 'IFNET_STATE_ALARM' 556 o interface_Name: The name of interface 558 o interface_state: 'UP', 'DOWN', 'CONGESTED' 560 o threshold: The threshold triggering the event 562 o severity: The severity of the alarm such as critical, high, 563 medium, low 565 o message: 'Current interface state' 567 7.2. System Events 569 Characteristics: 571 o acquisition_method: subscription 572 o emission_type: on-change 574 o dampening_type: on_repetition 576 7.2.1. Access Violation 578 The following information should be included in this event: 580 o event_name: 'ACCESS_DENIED' 582 o user: Name of a user 584 o group: Group to which a user belongs 586 o login_ip_address: Login IP address of a user 588 o authentication_mode: User authentication mode. e.g., Local 589 Authentication, Third-Party Server Authentication, Authentication 590 Exemption, SSO Authentication 592 o message: 'access denied' 594 7.2.2. Configuration Change 596 The following information should be included in this event: 598 o event_name: 'CONFIG_CHANGE' 600 o user: Name of a user 602 o group: Group to which a user belongs 604 o login_ip_address: Login IP address of a user 606 o authentication_mode: User authentication mode. e.g., Local 607 Authentication, Third-Party Server Authentication, Authentication 608 Exemption, SSO Authentication 610 o message: 'Configuration modified' 612 7.3. System Log 614 Characteristics: 616 o acquisition_method: subscription 618 o emission_type: on-change 619 o dampening_type: on_repetition 621 7.3.1. Access Logs 623 Access logs record administrators' login, logout, and operations on 624 the device. By analyzing them, security vulnerabilities can be 625 identified. The following information should be included in 626 operation report: 628 o Administrator: Administrator that operates on the device 630 o login_ip_address: IP address used by an administrator to log in 632 o login_mode: Specifies the administrator logs in mode e.g. root, 633 user 635 o operation_type: The operation type that the administrator execute, 636 e.g., login, logout, configuration, etc 638 o result: Command execution result 640 o content: Operation performed by an administrator after login. 642 7.3.2. Resource Utilization Logs 644 Running reports record the device system's running status, which is 645 useful for device monitoring. The following information should be 646 included in running report: 648 o system_status: The current system's running status 650 o CPU_usage: Specifies the CPU usage 652 o memory_usage: Specifies the memory usage 654 o disk_usage: Specifies the disk usage 656 o disk_left: Specifies the available disk space left 658 o session_number: Specifies total concurrent sessions 660 o process_number: Specifies total number of system processes 662 o in_traffic_rate: The total inbound traffic rate in pps 664 o out_traffic_rate: The total outbound traffic rate in pps 666 o in_traffic_speed: The total inbound traffic speed in bps 667 o out_traffic_speed: The total outbound traffic speed in bps 669 7.3.3. User Activity Logs 671 User activity logs provide visibility into users' online records 672 (such as login time, online/lockout duration, and login IP addresses) 673 and the actions users perform. User activity reports are helpful to 674 identify exceptions during user login and network access activities. 676 o user: Name of a user 678 o group: Group to which a user belongs 680 o login_ip_address: Login IP address of a user 682 o authentication_mode: User authentication mode. e.g., Local 683 Authentication, Third-Party Server Authentication, Authentication 684 Exemption, SSO Authentication 686 o access_mode: User access mode. e.g., PPP, SVN, LOCAL 688 o online_duration: Online duration 690 o lockout_duration: Lockout duration 692 o type: User activities. e.g., Successful User Login, Failed Login 693 attempts, User Logout, Successful User Password Change, Failed 694 User Password Change, User Lockout, User Unlocking, Unknown 696 o cause: Cause of a failed user activity 698 7.4. System Counters 700 Characteristics: 702 o acquisition_method: subscription or query 704 o emission_type: periodical 706 o dampening_type: none 708 7.4.1. Interface counters 710 Interface counters provide visibility into traffic into and out of 711 NSF, bandwidth usage. 713 o interface_name: Network interface name configured in NSF 714 o in_total_traffic_pkts: Total inbound packets 716 o out_total_traffic_pkts: Total outbound packets 718 o in_total_traffic_bytes: Total inbound bytes 720 o out_total_traffic_bytes: Total outbound bytes 722 o in_drop_traffic_pkts: Total inbound drop packets 724 o out_drop_traffic_pkts: Total outbound drop packets 726 o in_drop_traffic_bytes: Total inbound drop bytes 728 o out_drop_traffic_bytes: Total outbound drop bytes 730 o in_traffic_ave_rate: Inbound traffic average rate in pps 732 o in_traffic_peak_rate: Inbound traffic peak rate in pps 734 o in_traffic_ave_speed: Inbound traffic average speed in bps 736 o in_traffic_peak_speed: Inbound traffic peak speed in bps 738 o out_traffic_ave_rate: Outbound traffic average rate in pps 740 o out_traffic_peak_rate: Outbound traffic peak rate in pps 742 o out_traffic_ave_speed: Outbound traffic average speed in bps 744 o out_traffic_peak_speed: Outbound traffic peak speed in bps. 746 7.5. NSF Events 748 Characteristics: 750 o acquisition_method: subscription 752 o emission_type: on-change 754 o dampening_type: none 756 7.5.1. DDoS Event 758 The following information should be included in a DDoS Event: 760 o event_name: 'SEC_EVENT_DDoS' 761 o sub_attack_type: Any one of Syn flood, ACK flood, SYN-ACK flood, 762 FIN/RST flood, TCP Connection flood, UDP flood, Icmp flood, HTTPS 763 flood, HTTP flood, DNS query flood, DNS reply flood, SIP flood, 764 and etc. 766 o dst_ip: The IP address of a victum under attack 768 o dst_port: The port numbers that the attrack traffic aims at. 770 o start_time: The time stamp indicating when the attack started 772 o end_time: The time stamp indicating when the attack ended. If the 773 attack is still undergoing when sending out the alarm, this field 774 can be empty. 776 o attack_rate: The PPS of attack traffic 778 o attack_speed: the bps of attack traffic 780 o rule_id: The ID of the rule being triggered 782 o rule_name: The name of the rule being triggered 784 o profile: Security profile that traffic matches. 786 7.5.2. Session Table Event 788 The following information should be included in a Session 789 Table Event: 791 o event_name: 'SESSION_USAGE_HIGH' 793 o current: The number of concurrent sessions 795 o max: The maximum number of sessions that the session table can 796 support 798 o threshold: The threshold triggering the event 800 o message: 'The number of session table exceeded the threshold' 802 7.5.3. Virus Event 804 The following information should be included in a Virus Event: 806 o event_Name: 'SEC_EVENT_VIRUS' 807 o virus_type: Type of the virus, e.g., trojan, worm, macro Virus 808 type 810 o virus_name 812 o dst_ip: The destination IP address of the packet where the virus 813 is found 815 o src_ip: The source IP address of the packet where the virus is 816 found 818 o src_port: The source port of the packet where the virus is found 820 o dst_port: The destination port of the packet where the virus is 821 found 823 o src_zone: The source security zone of the packet where the virus 824 is found 826 o dst_zone: The destination security zone of the packet where the 827 virus is found 829 o file_type: The type of the file where the virus is hided within 831 o file_name: The name of the file where the virus is hided within 833 o virus_info: The brief introduction of virus 835 o raw_info: The information describing the packet triggering the 836 event. 838 o rule_id: The ID of the rule being triggered 840 o rule_name: The name of the rule being triggered 842 o profile: Security profile that traffic matches. 844 7.5.4. Intrusion Event 846 The following information should be included in a Intrustion Event: 848 o event_name: The name of event: 'SEC_EVENT_Intrusion' 850 o sub_attack_type: Attack type, e.g., brutal force, buffer overflow 852 o src_ip: The source IP address of the packet 854 o dst_ip: The destination IP address of the packet 855 o src_port:The source port number of the packet 857 o dst_port: The destination port number of the packet 859 o src_zone: The source security zone of the packet 861 o dst_zone: The destination security zone of the packet 863 o protocol: The employed transport layer protocol, e.g.,TCP, UDP 865 o app: The employed application layer protocol, e.g.,HTTP, FTP 867 o rule_id: The ID of the rule being triggered 869 o rule_name: The name of the rule being triggered 871 o profile: Security profile that traffic matches 873 o intrusion_info: Simple description of intrusion 875 o raw_info: The information describing the packet triggering the 876 event. 878 7.5.5. Botnet Event 880 The following information should be included in a Botnet Event: 882 o event_name: the name of event: 'SEC_EVENT_Botnet' 884 o botnet_name: The name of the detected botnet 886 o src_ip: The source IP address of the packet 888 o dst_ip: The destination IP address of the packet 890 o src_port: The source port number of the packet 892 o dst_port: The destination port number of the packet 894 o src_zone: The source security zone of the packet 896 o dst_zone: The destination security zone of the packet 898 o protocol: The employed transport layer protocol, e.g.,TCP, UDP 900 o app: The employed application layer protocol, e.g.,HTTP, FTP 902 o role: The role of the communicating parties within the botnet: 904 1. the packet from zombie host to the attacker 906 2. The packet from the attacker to the zombie host 908 3. The packet from the IRC/WEB server to the zombie host 910 4. The packet from the zombie host to the IRC/WEB server 912 5. The packet from the attacker to the IRC/WEB server 914 6. The packet from the IRC/WEB server to the attacker 916 7. The packet from the zombie host to the victim 918 o botnet_info: Simple description of Botnet 920 o rule_id: The ID of the rule being triggered 922 o rule_name: The name of the rule being triggered 924 o profile: Security profile that traffic matches 926 o raw_info: The information describing the packet triggering the 927 event. 929 7.5.6. Web Attack Event 931 The following information should be included in a Web Attack Alarm: 933 o event_name: the name of event: 'SEC_EVENT_WebAttack' 935 o sub_attack_type: Concret web attack type, e.g., sql injection, 936 command injection, XSS, CSRF 938 o src_ip: The source IP address of the packet 940 o dst_ip: The destination IP address of the packet 942 o src_port: The source port number of the packet 944 o dst_port: The destination port number of the packet 946 o src_zone: The source security zone of the packet 948 o dst_zone: The destination security zone of the packet 950 o req_method: The method of requirement. For instance, 'PUT' or 951 'GET' in HTTP 953 o req_url: Requested URL 955 o url_category: Matched URL category 957 o filtering_type: URL filtering type, e.g., Blacklist, Whitelist, 958 User-Defined, Predefined, Malicious Category, Unknown 960 o rule_id: The ID of the rule being triggered 962 o rule_name: The name of the rule being triggered 964 o profile: Security profile that traffic matches. 966 7.6. NSF Logs 968 Characteristics: 970 o acquisition_method: subscription 972 o emission_type: on-change 974 o dampening_type: on_repetition 976 7.6.1. DDoS Logs 978 Besides the fields in an DDoS Alarm, the following information should 979 be included in a DDoS Logs: 981 o attack_type: DDoS 983 o attack_ave_rate: The average pps of the attack traffic within the 984 recorded time 986 o attack_ave_speed: The average bps of the attack traffic within the 987 recorded time 989 o attack_pkt_num: The number attack packets within the recorded time 991 o attack_src_ip: The source IP addresses of attack traffics. If 992 there are a large amount of IP addresses, then pick a certain 993 number of resources according to different rules. 995 o action: Actions against DDoS attacks, e.g., Allow, Alert, Block, 996 Discard, Declare, Block-ip, Block-service. 998 7.6.2. Virus Logs 1000 Besides the fields in an Virus Alarm, the following information 1001 should be included in a Virus Logs: 1003 o attack_type: Virus 1005 o protocol: The transport layer protocol 1007 o app: The name of the application layer protocol 1009 o times: The time of detecting the virus 1011 o action: The actions dealing with the virus, e.g., alert, block 1013 o os: The OS that the virus will affect, e.g., all, android, ios, 1014 unix, windows 1016 7.6.3. Intrusion Logs 1018 Besides the fields in an Intrusion Alarm, the following information 1019 should be included in a Intrusion Logs: 1021 o attack_type: Intrusion 1023 o times: The times of intrusions happened in the recorded time 1025 o os: The OS that the intrusion will affect, e.g., all, android, 1026 ios, unix, windows 1028 o action: The actions dealing with the intrusions, e.g., e.g., 1029 Allow, Alert, Block, Discard, Declare, Block-ip, Block-service 1031 o attack_rate: NUM the pps of attack traffic 1033 o attack_speed: NUM the bps of attack traffic 1035 7.6.4. Botnet Logs 1037 Besides the fields in an Botnet Alarm, the following information 1038 should be included in a Botnet Logs: 1040 o attack_type: Botnet 1042 o botnet_pkt_num:The number of the packets sent to or from the 1043 detected botnet 1045 o action: The actions dealing with the detected packets, e.g., 1046 Allow, Alert, Block, Discard, Declare, Block-ip, Block-service, 1047 etc 1049 o os: The OS that the attack aiming at, e.g., all, android, ios, 1050 unix, windows, etc. 1052 7.6.5. DPI Logs 1054 DPI Logs provide statistics on uploaded and downloaded files and 1055 data, sent and received emails, and alert and block records on 1056 websites. It's helpful to learn risky user behaviors and why access 1057 to some URLs is blocked or allowed with an alert record. 1059 o type: DPI action types. e.g., File Blocking, Data Filtering, 1060 Application Behavior Control 1062 o file_name: The file name 1064 o file_type: The file type 1066 o src_zone: Source security zone of traffic 1068 o dst_zone: Destination security zone of traffic 1070 o src_region: Source region of the traffic 1072 o dst_region: Destination region of the traffic 1074 o src_ip: Source IP address of traffic 1076 o src_user: User who generates traffic 1078 o dst_ip: Destination IP address of traffic 1080 o src_port: Source port of traffic 1082 o dst_port: Destination port of traffic 1084 o protocol: Protocol type of traffic 1086 o app: Application type of traffic 1088 o policy_id: Security policy id that traffic matches 1090 o policy_name: Security policy name that traffic matches 1091 o action: Action defined in the file blocking rule, data filtering 1092 rule, or application behavior control rule that traffic matches. 1094 7.6.6. Vulnerabillity Scanning Logs 1096 Vulnerability scanning logs record the victim host and its related 1097 vulnerability information that should to be fixed. the following 1098 information should be included in the report: 1100 o victim_ip: IP address of the victim host which has vulnerabilities 1102 o vulnerability_id: The vulnerability id 1104 o vulnerability_level: The vulnerability level. e.g., high, middle, 1105 low 1107 o OS: The operating system of the victim host 1109 o service: The service which has vulnerabillity in the victim host 1111 o protocol: The protocol type. e.g., TCP, UDP 1113 o port: The port number 1115 o vulnerability_info: The information about the vulnerability 1117 o fix_suggestion: The fix suggestion to the vulnerability. 1119 7.6.7. Web Attack Logs 1121 Besides the fields in an Web Attack Alarm, the following information 1122 should be included in a Web Attack Report: 1124 o attack_type: Web Attack 1126 o rsp_code: Response code 1128 o req_clientapp: The client application 1130 o req_cookies: Cookies 1132 o req_host: The domain name of the requested host 1134 o raw_info: The information describing the packet triggering the 1135 event. 1137 7.7. NSF Counters 1139 Characteristics: 1141 o acquisition_method: subscription or query 1143 o emission_type: periodical 1145 o dampening_type: none 1147 7.7.1. Firewall counters 1149 Firewall counters provide visibility into traffic signatures, 1150 bandwidth usage, and how the configured security and bandwidth 1151 policies have been applied. 1153 o src_zone: Source security zone of traffic 1155 o dst_zone: Destination security zone of traffic 1157 o src_region: Source region of the traffic 1159 o dst_region: Destination region of the traffic 1161 o src_ip: Source IP address of traffic 1163 o src_user: User who generates traffic 1165 o dst_ip: Destination IP address of traffic 1167 o src_port: Source port of traffic 1169 o dst_port: Destination port of traffic 1171 o protocol: Protocol type of traffic 1173 o app: Application type of traffic 1175 o policy_id: Security policy id that traffic matches 1177 o policy_name: Security policy name that traffic matches 1179 o in_interface: Inbound interface of traffic 1181 o out_interface: Outbound interface of traffic 1183 o total_traffic: Total traffic volume 1184 o in_traffic_ave_rate: Inbound traffic average rate in pps 1186 o in_traffic_peak_rate: Inbound traffic peak rate in pps 1188 o in_traffic_ave_speed: Inbound traffic average speed in bps 1190 o in_traffic_peak_speed: Inbound traffic peak speed in bps 1192 o out_traffic_ave_rate: Outbound traffic average rate in pps 1194 o out_traffic_peak_rate: Outbound traffic peak rate in pps 1196 o out_traffic_ave_speed: Outbound traffic average speed in bps 1198 o out_traffic_peak_speed: Outbound traffic peak speed in bps. 1200 7.7.2. Policy Hit Counters 1202 Policy Hit Counters record the security policy that traffic matches 1203 and its hit count. It can check if policy configurations are 1204 correct. 1206 o src_zone: Source security zone of traffic 1208 o dst_zone: Destination security zone of traffic 1210 o src_region: Source region of the traffic 1212 o dst_region: Destination region of the traffic 1214 o src_ip: Source IP address of traffic 1216 o src_user: User who generates traffic 1218 o dst_ip: Destination IP address of traffic 1220 o src_port: Source port of traffic 1222 o dst_port: Destination port of traffic 1224 o protocol: Protocol type of traffic 1226 o app: Application type of traffic 1228 o policy_id: Security policy id that traffic matches 1230 o policy_name: Security policy name that traffic matches 1231 o hit_times: The hit times that the security policy matches the 1232 specified traffic. 1234 8. IANA Considerations 1236 This document makes no request of IANA. 1238 Note to RFC Editor: this section may be removed on publication as an 1239 RFC. 1241 9. Security Considerations 1243 The monitoring information of NSF should be protected by the secure 1244 communication channel, to ensure its confidentiality and integrity. 1245 In another side, the NSF and security controller can all be faked, 1246 which lead to undesireable results, i.e., leakage of NSF's important 1247 operational information, faked NSF sending false information to 1248 mislead security controller. The mutual authentication is essential 1249 to protected against this kind of attack. The current mainstream 1250 security technologies (i.e., TLS, DTLS, IPSEC, X.509 PKI) can be 1251 employed approriately to provide the above security functions. 1253 In addition, to defend against the DDoS attack caused by a lot of 1254 NSFs sending massive monitoring information to the security 1255 controller, the rate limiting or similar mechanisms should be 1256 considered in NSF and security controller, whether in advance or just 1257 in the process of DDoS attack. 1259 10. References 1261 10.1. Normative References 1263 [I-D.ietf-core-yang-cbor] 1264 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 1265 Minaburo, "CBOR Encoding of Data Modeled with YANG", 1266 draft-ietf-core-yang-cbor-07 (work in progress), September 1267 2018. 1269 [I-D.ietf-netconf-subscribed-notifications] 1270 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 1271 A. Tripathy, "Customized Subscriptions to a Publisher's 1272 Event Streams", draft-ietf-netconf-subscribed- 1273 notifications-17 (work in progress), September 2018. 1275 [I-D.ietf-netconf-yang-push] 1276 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 1277 Nygaard, E., Bierman, A., and B. Lengyel, "Subscription to 1278 YANG Datastores", draft-ietf-netconf-yang-push-20 (work in 1279 progress), October 2018. 1281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1282 Requirement Levels", BCP 14, RFC 2119, 1283 DOI 10.17487/RFC2119, March 1997, 1284 . 1286 [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management 1287 Information Base (MIB)", RFC 3877, DOI 10.17487/RFC3877, 1288 September 2004, . 1290 [RFC4765] Debar, H., Curry, D., and B. Feinstein, "The Intrusion 1291 Detection Message Exchange Format (IDMEF)", RFC 4765, 1292 DOI 10.17487/RFC4765, March 2007, 1293 . 1295 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1296 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1297 . 1299 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 1300 DOI 10.17487/RFC5424, March 2009, 1301 . 1303 [RFC6587] Gerhards, R. and C. Lonvick, "Transmission of Syslog 1304 Messages over TCP", RFC 6587, DOI 10.17487/RFC6587, April 1305 2012, . 1307 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 1308 "Specification of the IP Flow Information Export (IPFIX) 1309 Protocol for the Exchange of Flow Information", STD 77, 1310 RFC 7011, DOI 10.17487/RFC7011, September 2013, 1311 . 1313 10.2. Informative References 1315 [I-D.ietf-i2nsf-framework] 1316 Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1317 Kumar, "Framework for Interface to Network Security 1318 Functions", draft-ietf-i2nsf-framework-10 (work in 1319 progress), November 2017. 1321 [I-D.ietf-i2nsf-terminology] 1322 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1323 Birkholz, "Interface to Network Security Functions (I2NSF) 1324 Terminology", draft-ietf-i2nsf-terminology-06 (work in 1325 progress), July 2018. 1327 [I-D.xia-i2nsf-capability-interface-im] 1328 Xia, L., Strassner, J., Li, K., Zhang, D., Lopez, E., 1329 Bouthors, N., and L. Fang, "Information Model of Interface 1330 to Network Security Functions Capability Interface", 1331 draft-xia-i2nsf-capability-interface-im-06 (work in 1332 progress), July 2016. 1334 [I-D.xibassnez-i2nsf-capability] 1335 Xia, L., Strassner, J., Basile, C., and D. Lopez, 1336 "Information Model of NSFs Capabilities", draft-xibassnez- 1337 i2nsf-capability-02 (work in progress), July 2017. 1339 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 1340 Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, 1341 . 1343 Acknowledgements 1345 Authors' Addresses 1347 Liang Xia 1348 Huawei 1350 Email: frank.xialiang@huawei.com 1352 Dacheng Zhang 1353 Huawei 1355 Email: dacheng.zhang@huawei.com 1357 Yi Wu 1358 Aliababa Group 1360 Email: anren.wy@alibaba-inc.com 1362 Rakesh Kumar 1363 Juniper Networks 1365 Email: rkkumar@juniper.net 1366 Anil Lohiya 1367 Juniper Networks 1369 Email: alohiya@juniper.net 1371 Henk Birkholz 1372 Fraunhofer SIT 1374 Email: henk.birkholz@sit.fraunhofer.de