idnits 2.17.1 draft-zhang-i2nsf-info-model-monitoring-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 04, 2017) is 2486 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-03 Summary: 0 errors (**), 0 flaws (~~), 3 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: January 5, 2018 Y. Wu 6 Aliababa Group 7 R. Kumar 8 A. Lohiya 9 Juniper Networks 10 H. Birkholz 11 Fraunhofer SIT 12 July 04, 2017 14 An Information Model for the Monitoring of Network Security Functions 15 (NSF) 16 draft-zhang-i2nsf-info-model-monitoring-04 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 NSFs to enforce the security policy provisioning 23 and network security status monitoring. This document focuses on the 24 monitoring part of it and proposes the information model for it. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 5, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 64 3. Use cases for NSF Monitoring Data . . . . . . . . . . . . . . 4 65 4. Classification of NSF Monitoring Data . . . . . . . . . . . . 4 66 4.1. Retention and Emission . . . . . . . . . . . . . . . . . 5 67 4.2. Notifications and Events . . . . . . . . . . . . . . . . 6 68 4.3. Unsolicited Poll and Solicited Push . . . . . . . . . . . 7 69 4.4. I2NSF Monitoring Terminology for Retained Information . . 8 70 5. Conveyance of NSF Monitoring Information . . . . . . . . . . 8 71 6. Basic Information Model for All Monitoring Data . . . . . . . 9 72 7. Extended Information Model for Monitoring Data . . . . . . . 10 73 7.1. System Alarm . . . . . . . . . . . . . . . . . . . . . . 10 74 7.1.1. Memory Alarm . . . . . . . . . . . . . . . . . . . . 10 75 7.1.2. CPU Alarm . . . . . . . . . . . . . . . . . . . . . . 11 76 7.1.3. Disk Alarm . . . . . . . . . . . . . . . . . . . . . 11 77 7.1.4. Hardware Alarm . . . . . . . . . . . . . . . . . . . 11 78 7.1.5. Interface Alarm . . . . . . . . . . . . . . . . . . . 12 79 7.2. System Events . . . . . . . . . . . . . . . . . . . . . . 12 80 7.2.1. Access Violation . . . . . . . . . . . . . . . . . . 12 81 7.2.2. Configuration Change . . . . . . . . . . . . . . . . 12 82 7.3. System Log . . . . . . . . . . . . . . . . . . . . . . . 13 83 7.3.1. Access Logs . . . . . . . . . . . . . . . . . . . . . 13 84 7.3.2. Resource Utilization Logs . . . . . . . . . . . . . . 13 85 7.3.3. User Activity Logs . . . . . . . . . . . . . . . . . 14 86 7.4. System Counters . . . . . . . . . . . . . . . . . . . . . 14 87 7.4.1. Interface counters . . . . . . . . . . . . . . . . . 14 88 7.5. NSF Events . . . . . . . . . . . . . . . . . . . . . . . 15 89 7.5.1. DDoS Event . . . . . . . . . . . . . . . . . . . . . 15 90 7.5.2. Session Table Event . . . . . . . . . . . . . . . . . 16 91 7.5.3. Virus Event . . . . . . . . . . . . . . . . . . . . . 16 92 7.5.4. Intrusion Event . . . . . . . . . . . . . . . . . . . 17 93 7.5.5. Botnet Event . . . . . . . . . . . . . . . . . . . . 18 94 7.5.6. Web Attack Event . . . . . . . . . . . . . . . . . . 19 95 7.6. NSF Logs . . . . . . . . . . . . . . . . . . . . . . . . 20 96 7.6.1. DDoS Logs . . . . . . . . . . . . . . . . . . . . . . 20 97 7.6.2. Virus Logs . . . . . . . . . . . . . . . . . . . . . 20 98 7.6.3. Intrusion Logs . . . . . . . . . . . . . . . . . . . 21 99 7.6.4. Botnet Logs . . . . . . . . . . . . . . . . . . . . . 21 100 7.6.5. DPI Logs . . . . . . . . . . . . . . . . . . . . . . 21 101 7.6.6. Vulnerabillity Scanning Logs . . . . . . . . . . . . 22 102 7.6.7. Web Attack Logs . . . . . . . . . . . . . . . . . . . 23 103 7.7. NSF Counters . . . . . . . . . . . . . . . . . . . . . . 23 104 7.7.1. Firewall counters . . . . . . . . . . . . . . . . . . 23 105 7.7.2. Policy Hit Counters . . . . . . . . . . . . . . . . . 24 106 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 107 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 108 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 109 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 110 10.2. Informative References . . . . . . . . . . . . . . . . . 26 111 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 114 1. Introduction 116 According to [I-D.ietf-i2nsf-terminology], the interface provided by 117 a NSF (e.g., FW, IPS, Anti-DDOS, or Anti-Virus function) to 118 administrative entities (e.g., NMS, security controller) for 119 configuring security function in the NSF and monitoring the NSF is 120 referred to as a "I2NSF NSF-Facing Interface". The monitoring part 121 of it is meant to acquire vital information about the NSF via, e.g. 122 notifications, events, records, counters. The monitoring of the NSF 123 plays a very important role in the overall security framework if done 124 in a timely and comprehensive way. The monitoring information 125 generated by a NSF can very well be an early indication of malicious 126 activity, or anomalous behavior, or a potential sign of denial of 127 service attacks. 129 This draft proposes a comprehensive NSF monitoring information model 130 that provides visibility into NSFs. This document will not go into 131 the design details of NSF-Facing Interfaces. Instead, this draft is 132 focused on specifying the information and illustrates the methods 133 that enable a NSF to provide the information required in order to be 134 monitored in a scalable and efficient way via the NSF-Facing 135 Interface. The information model for monitoring presented in this 136 document is a complement to the information model for the security 137 policy provisioning part of the NSF-Facing Interface specified in 138 [I-D.xibassnez-i2nsf-capability]. 140 2. Terminology 142 2.1. Key Words 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 2.2. Definition of Terms 150 This document uses the terms defined in [I-D.ietf-i2nsf-terminology]. 152 3. Use cases for NSF Monitoring Data 154 As mentioned earlier, monitoring plays a very critical role in the 155 overall security framework. The monitoring of the NSF provides very 156 valuable information to the security controller in maintaining the 157 provisioned security posture. Besides this, there are various other 158 reasons to monitor the NSFs as listed below: 160 o The security administrator can configure a policy that is 161 triggered on a specific event happened in the NSF or the network. 162 The security controller would monitor for the specified event and 163 once it happens, it configures additional security functions as 164 per the policy. 166 o The events triggered by NSFs as a result of security policy 167 violation can be used by SIEM to detect any suspicious activity. 169 o The events and activity logs from NSFs can be used to build 170 advanced analytics such as behavior and predictive to improve the 171 security posture. 173 o The security controller can use events from the NSF for achieving 174 high availability. It can take corrective actions such as 175 restarting a failed NSF, horizontally scaling the NSF etc. 177 o The events and activity logs from the NSF can aid in debugging and 178 root cause analysis of an operational issue. 180 o The activity logs from the NSF can be used to build historical 181 data for operational and business reasons. 183 4. Classification of NSF Monitoring Data 185 In order to maintain a strong security posture, it is not only 186 necessary to configure NSF security policies but also to continuously 187 monitor NSF by consuming acquirable observable information. This 188 enables security admins to assess what is happening in the network 189 timely. It is not possible to block all the internal and external 190 threats based on static security posture. To achieve this goal, a 191 very dynamic posture with constant visibility is required. This 192 draft defines a set of information elements (and their scope) that 193 can be acquired from NSF and can be used as monitoring information. 194 In essence, these types of monitoring information can be leveraged to 195 support constant visibility on multiple levels of granularity and can 196 be consumed by corresponding functions. 198 Three basic domains about the monitoring of information originating 199 from a system entity [RFC4949] or a NSF are highlighted in this 200 document. 202 o Retention and Emission 204 o Notifications and Events 206 o Unsolicited Poll and Solicited Push 208 The Alarm Management Framework in [RFC3877] defines an Event as 209 "something that happens which may be of interest. A fault, a change 210 in status, crossing a threshold, or an external input to the system, 211 for example." In the I2NSF domain, I2NSF events 212 [I-D.ietf-i2nsf-terminology] are created and the scope of the Alarm 213 Management Framework Events is still applicable due to its broad 214 definition. The model presented in this document elaborates on the 215 work-flow of creating I2NSF events in the context of NSF monitoring 216 and on how initial I2NSF events are created. 218 As with I2NSF components, every generic system entity can include a 219 set of capabilities [I-D.ietf-i2nsf-terminology] that creates 220 information about the context, composition, configuration, state or 221 behavior of that system entity. This information is intended to be 222 provided to other consumers of informations--and in the scope of this 223 document, to monitor that information in an automated fashion. 225 4.1. Retention and Emission 227 Typically, a system entity populates standardized interface, such as 228 SNMP, NETCONF, RESTCONF or CoMI to provide and emit created 229 information directly via NSF-Facing Interfaces 230 [I-D.ietf-i2nsf-terminology]. Alternatively, the created information 231 is retained inside the system entity (or hierarchy of system entities 232 in a composite device) via records or counters that are not exposed 233 directly via NSF-Facing Interfaces. 235 Information emitted via standardized interfaces can be consumed by an 236 I2NSF Agent [I-D.ietf-i2nsf-terminology] that includes the capability 237 to consume information not only via I2NSF Interfaces but also via 238 interfaces complementary to the standardized interfaces a generic 239 system entity provides. 241 Information retained on a system entity requires a corresponding 242 I2NSF Agent to access aggregated records of information, typically in 243 the form of logfiles or databases. There are ways to aggregate 244 records originating from different system entities over a network, 245 for examples via Syslog [RFC5424] or Syslog over TCP [RFC6587]. But 246 even if records are conveyed, the result is the same kind of 247 retention in form of a bigger aggregate of records on another system 248 entity. 250 An I2NSF Agent is required to process fresh [RFC4949] records created 251 by I2NSF Functions in order to provide them to other I2NSF Components 252 via corresponding I2NSF Interfaces timely. This process is 253 effectively based on homogenizing functions that can access and 254 convert specific kinds of records into information that can be 255 provided and emitted via I2NSF interfaces. 257 Retained or emitted, the information required to support monitoring 258 processes has to be processed by an I2NSF Agent at some point in the 259 work-flow. Typical locations of these I2NSF Agents are: 261 o a system entity that creates the information 263 o a system entity that retains an aggregation of records 265 o an I2NSF Component that includes the capabilities of using 266 standardized interfaces provided by other system entities that are 267 not I2NSF Components 269 o an I2NSF Component that creates the information 271 4.2. Notifications and Events 273 A specific task of I2NSF Agents is to process I2NSF Policy Rules 274 [I-D.ietf-i2nsf-terminology]. Rules are composed of three clauses: 275 Events, Conditions, and Actions. In consequence, an I2NSF Event is 276 required to trigger an I2NSF Policy Rule. "An I2NSF Event is defined 277 as any important occurrence in time of a change in the system being 278 managed, and/or in the environment of the system being managed." 279 [I-D.ietf-i2nsf-terminology], which aligns well with the generic 280 definition of Event from [RFC3877]. 282 The model illustrated in this document introduces a complementary 283 type of information that can be conveyed--notification. 285 Notification: An occurrence of a change of context, composition, 286 configuration, state or behavior of a system entity that can be 287 directly or indirectly observed by an I2NSF Agent and can be used 288 as input for an event-clause in I2NSF Policy Rules. 290 A notification is similar to an I2NSF Event with the exception 291 that it is created by a system entity that is not an I2NSF 292 Component and that its importances is yet to be assessed. 293 Semantically, a notification is not an I2NSF Event in the context 294 of I2NSF, although they can potentially use the exact same 295 information or data model. In respect to [RFC3877], a 296 Notification is a specific subset of events, because they convey 297 information about "something that happens which may be of 298 interest". In consequence, Notifications can contain information 299 with very low expressiveness or relevance. Hence, additional 300 post-processing functions, such as aggregation, correlation or 301 simple anomaly detection, might have to be employed to satisfy a 302 level of expressiveness that is required for an event-clause of an 303 I2NSF Policy Rule. 305 It is important to note that the consumer of a notification (the 306 observer) assesses the importance of a notification and not the 307 producer. The producer can include metadata in a notification that 308 supports the observer in assessing the importance (even metadata 309 about severity), but the deciding entity is an I2NSF Agent. 311 4.3. Unsolicited Poll and Solicited Push 313 The freshness of the monitored information depends on the acquisition 314 method. Ideally, an I2NSF Agent is accessing every relevant 315 information about the I2NSF Component and is emitting I2NSF Events to 316 a monitoring NSF timely. Publication of events via a pubsub/broker 317 model, peer-2-peer meshes, or static defined channels are only a few 318 examples on how a solicited push of I2NSF Events can be facilitated. 319 The actual mechanic implemented by an I2NSF Component is out of the 320 scope of this document. 322 Often, corresponding management interfaces have to be queried in 323 intervals or on-demand if required by an I2NSF Policy rule. In some 324 cases, a collection of information has to be conducted via login 325 mechanics provided by a system entity. Accessing records of 326 information via this kind of unsolicited polls can introduce a 327 significant latency in regard to the freshness of the monitored 328 information. The actual definition of intervals implemented by an 329 I2NSF Component is also out of scope of this document. 331 4.4. I2NSF Monitoring Terminology for Retained Information 333 Records: Unlike information emitted via notifications and events, 334 records do not require immediate attention from an analyst but may 335 be useful for visibility and retroactive cyber forensic. 336 Depending on the record format, there are different qualities in 337 regard to structure and detail. Records are typically stored in 338 logfiles or databases on a system entity or NSF. Records in the 339 form of logfiles usually include less structures but potentially 340 more detailed information in regard to changes of an system 341 entity's characteristics. In contrast, databases often use more 342 strict schemas or data models, therefore enforcing a better 343 structure, but inhibit storing information that do not match those 344 models ('closed world assumption'). Records can be continuously 345 processed by I2NSF Agents that act as I2NSF Producer and emit 346 events via functions specifically tailored to a certain type of 347 record. Typically, records are information generated by NSF or 348 system entity about their operational and informational data, or 349 various changes in system characteristics, such as user 350 activities, network/traffic status, network activity, etc. They 351 are important for debugging, auditing and security forensic. 353 Counters: A specific representation of continuous value changes of 354 information elements that potentially occur in high frequency. A 355 prominent example are network interface counters, e.g. PDU amount 356 or byte amount, drop counters, error counters etc. Counters are 357 useful in debugging and visibility into operational behavior of 358 the NSF. An I2NSF Agent that observes the progression of counters 359 can act as an I2NSF Producer and emit events in respect to I2NSF 360 Policy Rules. 362 5. Conveyance of NSF Monitoring Information 364 As per the use cases of NSF monitoring data, information needs to be 365 conveyed to various I2NSF Consumers based on requirements imposed by 366 I2NSF Capabilities and work-flows. There are multiple aspects to be 367 considered in regard to emission of monitoring information to 368 requesting parties as listed below: 370 o Pull-Push Model: A set of data can be pushed by a NSF to the 371 requesting party or pulled by the requesting party from a NSF. 372 Specific types of information might need both the models at the 373 same time if there are multiple I2NSF Consumers with varying 374 requirements. In general, any I2NSF Event including a high 375 severity assessment is considered to be of great importance and 376 should be processed as soon as possible (push-model). Records, in 377 contrast, are typically not as critical (pull-model). The I2NSF 378 Architecture does not mandate a specific scheme for each type of 379 information and is therefore out of scope of this document. 381 o Pub-Sub Model: In order for an I2NSF Provider to push monitoring 382 information to multiple appropriate I2NSF Consumers, a 383 subscription can be maintained by both I2NSF Components. 384 Discovery of available monitoring information can be supported by 385 an I2NSF Controller that takes on the role of a broker and 386 therefore includes I2NSF Capabilities that support registration. 388 o Export Frequency: Monitoring information can be emitted 389 immediately upon generation by a NSF to requesting I2NSF Consumers 390 or can be pushed periodically. The frequency of exporting the 391 data depends upon its size and timely usefulness. It is out of 392 the scope of I2NSF and left to each NSF implementation. 394 o Authentication: There may be a need for authentication between 395 I2NSF Producer of monitoring information and corresponding I2NSF 396 Consumer to ensure that critical information remains confidential. 397 Authentication in the scope of I2NSF can also require a 398 corresponding content authorization. This may be necessary, for 399 example, if a NSF emits monitoring information to I2NSF Consumer 400 outside its administrative domain. The I2NSF Architecture does 401 not mandate when and how specific authentication has to be 402 implemented. 404 o Data-Transfer Model: Monitoring information can be pushed by NSF 405 using a connection-less model that does require a persistent 406 connection or streamed over a persistent connection. An 407 appropriate model depends on the I2NSF Consumer requirements and 408 the semantics of the information to be conveyed. 410 o Data Model and Interaction Model for Data in Motion: There are a 411 lot of 413 o transport mechanisms such as IP, UDP, TCP. There are also open 414 source implementations for specific set of data such as systems 415 counter, e.g. IPFIX [RFC7011] or NetFlow [RFC3954]. The I2NSF 416 does not mandate any specific method for a given data set, it is 417 up to each implementation. 419 6. Basic Information Model for All Monitoring Data 421 As explained in the above section, there is a wealth of data 422 available from the NSF that can be monitored. Firstly, there must be 423 some general information with each monitoring message sent from an 424 NSF that helps consumer in identifying meta data with that message, 425 which are listed as below: 427 o message_version: Indicate the version of the data format and is a 428 two-digit decimal numeral starting from 01 430 o message_type: Event, Alert, Alarm, Log, Counter, etc 432 o time_stamp: Indicate the time when the message is generated 434 o vendor_name: The name of the NSF vendor 436 o NSF_name: The name (or IP) of the NSF generating the message 438 o Module_name: The module name outputting the message 440 o Severity: Indicates the level of the logs. There are total eight 441 levels, from 0 to 7. The smaller the numeral is, the higher the 442 severity is. 444 7. Extended Information Model for Monitoring Data 446 This section covers the additional information associated with the 447 system messages. The extended information model is only for the 448 structured data such as alarm. Any unstructured data is specified 449 with basic information model only. 451 [Editors' note]: This section remains the same as -02 version, 452 although the classification of the monitoring data has been changed 453 from -02 version. The new inconsistency will be addressed in next 454 verion. 456 7.1. System Alarm 458 7.1.1. Memory Alarm 460 The following information should be included in a Memory Alarm: 462 o event_name: 'MEM_USAGE_ALARM' 464 o module_name: Indicate the NSF module responsible for generating 465 this alarm 467 o usage: specifies the amount of memory used 469 o threshold: The threshold triggering the alarm 471 o severity: The severity of the alarm such as critical, high, 472 medium, low 474 o message: 'The memory usage exceeded the threshold' 476 7.1.2. CPU Alarm 478 The following information should be included in a CPU Alarm: 480 o event_name: 'CPU_USAGE_ALARM' 482 o usage: Specifies the amount of CPU used 484 o threshold: The threshold triggering the event 486 o severity: The severity of the alarm such as critical, high, 487 medium, low 489 o message: 'The CPU usage exceeded the threshold' 491 7.1.3. Disk Alarm 493 The following information should be included in a Disk Alarm: 495 o event_name: 'DISK_USAGE_ALARM' 497 o usage: Specifies the amount of disk space used 499 o threshold: The threshold triggering the event 501 o severity: The severity of the alarm such as critical, high, 502 medium, low 504 o message: 'The disk usage exceeded the threshold' 506 7.1.4. Hardware Alarm 508 The following information should be included in a Hardware Alarm: 510 o event_name: 'HW_FAILURE_ALARM' 512 o component_name: Indicate the HW component responsible for 513 generating this alarm 515 o threshold: The threshold triggering the alarm 517 o severity: The severity of the alarm such as critical, high, 518 medium, low 520 o message: 'The HW component has failed or degraded' 522 7.1.5. Interface Alarm 524 The following information should be included in a Interface Alarm: 526 o event_name: 'IFNET_STATE_ALARM' 528 o interface_Name: The name of interface 530 o interface_state: 'UP', 'DOWN', 'CONGESTED' 532 o threshold: The threshold triggering the event 534 o severity: The severity of the alarm such as critical, high, 535 medium, low 537 o message: 'Current interface state' 539 7.2. System Events 541 7.2.1. Access Violation 543 The following information should be included in this event: 545 o event_name: 'ACCESS_DENIED' 547 o user: Name of a user 549 o group: Group to which a user belongs 551 o login_ip_address: Login IP address of a user 553 o authentication_mode: User authentication mode. e.g., Local 554 Authentication, Third-Party Server Authentication, Authentication 555 Exemption, SSO Authentication 557 o message: 'access denied' 559 7.2.2. Configuration Change 561 The following information should be included in this event: 563 o event_name: 'CONFIG_CHANGE' 565 o user: Name of a user 567 o group: Group to which a user belongs 569 o login_ip_address: Login IP address of a user 570 o authentication_mode: User authentication mode. e.g., Local 571 Authentication, Third-Party Server Authentication, Authentication 572 Exemption, SSO Authentication 574 o message: 'Configuration modified' 576 7.3. System Log 578 7.3.1. Access Logs 580 Access logs record administrators' login, logout, and operations on 581 the device. By analyzing them, security vulnerabilities can be 582 identified. The following information should be included in 583 operation report: 585 o Administrator: Administrator that operates on the device 587 o login_ip_address: IP address used by an administrator to log in 589 o login_mode: Specifies the administrator logs in mode e.g. root, 590 user 592 o operation_type: The operation type that the administrator execute, 593 e.g., login, logout, configuration, etc 595 o result: Command execution result 597 o content: Operation performed by an administrator after login. 599 7.3.2. Resource Utilization Logs 601 Running reports record the device system's running status, which is 602 useful for device monitoring. The following information should be 603 included in running report: 605 o system_status: The current system's running status 607 o CPU_usage: Specifies the CPU usage 609 o memory_usage: Specifies the memory usage 611 o disk_usage: Specifies the disk usage 613 o disk_left: Specifies the available disk space left 615 o session_number: Specifies total concurrent sessions 617 o process_number: Specifies total number of system processes 618 o in_traffic_rate: The total inbound traffic rate in pps 620 o out_traffic_rate: The total outbound traffic rate in pps 622 o in_traffic_speed: The total inbound traffic speed in bps 624 o out_traffic_speed: The total outbound traffic speed in bps 626 7.3.3. User Activity Logs 628 User activity logs provide visibility into users' online records 629 (such as login time, online/lockout duration, and login IP addresses) 630 and the actions users perform. User activity reports are helpful to 631 identify exceptions during user login and network access activities. 633 o user: Name of a user 635 o group: Group to which a user belongs 637 o login_ip_address: Login IP address of a user 639 o authentication_mode: User authentication mode. e.g., Local 640 Authentication, Third-Party Server Authentication, Authentication 641 Exemption, SSO Authentication 643 o access_mode: User access mode. e.g., PPP, SVN, LOCAL 645 o online_duration: Online duration 647 o lockout_duration: Lockout duration 649 o type: User activities. e.g., Successful User Login, Failed Login 650 attempts, User Logout, Successful User Password Change, Failed 651 User Password Change, User Lockout, User Unlocking, Unknown 653 o cause: Cause of a failed user activity 655 7.4. System Counters 657 7.4.1. Interface counters 659 Interface counters provide visibility into traffic into and out of 660 NSF, bandwidth usage. 662 o interface_name: Network interface name configured in NSF 664 o in_total_traffic_pkts: Total inbound packets 665 o out_total_traffic_pkts: Total outbound packets 667 o in_total_traffic_bytes: Total inbound bytes 669 o out_total_traffic_bytes: Total outbound bytes 671 o in_drop_traffic_pkts: Total inbound drop packets 673 o out_drop_traffic_pkts: Total outbound drop packets 675 o in_drop_traffic_bytes: Total inbound drop bytes 677 o out_drop_traffic_bytes: Total outbound drop bytes 679 o in_traffic_ave_rate: Inbound traffic average rate in pps 681 o in_traffic_peak_rate: Inbound traffic peak rate in pps 683 o in_traffic_ave_speed: Inbound traffic average speed in bps 685 o in_traffic_peak_speed: Inbound traffic peak speed in bps 687 o out_traffic_ave_rate: Outbound traffic average rate in pps 689 o out_traffic_peak_rate: Outbound traffic peak rate in pps 691 o out_traffic_ave_speed: Outbound traffic average speed in bps 693 o out_traffic_peak_speed: Outbound traffic peak speed in bps. 695 7.5. NSF Events 697 7.5.1. DDoS Event 699 The following information should be included in a DDoS Event: 701 o event_name: 'SEC_EVENT_DDoS' 703 o sub_attack_type: Any one of Syn flood, ACK flood, SYN-ACK flood, 704 FIN/RST flood, TCP Connection flood, UDP flood, Icmp flood, HTTPS 705 flood, HTTP flood, DNS query flood, DNS reply flood, SIP flood, 706 and etc. 708 o dst_ip: The IP address of a victum under attack 710 o dst_port: The port numbers that the attrack traffic aims at. 712 o start_time: The time stamp indicating when the attack started 713 o end_time: The time stamp indicating when the attack ended. If the 714 attack is still undergoing when sending out the alarm, this field 715 can be empty. 717 o attack_rate: The PPS of attack traffic 719 o attack_speed: the bps of attack traffic 721 o rule_id: The ID of the rule being triggered 723 o rule_name: The name of the rule being triggered 725 o profile: Security profile that traffic matches. 727 7.5.2. Session Table Event 729 The following information should be included in a Session 730 Table Event: 732 o event_name: 'SESSION_USAGE_HIGH' 734 o current: The number of concurrent sessions 736 o max: The maximum number of sessions that the session table can 737 support 739 o threshold: The threshold triggering the event 741 o message: 'The number of session table exceeded the threshold' 743 7.5.3. Virus Event 745 The following information should be included in a Virus Event: 747 o event_Name: 'SEC_EVENT_VIRUS' 749 o virus_type: Type of the virus, e.g., trojan, worm, macro Virus 750 type 752 o virus_name 754 o dst_ip: The destination IP address of the packet where the virus 755 is found 757 o src_ip: The source IP address of the packet where the virus is 758 found 760 o src_port: The source port of the packet where the virus is found 761 o dst_port: The destination port of the packet where the virus is 762 found 764 o src_zone: The source security zone of the packet where the virus 765 is found 767 o dst_zone: The destination security zone of the packet where the 768 virus is found 770 o file_type: The type of the file where the virus is hided within 772 o file_name: The name of the file where the virus is hided within 774 o virus_info: The brief introduction of virus 776 o raw_info: The information describing the packet triggering the 777 event. 779 o rule_id: The ID of the rule being triggered 781 o rule_name: The name of the rule being triggered 783 o profile: Security profile that traffic matches. 785 7.5.4. Intrusion Event 787 The following information should be included in a Intrustion Event: 789 o event_name: The name of event: 'SEC_EVENT_Intrusion' 791 o sub_attack_type: Attack type, e.g., brutal force, buffer overflow 793 o src_ip: The source IP address of the packet 795 o dst_ip: The destination IP address of the packet 797 o src_port:The source port number of the packet 799 o dst_port: The destination port number of the packet 801 o src_zone: The source security zone of the packet 803 o dst_zone: The destination security zone of the packet 805 o protocol: The employed transport layer protocol, e.g.,TCP, UDP 807 o app: The employed application layer protocol, e.g.,HTTP, FTP 808 o rule_id: The ID of the rule being triggered 810 o rule_name: The name of the rule being triggered 812 o profile: Security profile that traffic matches 814 o intrusion_info: Simple description of intrusion 816 o raw_info: The information describing the packet triggering the 817 event. 819 7.5.5. Botnet Event 821 The following information should be included in a Botnet Event: 823 o event_name: the name of event: 'SEC_EVENT_Botnet' 825 o botnet_name: The name of the detected botnet 827 o src_ip: The source IP address of the packet 829 o dst_ip: The destination IP address of the packet 831 o src_port: The source port number of the packet 833 o dst_port: The destination port number of the packet 835 o src_zone: The source security zone of the packet 837 o dst_zone: The destination security zone of the packet 839 o protocol: The employed transport layer protocol, e.g.,TCP, UDP 841 o app: The employed application layer protocol, e.g.,HTTP, FTP 843 o role: The role of the communicating parties within the botnet: 845 1. the packet from zombie host to the attacker 847 2. The packet from the attacker to the zombie host 849 3. The packet from the IRC/WEB server to the zombie host 851 4. The packet from the zombie host to the IRC/WEB server 853 5. The packet from the attacker to the IRC/WEB server 855 6. The packet from the IRC/WEB server to the attacker 856 7. The packet from the zombie host to the victim 858 o botnet_info: Simple description of Botnet 860 o rule_id: The ID of the rule being triggered 862 o rule_name: The name of the rule being triggered 864 o profile: Security profile that traffic matches 866 o raw_info: The information describing the packet triggering the 867 event. 869 7.5.6. Web Attack Event 871 The following information should be included in a Web Attack Alarm: 873 o event_name: the name of event: 'SEC_EVENT_WebAttack' 875 o sub_attack_type: Concret web attack type, e.g., sql injection, 876 command injection, XSS, CSRF 878 o src_ip: The source IP address of the packet 880 o dst_ip: The destination IP address of the packet 882 o src_port: The source port number of the packet 884 o dst_port: The destination port number of the packet 886 o src_zone: The source security zone of the packet 888 o dst_zone: The destination security zone of the packet 890 o req_method: The method of requirement. For instance, 'PUT' or 891 'GET' in HTTP 893 o req_url: Requested URL 895 o url_category: Matched URL category 897 o filtering_type: URL filtering type, e.g., Blacklist, Whitelist, 898 User-Defined, Predefined, Malicious Category, Unknown 900 o rule_id: The ID of the rule being triggered 902 o rule_name: The name of the rule being triggered 903 o profile: Security profile that traffic matches. 905 7.6. NSF Logs 907 7.6.1. DDoS Logs 909 Besides the fields in an DDoS Alarm, the following information should 910 be included in a DDoS Logs: 912 o attack_type: DDoS 914 o attack_ave_rate: The average pps of the attack traffic within the 915 recorded time 917 o attack_ave_speed: The average bps of the attack traffic within the 918 recorded time 920 o attack_pkt_num: The number attack packets within the recorded time 922 o attack_src_ip: The source IP addresses of attack traffics. If 923 there are a large amount of IP addresses, then pick a certain 924 number of resources according to different rules. 926 o action: Actions against DDoS attacks, e.g., Allow, Alert, Block, 927 Discard, Declare, Block-ip, Block-service. 929 7.6.2. Virus Logs 931 Besides the fields in an Virus Alarm, the following information 932 should be included in a Virus Logs: 934 o attack_type: Virus 936 o protocol: The transport layer protocol 938 o app: The name of the application layer protocol 940 o times: The time of detecting the virus 942 o action: The actions dealing with the virus, e.g., alert, block 944 o os: The OS that the virus will affect, e.g., all, android, ios, 945 unix, windows 947 7.6.3. Intrusion Logs 949 Besides the fields in an Intrusion Alarm, the following information 950 should be included in a Intrusion Logs: 952 o attack_type: Intrusion 954 o times: The times of intrusions happened in the recorded time 956 o os: The OS that the intrusion will affect, e.g., all, android, 957 ios, unix, windows 959 o action: The actions dealing with the intrusions, e.g., e.g., 960 Allow, Alert, Block, Discard, Declare, Block-ip, Block-service 962 o attack_rate: NUM the pps of attack traffic 964 o attack_speed: NUM the bps of attack traffic 966 7.6.4. Botnet Logs 968 Besides the fields in an Botnet Alarm, the following information 969 should be included in a Botnet Logs: 971 o attack_type: Botnet 973 o botnet_pkt_num:The number of the packets sent to or from the 974 detected botnet 976 o action: The actions dealing with the detected packets, e.g., 977 Allow, Alert, Block, Discard, Declare, Block-ip, Block-service, 978 etc 980 o os: The OS that the attack aiming at, e.g., all, android, ios, 981 unix, windows, etc. 983 7.6.5. DPI Logs 985 DPI Logs provide statistics on uploaded and downloaded files and 986 data, sent and received emails, and alert and block records on 987 websites. It's helpful to learn risky user behaviors and why access 988 to some URLs is blocked or allowed with an alert record. 990 o type: DPI action types. e.g., File Blocking, Data Filtering, 991 Application Behavior Control 993 o file_name: The file name 994 o file_type: The file type 996 o src_zone: Source security zone of traffic 998 o dst_zone: Destination security zone of traffic 1000 o src_region: Source region of the traffic 1002 o dst_region: Destination region of the traffic 1004 o src_ip: Source IP address of traffic 1006 o src_user: User who generates traffic 1008 o dst_ip: Destination IP address of traffic 1010 o src_port: Source port of traffic 1012 o dst_port: Destination port of traffic 1014 o protocol: Protocol type of traffic 1016 o app: Application type of traffic 1018 o policy_id: Security policy id that traffic matches 1020 o policy_name: Security policy name that traffic matches 1022 o action: Action defined in the file blocking rule, data filtering 1023 rule, or application behavior control rule that traffic matches. 1025 7.6.6. Vulnerabillity Scanning Logs 1027 Vulnerability scanning logs record the victim host and its related 1028 vulnerability information that should to be fixed. the following 1029 information should be included in the report: 1031 o victim_ip: IP address of the victim host which has vulnerabilities 1033 o vulnerability_id: The vulnerability id 1035 o vulnerability_level: The vulnerability level. e.g., high, middle, 1036 low 1038 o OS: The operating system of the victim host 1040 o service: The service which has vulnerabillity in the victim host 1041 o protocol: The protocol type. e.g., TCP, UDP 1043 o port: The port number 1045 o vulnerability_info: The information about the vulnerability 1047 o fix_suggestion: The fix suggestion to the vulnerability. 1049 7.6.7. Web Attack Logs 1051 Besides the fields in an Web Attack Alarm, the following information 1052 should be included in a Web Attack Report: 1054 o attack_type: Web Attack 1056 o rsp_code: Response code 1058 o req_clientapp: The client application 1060 o req_cookies: Cookies 1062 o req_host: The domain name of the requested host 1064 o raw_info: The information describing the packet triggering the 1065 event. 1067 7.7. NSF Counters 1069 7.7.1. Firewall counters 1071 Firewall counters provide visibility into traffic signatures, 1072 bandwidth usage, and how the configured security and bandwidth 1073 policies have been applied. 1075 o src_zone: Source security zone of traffic 1077 o dst_zone: Destination security zone of traffic 1079 o src_region: Source region of the traffic 1081 o dst_region: Destination region of the traffic 1083 o src_ip: Source IP address of traffic 1085 o src_user: User who generates traffic 1087 o dst_ip: Destination IP address of traffic 1088 o src_port: Source port of traffic 1090 o dst_port: Destination port of traffic 1092 o protocol: Protocol type of traffic 1094 o app: Application type of traffic 1096 o policy_id: Security policy id that traffic matches 1098 o policy_name: Security policy name that traffic matches 1100 o in_interface: Inbound interface of traffic 1102 o out_interface: Outbound interface of traffic 1104 o total_traffic: Total traffic volume 1106 o in_traffic_ave_rate: Inbound traffic average rate in pps 1108 o in_traffic_peak_rate: Inbound traffic peak rate in pps 1110 o in_traffic_ave_speed: Inbound traffic average speed in bps 1112 o in_traffic_peak_speed: Inbound traffic peak speed in bps 1114 o out_traffic_ave_rate: Outbound traffic average rate in pps 1116 o out_traffic_peak_rate: Outbound traffic peak rate in pps 1118 o out_traffic_ave_speed: Outbound traffic average speed in bps 1120 o out_traffic_peak_speed: Outbound traffic peak speed in bps. 1122 7.7.2. Policy Hit Counters 1124 Policy Hit Counters record the security policy that traffic matches 1125 and its hit count. It can check if policy configurations are 1126 correct. 1128 o src_zone: Source security zone of traffic 1130 o dst_zone: Destination security zone of traffic 1132 o src_region: Source region of the traffic 1134 o dst_region: Destination region of the traffic 1135 o src_ip: Source IP address of traffic 1137 o src_user: User who generates traffic 1139 o dst_ip: Destination IP address of traffic 1141 o src_port: Source port of traffic 1143 o dst_port: Destination port of traffic 1145 o protocol: Protocol type of traffic 1147 o app: Application type of traffic 1149 o policy_id: Security policy id that traffic matches 1151 o policy_name: Security policy name that traffic matches 1153 o hit_times: The hit times that the security policy matches the 1154 specified traffic. 1156 8. IANA Considerations 1158 This document makes no request of IANA. 1160 Note to RFC Editor: this section may be removed on publication as an 1161 RFC. 1163 9. Security Considerations 1165 The monitoring information of NSF should be protected by the secure 1166 communication channel, to ensure its confidentiality and integrity. 1167 In another side, the NSF and security controller can all be faked, 1168 which lead to undesireable results, i.e., leakage of NSF's important 1169 operational information, faked NSF sending false information to 1170 mislead security controller. The mutual authentication is essential 1171 to protected against this kind of attack. The current mainstream 1172 security technologies (i.e., TLS, DTLS, IPSEC, X.509 PKI) can be 1173 employed approriately to provide the above security functions. 1175 In addition, to defend against the DDoS attack caused by a lot of 1176 NSFs sending massive monitoring information to the security 1177 controller, the rate limiting or similar mechanisms should be 1178 considered in NSF and security controller, whether in advance or just 1179 in the process of DDoS attack. 1181 10. References 1183 10.1. Normative References 1185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1186 Requirement Levels", BCP 14, RFC 2119, 1187 DOI 10.17487/RFC2119, March 1997, 1188 . 1190 [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management 1191 Information Base (MIB)", RFC 3877, DOI 10.17487/RFC3877, 1192 September 2004, . 1194 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1195 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1196 . 1198 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 1199 DOI 10.17487/RFC5424, March 2009, 1200 . 1202 [RFC6587] Gerhards, R. and C. Lonvick, "Transmission of Syslog 1203 Messages over TCP", RFC 6587, DOI 10.17487/RFC6587, April 1204 2012, . 1206 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 1207 "Specification of the IP Flow Information Export (IPFIX) 1208 Protocol for the Exchange of Flow Information", STD 77, 1209 RFC 7011, DOI 10.17487/RFC7011, September 2013, 1210 . 1212 10.2. Informative References 1214 [I-D.ietf-i2nsf-terminology] 1215 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1216 Birkholz, "Interface to Network Security Functions (I2NSF) 1217 Terminology", draft-ietf-i2nsf-terminology-03 (work in 1218 progress), March 2017. 1220 [I-D.xibassnez-i2nsf-capability] 1221 Xia, L., Strassner, J., Basile, C., and D. Lopez, 1222 "Information Model of NSFs Capabilities", draft-xibassnez- 1223 i2nsf-capability-02 (work in progress), July 2017. 1225 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 1226 Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, 1227 . 1229 Acknowledgements 1231 Authors' Addresses 1233 Liang Xia 1234 Huawei 1236 Email: frank.xialiang@huawei.com 1238 Dacheng Zhang 1239 Huawei 1241 Email: dacheng.zhang@huawei.com 1243 Yi Wu 1244 Aliababa Group 1246 Email: anren.wy@alibaba-inc.com 1248 Rakesh Kumar 1249 Juniper Networks 1251 Email: rkkumar@juniper.net 1253 Anil Lohiya 1254 Juniper Networks 1256 Email: alohiya@juniper.net 1258 Henk Birkholz 1259 Fraunhofer SIT 1261 Email: henk.birkholz@sit.fraunhofer.de