--- 1/draft-ietf-i2nsf-nsf-monitoring-data-model-11.txt 2021-11-17 06:13:11.649825550 -0800 +++ 2/draft-ietf-i2nsf-nsf-monitoring-data-model-12.txt 2021-11-17 06:13:11.805829450 -0800 @@ -1,23 +1,23 @@ Network Working Group J. Jeong, Ed. Internet-Draft P. Lingga Intended status: Standards Track Sungkyunkwan University -Expires: 18 April 2022 S. Hares +Expires: 21 May 2022 S. Hares L. Xia Huawei H. Birkholz Fraunhofer SIT - 15 October 2021 + 17 November 2021 I2NSF NSF Monitoring Interface YANG Data Model - draft-ietf-i2nsf-nsf-monitoring-data-model-11 + draft-ietf-i2nsf-nsf-monitoring-data-model-12 Abstract This document proposes an information model and the corresponding YANG data model of an interface for monitoring Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework. If the monitoring of NSFs is performed with the NSF monitoring interface in a comprehensive way, it is possible to detect the indication of malicious activity, anomalous behavior, the potential sign of denial of service attacks, or system overload in a @@ -35,21 +35,21 @@ 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 18 April 2022. + This Internet-Draft will expire on 21 May 2022. Copyright Notice Copyright (c) 2021 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 carefully, as they describe your rights @@ -58,39 +58,39 @@ as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 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, Events, and Records . . . . . . . . . . . 8 + 4.2. Notifications, Events, and Records . . . . . . . . . . . 7 4.3. Unsolicited Poll and Solicited Push . . . . . . . . . . . 8 5. Basic Information Model for Monitoring Data . . . . . . . . . 9 6. Extended Information Model for Monitoring Data . . . . . . . 9 6.1. System Alarms . . . . . . . . . . . . . . . . . . . . . . 10 6.1.1. Memory Alarm . . . . . . . . . . . . . . . . . . . . 10 - 6.1.2. CPU Alarm . . . . . . . . . . . . . . . . . . . . . . 11 + 6.1.2. CPU Alarm . . . . . . . . . . . . . . . . . . . . . . 10 6.1.3. Disk Alarm . . . . . . . . . . . . . . . . . . . . . 11 6.1.4. Hardware Alarm . . . . . . . . . . . . . . . . . . . 11 6.1.5. Interface Alarm . . . . . . . . . . . . . . . . . . . 12 6.2. System Events . . . . . . . . . . . . . . . . . . . . . . 12 6.2.1. Access Violation . . . . . . . . . . . . . . . . . . 12 6.2.2. Configuration Change . . . . . . . . . . . . . . . . 13 6.2.3. Session Table Event . . . . . . . . . . . . . . . . . 13 - 6.2.4. Traffic Flows . . . . . . . . . . . . . . . . . . . . 14 + 6.2.4. Traffic Flows . . . . . . . . . . . . . . . . . . . . 13 6.3. NSF Events . . . . . . . . . . . . . . . . . . . . . . . 14 6.3.1. DDoS Detection . . . . . . . . . . . . . . . . . . . 14 6.3.2. Virus Event . . . . . . . . . . . . . . . . . . . . . 15 - 6.3.3. Intrusion Event . . . . . . . . . . . . . . . . . . . 16 + 6.3.3. Intrusion Event . . . . . . . . . . . . . . . . . . . 15 6.3.4. Web Attack Event . . . . . . . . . . . . . . . . . . 16 6.3.5. VoIP/VoLTE Event . . . . . . . . . . . . . . . . . . 17 6.4. System Logs . . . . . . . . . . . . . . . . . . . . . . . 18 6.4.1. Access Log . . . . . . . . . . . . . . . . . . . . . 18 6.4.2. Resource Utilization Log . . . . . . . . . . . . . . 18 6.4.3. User Activity Log . . . . . . . . . . . . . . . . . . 19 6.5. NSF Logs . . . . . . . . . . . . . . . . . . . . . . . . 20 6.5.1. Deep Packet Inspection Log . . . . . . . . . . . . . 20 6.6. System Counter . . . . . . . . . . . . . . . . . . . . . 20 @@ -102,26 +102,26 @@ 8. Tree Structure . . . . . . . . . . . . . . . . . . . . . . . 25 9. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 32 10. I2NSF Event Stream . . . . . . . . . . . . . . . . . . . . . 78 11. XML Examples for I2NSF NSF Monitoring . . . . . . . . . . . . 79 11.1. I2NSF System Detection Alarm . . . . . . . . . . . . . . 79 11.2. I2NSF Interface Counters . . . . . . . . . . . . . . . . 80 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82 13. Security Considerations . . . . . . . . . . . . . . . . . . . 82 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 84 - 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 - 16.1. Normative References . . . . . . . . . . . . . . . . . . 84 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 85 + 16.1. Normative References . . . . . . . . . . . . . . . . . . 85 16.2. Informative References . . . . . . . . . . . . . . . . . 88 Appendix A. Changes from - draft-ietf-i2nsf-nsf-monitoring-data-model-09 . . . . . . 89 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89 + draft-ietf-i2nsf-nsf-monitoring-data-model-11 . . . . . . 90 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90 1. Introduction According to [RFC8329], the interface provided by a Network Security Function (NSF) (e.g., Firewall, IPS, or Anti-DDoS function) to administrative entities (e.g., Security Controller) to enable remote management (i.e., configuring and monitoring) is referred to as an I2NSF Monitoring Interface. This interface enables the sharing of vital data from the NSFs (e.g., alarms, records, and counters) to the Security Controller through a variety of mechanisms (e.g., queries, @@ -227,22 +227,22 @@ set of capabilities that creates information about some context with monitoring data (i.e., monitoring information), composition, configuration, state or behavior of that system entity. This information is intended to be provided to other consumers of information and in the scope of this document, which deals with NSF monitoring data in an automated fashion. 4.1. Retention and Emission A system entity (e.g., NSF) first retains I2NSF monitoring data - inside its own system before emitting the information another I2NSF - component (e.g., NSF Data Collector). The I2NSF monitoring + inside its own system before emitting the information to another + I2NSF component (e.g., NSF Data Collector). The I2NSF monitoring information consist of I2NSF Event, I2NSF Record, and I2NSF Counter as follows: I2NSF Event: I2NSF Event is defined as an important occurrence over time, that is, a change in the system being managed or a change in the environment of the system being managed. An I2NSF Event requires immediate attention and should be notified as soon as possible. When used in the context of an (imperative) I2NSF Policy Rule, an I2NSF Event is used to determine whether the Condition clause of that Policy Rule can be evaluated or not. The @@ -278,35 +278,27 @@ I2NSF Counter: An I2NSF Counter is defined as a specific representation of continuous value changes of information elements that occur very frequently. Prominent examples are network interface counters for protocol data unit (PDU) amount, byte amount, drop counters, and error counters. Counters are useful in debugging and visibility into operational behavior of a system entity (e.g., NSF). When an NSF data collector asks for the value of a counter to it, a system entity emits - For the utilization of the storage space for accumulated NSF - monitoring data, all of the information MUST provide the general - information (e.g., timestamp) for purging existing records, which is - discussed in Section 5. This document provides a YANG data model in - Section 9 for the important I2NSF monitoring information that should - be retained. All of the information in the data model is considered - important and should be kept permanently as the information might be - useful in many circumstances in the future. The allowed cases for - removing some monitoring information include the following: - - * When the system storage is full to create a fresh record - [RFC4949], the oldest record can be removed. - - * The administrator deletes existing records manually after - analyzing the information in them. + The retention of I2NSF monitoring information listed in Section 9 may + be affected by the importance of the data. The importance of the + data could be context-dependent, where it may not just be based on + the type of data, but may also depend on where it is deployed, e.g., + a test lab and testbed. The local policy and configuration will + dictate the policies and procedures to review, archive, or purge the + collected monitoring data. The I2NSF monitoring information retained on a system entity (e.g., NSF) may be delivered to a corresponding I2NSF User via an NSF data collector. The information consists of the aggregated records, typically in the form of log-files or databases. For the NSF Monitoring Interface to deliver the information to the NSF data collector, the NSF needs to accommodate standardized delivery protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. The NSF data collector can forward the information to the I2NSF User through one of standardized delivery protocols. The interface for this @@ -461,21 +453,21 @@ 6.1.2. CPU Alarm CPU is the Central Processing Unit that executes basic operations of the system. The cpu-alarm is emitted when the CPU usage exceeds the threshold. The following information should be included in a CPU Alarm: * event-name: cpu-alarm. - * usage: Specifies the size of CPU used. + * usage: Specifies the CPU utilization. * threshold: The threshold triggering the event. * severity: The severity of the alarm such as critical, high, medium, and low. * message: Simple information such as "The CPU usage exceeded the threshold" or with extra information. 6.1.3. Disk Alarm @@ -654,53 +646,54 @@ * 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. * attack-rate: The packets per second of attack traffic. * attack-speed: The bytes per second of attack traffic. * rule-name: The name of the I2NSF Policy Rule being triggered. Note that rule-name is used to match a detected NSF event with a - policy rule in [I-D.ietf-i2nsf-nsf-facing-interface-dm], and also - that there is no rule-name in a system event. + policy rule in [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 6.3.2. Virus Event The following information should be included in a Virus Event: * event-name: detection-virus. * virus: Type of the virus. e.g., trojan, worm, macro virus type. * virus-name: Name of the virus. - * dst-ip: The destination IP address of the packet where the virus - is found. + * dst-ip: The destination IP address of the flow where the virus is + found. - * src-ip: The source IP address of the packet where the virus is + * src-ip: The source IP address of the flow where the virus is found. - * src-port: The source port of the packet where the virus is found. + * src-port: The source port of the flow where the virus is found. - * dst-port: The destination port of the packet where the virus is + * dst-port: The destination port of the flow where the virus is found. - * src-location: The source geographical location (e.g., country and - city) of the virus. + * src-location: The geographical location (e.g., country and city) + of the src-ip field. - * dst-location: The destination geographical location (e.g., country - and city) of the virus. + * dst-location: The geographical location (e.g., country and city) + of the dst-ip field. - * file-type: The type of the file where the virus is hided within. + * os: The operating system of the host that has the virus. - * file-name: The name of the file where the virus is hided within. + * file-type: The type of the file where the virus is hidden. + + * file-name: The name of the file where the virus is hidden. * raw-info: The information describing the packet triggering the event. * rule-name: The name of the rule being triggered. 6.3.3. Intrusion Event The following information should be included in an Intrusion Event: @@ -710,24 +703,24 @@ * src-ip: The source IP address of the flow. * dst-ip: The destination IP address of the flow. * src-port:The source port number of the flow. * dst-port: The destination port number of the flow * src-location: The source geographical location (e.g., country and - city) of the flow. + city) of the src-ip field. * dst-location: The destination geographical location (e.g., country - and city) of the flow. + and city) of the dst-ip field. * protocol: The employed transport layer protocol. e.g., TCP and UDP. * app: The employed application layer protocol. e.g., HTTP and FTP. * rule-name: The name of the I2NSF Policy Rule being triggered. * raw-info: The information describing the flow triggering the event. @@ -743,40 +736,37 @@ * src-ip: The source IP address of the packet. * dst-ip: The destination IP address of the packet. * src-port: The source port number of the packet. * dst-port: The destination port number of the packet. * src-location: The source geographical location (e.g., country and - city) of the packet. + city) of the src-ip field. * dst-location: The destination geographical location (e.g., country - and city) of the packet. + and city) of the dst-ip field. - * request-method: The method of requirement. For instance, "PUT" + * req-method: The HTTP method of the request. For instance, "PUT" and "GET" in HTTP. - * req-uri: Requested URI. - - * response-code: The HTTP Response code. + * req-target: The HTTP Request Target. - * req-user-agent: The HTTP request user agent header field. + * response-code: The HTTP Response status code. - * req-cookies: The HTTP Cookie previously sent by the server with - Set-Cookie. + * req-user-agent: The HTTP User-Agent header field of the request. - * req-host: The domain name of the requested host. + * cookies: The HTTP Set-Cookie header field of the response. - * uri-category: Matched URI category. + * req-host: The HTTP Host header field of the request. * filtering-type: URL filtering type. e.g., deny-list, allow-list, and unknown. * rule-name: The name of the I2NSF Policy Rule being triggered. 6.3.5. VoIP/VoLTE Event The following information should be included in a VoIP/VoLTE Event: @@ -791,24 +781,24 @@ * src-ip: The source IP address of the VoIP/VoLTE. * dst-ip: The destination IP address of the VoIP/VoLTE. * src-port: The source port number of the VoIP/VoLTE. * dst-port: The destination port number of VoIP/VoLTE. * src-location: The source geographical location (e.g., country and - city) of the VoIP/VoLTE. + city) of the src-ip field. * dst-location: The destination geographical location (e.g., country - and city) of the VoIP/VoLTE. + and city) of the dst-ip field. * rule-name: The name of the I2NSF Policy Rule being triggered. 6.4. System Logs System log is a record that is used to monitor the activity of the user on the NSF and the status of the NSF. System logs have the following characteristics: * acquisition-method: subscription @@ -821,22 +811,22 @@ 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: * username: The username that operates on the device. * login-ip: IP address used by an administrator to log in. - * login-mode: Specifies the administrator logs in mode e.g. - administrator, user, and guest. + * login-role: The login role to specify the privilege level of the + user account, e.g., administrator, user, and guest. * operation-type: The operation type that the administrator execute, e.g., login, logout, configuration, and other. * input: The operation performed by a user after login. The operation is a command given by a user. * output: The result after executing the input. 6.4.2. Resource Utilization Log @@ -1441,25 +1432,25 @@ | +--ro dst-ip? inet:ip-address-no-zone | +--ro dst-port? inet:port-number | +--ro rule-name -> /nsfintf:i2nsf-security-policy/rules/rule-name | +--ro raw-info? string | +--ro src-ip? inet:ip-address-no-zone | +--ro src-port? inet:port-number | +--ro src-location? string | +--ro dst-location? string | +--ro attack-type? identityref - | +--ro request-method? identityref - | +--ro req-uri? string + | +--ro req-method? identityref + | +--ro req-target? string | +--ro filtering-type* identityref | +--ro req-user-agent? string - | +--ro req-cookie? string + | +--ro cookies? string | +--ro req-host? string | +--ro response-code? string | +--ro acquisition-method? identityref | +--ro emission-type? identityref | +--ro dampening-type? identityref | +--ro action* log-action | +--ro message? string | +--ro vendor-name? string | +--ro nsf-name? union | +--ro severity? severity @@ -1495,26 +1486,26 @@ Figure 1: Information Model for NSF Monitoring 9. YANG Data Model This section describes a YANG module of I2NSF NSF Monitoring. The data model provided in this document uses identities to be used to get information of the monitored of an NSF's monitoring data. Every identity used in the document gives information or status about the current situation of an NSF. This YANG module imports from [RFC6991], and makes references to [RFC0768][RFC0791] - [RFC0792][RFC0793][RFC0854] [RFC1939][RFC0959][RFC3501] - [RFC4340][RFC4443][RFC4960] [RFC5321][RFC6242][RFC7230] - [RFC7231][RFC8200][RFC8641] [I-D.ietf-tcpm-rfc793bis] + [RFC0792][RFC0793][RFC0854] [RFC1939][RFC0959][RFC4340] + [RFC4443][RFC4960][RFC5321] [RFC6242][RFC6265][RFC7230] + [RFC7231][RFC8200][RFC8641] [RFC9051] [I-D.ietf-tcpm-rfc793bis] [IANA-HTTP-Status-Code] [IANA-Media-Types]. - file "ietf-i2nsf-nsf-monitoring@2021-10-15.yang" + file "ietf-i2nsf-nsf-monitoring@2021-11-17.yang" module ietf-i2nsf-nsf-monitoring { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-i2nsf-nsf-monitoring"; prefix nsfmi; import ietf-inet-types{ prefix inet; reference "Section 4 of RFC 6991"; @@ -1565,21 +1556,21 @@ 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 (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; - revision "2021-10-15" { + revision "2021-11-17" { description "Latest revision"; reference "RFC XXXX: I2NSF NSF Monitoring Interface YANG Data Model"; // RFC Ed.: replace XXXX with an actual RFC number and remove // this note. } /* * Typedefs @@ -1713,37 +1704,37 @@ } description "The type of operation done by a user during a session. The user operation is not considering their privileges."; } typedef login-role { type enumeration { enum administrator { description - "Administrator (i.e., Super User) login role. + "Administrator (i.e., Superuser)'s login role. Non-restricted role."; } enum user { description "User login role. Semi-restricted role, some data and configurations are available but confidential or important data and configuration are restricted."; } enum guest { description "Guest login role. Restricted role, only few read data are available and write configurations are restricted."; } } description - "The role of a user after login."; + "The privilege level of the user account."; } /* * Identity */ identity characteristics { description "Base identity for monitoring information characteristics"; @@ -2074,83 +2065,83 @@ base ddos-type; description "An Secure Sockets Layer (SSL) flood is detected"; } identity ntp-amp-flood { base ddos-type; description "A Network Time Protocol (NTP) amplification is detected"; } - identity request-method { + identity req-method { description "A set of request types in HTTP (if applicable)."; } identity put { - base request-method; + base req-method; description "The detected request type is PUT."; reference "RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content - Request Method PUT"; } identity post { - base request-method; + base req-method; description "The detected request type is POST."; reference "RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content - Request Method POST"; } identity get { - base request-method; + base req-method; description "The detected request type is GET."; reference "RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content - Request Method GET"; } identity head { - base request-method; + base req-method; description "The detected request type is HEAD."; reference "RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content - Request Method HEAD"; } identity delete { - base request-method; + base req-method; description "The detected request type is DELETE."; reference "RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content - Request Method DELETE"; } identity connect { - base request-method; + base req-method; description "The detected request type is CONNECT."; reference "RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content - Request Method CONNECT"; } identity options { - base request-method; + base req-method; description "The detected request type is OPTIONS."; reference "RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content - Request Method OPTIONS"; } identity trace { - base request-method; + base req-method; description "The detected request type is TRACE."; reference "RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content - Request Method TRACE"; } identity filter-type { description @@ -2326,21 +2317,22 @@ description "The identity for pop3."; reference "RFC 1939: Post Office Protocol - Version 3 (POP3)"; } identity imap { base application-protocol; description "The identity for Internet Message Access Protocol."; reference - "RFC 3501: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"; + "RFC 9051: Internet Message Access Protocol (IMAP) - Version + 4rev2"; } /* * Grouping */ grouping timestamp { description "Grouping for identifying the time of the message."; leaf timestamp { @@ -2495,49 +2486,50 @@ } } grouping i2nsf-nsf-event-type-content-extend { description "A set of extended common IPv4 (or IPv6)-related NSF event content elements"; uses i2nsf-nsf-event-type-content; leaf src-ip { type inet:ip-address-no-zone; description - "The source IPv4 (or IPv6) address of the packet"; + "The source IPv4 (or IPv6) address of the packet or flow"; } leaf src-port { type inet:port-number; description - "The source port of the packet"; + "The source port of the packet or flow"; } leaf src-location { type string { length "1..100"; pattern "[0-9a-zA-Z ]*"; } description "The source geographical location (e.g., country and city) - of the packet."; + of the src-ip field."; } leaf dst-location { type string { length "1..100"; pattern "[0-9a-zA-Z ]*"; } description "The destination geographical location (e.g., country and - city) of the packet."; + city) of the dst-ip field."; } } grouping log-action { description "A grouping for logging action."; + leaf-list action { type log-action; description "Action type: allow, alert, block, discard, declare, block-ip, block-service"; } } grouping attack-rates { description "A set of traffic rates for monitoring attack traffic @@ -2971,22 +2966,22 @@ "Login IP address of a user"; } leaf username { type string; description "The login username that maintains the device"; } leaf login-role { type login-role; description - "Specifies the user log-in role, i.e., administrator, - user, or guest."; + "The login role to specify the privilege level of the + user account, e.g., administrator, user, or guest."; } leaf operation-type { type operation-type; description "The operation type that the user executes"; } leaf input { type string; description "The operation performed by a user after login. The @@ -3027,22 +3021,22 @@ security service."; } } description "The current system's running status"; } leaf cpu-usage { type uint8; units "percent"; description - "Specifies the relative percentage of CPU usage with - respect to platform resources"; + "Specifies the relative percentage of CPU utilization + with respect to platform resources"; } leaf memory-usage { type uint8; units "percent"; description "Specifies the percentage of memory usage."; } list disk { key disk-id; description @@ -3360,63 +3353,76 @@ detected."; uses i2nsf-nsf-event-type-content-extend; leaf attack-type { type identityref { base web-attack-type; } description "Concrete web attack type, e.g., SQL injection, command injection, XSS, and CSRF."; } - leaf request-method { + leaf req-method { type identityref { - base request-method; + base req-method; } description - "The HTTP request method, e.g., PUT or GET."; + "The HTTP method of the request, e.g., PUT or GET."; reference "RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content - Request Methods"; } - leaf req-uri { + leaf req-target { type string; description - "The Requested URI"; + "The HTTP Request Target. This field can be filled in + the format of origin-form, absolute-form, + authority-form, or asterisk-form"; + reference + "RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): + Message Syntax and Routing - Request Target"; } leaf-list filtering-type { type identityref { base filter-type; } description "URL filtering type, e.g., deny-list, allow-list, and Unknown"; } leaf req-user-agent { type string; description - "The request user agent"; + "The HTTP User-Agent header field of the request"; + reference + "RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): + Semantics and Content - User Agent"; } - leaf req-cookie { + leaf cookies { type string; description - "The HTTP Cookie previously sent by the server with + "The HTTP Set-Cookie header field of the response"; + reference + "RFC 6265: HTTP State Management Mechanism - Set-Cookie"; } leaf req-host { type string; description - "The domain name of the requested host"; + "The HTTP Host header field of the request"; + reference + "RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): + Message Syntax and Routing - Host"; } leaf response-code { type string; description - "The HTTP Response code"; + "The HTTP Response status code"; reference "IANA Website: Hypertext Transfer Protocol (HTTP) Status Code Registry"; } uses characteristics; uses log-action; uses common-monitoring-data; } } case i2nsf-nsf-detection-voip-volte{ @@ -3878,24 +3885,24 @@ 13. Security Considerations YANG module described in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. - The NETCONF access control model [RFC8341] provides the means to - restrict access for particular NETCONF or RESTCONF users to a - preconfigured subset of all available NETCONF or RESTCONF protocol - operations and content. + The Network Configuration Access Control Model (NACM) [RFC8341] + provides the means to restrict access for particular NETCONF or + RESTCONF users to a preconfigured subset of all available NETCONF or + RESTCONF protocol operations and content. All data nodes defined in the YANG module which can be created, modified and deleted (i.e., config true, which is the default) are considered sensitive as they all could potentially impact security monitoring and mitigation activities. Write operations (e.g., edit- config) applied to these data nodes without proper protection could result in missed alarms or incorrect alarms information being returned to the NSF data collector. There are threats that need to be considered and mitigated: @@ -3927,28 +3934,35 @@ (collector-to-NSF), mutual authentication should be used to mitigate the threat. In addition, to defend against the DDoS attack caused by a lot of NSFs sending massive notifications to the NSF data collector, the rate limiting or similar mechanisms should be considered in both an NSF and NSF data collector, whether in advance or just in the process of DDoS attack. All of the readable data nodes in this YANG module may be considered - vulnerable in some network environments. Some data also may contain - private information that is highly sensitive to the user, such as the - IP address of a user in the container "i2nsf-system-user-activity- - log" and the container "i2nsf-system-detection-event". It is - important to control read access (e.g., via get, get-config, or - notification) to the data nodes. If access control is not properly - configured, it can expose system internals to those who should not - have access to this information. + sensitive in some network environments. These data nodes represent + information consistent with the logging commonly performed in network + and security operations. They may reveal the specific configuration + of a network; vulnerabilities in specific systems; and the deployed + security controls and their relative efficacy in detecting or + mitigating an attack. To an attacker, this information could inform + how to (further) compromise the network, evade detection, or confirm + whether they have been observed by the network operator. + + Additionally, many of the data nodes in this YANG module such as + containers "i2nsf-system-user-activity-log", "i2nsf-system-detection- + event", and "i2nsf-nsf-detection-voip-volte" are privacy sensitive. + They may describe specific or aggregate user activity to include + associating user names with specific IP addresses; or users with + specific network usage. 14. 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 IITP (2020-0-00395, Standard Development of Blockchain based Network Management Automation Technology). This work was supported @@ -4015,24 +4029,20 @@ [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . - [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION - 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, - . - [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, DOI 10.17487/RFC3877, September 2004, . [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, @@ -4059,20 +4069,24 @@ [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . + [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, + DOI 10.17487/RFC6265, April 2011, + . + [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer @@ -4127,20 +4141,25 @@ [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019, . [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, . + [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message + Access Protocol (IMAP) - Version 4rev2", RFC 9051, + DOI 10.17487/RFC9051, August 2021, + . + 16.2. Informative References [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [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, . @@ -4155,31 +4174,31 @@ "I2NSF Consumer-Facing Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-i2nsf-consumer- facing-interface-dm-15, 15 September 2021, . [I-D.ietf-i2nsf-nsf-facing-interface-dm] Kim, J. (., Jeong, J. (., Park, J., Hares, S., and Q. Lin, "I2NSF Network Security Function-Facing Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf- - i2nsf-nsf-facing-interface-dm-14, 15 September 2021, + i2nsf-nsf-facing-interface-dm-15, 4 October 2021, . + facing-interface-dm-15.txt>. [I-D.ietf-i2nsf-registration-interface-dm] Hyun, S., Jeong, J. P., Roh, T., Wi, S., and J. Park, "I2NSF Registration Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-i2nsf-registration- - interface-dm-12, 15 September 2021, + interface-dm-13, 4 October 2021, . + registration-interface-dm-13.txt>. [I-D.ietf-i2nsf-applicability] Jeong, J. P., Hyun, S., Ahn, T., Hares, S., and D. R. Lopez, "Applicability of Interfaces to Network Security Functions to Network-Based Security Services", Work in Progress, Internet-Draft, draft-ietf-i2nsf-applicability- 18, 16 September 2019, . [I-D.yang-i2nsf-security-policy-translation] @@ -4201,31 +4220,29 @@ Internet Assigned Numbers Authority (IANA), "Hypertext Transfer Protocol (HTTP) Status Code Registry", September 2018, . [IANA-Media-Types] Internet Assigned Numbers Authority (IANA), "Media Types", August 2021, . -Appendix A. Changes from draft-ietf-i2nsf-nsf-monitoring-data-model-09 +Appendix A. Changes from draft-ietf-i2nsf-nsf-monitoring-data-model-11 The following changes are made from draft-ietf-i2nsf-nsf-monitoring- - data-model-09: - - * This version is revised following Tom Petch's, Martin Bjorklund's, - and Roman Danyliw's Comments. + data-model-11: - * This version is revised to synchronize with other I2NSF documents. + * This version is revised following Roman Danyliw's Comments. Authors' Addresses + Jaehoon (Paul) Jeong (editor) Department of Computer Science and Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4957