--- 1/draft-ietf-i2nsf-nsf-monitoring-data-model-01.txt 2019-11-04 05:14:06.270677399 -0800 +++ 2/draft-ietf-i2nsf-nsf-monitoring-data-model-02.txt 2019-11-04 05:14:06.398680636 -0800 @@ -1,53 +1,67 @@ -I2NSF Working Group J. Jeong +Network Working Group J. Jeong Internet-Draft C. Chung Intended status: Standards Track Sungkyunkwan University -Expires: January 25, 2020 S. Hares +Expires: May 7, 2020 S. Hares L. Xia Huawei H. Birkholz Fraunhofer SIT - July 24, 2019 + November 4, 2019 I2NSF NSF Monitoring YANG Data Model - draft-ietf-i2nsf-nsf-monitoring-data-model-01 + draft-ietf-i2nsf-nsf-monitoring-data-model-02 Abstract - This document describes an information model and the corresponding + This document proposes an information model and the corresponding YANG data model for monitoring Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework. If the monitoring of NSFs is performed in a comprehensive way, it is - possible to detect malicious activity, anomalous behavior, and the - potential sign of denial of service attacks in a timely manner. This - monitoring functionality is based on the monitoring information that - is generated by NSFs. Thus, this document describes not only an - information model for monitoring NSFs along with a YANG data diagram, - but also the corresponding YANG data model for monitoring NSFs. + possible to detect the indication of malicious activity, anomalous + behavior or the potential sign of denial of service attacks in a + timely manner. This monitoring functionality is based on the + monitoring information that is generated by NSFs. Thus, this + document describes not only an information model for monitoring NSFs + along with a YANG data diagram, but also the corresponding YANG data + model for monitoring NSFs. + +Editorial Note (To be removed by RFC Editor) + + Please update these statements within the document with the RFC + number to be assigned to this document: + + "This version of this YANG module is part of RFC 6087;" + + "RFC XXXX: I2NSF NSF Monitoring YANG Data Model" + + "reference: RFC 6087" + + Please update the "revision" date of the YANG module. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 25, 2020. + This Internet-Draft will expire on May 7, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -65,76 +79,78 @@ 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases for NSF Monitoring Data . . . . . . . . . . . . . . 4 4. Classification of NSF Monitoring Data . . . . . . . . . . . . 5 4.1. Retention and Emission . . . . . . . . . . . . . . . . . 6 4.2. Notifications and Events . . . . . . . . . . . . . . . . 7 4.3. Unsolicited Poll and Solicited Push . . . . . . . . . . . 8 4.4. I2NSF Monitoring Terminology for Retained Information . . 8 5. Conveyance of NSF Monitoring Information . . . . . . . . . . 9 5.1. Information Types and Acquisition Methods . . . . . . . . 10 - 6. Basic Information Model for All Monitoring Data . . . . . . . 10 + 6. Basic Information Model for All Monitoring Data . . . . . . . 11 7. Extended Information Model for Monitoring Data . . . . . . . 11 - 7.1. System Alarm . . . . . . . . . . . . . . . . . . . . . . 11 - 7.1.1. Memory Alarm . . . . . . . . . . . . . . . . . . . . 11 + 7.1. System Alarms . . . . . . . . . . . . . . . . . . . . . . 11 + 7.1.1. Memory Alarm . . . . . . . . . . . . . . . . . . . . 12 7.1.2. CPU Alarm . . . . . . . . . . . . . . . . . . . . . . 12 7.1.3. Disk Alarm . . . . . . . . . . . . . . . . . . . . . 12 - 7.1.4. Hardware Alarm . . . . . . . . . . . . . . . . . . . 12 + 7.1.4. Hardware Alarm . . . . . . . . . . . . . . . . . . . 13 7.1.5. Interface Alarm . . . . . . . . . . . . . . . . . . . 13 + 7.2. System Events . . . . . . . . . . . . . . . . . . . . . . 13 7.2.1. Access Violation . . . . . . . . . . . . . . . . . . 13 7.2.2. Configuration Change . . . . . . . . . . . . . . . . 14 - 7.3. System Log . . . . . . . . . . . . . . . . . . . . . . . 14 - 7.3.1. Access Logs . . . . . . . . . . . . . . . . . . . . . 14 - 7.3.2. Resource Utilization Logs . . . . . . . . . . . . . . 15 - 7.3.3. User Activity Logs . . . . . . . . . . . . . . . . . 15 - 7.4. System Counters . . . . . . . . . . . . . . . . . . . . . 16 - 7.4.1. Interface counters . . . . . . . . . . . . . . . . . 16 - 7.5. NSF Events . . . . . . . . . . . . . . . . . . . . . . . 17 - 7.5.1. DDoS Event . . . . . . . . . . . . . . . . . . . . . 17 - 7.5.2. Session Table Event . . . . . . . . . . . . . . . . . 18 - 7.5.3. Virus Event . . . . . . . . . . . . . . . . . . . . . 18 - 7.5.4. Intrusion Event . . . . . . . . . . . . . . . . . . . 19 - 7.5.5. Botnet Event . . . . . . . . . . . . . . . . . . . . 20 - 7.5.6. Web Attack Event . . . . . . . . . . . . . . . . . . 21 - 7.6. NSF Logs . . . . . . . . . . . . . . . . . . . . . . . . 21 - 7.6.1. DDoS Logs . . . . . . . . . . . . . . . . . . . . . . 22 - 7.6.2. Virus Logs . . . . . . . . . . . . . . . . . . . . . 22 - 7.6.3. Intrusion Logs . . . . . . . . . . . . . . . . . . . 23 - 7.6.4. Botnet Logs . . . . . . . . . . . . . . . . . . . . . 23 - 7.6.5. DPI Logs . . . . . . . . . . . . . . . . . . . . . . 23 - 7.6.6. Vulnerability Scanning Logs . . . . . . . . . . . . . 24 - 7.6.7. Web Attack Logs . . . . . . . . . . . . . . . . . . . 25 + 7.3. NSF Events . . . . . . . . . . . . . . . . . . . . . . . 14 + 7.3.1. DDoS Event . . . . . . . . . . . . . . . . . . . . . 14 + 7.3.2. Session Table Event . . . . . . . . . . . . . . . . . 15 + 7.3.3. Virus Event . . . . . . . . . . . . . . . . . . . . . 15 + 7.3.4. Intrusion Event . . . . . . . . . . . . . . . . . . . 16 + 7.3.5. Botnet Event . . . . . . . . . . . . . . . . . . . . 17 + 7.3.6. Web Attack Event . . . . . . . . . . . . . . . . . . 18 + 7.4. System Logs . . . . . . . . . . . . . . . . . . . . . . . 19 + 7.4.1. Access Log . . . . . . . . . . . . . . . . . . . . . 19 + 7.4.2. Resource Utilization Log . . . . . . . . . . . . . . 19 + 7.4.3. User Activity Log . . . . . . . . . . . . . . . . . . 20 + 7.5. NSF Logs . . . . . . . . . . . . . . . . . . . . . . . . 21 + 7.5.1. DDoS Log . . . . . . . . . . . . . . . . . . . . . . 21 + 7.5.2. Virus Log . . . . . . . . . . . . . . . . . . . . . . 21 + 7.5.3. Intrusion Log . . . . . . . . . . . . . . . . . . . . 22 + 7.5.4. Botnet Log . . . . . . . . . . . . . . . . . . . . . 22 + 7.5.5. DPI Log . . . . . . . . . . . . . . . . . . . . . . . 23 + 7.5.6. Vulnerability Scanning Log . . . . . . . . . . . . . 23 + 7.5.7. Web Attack Log . . . . . . . . . . . . . . . . . . . 24 + 7.6. System Counter . . . . . . . . . . . . . . . . . . . . . 24 + 7.6.1. Interface counter . . . . . . . . . . . . . . . . . . 25 7.7. NSF Counters . . . . . . . . . . . . . . . . . . . . . . 25 - 7.7.1. Firewall counters . . . . . . . . . . . . . . . . . . 25 - 7.7.2. Policy Hit Counters . . . . . . . . . . . . . . . . . 26 + 7.7.1. Firewall counter . . . . . . . . . . . . . . . . . . 26 + 7.7.2. Policy Hit Counter . . . . . . . . . . . . . . . . . 27 8. NSF Monitoring Management in I2NSF . . . . . . . . . . . . . 27 9. Tree Structure . . . . . . . . . . . . . . . . . . . . . . . 28 - 10. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 36 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 + 10. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 37 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 12. Security Considerations . . . . . . . . . . . . . . . . . . . 72 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 72 - 13.2. Informative References . . . . . . . . . . . . . . . . . 74 + 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 73 + 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 73 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 73 + 15.1. Normative References . . . . . . . . . . . . . . . . . . 73 + 15.2. Informative References . . . . . . . . . . . . . . . . . 75 Appendix A. Changes from draft-ietf-i2nsf-nsf-monitoring-data- - model-00 . . . . . . . . . . . . . . . . . . . . . . 76 - Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 76 - Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 76 + model-01 . . . . . . . . . . . . . . . . . . . . . . 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 1. Introduction According to [I-D.ietf-i2nsf-terminology], the interface provided by - Network Security Functions (NSFs) (e.g., Firewall, IPS, Anti-DDoS, or + a Network Security Function (NSF) (e.g., Firewall, IPS, Anti-DDoS, or Anti-Virus function) to administrative entities (e.g., Security Controller) to enable remote management (i.e., configuring and monitoring) is referred to as an I2NSF NSF-Facing Interface + [I-D.ietf-i2nsf-nsf-facing-interface-dm]. Monitoring procedures intent to acquire vital types of data with respect to NSFs, (e.g., alarms, records, and counters) via data in motion (e.g., queries, notifications, and events). The monitoring of NSF plays an important role in an overall security framework, if it is done in a timely and comprehensive way. The monitoring information generated by an NSF can be a good, early indication of anomalous behavior or malicious activity, such as denial of service attacks (DoS). This document defines a comprehensive NSF monitoring information @@ -492,21 +508,21 @@ eight levels, from 0 to 7. The smaller the numeral is, the higher the severity is. 7. Extended Information Model for Monitoring Data This section covers the additional information associated with the system messages. The extended information model is only for the structured data such as alarm. Any unstructured data is specified with basic information model only. -7.1. System Alarm +7.1. System Alarms Characteristics: o acquisition_method: subscription o emission_type: on-change o dampening_type: no-dampening 7.1.1. Memory Alarm @@ -628,167 +644,31 @@ o group: Group to which a user belongs o login_ip_address: Login IP address of a user o authentication_mode: User authentication mode. e.g., Local Authentication, Third-Party Server Authentication, Authentication Exemption, SSO Authentication o message: Configuration is modified. -7.3. System Log - - Characteristics: - - o acquisition_method: subscription - - o emission_type: on-change - - o dampening_type: on-repetition - -7.3.1. Access Logs - - Access logs record administrators' login, logout, and operations on a - device. By analyzing them, security vulnerabilities can be - identified. The following information should be included in an - operation report: - - o Administrator: Administrator that operates on the device - - o login_ip_address: IP address used by an administrator to log in - - o login_mode: Specifies the administrator logs in mode e.g. root, - user - - o operation_type: The operation type that the administrator execute, - e.g., login, logout, and configuration. - - o result: Command execution result - o content: Operation performed by an administrator after login. - -7.3.2. Resource Utilization Logs - - Running reports record the device system's running status, which is - useful for device monitoring. The following information should be - included in running report: - - o system_status: The current system's running status - - o CPU_usage: Specifies the CPU usage. - - o memory_usage: Specifies the memory usage. - - o disk_usage: Specifies the disk usage. - - o disk_left: Specifies the available disk space left. - - o session_number: Specifies total concurrent sessions. - - o process_number: Specifies total number of systems processes. - - o in_traffic_rate: The total inbound traffic rate in pps - - o out_traffic_rate: The total outbound traffic rate in pps - - o in_traffic_speed: The total inbound traffic speed in bps - - o out_traffic_speed: The total outbound traffic speed in bps - -7.3.3. User Activity Logs - - User activity logs provide visibility into users' online records - (such as login time, online/lockout duration, and login IP addresses) - and the actions that users perform. User activity reports are - helpful to identify exceptions during a user's login and network - access activities. - - o user: Name of a user - - o group: Group to which a user belongs - - o login_ip_address: Login IP address of a user - - o authentication_mode: User authentication mode. e.g., Local - Authentication, Third-Party Server Authentication, Authentication - Exemption, SSO Authentication - - o access_mode: User access mode. e.g., PPP, SVN, LOCAL - - o online_duration: Online duration - - o lockout_duration: Lockout duration - - o type: User activities. e.g., Successful User Login, Failed Login - attempts, User Logout, Successful User Password Change, Failed - User Password Change, User Lockout, User Unlocking, Unknown - - o cause: Cause of a failed user activity - -7.4. System Counters - - Characteristics: - - o acquisition_method: subscription or query - - o emission_type: periodical - - o dampening_type: none - -7.4.1. Interface counters - - Interface counters provide visibility into traffic into and out of an - NSF, and bandwidth usage. - - o interface_name: Network interface name configured in NSF - - o in_total_traffic_pkts: Total inbound packets - - o out_total_traffic_pkts: Total outbound packets - - o in_total_traffic_bytes: Total inbound bytes - - o out_total_traffic_bytes: Total outbound bytes - - o in_drop_traffic_pkts: Total inbound drop packets - - o out_drop_traffic_pkts: Total outbound drop packets - - o in_drop_traffic_bytes: Total inbound drop bytes - - o out_drop_traffic_bytes: Total outbound drop bytes - - o in_traffic_ave_rate: Inbound traffic average rate in pps - - o in_traffic_peak_rate: Inbound traffic peak rate in pps - o in_traffic_ave_speed: Inbound traffic average speed in bps - - o in_traffic_peak_speed: Inbound traffic peak speed in bps - - o out_traffic_ave_rate: Outbound traffic average rate in pps - - o out_traffic_peak_rate: Outbound traffic peak rate in pps - - o out_traffic_ave_speed: Outbound traffic average speed in bps - - o out_traffic_peak_speed: Outbound traffic peak speed in bps - -7.5. NSF Events +7.3. NSF Events Characteristics: o acquisition_method: subscription o emission_type: on-change o dampening_type: none -7.5.1. DDoS Event +7.3.1. DDoS Event The following information should be included in a DDoS Event: o event_name: SEC_EVENT_DDoS o sub_attack_type: Any one of SYN flood, ACK flood, SYN-ACK flood, FIN/RST flood, TCP Connection flood, UDP flood, ICMP flood, HTTPS flood, HTTP flood, DNS query flood, DNS reply flood, SIP flood, and etc. @@ -800,41 +680,42 @@ o end_time: The time stamp indicating when the attack ended. If the attack is still undergoing when sending out the alarm, this field can be empty. o attack_rate: The PPS of attack traffic o attack_speed: the bps of attack traffic o rule_id: The ID of the rule being triggered + o rule_name: The name of the rule being triggered o profile: Security profile that traffic matches. -7.5.2. Session Table Event +7.3.2. Session Table Event The following information should be included in a Session Table Event: o event_name: SESSION_USAGE_HIGH o current: The number of concurrent sessions o max: The maximum number of sessions that the session table can support o threshold: The threshold triggering the event o message: The number of session table exceeded the threshold. -7.5.3. Virus Event +7.3.3. Virus Event The following information should be included in a Virus Event: o event_Name: SEC_EVENT_VIRUS o virus_type: Type of the virus. e.g., trojan, worm, macro virus type o virus_name: Name of the virus @@ -863,21 +744,21 @@ o raw_info: The information describing the packet triggering the event. o rule_id: The ID of the rule being triggered o rule_name: The name of the rule being triggered o profile: Security profile that traffic matches. -7.5.4. Intrusion Event +7.3.4. Intrusion Event The following information should be included in an Intrusion Event: o event_name: The name of event. e.g., SEC_EVENT_Intrusion o sub_attack_type: Attack type, e.g., brutal force and buffer overflow o src_ip: The source IP address of the packet @@ -895,24 +775,25 @@ o app: The employed application layer protocol. e.g.,HTTP and FTP o rule_id: The ID of the rule being triggered o rule_name: The name of the rule being triggered o profile: Security profile that traffic matches o intrusion_info: Simple description of intrusion + o raw_info: The information describing the packet triggering the event -7.5.5. Botnet Event +7.3.5. Botnet Event The following information should be included in a Botnet Event: o event_name: The name of event. e.g., SEC_EVENT_Botnet o botnet_name: The name of the detected botnet o src_ip: The source IP address of the packet o dst_ip: The destination IP address of the packet @@ -943,26 +823,27 @@ 6. The packet from the IRC/WEB server to the attacker 7. The packet from the zombie host to the victim o botnet_info: Simple description of Botnet o rule_id: The ID of the rule being triggered o rule_name: The name of the rule being triggered + o profile: Security profile that traffic matches o raw_info: The information describing the packet triggering the event. -7.5.6. Web Attack Event +7.3.6. Web Attack Event The following information should be included in a Web Attack Alarm: o event_name: The name of event. e.g., SEC_EVENT_WebAttack o sub_attack_type: Concrete web attack type. e.g., SQL injection, command injection, XSS, CSRF o src_ip: The source IP address of the packet @@ -985,30 +865,119 @@ o filtering_type: URL filtering type. e.g., Blacklist, Whitelist, User-Defined, Predefined, Malicious Category, and Unknown o rule_id: The ID of the rule being triggered o rule_name: The name of the rule being triggered o profile: Security profile that traffic matches -7.6. NSF Logs +7.4. System Logs Characteristics: o acquisition_method: subscription + + o emission_type: on-change + + o dampening_type: on-repetition + +7.4.1. Access Log + + Access logs record administrators' login, logout, and operations on a + device. By analyzing them, security vulnerabilities can be + identified. The following information should be included in an + operation report: + + o Administrator: Administrator that operates on the device + + o login_ip_address: IP address used by an administrator to log in + + o login_mode: Specifies the administrator logs in mode e.g. root, + user + + o operation_type: The operation type that the administrator execute, + e.g., login, logout, and configuration. + + o result: Command execution result + + o content: Operation performed by an administrator after login. + +7.4.2. Resource Utilization Log + + Running reports record the device system's running status, which is + useful for device monitoring. The following information should be + included in running report: + + o system_status: The current system's running status + + o CPU_usage: Specifies the CPU usage. + + o memory_usage: Specifies the memory usage. + + o disk_usage: Specifies the disk usage. + + o disk_left: Specifies the available disk space left. + + o session_number: Specifies total concurrent sessions. + + o process_number: Specifies total number of systems processes. + + o in_traffic_rate: The total inbound traffic rate in pps + + o out_traffic_rate: The total outbound traffic rate in pps + + o in_traffic_speed: The total inbound traffic speed in bps + + o out_traffic_speed: The total outbound traffic speed in bps + +7.4.3. User Activity Log + + User activity logs provide visibility into users' online records + (such as login time, online/lockout duration, and login IP addresses) + and the actions that users perform. User activity reports are + helpful to identify exceptions during a user's login and network + access activities. + + o user: Name of a user + + o group: Group to which a user belongs + + o login_ip_address: Login IP address of a user + + o authentication_mode: User authentication mode. e.g., Local + Authentication, Third-Party Server Authentication, Authentication + Exemption, SSO Authentication + + o access_mode: User access mode. e.g., PPP, SVN, LOCAL + + o online_duration: Online duration + + o lockout_duration: Lockout duration + o type: User activities. e.g., Successful User Login, Failed Login + attempts, User Logout, Successful User Password Change, Failed + User Password Change, User Lockout, User Unlocking, Unknown + + o cause: Cause of a failed user activity + +7.5. NSF Logs + + Characteristics: + + o acquisition_method: subscription + o emission_type: on-change o dampening_type: on_repetition -7.6.1. DDoS Logs +7.5.1. DDoS Log Besides the fields in a DDoS Alarm, the following information should be included in a DDoS Logs: o attack_type: DDoS o attack_ave_rate: The average pps of the attack traffic within the recorded time o attack_ave_speed: The average bps of the attack traffic within the @@ -1017,75 +986,74 @@ o attack_pkt_num: The number of attack packets within the recorded time o attack_src_ip: The source IP addresses of attack traffics. If there are a large number of IP addresses, then pick a certain number of resources according to different rules. o action: Actions against DDoS attacks. e.g., Allow, Alert, Block, Discard, Declare, Block-ip, and Block-service. -7.6.2. Virus Logs +7.5.2. Virus Log Besides the fields in a Virus Alarm, the following information should be included in a Virus Logs: o attack_type: Virus o protocol: The transport layer protocol - o app: The name of the application layer protocol o times: The time of detecting the virus o action: The actions dealing with the virus. e.g., alert and block o os: The OS that the virus will affect. e.g., all, android, ios, unix, and windows -7.6.3. Intrusion Logs +7.5.3. Intrusion Log Besides the fields in an Intrusion Alarm, the following information should be included in an Intrusion Logs: o attack_type: Intrusion o times: The times of intrusions happened in the recorded time o os: The OS that the intrusion will affect. e.g., all, android, ios, unix, and windows o action: The actions dealing with the intrusions. e.g., Allow, Alert, Block, Discard, Declare, Block-ip, and Block-service o attack_rate: NUM the pps of attack traffic o attack_speed: NUM the bps of attack traffic -7.6.4. Botnet Logs +7.5.4. Botnet Log Besides the fields in a Botnet Alarm, the following information should be included in a Botnet Logs: o attack_type: Botnet o botnet_pkt_num:The number of the packets sent to or from the detected botnet o action: The actions dealing with the detected packets. e.g., Allow, Alert, Block, Discard, Declare, Block-ip, and Block- service. o os: The OS that the attack aims at. e.g., all, android, ios, unix, and windows. -7.6.5. DPI Logs +7.5.5. DPI Log DPI Logs provide statistics on uploaded and downloaded files and data, sent and received emails, and alert and block records on websites. It is helpful to learn risky user behaviors and why access to some URLs is blocked or allowed with an alert record. o type: DPI action types. e.g., File Blocking, Data Filtering, and Application Behavior Control o file_name: The file name @@ -1113,21 +1082,21 @@ o app: Application type of traffic o policy_id: Security policy id that traffic matches o policy_name: Security policy name that traffic matches o action: Action defined in the file blocking rule, data filtering rule, or application behavior control rule that traffic matches. -7.6.6. Vulnerability Scanning Logs +7.5.6. Vulnerability Scanning Log Vulnerability scanning logs record the victim host and its related vulnerability information that should to be fixed. The following information should be included in the report: o victim_ip: IP address of the victim host which has vulnerabilities o vulnerability_id: The vulnerability id o vulnerability_level: The vulnerability level. e.g., high, middle, @@ -1129,57 +1098,107 @@ o victim_ip: IP address of the victim host which has vulnerabilities o vulnerability_id: The vulnerability id o vulnerability_level: The vulnerability level. e.g., high, middle, and low o OS: The operating system of the victim host o service: The service which has vulnerability in the victim host + o protocol: The protocol type. e.g., TCP and UDP o port: The port number o vulnerability_info: The information about the vulnerability o fix_suggestion: The fix suggestion to the vulnerability. -7.6.7. Web Attack Logs +7.5.7. Web Attack Log Besides the fields in a Web Attack Alarm, the following information should be included in a Web Attack Report: o attack_type: Web Attack o rsp_code: Response code o req_clientapp: The client application o req_cookies: Cookies o req_host: The domain name of the requested host o raw_info: The information describing the packet triggering the event. +7.6. System Counter + + Characteristics: + + o acquisition_method: subscription or query + + o emission_type: periodical + + o dampening_type: none + +7.6.1. Interface counter + + Interface counters provide visibility into traffic into and out of an + NSF, and bandwidth usage. + + o interface_name: Network interface name configured in NSF + + o in_total_traffic_pkts: Total inbound packets + + o out_total_traffic_pkts: Total outbound packets + + o in_total_traffic_bytes: Total inbound bytes + + o out_total_traffic_bytes: Total outbound bytes + + o in_drop_traffic_pkts: Total inbound drop packets + + o out_drop_traffic_pkts: Total outbound drop packets + + o in_drop_traffic_bytes: Total inbound drop bytes + + o out_drop_traffic_bytes: Total outbound drop bytes + + o in_traffic_ave_rate: Inbound traffic average rate in pps + + o in_traffic_peak_rate: Inbound traffic peak rate in pps + + o in_traffic_ave_speed: Inbound traffic average speed in bps + + o in_traffic_peak_speed: Inbound traffic peak speed in bps + + o out_traffic_ave_rate: Outbound traffic average rate in pps + + o out_traffic_peak_rate: Outbound traffic peak rate in pps + + o out_traffic_ave_speed: Outbound traffic average speed in bps + + o out_traffic_peak_speed: Outbound traffic peak speed in bps + 7.7. NSF Counters Characteristics: o acquisition_method: subscription or query o emission_type: periodical o dampening_type: none -7.7.1. Firewall counters +7.7.1. Firewall counter Firewall counters provide visibility into traffic signatures, bandwidth usage, and how the configured security and bandwidth policies have been applied. o src_zone: Source security zone of traffic o dst_zone: Destination security zone of traffic o src_region: Source region of traffic @@ -1211,28 +1231,27 @@ o in_traffic_ave_rate: Inbound traffic average rate in pps o in_traffic_peak_rate: Inbound traffic peak rate in pps o in_traffic_ave_speed: Inbound traffic average speed in bps o in_traffic_peak_speed: Inbound traffic peak speed in bps o out_traffic_ave_rate: Outbound traffic average rate in pps - o out_traffic_peak_rate: Outbound traffic peak rate in pps o out_traffic_ave_speed: Outbound traffic average speed in bps o out_traffic_peak_speed: Outbound traffic peak speed in bps. -7.7.2. Policy Hit Counters +7.7.2. Policy Hit Counter Policy Hit Counters record the security policy that traffic matches and its hit count. It can check if policy configurations are correct. o src_zone: Source security zone of traffic o dst_zone: Destination security zone of traffic o src_region: Source region of the traffic @@ -1693,21 +1712,21 @@ +--ro module-name? string +--ro severity? severity Figure 1: Information Model for NSF Monitoring 10. YANG Data Model This section introduces a YANG data model for the information model of the NSF monitoring information model. - file "ietf-i2nsf-monitor@2019-07-23.yang" + file "ietf-i2nsf-monitor@2019-11-04.yang" module ietf-i2nsf-monitor { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-monitor"; prefix iim; import ietf-inet-types{ prefix inet; reference "Section 4 of RFC 6991"; @@ -1743,22 +1761,22 @@ Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 6087; see the RFC itself for full legal notices."; - revision "2019-07-23" { - description "First revision"; + revision "2019-11-04" { + description "The third revision"; reference "RFC XXXX: I2NSF NSF Monitoring YANG Data Model"; } typedef severity { type enumeration { enum high { description "high-level"; } @@ -3421,23 +3443,53 @@ The current mainstream security technologies (i.e., TLS, DTLS, IPSEC, and X.509 PKI) can be employed appropriately to provide the above security functions. In addition, to defend against the DDoS attack caused by a lot of NSFs sending massive notifications to the security controller, the rate limiting or similar mechanisms should be considered in an NSF and security controller, whether in advance or just in the process of DDoS attack. -13. References +13. Acknowledgments -13.1. Normative References + This work was supported by Institute of Information & Communications + Technology Planning & Evaluation (IITP) grant funded by the Ministry + of Science and ICT (MSIT), Korea, (R-20160222-002755, Cloud based + Security Intelligence Technology Development for the Customized + Security Service Provisioning). + + This work was supported in part by the MSIT under the Information + Technology Research Center (ITRC) support program (IITP- + 2019-2017-0-01633) supervised by the IITP. + +14. Contributors + + This document is made by the group effort of I2NSF working group. + Many people actively contributed to this document. The following are + considered co-authors: + + o Jinyong Tim Kim (Sungkyunkwan University) + + o Dongjin Hong (Sungkyunkwan University) + + o Dacheng Zhang (Huawei) + + o Yi Wu (Aliababa Group) + + o Rakesh Kumar (Juniper Networks) + + o Anil Lohiya (Juniper Networks) + +15. References + +15.1. Normative References [I-D.ietf-netconf-subscribed-notifications] Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Event Notifications", draft-ietf-netconf-subscribed-notifications-26 (work in progress), May 2019. [I-D.ietf-netconf-yang-push] Clemm, A. and E. Voit, "Subscription to YANG Datastores", draft-ietf-netconf-yang-push-25 (work in progress), May @@ -3511,123 +3563,88 @@ [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . -13.2. Informative References +15.2. Informative References [I-D.ietf-i2nsf-capability] Xia, L., Strassner, J., Basile, C., and D. Lopez, "Information Model of NSFs Capabilities", draft-ietf- i2nsf-capability-05 (work in progress), April 2019. [I-D.ietf-i2nsf-consumer-facing-interface-dm] Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares, "I2NSF Consumer-Facing Interface YANG Data Model", draft- - ietf-i2nsf-consumer-facing-interface-dm-05 (work in - progress), June 2019. + ietf-i2nsf-consumer-facing-interface-dm-06 (work in + progress), July 2019. [I-D.ietf-i2nsf-nsf-facing-interface-dm] Kim, J., Jeong, J., J., J., PARK, P., Hares, S., and Q. Lin, "I2NSF Network Security Function-Facing Interface YANG Data Model", draft-ietf-i2nsf-nsf-facing-interface- - dm-06 (work in progress), June 2019. + dm-07 (work in progress), July 2019. [I-D.ietf-i2nsf-registration-interface-dm] Hyun, S., Jeong, J., Roh, T., Wi, S., J., J., and P. PARK, "I2NSF Registration Interface YANG Data Model", draft- - ietf-i2nsf-registration-interface-dm-04 (work in - progress), June 2019. + ietf-i2nsf-registration-interface-dm-05 (work in + progress), July 2019. [I-D.ietf-i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Birkholz, "Interface to Network Security Functions (I2NSF) Terminology", draft-ietf-i2nsf-terminology-08 (work in progress), July 2019. [I-D.yang-i2nsf-nfv-architecture] Yang, H., Kim, Y., Jeong, J., and J. Kim, "I2NSF on the NFV Reference Architecture", draft-yang-i2nsf-nfv- architecture-05 (work in progress), July 2019. [I-D.yang-i2nsf-security-policy-translation] - Yang, J., Jeong, J., and J. Kim, "Security Policy - Translation in Interface to Network Security Functions", - draft-yang-i2nsf-security-policy-translation-03 (work in - progress), March 2019. + Jeong, J., Yang, J., Chung, C., and J. Kim, "Security + Policy Translation in Interface to Network Security + Functions", draft-yang-i2nsf-security-policy- + translation-04 (work in progress), July 2019. [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, . [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, January 2011, . [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . -Appendix A. Changes from draft-ietf-i2nsf-nsf-monitoring-data-model-00 +Appendix A. Changes from draft-ietf-i2nsf-nsf-monitoring-data-model-01 The following changes are made from draft-ietf-i2nsf-nsf-monitoring- - data-model-00: - - o In Section 2.1, Requirements Notation is updated. - - o In Section 2.2, the reference [RFC8329] is added. - - o In Section 2.3, the reference [RFC8342] is added. - - o In Section 11, the reference [RFC6020] is added. - - o Many editorial errors have been corrected. - -Appendix B. Acknowledgments - - This work was supported by Institute of Information & Communications - Technology Planning & Evaluation (IITP) grant funded by the Korea - MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based - Security Intelligence Technology Development for the Customized - Security Service Provisioning). - - This work was supported in part by the MSIT, Korea, under the ITRC - (Information Technology Research Center) support program (IITP- - 2019-2017-0-01633) supervised by the IITP. - -Appendix C. Contributors - - This document is made by the group effort of I2NSF working group. - Many people actively contributed to this document. The following are - considered co-authors: - - o Jinyong Tim Kim (Sungkyunkwan University) - - o Dongjin Hong (Sungkyunkwan University) - - o Dacheng Zhang (Huawei) - - o Yi Wu (Aliababa Group) - - o Rakesh Kumar (Juniper Networks) + data-model-01: - o Anil Lohiya (Juniper Networks) + o Section 7 is reorganized such that the subsections for the + monitored objects (i.e., event, log, and counter) of System and + NSF are listed up pairwisely with a pair of System and NSF except + alarm because alarm is a monitored object to only System. Authors' Addresses Jaehoon Paul Jeong Department of Computer Science and Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea @@ -3636,21 +3653,21 @@ EMail: pauljeong@skku.edu URI: http://iotlab.skku.edu/people-jaehoon-jeong.php Chaehong Chung Department of Electronic, Electrical and Computer Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea - Phone: +82 10 8541 7158 + Phone: +82 31 299 4957 EMail: darkhong@skku.edu Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA Phone: +1-734-604-0332 EMail: shares@ndzh.com