I2NSF Internet Draft W. Wang Intended status: Proposed Standard H. Zhou M. Li Q. Guo S. Deng Document: draft-wang-i2nsf-intelligent-detection-01.txt Beijing Jiaotong University Expires: October 2023 March 2023 YANG Data Models for Attacks Intelligent Detection 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." Abstract This document describes how to extend the Interface to Network Security Function (I2NSF) framework to make it suitable for attacks intelligent detection. Intelligent detection means that the network can dynamically adjust detection policies based on resource status, traffic features, or detection results. This document describes the application of I2NSF Framework for Security Management Automation (SMA) for attacks intelligent detection in Software-Defined Networking (SDN) and Service Function Chaining (SFC) environment. This document will extend the YANG data model of Monitoring Interface, Analytics Interface and NSF-Facing Interface in I2NSF for SMA framework to make it suitable for attacks intelligent detection in SDN and SFC environments. Copyright Notice Wang, et al. Expires – October 2023 [Page 1] I2NSF Intelligent Detection March 2023 Copyright (c) 2022 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 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. I2NSF Framework for Attacks Intelligent Detection..............4 3.1 Components with I2NSF Framework for AID....................4 3.2 Interfaces with I2NSF Framework for AID....................6 4. The Extended YANG Data Models..................................6 4.1 The Extended Monitoring Interface..........................6 4.1.1 YANG Tree Structure of Extended Monitoring Interface.............................................9 4.1.2 YANG Data Model of Extended Monitoring Interface............................................11 4.2 The Extended Analytics Interface..........................29 4.2.1 YANG Tree Structure of Extended Analytics Interface............................................30 4.2.2 YANG Data Model of Extended Analytics Interface .....31 4.3 The Extended NSF-Facing Interface.........................45 4.3.1 YANG Tree Structure of Extended NSF-Facing YANG Module...............................................45 4.3.2 YANG Data Model of Extended NSF-Facing YANG Module ....... ....................................46 5. XML Examples of I2NSF Framework for AID.......................49 6. IANA Considerations...........................................54 7. Security Considerations.......................................54 8. References....................................................54 8.1 Normative References......................................54 8.2 Informative References....................................58 Acknowledgments..................................................59 Author's Addresses...............................................59 1. Introduction I2NSF defines the framework and interface for interacting with NSFs [RFC8192] [RFC8329]. It is centered on the Security Controller and Wang, et al. Expires – October 2023 [Page 2] I2NSF Intelligent Detection March 2023 implements consumer-facing NSFs management and configuration through Consumer-Facing Interface and NSF-Facing Interface. I2NSF Framework for Security Management Automation has added new components I2NSF Analyzer, new interface Monitoring Interface and Analytics Interface, which enable it to achieve feedback based automatic security management [I-D. jeong-i2nsf-security-management-automation]. SDN relocates the control of network resources to a dedicated network element, namely SDN Controller, which provides a means to program, orchestrate, control and manage the network resources through software [ITU-TY.3300]. SFC [RFC7665] is a technique for ordering packets through different service functions. The SDN Controller can manage the SFC. The SDN Controller can send traffic tables to the SFC Classifiers (CFs) and Service Function Forwarder (SFFs), so that different traffic passes through different Service Function Paths (SFPs) according to different traffic table forwarding rules. I2NSF can be combined with SDN and SFC [I-D. ietf-i2nsf-applicability]. The application of SDN and SFC technology in I2NSF can provide more flexible NSFs combination for I2NSF User. NSF can provide a range of security-related services, such as detecting, blocking, or mitigating cyber-attacks [RFC8329]. The NSFs referred in this document specifically refers to NSFs with the capability to detect attacks, which are called Detection Modules (DMs). Different detection modules apply to different types of attacks, such as Distributed Denial of service (DDoS) attacks, worm attacks and so on. Detection modules can form different SFPs in SDN and SFC environments. Traffic with different features, such as protocols or port numbers, passes through different paths to improve network detection efficiency and reduce NSFs load and traffic transmission delay. This document will design extended YANG data models for Monitoring Interface, Analytics Interface and NSF-Facing Interface in I2NSF Framework for Security Management Automation. The I2NSF Analyzer can collect network resource information, traffic features, and detection results through the Extended Monitoring Interface. The I2NSF Analyzer can send resource alarms, detection results, and path reconfiguration policies to the Security Controller through the Extended Analytics Interface. The Security Controller can send the path configuration rules to the SDN Controller through the Extended NSF-facing Interface. The extended framework can realize closed-loop feedback based dynamic adjustment of attack detection policies in SDN and SFC environment. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and Wang, et al. Expires – October 2023 [Page 3] I2NSF Intelligent Detection March 2023 "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the terminology described in [RFC8329], [I-D. jeong-i2nsf-security-management-automation], [RFC7665], [ITU-TY.3300] and [RFC8455]. In addition, the following terms are defined below: o Intelligent Detection: The network can dynamically adjust detection policies based on the feedback resource status, traffic features, and detection results. o Detection Module (DM): The NSF with detection capability. Different DMs apply to different types of attacks, such as DDoS attacks, worm attacks and so on. 3. I2NSF Framework for Attacks Intelligent Detection This section summarizes the I2NSF Framework for Attacks Intelligent Detection (I2NSF Framework for AID) in SDN and SFC environment. As shown in Figure 1, The Security Controller and I2NSF Analyzer implement closed-loop automatic management of SDN controller, CFs/SFFs and DMs through Monitoring Interface, Analytics Interface and NSF-Facing Interface. 3.1 Components with I2NSF Framework for AID The following are the system components for the I2NSF framework for AID. o I2NSF User: An entity that delivers a high-level security policy to Security Controller [RFC8329]. o Security Controller: An entity that controls and manages other system components in the I2NSF framework. It translates a high- level security policy (from I2NSF User) or reconfiguration policy (from I2NSF Analyzer) into the corresponding low-level security policy. It selects appropriate NSFs (including DMs, SDN Controller, CFs and SFFs) to execute the security rules of the low-level security policy [RFC8329]. o Developer's Management System (DMS): An entity that provides an image of a virtualized NSF for a security service to the I2NSF framework, and registers the capability and access information of an NSF with Security Controller [RFC8329]. Wang, et al. Expires – October 2023 [Page 4] I2NSF Intelligent Detection March 2023 o I2NSF Analyzer: An entity that collects monitoring data from NSFs and analyzes such data for checking the activity and performance of the NSFs. If there is a suspicious attack activity for the target network or NSF, I2NSF Analyzer delivers a report of the augmentation or generation of reconfiguration policy to Security Controller [I-D. jeong-i2nsf-security-management-automation]. +----------+ |I2NSF User| +----------+ ^ | Consumer-Facing Interface v +-------------------+ Registration +-----------------------+ |Security Controller|<----------------> |Developer's Mgmt System| +-------------------+ Interface +-----------------------+ ^ ^ ^ | | | | | | Analytics Interface +--------------+ | | +--------------------->|I2NSF Analyzer| |NSF-Facing | +--------------+ |Interface +-------+ NSF-Facing ^ Monitoring | | Interface | Interface +-----------------------------------------------------------+ | v | v | | +--------------+ | | | |SDN Controller| | | | +--------------+ | | | ^ | | | | SDN Southbound | | | | Interface | | | v | | | +--------------+ v | | | +----------+ |----------------------------------+ | | | |Classifier| | | | | | | | +----------+ | v v v | | | +-----+ | +------+ +------+ +------+ | | | | SFF | | | DM-1 | | DM-2 | ... | DM-n | | | | +-----+ | +------+ +------+ +------+ | | +--------------+ | +-----------------------------------------------------------+ Figure 1: I2NSF Framework for Attacks Intelligent Detection o SDN Controller: An entity that provides a means to program, orchestrate, control and manage the network resources through software. It can parse path rules of the low-level security policy and deliver flow tables to CFs and SFFs to form SFPs [ITU-TY.3300]. Wang, et al. Expires – October 2023 [Page 5] I2NSF Intelligent Detection March 2023 o Detection Module (DM): The NSF with detection capability. 3.2 Interfaces with I2NSF Framework for AID The following are the interfaces for the AID I2NSF framework. Note that the interfaces are modeled with YANG [RFC6020] and security policies are delivered through either RESTCONF [RFC8040] or NETCONF [RFC6241]. o Consumer-Facing Interface: An interface between I2NSF User and Security Controller for the delivery of a high-level security policy [RFC8329]. o NSF-Facing Interface: An interface between Security Controller and an NSF for the delivery of a low-level security policy [RFC8329]. o Registration Interface: An interface between a DMS and Security Controller for the registration of an NSF's capability and access information with Security Controller or the query of an NSF for a required low-level security policy [RFC8329]. o Analytics Interface: An interface to deliver an analytics report for augmentation or generation of a security policy rule created by I2NSF Analyzer to Security Controller [I-D. jeong-i2nsf- security-management-automation]. o SDN Southbound Interface: The application programming interface provided by the SDN Controller to interact with the SDN nodes [RFC8455]. 4. The Extended YANG Data Models This section describes the extended Monitoring Interface, Analytics Interface and NSF-Facing Interface YANG data model. 4.1 The Extended Monitoring Interface This section describes the Extended Monitoring Interface. This document modifies or adds traffic features, resource utilization logs, and DM detection results for Monitoring Interface. Traffic features contain the following information: Wang, et al. Expires – October 2023 [Page 6] I2NSF Intelligent Detection March 2023 o measurement-time: The duration of the measurement in seconds for the features of traffic flows. These traffic flow features are measured over the past measurement duration before now. o packets-per-second: Average number of packets forwarded per second measured over the past 'measurement-time'. o bytes-per-second: Average number of bytes forwarded per second measured over the past 'measurement-time'. o packet-size-mean: Average packet length of packets measured over the past 'measurement-time'. o src-ip-entropy: Entropy of the source IP address measured over the past 'measurement-time'. o dst-ip-entropy: The entropy of the destination IP address measured over the past 'measurement-time'. o TTL-entropy: Packet lifetime TTL entropy measured over the past 'measurement-time'. o tcp-src-port-entropy: TCP Packet source port entropy measured over the past 'measurement-time'. o tcp-dst-port-entropy: TCP Packet destination port entropy measured over the past 'measurement-time'. o udp-src-port-entropy: UDP Packet source port entropy measured over the past 'measurement-time'. o udp-dst-port-entropy: UDP Packet destination port entropy measured over the past 'measurement-time'. o packet-size-entropy: The entropy of packet length measured over the past 'measurement-time'. o packets-variance: Variance of packets measured over the past 'measurement-time'. Resource utilization logs contain the following information: o system-status: The current system's running status [I-D. ietf- i2nsf-nsf-monitoring-data-model]. o cpu-usage: Specifies the aggregated CPU usage in percentage [I-D. ietf-i2nsf-nsf-monitoring-data-model]. Wang, et al. Expires – October 2023 [Page 7] I2NSF Intelligent Detection March 2023 o cpu-freq: Specifies the frequency of CPU in MHz. o memory-usage: Specifies the MB of memory usage. o memory-total: Specifies the MB of total memory. o memory-available: Specifies the MB of available memory. o disk-id: The ID of the storage disk. It is a free form identifier to identify the storage disk [I-D. ietf-i2nsf-nsf-monitoring-data- model]. o disk-usage: Specifies the percentage of disk usage [I-D. ietf- i2nsf-nsf-monitoring-data-model]. o disk-space-left: Specifies the available disk space left of disk-id in percentage [I-D. ietf-i2nsf-nsf-monitoring-data-model]. o interface-id: Specifies the interface ID to identify the network interface [I-D. ietf-i2nsf-nsf-monitoring-data-model]. o in-traffic-rate: The total inbound data plane traffic rate in packets per second [I-D. ietf-i2nsf-nsf-monitoring-data-model]. o out-traffic-rate: The total outbound data plane traffic rate in packets per second [I-D. ietf-i2nsf-nsf-monitoring-data-model]. o in-traffic-throughput: The total inbound data plane traffic throughput in bytes per second [I-D. ietf-i2nsf-nsf-monitoring- data-model]. o out-traffic-throughput: The total outbound data plane traffic throughput in bytes per second[I-D. ietf-i2nsf-nsf-monitoring- data-model]. o packet-loss-rate: The percentage of discarded packets. The DM detection result contains the following information: o detection-module-name: The name of the specific detection module. o time-stamp: Specify the time of a message being delivered. o response-time: The time taken for the detection. Wang, et al. Expires – October 2023 [Page 8] I2NSF Intelligent Detection March 2023 o start-time: The start time for the detection. o end-time: The end time for the detection. o attack-id: The ID of the specific attack traffic which has the same src/dst IP, protocol and attack type. o attack-type: The type of the detected attack. o attack-src-ip: The source IPv4 or IPv6 addresses of attack traffic. o attack-dst-ip: The destination IPv4 or IPv6 addresses of attack traffic. o attack-src-port: The transport-layer source ports of the attack. It can hold multiple ports. o attack-dst-port: The transport-layer destination ports of the attack. It can hold multiple ports. o protocol: The type of network protocol for the attack. o attack-rate: The average packets per second (pps) rate of attack traffic [I-D. ietf-i2nsf-nsf-monitoring-data-model]. o attack-throughput: The average bytes per second (Bps) throughput of attack traffic [I-D. ietf-i2nsf-nsf-monitoring-data-model]. 4.1.1 YANG Tree Structure of Extended Monitoring Interface The tree structure of the Extended Monitoring Interface is provided below: module: wang-i2nsf-extended-monitoring-interface notifications: +---n i2nsf-event | +--ro vendor-name? string | +--ro device-model? string | +--ro software-version? string | +--ro nsf-name union | +--ro message? string | +--ro language? string | +--ro acquisition-method? identityref Wang, et al. Expires – October 2023 [Page 9] I2NSF Intelligent Detection March 2023 | +--ro emission-type? identityref | +--ro dampening-type? identityref | +--ro (sub-event-type)? | +--:(i2nsf-flow-features) | +--ro i2nsf-traffic-flow-features | +--ro measurement-time? uint32 | +--ro packets-per-second? uint64 | +--ro bytes-per-second? uint64 | +--ro packet-size-mean? uint64 | +--ro src-ip-entropy? uint64 | +--ro dst-ip-entropy? uint64 | +--ro TTL-entropy? uint64 | +--ro tcp-src-port-entropy? uint64 | +--ro tcp-dst-port-entropy? uint64 | +--ro udp-src-port-entropy? uint64 | +--ro udp-dst-port-entropy? uint64 | +--ro packet-size-entropy? uint64 | +--ro packets-variance? uint64 +---n i2nsf-log | +--ro vendor-name? string | +--ro device-model? string | +--ro software-version? string | +--ro nsf-name union | +--ro message? string | +--ro language? string | +--ro acquisition-method? identityref | +--ro emission-type? identityref | +--ro dampening-type? identityref | +--ro (sub-logs-type)? | +--:(i2nsf-system-res-util-log) | +--ro i2nsf-system-res-util-log | +--ro system-status? enumeration | +--ro cpu-usage? uint8 | +--ro cpu-freq? uint64 | +--ro memory-usage? uint64 | +--ro memory-total? uint64 | +--ro memory-available? uint64 | +--ro disks* [disk-id] | | +--ro disk-id string | | +--ro disk-usage? uint8 | | +--ro disk-space-left? uint8 | +--ro interface* [interface-id] | +--ro interface-id string | +--ro in-traffic-rate? uint64 | +--ro out-traffic-rate? uint64 | +--ro in-traffic-throughput? uint64 | +--ro out-traffic-throughput? uint64 | +--ro packet-loss-rate? uint64 +---n i2nsf-nsf-event Wang, et al. Expires – October 2023 [Page 10] I2NSF Intelligent Detection March 2023 +--ro vendor-name? string +--ro device-model? string +--ro software-version? string +--ro nsf-name union +--ro message? string +--ro language? string +--ro acquisition-method? identityref +--ro emission-type? identityref +--ro dampening-type? identityref +--ro (sub-event-type)? +--:(i2nsf-nsf-detection-module) +--ro i2nsf-nsf-detection-module +--ro detection-module* [detection-module-name] +--ro detection-module-name string +--ro time-stamp? yang:date-and-time +--ro response-time? yang:date-and-time +--ro start-time? yang:date-and-time +--ro end-time? yang:date-and-time +--ro detected-attacks +--ro attack-traffic* [attack-id] +--ro attack-id string +--ro attack-type string +--ro attack-src-ip? inet:ip-address-no-zone +--ro attack-dst-ip? inet:ip-address-no-zone +--ro attack-src-port* inet:port-number +--ro attack-dst-port* inet:port-number +--ro protocol? identityref +--ro attack-rate? uint64 +--ro attack-throughput? uint64 Figure 2: YANG Tree Structure of Extended Monitoring Interface 4.1.2 YANG Data Model of Extended Monitoring Interface This section describes a YANG module of I2NSF Extended Monitoring Interface. This YANG module imports from [RFC6991], and makes references to [I-D. ietf-i2nsf-nsf-monitoring-data-model] [RFC0768] [RFC0791] [RFC0792] [RFC0854] [RFC1939] [RFC0959] [RFC2595] [RFC4340] [RFC4443] [RFC5321] [RFC5646] [RFC6242] [RFC8200] [RFC8641] [RFC9051] [RFC9110] [RFC9112] [RFC9113] [RFC9260] [RFC9293]. file "wang-i2nsf-extended-monitoring-interface@2023- 03-28.yang" module ietf-wang-i2nsf-extended-monitoring-interface{ Wang, et al. Expires – October 2023 [Page 11] I2NSF Intelligent Detection March 2023 yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:wang-i2nsf-extended- monitoring-interface"; prefix i2nsf-exmi; import ietf-inet-types{ prefix inet; reference "Section 4 of RFC 6991"; } import ietf-yang-types{ prefix yang; reference "Section 3 of RFC 6991"; } organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; contact "WG Web: WG List: Author: Weilin Wang Author: Huachun Zhou Author: Man Li Author: Qi Guo Author: Shuangxing Deng "; description "This module is a YANG module for the extension of I2NSF NSF Monitoring. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear Wang, et al. Expires – October 2023 [Page 12] I2NSF Intelligent Detection March 2023 in all capitals, as shown here. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. 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 Revised 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 "2023-03-28" { description "Initial revision."; reference "RFC XXXX: Extension of I2NSF NSF Monitoring Interface YANG Data Model"; } /* * Identity */ identity characteristics { description "Base identity for monitoring information characteristics."; reference "I-D: I2NSF NSF Monitoring Interface YANG Data Model"; } identity acquisition-method { base characteristics; description "The type of acquisition-method. It can be multiple types at once."; } identity subscription { base acquisition-method; description "The acquisition-method type is subscription."; } identity query { base acquisition-method; description "The acquisition-method type is query."; } Wang, et al. Expires – October 2023 [Page 13] I2NSF Intelligent Detection March 2023 identity emission-type { base characteristics; description "The type of emission-type."; } identity periodic { base emission-type; description "The emission-type type is periodic."; } identity on-change { base emission-type; description "The emission-type type is on-change."; } identity dampening-type { base characteristics; description "The type of message dampening to stop the rapid transmission of messages, such as on-repetition and no-dampening."; } identity no-dampening { base dampening-type; description "The dampening-type is no-dampening. No-dampening type does not limit the transmission for the messages of the same type."; } identity on-repetition { base dampening-type; description "The dampening-type is on-repetition. On-repetition type limits the transmitted on-change message to one message at a certain interval."; } identity protocol { description "An identity used to enable type choices in leaves and leaf-lists with respect to protocol metadata. This is used to identify the type of protocol that goes through the NSF."; } identity ip { base protocol; description "General IP protocol type."; reference "RFC0791: Internet Protocol Wang, et al. Expires – October 2023 [Page 14] I2NSF Intelligent Detection March 2023 RFC8200: Internet Protocol, Version 6 (IPv6)"; } identity ipv4 { base ip; description "IPv4 protocol type."; reference "RFC0791: Internet Protocol"; } identity ipv6 { base ip; description "IPv6 protocol type."; reference "RFC8200: Internet Protocol, Version 6 (IPv6)"; } identity icmp { base protocol; description "Base identity for ICMPv4 and ICMPv6 condition capability"; reference "RFC0792: Internet Control Message Protocol RFC4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification- ICMPv6"; } identity icmpv4 { base icmp; description "ICMPv4 protocol type."; reference "RFC0791: Internet Protocol RFC0792: Internet Control Message Protocol"; } identity icmpv6 { base icmp; description "ICMPv6 protocol type."; reference "RFC8200: Internet Protocol, Version 6 (IPv6) RFC4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"; } identity transport-protocol { base protocol; description "Base identity for Layer 4 protocol condition Wang, et al. Expires – October 2023 [Page 15] I2NSF Intelligent Detection March 2023 capabilities, e.g., TCP, UDP, SCTP, DCCP, and ICMP."; } identity tcp { base transport-protocol; description "TCP protocol type."; reference "[RFC9293]: Transmission Control Protocol (TCP)."; } identity udp { base transport-protocol; description "UDP protocol type."; reference "RFC0768: User Datagram Protocol"; } identity sctp { base transport-protocol; description "Identity for SCTP condition capabilities"; reference "RFC9260: Stream Control Transmission Protocol"; } identity dccp { base transport-protocol; description "Identity for DCCP condition capabilities"; reference "RFC4340: Datagram Congestion Control Protocol"; } identity application-protocol { base protocol; description "Base identity for Application protocol. Note that a subset of application protocols (e.g., HTTP, HTTPS, FTP, POP3, and IMAP) are handled in this YANG module, rather than all the existing application protocols."; } identity http { base application-protocol; description "The identity for Hypertext Transfer Protocol version 1.1 (HTTP/1.1)."; reference "[RFC9110]: HTTP Semantics [RFC9112]: HTTP/1.1"; Wang, et al. Expires – October 2023 [Page 16] I2NSF Intelligent Detection March 2023 } identity https { base application-protocol; description "The identity for Hypertext Transfer Protocol version 1.1 (HTTP/1.1) over TLS."; reference "[RFC9110]: HTTP Semantics [RFC9112]: HTTP/1.1"; } identity http2 { base application-protocol; description "The identity for Hypertext Transfer Protocol version 2 (HTTP/2)."; reference "RFC9113: HTTP/2"; } identity https2 { base application-protocol; description "The identity for Hypertext Transfer Protocol version 2 (HTTP/2) over TLS."; reference "RFC9113: HTTP/2"; } identity ftp { base application-protocol; description "FTP protocol type."; reference "RFC0959: File Transfer Protocol"; } identity ssh { base application-protocol; description "SSH protocol type."; reference "RFC6242: Using the NETCONF Protocol over Secure Shell (SSH)"; } identity telnet { base application-protocol; description "The identity for telnet."; reference "RFC0854: Telnet Protocol"; } identity smtp { Wang, et al. Expires – October 2023 [Page 17] I2NSF Intelligent Detection March 2023 base application-protocol; description "The identity for smtp."; reference "RFC5321: Simple Mail Transfer Protocol (SMTP)"; } identity pop3 { base application-protocol; description "The identity for Post Office Protocol 3 (POP3)."; reference "RFC1939: Post Office Protocol - Version 3 (POP3)"; } identity pop3s { base application-protocol; description "The identity for Post Office Protocol 3 (POP3) over TLS"; reference "RFC1939: Post Office Protocol -Version 3(POP3) RFC2595: Using TLS with IMAP, POP3 and ACAP"; } identity imap { base application-protocol; description "The identity for Internet Message Access Protocol (IMAP)."; reference "RFC9051: Internet Message Access Protocol (IMAP) - Version 4rev2"; } identity imaps { base application-protocol; description "The identity for Internet Message Access Protocol (IMAP) over TLS"; reference "RFC9051: Internet Message Access Protocol (IMAP) - Version 4rev2 RFC2595: Using TLS with IMAP, POP3 and ACAP"; } /* * Grouping */ grouping common-monitoring-data { description Wang, et al. Expires – October 2023 [Page 18] I2NSF Intelligent Detection March 2023 "A set of common monitoring data that is needed as the basic information."; leaf vendor-name { type string; description "The name of the NSF vendor. The string is unrestricted to identify the provider or vendor of the NSF."; } leaf device-model { type string; description "The model of the device, can be represented by the device model name or serial number. This field is used to identify the model of the device that provides the security service."; } leaf software-version { type string; description "The version of the software used to provide the security service."; } leaf nsf-name { type union{ type string; type inet:ip-address-no-zone; } mandatory true; description "The name or IP address of the NSF generating the message.If the given nsf-name is not an IP address, the name can be an arbitrary string including a FQDN (Fully Qualified Domain Name). The name MUST be unique in the scope of management domain for a different NSF to identify the NSF that generates the message."; } } grouping message { description "A set of common monitoring data that is needed as the basic information."; leaf message { type string; description "This is a freetext annotation for monitoring a notification's content."; Wang, et al. Expires – October 2023 [Page 19] I2NSF Intelligent Detection March 2023 } leaf language { type string { pattern '((([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})' + '{0,2})?)|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})?' + '(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}' + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WYZa-wyz]' + '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]' + '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|' + '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-' + '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-' + '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-' + '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]' + '|[Ii]-[Hh][Aa][Kk]|' + '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|' + '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|' + '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|' + '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|' + '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|' + '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-' + '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-' + '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-' + '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|' + '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-' + '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|' + '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-' + '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-' + '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))'; } default "en-US"; description "The value in this field indicates the language tag used for the human readable fields (i.e., '../message', '/i2nsf-log/i2nsf-nsf-system-access-log/output', and '/i2nsf-log/i2nsf-system-user-activity-log/additional-info /cause'). The attribute is encoded following the rules in Section 2.1 in RFC 5646. The default language tag is 'en-US'"; reference "RFC 5646: Tags for Identifying Languages."; } } grouping characteristics { description "A set of characteristics of a monitoring information."; leaf acquisition-method { type identityref { base acquisition-method; } Wang, et al. Expires – October 2023 [Page 20] I2NSF Intelligent Detection March 2023 description "The acquisition-method for characteristics"; } leaf emission-type { when "derived-from-or-self(../acquisition-method, " + "'i2nsf-exmi:subscription')"; type identityref { base emission-type; } description "The emission-type for characteristics. This attribute is used only when the acquisition-method is a 'subscription'."; } } grouping characteristics-extended { description "An extended characteristics for the monitoring information."; uses characteristics; leaf dampening-type { type identityref { base dampening-type; } description "The dampening-type for characteristics"; } } grouping attack-rates { description "A set of traffic rates for monitoring attack traffic data."; leaf attack-rate { type uint64; units "pps"; description "The average packets per second (pps) rate of attack traffic."; } leaf attack-throughput { type uint64; units "Bps"; description "The average bytes per second (Bps) throughput of attack traffic."; } } /* * Notification nodes */ Wang, et al. Expires – October 2023 [Page 21] I2NSF Intelligent Detection March 2023 notification i2nsf-event { description "Notification for I2NSF Event. This notification provides general information that can be supported by most types of NSFs."; uses common-monitoring-data; uses message; uses characteristics-extended; choice sub-event-type { description "This choice must be augmented with cases for each allowed sub-event. Only 1 sub-event will be instantiated in each i2nsf-event message. Each case is expected to define one container with all the sub-event fields."; case i2nsf-flow-features { container i2nsf-traffic-flow-features { description "This notification is sent to inform about the traffic flow features."; leaf measurement-time { type uint32; units "seconds"; description "The duration of the measurement in seconds for the features of traffic flows. These traffic flow features are measured over the past measurement duration before now."; } leaf packets-per-second { type uint64; description "Average number of packets forwarded per second measured over the past 'measurement-time'."; } leaf bytes-per-second { type uint64; description "Average number of bytes forwarded per second measured over the past 'measurement-time'."; } leaf packet-size-mean { type uint64; description "Average packet length of packets measured over the past 'measurement-time'."; } Wang, et al. Expires – October 2023 [Page 22] I2NSF Intelligent Detection March 2023 leaf src-ip-entropy { type uint64; description "Entropy of the source IP address measured over the past 'measurement-time'."; } leaf dst-ip-entropy { type uint64; description "The entropy of the destination IP address measured over the past 'measurement-time'."; } leaf TTL-entropy { type uint64; description "Packet lifetime TTL entropy measured over the past 'measurement-time'."; } leaf tcp-src-port-entropy { type uint64; description "TCP Packet source port entropy measured over the past 'measurement-time'."; } leaf tcp-dst-port-entropy { type uint64; description "TCP Packet destination port entropy measured over the past 'measurement-time'."; } leaf udp-src-port-entropy { type uint64; description "UDP Packet source port entropy measured over the past 'measurement-time'."; } leaf udp-dst-port-entropy { type uint64; description "UDP Packet destination port entropy measured over the past 'measurement-time'."; } leaf packet-size-entropy { type uint64; description "The entropy of packet length measured over the past 'measurement-time'."; } leaf packets-variance { Wang, et al. Expires – October 2023 [Page 23] I2NSF Intelligent Detection March 2023 type uint64; description "Variance of packets measured over the past 'measurement-time'."; } } } } } notification i2nsf-log { description "Notification for I2NSF log. The notification is generated from the logs of the NSF."; uses common-monitoring-data; uses message; uses characteristics-extended; choice sub-logs-type { description "This choice must be augmented with cases for each allowed sub-logs. Only 1 sub-event will be instantiated in each i2nsf-logs message. Each case is expected to define one container with all the sub-logs fields."; case i2nsf-system-res-util-log { container i2nsf-system-res-util-log { description "This notification is sent, if there is a new log entry representing resource utilization updates."; leaf system-status { type enumeration { enum running { description "The system is active and running the security service."; } enum waiting { description "The system is active but waiting for an event to provide the security service."; } enum inactive { description "The system is inactive and not running the security service."; } } description Wang, et al. Expires – October 2023 [Page 24] I2NSF Intelligent Detection March 2023 "The current system's running status."; } leaf cpu-usage { type uint8; units "percent"; description "Specifies the aggregated CPU usage in percentage."; } leaf cpu-freq { type uint64; units "MHz"; description "Specifies the frequency of CPU in MHz."; } leaf memory-usage { type uint64; units "MB"; description "Specifies the MB of memory usage."; } leaf memory-total { type uint64; units "MB"; description "Specifies the MB of total memory."; } leaf memory-available { type uint64; units "MB"; description "Specifies the MB of available memory."; } list disks { key disk-id; description "Disk is the hardware to store information for a long period, i.e., Hard Disk or Solid-State Drive."; leaf disk-id { type string; description "The ID of the storage disk. It is a free form identifier to identify the storage disk."; } leaf disk-usage { type uint8; units "percent"; description "Specifies the percentage of disk usage."; } Wang, et al. Expires – October 2023 [Page 25] I2NSF Intelligent Detection March 2023 leaf disk-space-left { type uint8; units "percent"; description "Specifies the available disk space left of disk-id in percentage."; } } list interface { key interface-id; description "The network interface for connecting a device with the network."; leaf interface-id { type string; description "The ID of the network interface. It is a free form identifier to identify the network interface."; } leaf in-traffic-rate { type uint64; units "pps"; description "The total inbound traffic rate in packets per second"; } leaf out-traffic-rate { type uint64; units "pps"; description "The total outbound traffic rate in packets per second"; } leaf in-traffic-throughput { type uint64; units "Bps"; description "The total inbound traffic throughput in bytes per second"; } leaf out-traffic-throughput { type uint64; units "Bps"; description "The total outbound traffic throughput in bytes per second."; } leaf packet-loss-rate { Wang, et al. Expires – October 2023 [Page 26] I2NSF Intelligent Detection March 2023 type uint64; units "percent"; description "The percentage of discarded packets."; } } } } } } notification i2nsf-nsf-event { description "Notification for I2NSF NSF Event. This notification provides specific information that can only be provided by an NSF that supports additional features (e.g., DDoS attack detection)."; uses common-monitoring-data; uses message; uses characteristics-extended; choice sub-event-type { description "This choice must be augmented with cases for each allowed sub-event. Only 1 sub-event will be instantiated in each container with all the sub-event fields."; case i2nsf-nsf-detection-module { container i2nsf-nsf-detection-module { description "This notification is sent, when a specific attack is detected."; list detection-module { key detection-module-name; description "The specific detection module."; leaf detection-module-name { type string; description "The name of the specific detection module."; } leaf time-stamp { type yang:date-and-time; description "Specify the time of a message being delivered."; } leaf response-time { type yang:date-and-time; description Wang, et al. Expires – October 2023 [Page 27] I2NSF Intelligent Detection March 2023 "The time taken for the detection."; } leaf start-time { type yang:date-and-time; description "The start time for the detection."; } leaf end-time { type yang:date-and-time; description "The end time for the detection."; } container detected-attacks { description "The information of detected attacks."; list attack-traffic{ key attack-id; description "The five-tuple (src/dst ip, port and protocol) and attack type information of specific attack traffic."; leaf attack-id { type string; description "The ID of the specific attack traffic which has the same src/dst IP,protocol and attack type."; } leaf attack-type { type string; description "The type of the detected attack."; } leaf attack-src-ip { type inet:ip-address-no-zone; description "The source IPv4 or IPv6 addresses of attack traffic. "; } leaf attack-dst-ip { type inet:ip-address-no-zone; description "The destination IPv4 or IPv6 addresses of attack traffic. "; } leaf-list attack-src-port { type inet:port-number; description "The transport-layer source ports of the Wang, et al. Expires – October 2023 [Page 28] I2NSF Intelligent Detection March 2023 attack. It can hold multiple ports."; } leaf-list attack-dst-port { type inet:port-number; description "The transport-layer destination ports of the attack. It can hold multiple ports."; } leaf protocol { type identityref { base protocol; } description "The type of network protocol for the attack."; } uses attack-rates; } } } } } } } } 4.2 The Extended Analytics Interface This section describes the Extended Analytics Interface. The I2NSF Analyzer sends feedback information and reconfiguration policies to the Security Controller through this interface. The reconfiguration policy in this document specifically refers to the path reconfiguration policy. The system feedback information refers to [I-D. lingga-i2nsf- analytics-interface-dm], including the following information: memory, CPU, disk, and interface alarm. The NSF feedback in this document specifically refers to the DM feedback, which is the same as the detection results defined in the Extended Monitoring Interface. The path reconfiguration policy is a new NSF path generated by analyzing traffic features or detection results through the I2NSF Analyzer to better detect attacks. The path reconfiguration policy contains the following information: Wang, et al. Expires – October 2023 [Page 29] I2NSF Intelligent Detection March 2023 o name: The name of the reconfiguration policy. o path-id: Identify the different service function paths. o nsf-name: Use the name to identify the NSF. o sequence-number: Identifies the sequence of the NSF in the service function path. 4.2.1 YANG Tree Structure of Extended Analytics Interface The tree structure of the Extended Analytics Interface is provided below: module: wang-i2nsf-extended-analytics-interface +--rw i2nsf-feedback-information* [time-stamp] | +--rw time-stamp yang:date-and-time | +--rw message? string | +--rw language? string | +--rw system-feedback-information | | +--rw (alarm-type)? | | +--:(memory-alarm) | | | +--rw memory-alarm | | | +--rw usage? uint8 | | | +--rw duration? uint32 | | +--:(cpu-alarm) | | | +--rw cpu-alarm | | | +--rw usage? uint8 | | | +--rw duration? uint32 | | +--:(disk-alarm) | | | +--rw disk-alarm | | | +--rw disk-id? string | | | +--rw usage? uint8 | | | +--rw duration? uint32 | | +--:(interface-alarm) | | +--rw interface-alarm | | +--rw interface-id? string | | +--rw interface-state? enumeration | | +--rw duration? uint32 | +--rw nsf-feedback-information | +--rw (nsf-type)? | +--:(detection-module) | +--rw detection-module | +--rw detection-module-name? string | +--rw detected-attacks | +--rw attack-traffic* [attack-id] | +--rw attack-id string Wang, et al. Expires – October 2023 [Page 30] I2NSF Intelligent Detection March 2023 | +--rw attack-src-ip? inet:ip-address-no-zone | +--rw attack-dst-ip? inet:ip-address-no-zone | +--rw attack-src-port* inet:port-number | +--rw attack-dst-port* inet:port-number | +--rw protocol? identityref | +--rw attack-rate? uint64 | +--rw attack-throughput? uint64 +--rw i2nsf-reconfiguration-policy* [name] +--rw name string +--rw (policy-type)? +--:(path-reconfiguration-policy) +--rw path-reconfiguration-policy +--rw service-function-path* [path-id] +--rw path-id string +--rw nsfs +--rw nsf* [nsf-name] +--rw nsf-name string +--rw sequence-number? uint64 Figure3 YANG Tree Structure of Extended Analytics Interface 4.2.2 YANG Data Model of Extended Analytics Interface This section describes a YANG module of I2NSF Extended Analytics interface. This YANG module imports from [RFC6991], and makes references to [I-D. lingga-analytics-interface-dm] [RFC0768] [RFC0791] [RFC0792] [RFC0854] [RFC1939] [RFC0959] [RFC2595] [RFC4340] [RFC4443] [RFC5321] [RFC5646] [RFC6242] [RFC8200] [RFC9051] [RFC9110] [RFC9112] [RFC9113] [RFC9260] [RFC9293]. file "wang-i2nsf-extended-analytics-interface@2023-03- 21.yang" module ietf-wang-i2nsf-extended-analytics-interface { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:wang-i2nsf-extension- analytics-interface"; prefix i2nsf-exai; import ietf-inet-types { prefix inet; reference "RFC6991"; } import ietf-yang-types { Wang, et al. Expires – October 2023 [Page 31] I2NSF Intelligent Detection March 2023 prefix yang; reference "RFC6991"; } organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; contact "WG Web: WG List: Author: Weilin Wang Author: Qi Guo Author: Shuangxing Deng "; description "This module is a YANG module for the extension of I2NSF Analytics Interface. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. 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 Revised 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 "2023-03-21"{ description "Initial revision."; reference "RFC XXXX: Extension of I2NSF NSF Analytics Interface Wang, et al. Expires – October 2023 [Page 32] I2NSF Intelligent Detection March 2023 YANG Data Model"; } /* *Identity */ identity protocol { description "An identity used to enable type choices in leaves and leaf-lists with respect to protocol metadata. This is used to identify the type of protocol that goes through the NSF."; } identity ip { base protocol; description "General IP protocol type."; reference "RFC0791: Internet Protocol RFC8200: Internet Protocol, Version 6 (IPv6)"; } identity ipv4 { base ip; description "IPv4 protocol type."; reference "RFC0791: Internet Protocol"; } identity ipv6 { base ip; description "IPv6 protocol type."; reference "RFC8200: Internet Protocol, Version 6 (IPv6)"; } identity icmp { base protocol; description "Base identity for ICMPv4 and ICMPv6 condition capability"; reference "RFC0792: Internet Control Message Protocol RFC4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification - ICMPv6"; } identity icmpv4 { base icmp; description "ICMPv4 protocol type."; reference Wang, et al. Expires – October 2023 [Page 33] I2NSF Intelligent Detection March 2023 "RFC0791: Internet Protocol RFC0792: Internet Control Message Protocol"; } identity icmpv6 { base icmp; description "ICMPv6 protocol type."; reference "RFC8200: Internet Protocol, Version 6 (IPv6) RFC4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"; } identity transport-protocol { base protocol; description "Base identity for Layer 4 protocol condition capabilities, e.g., TCP, UDP, SCTP, DCCP, and ICMP."; } identity tcp { base transport-protocol; description "TCP protocol type."; reference "[RFC9293]: Transmission Control Protocol (TCP)."; } identity udp { base transport-protocol; description "UDP protocol type."; reference "RFC0768: User Datagram Protocol"; } identity sctp { base transport-protocol; description "Identity for SCTP condition capabilities"; reference "RFC9260: Stream Control Transmission Protocol"; } identity dccp { base transport-protocol; description "Identity for DCCP condition capabilities"; reference "RFC4340: Datagram Congestion Control Protocol"; } Wang, et al. Expires – October 2023 [Page 34] I2NSF Intelligent Detection March 2023 identity application-protocol { base protocol; description "Base identity for Application protocol. Note that a subset of application protocols (e.g., HTTP, HTTPS, FTP, POP3, and IMAP) are handled in this YANG module, rather than all the existing application protocols."; } identity http { base application-protocol; description "The identity for Hypertext Transfer Protocol version 1.1 (HTTP/1.1)."; reference "[RFC9110]: HTTP Semantics [RFC9112]: HTTP/1.1"; } identity https { base application-protocol; description "The identity for Hypertext Transfer Protocol version 1.1 (HTTP/1.1) over TLS."; reference "[RFC9110]: HTTP Semantics [RFC9112]: HTTP/1.1"; } identity http2 { base application-protocol; description "The identity for Hypertext Transfer Protocol version 2 (HTTP/2)."; reference "RFC9113: HTTP/2"; } identity https2 { base application-protocol; description "The identity for Hypertext Transfer Protocol version 2 (HTTP/2) over TLS."; reference "RFC9113: HTTP/2"; } identity ftp { base application-protocol; description "FTP protocol type."; reference "RFC 0959: File Transfer Protocol"; Wang, et al. Expires – October 2023 [Page 35] I2NSF Intelligent Detection March 2023 } identity ssh { base application-protocol; description "SSH protocol type."; reference "RFC6242: Using the NETCONF Protocol over Secure Shell (SSH)"; } identity telnet { base application-protocol; description "The identity for telnet."; reference "RFC 0854: Telnet Protocol"; } identity smtp { base application-protocol; description "The identity for smtp."; reference "RFC 5321: Simple Mail Transfer Protocol (SMTP)"; } identity pop3 { base application-protocol; description "The identity for Post Office Protocol 3 (POP3)."; reference "RFC1939: Post Office Protocol - Version 3 (POP3)"; } identity pop3s { base application-protocol; description "The identity for Post Office Protocol 3 (POP3) over TLS"; reference "RFC1939: Post Office Protocol - Version 3 (POP3) RFC2595: Using TLS with IMAP, POP3 and ACAP"; } identity imap { base application-protocol; description "The identity for Internet Message Access Protocol (IMAP)."; reference Wang, et al. Expires – October 2023 [Page 36] I2NSF Intelligent Detection March 2023 "RFC9051: Internet Message Access Protocol (IMAP) - Version 4rev2"; } identity imaps { base application-protocol; description "The identity for Internet Message Access Protocol (IMAP) over TLS"; reference "RFC9051: Internet Message Access Protocol (IMAP) - Version 4rev2 RFC2595: Using TLS with IMAP, POP3 and ACAP"; } /* *Grouping */ grouping message { description "A set of common monitoring data that is needed as the basic information."; leaf message { type string; description "This is a free text annotation for monitoring a notification's content."; } leaf language { type string { pattern '((([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})' + '{0,2})?)|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})?' + '(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}' + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WYZa-wyz]' + '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]' + '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|' + '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-' + '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-' + '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-' + '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]' + '|[Ii]-[Hh][Aa][Kk]|' + '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|' + '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|' + '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|' + '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|' + '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|' + '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-' + '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-' + '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-' Wang, et al. Expires – October 2023 [Page 37] I2NSF Intelligent Detection March 2023 + '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|' + '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-' + '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|' + '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-' + '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-' + '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))'; } default "en-US"; description "The value in this field indicates the language tag used for the human readable fields (i.e., '../message', '/i2nsf-log/i2nsf-nsf-system-access-log/output', and '/i2nsf-log/i2nsf-system-user-activity-log/additional-info /cause'). The attribute is encoded following the rules in Section 2.1 in RFC5646. The default language tag is 'en-US'"; reference "RFC5646: Tags for Identifying Languages."; } } grouping attack-rates { description "A set of traffic rates for monitoring attack traffic data."; leaf attack-rate { type uint64; units "pps"; description "The average packets per second (pps) rate of attack traffic"; } leaf attack-throughput { type uint64; units "Bps"; description "The average bytes per second (Bps) throughput of attack traffic"; } } list i2nsf-feedback-information { key time-stamp; description "Feedback information includes system feedback information about resources and NSF feedback information."; leaf time-stamp { type yang:date-and-time; description Wang, et al. Expires – October 2023 [Page 38] I2NSF Intelligent Detection March 2023 "Specify the time of the information being delivered."; } uses message; container system-feedback-information { description "The resources alarm about CPU, memory, disks or interfaces will be sent to I2NSF security controller."; choice alarm-type { description "The alarm type."; case memory-alarm { container memory-alarm { description "The container for memory alarm."; leaf usage { type uint8 { range "0..100"; } units "percent"; description "The average usage for the duration of the alarm."; } leaf duration { type uint32; description "Specify the duration of the first alarm triggered until the feedback information is created."; } } } case cpu-alarm { container cpu-alarm { description "The case for CPU alarm."; leaf usage { type uint8 { range "0..100"; } units "percent"; description "The average usage for the duration of the alarm."; } leaf duration { type uint32; Wang, et al. Expires – October 2023 [Page 39] I2NSF Intelligent Detection March 2023 description "Specify the duration of the first alarm triggered until the feedback information is created."; } } } case disk-alarm { container disk-alarm { description "The container for disk alarm."; leaf disk-id { type string; description "The ID of the storage disk. It is free form identifier to identify the storage disk."; } leaf usage { type uint8 { range "0..100"; } units "percent"; description "The average usage for the duration of the alarm."; } leaf duration { type uint32; description "Specify the duration of the first alarm triggered until the feedback information is created."; } } } case interface-alarm { container interface-alarm { description "The container for interface alarm."; leaf interface-id { type string; description "The ID of the network interface. It is a free form identifier to identify the network interface."; } leaf interface-state { type enumeration { Wang, et al. Expires – October 2023 [Page 40] I2NSF Intelligent Detection March 2023 enum up { value 1; description "The interface state is up and not congested. The interface is ready to pass packets."; } enum down { value 2; description "The interface state is down, i.e., does not pass any packets."; } enum congested { value 3; description "The interface state is up but congested."; } enum testing { value 4; description "In some test mode. No operational packets can be passed."; } enum unknown { value 5; description "Status cannot be determined for some reason."; } enum dormant { value 6; description "Waiting for some external event."; } enum not-present { value 7; description "Some component (typically hardware) is missing."; } enum lower-layer-down { value 8; description "Down due to state of lower-layer interface(s)."; } } Wang, et al. Expires – October 2023 [Page 41] I2NSF Intelligent Detection March 2023 description "The state of the interface. Applicable for Network Interface Failure Alarm."; reference "RFC 8343: A YANG Data Model for Interface Management- Operational States"; } leaf duration { type uint32; description "Specify the duration of the first alarm triggered until the feedback information is created."; } } } } } container nsf-feedback-information { description "The output of NSFs will be sent to the I2NSF security controller."; choice nsf-type { description "The NSF type."; case detection-module { container detection-module{ description "The container for the detection module."; leaf detection-module-name { type string; description "The name of the specific detection module."; } container detected-attacks { description "The information of detected attacks."; list attack-traffic{ key attack-id; description "The five-tuple (src/dst ip, port and protocol) and attack type information of specific attack traffic."; leaf attack-id { type string; description "The ID of the specific attack traffic Wang, et al. Expires – October 2023 [Page 42] I2NSF Intelligent Detection March 2023 which has the same src/dst ip, protocol and attack type."; } leaf attack-type { type string; description "The type of the detected attack."; } leaf attack-src-ip { type inet:ip-address-no-zone; description "The source IPv4 or IPv6 addresses of attack traffic. It can hold multiple IPv4 or IPv6 addresses."; } leaf attack-dst-ip { type inet:ip-address-no-zone; description "The destination IPv4 or IPv6 addresses of attack traffic. It can hold multiple IPv4 or IPv6 addresses."; } leaf-list attack-src-port { type inet:port-number; description "The transport-layer source ports of the attack."; } leaf-list attack-dst-port { type inet:port-number; description "The transport-layer destination ports of the attack."; } leaf protocol { type identityref { base protocol; } description "The type of network protocol for the interface counter. If this field is empty, then the counter includes all protocols (e.g., IPv4, IPv6, TCP, and UDP)"; } uses attack-rates; } } } Wang, et al. Expires – October 2023 [Page 43] I2NSF Intelligent Detection March 2023 } } } } list i2nsf-reconfiguration-policy { description "The reconfiguration policy generated by the I2NSF Analyzer, which will be sent to the I2NSF security controller."; key name; leaf name { type string; description "The name of the reconfiguration policy."; } choice policy-type { case path-reconfiguration-policy{ container path-reconfiguration-policy{ description "The container for path reconfiguration policy."; list service-function-path{ key path-id; description "Indicates the NSFs through which traffic passes in sequence."; leaf path-id{ type string; description "Identify the different service function paths."; } container nsfs { description "The container for the NSFs in the service function chain (SFC)."; list nsf { key nsf-name; description "The container for the NSF."; leaf nsf-name { type string; description "Use the name to identify the NSF."; } leaf sequence-number { type uint64; description "Identifies the sequence of the NSF Wang, et al. Expires – October 2023 [Page 44] I2NSF Intelligent Detection March 2023 in the service function path."; } } } } } } } } } 4.3 The Extended NSF-Facing Interface This section describes the Extended NSF-Facing Interface. The extension to the interface is the path configuration rule. The path configuration rule contains the following information: o path-id: Identify the different service function paths. o classifier-name: Use the name to identity the classifier. o classifier-ip: The IPv4 or IPv6 address of the classifier. o nsf-name: Use the name to identify the NSF. o sequence-number: Identifies the sequence of the NSF in the service function path. o nsf-ip: The IPv4 or IPv6 address of the NSF. o sff-ip: The IPv4 or IPv6 address of the corresponding SFF. 4.3.1 YANG Tree Structure of Extended NSF-Facing YANG Module The tree structure of the Extended NSF-Facing YANG module is provided below: module: wang-i2nsf-extension-nsf-facing-interface +--rw i2nsf-security-policy* [policy-name] +--rw policy-name string +--rw path-configuration-rule +--rw path-id? string Wang, et al. Expires – October 2023 [Page 45] I2NSF Intelligent Detection March 2023 +--rw classifiers | +--rw classifier* [classifier-name] | +--rw classifier-name string | +--rw classifier-ip? inet:ip-address-no-zone +--rw nsfs +--rw nsf* [nsf-name] +--rw nsf-name string +--rw sequence-number? uint64 +--rw ip-address +--rw nsf-ip? inet:ip-address-no-zone +--rw sff-ip? inet:ip-address-no-zone Figure 4: YANG Tree Structure of Extended NSF-Facing YANG Module 4.3.2 YANG Data Model of Extended NSF-Facing YANG Module This section describes a YANG module of I2NSF extended NSF facing interface. This YANG module imports from [RFC6991], and makes references to [I-D. ietf-i2nsf-nsf-facing-interface-dm]. file "wang-i2nsf-extended-nsf-facing-interface@2023- 03-21.yang" module ietf-wang-i2nsf-extension-nsf-facing-interface { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:wang-i2nsf-extension- nsf-facing-interface"; prefix i2nsf-exnfi; import ietf-inet-types { prefix inet; reference "RFC 6991"; } organization "IETF I2NSF (Interface to Network Security Functions) Working Group"; contact "WG Web: WG List: Author: Weilin Wang Author: Qi Guo Wang, et al. Expires – October 2023 [Page 46] I2NSF Intelligent Detection March 2023 Author: Shuangxing Deng "; description "This module is a YANG module for the extension of I2NSF NSF-Facing Interface. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2022 IETF Trust and the persons identified as authors of the code. All rights reserved. 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 Revised 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 "2023-03-21"{ description "Initial revision."; reference "RFC XXXX: Extension of I2NSF NSF-Facing Interface YANG Data Model"; } list i2nsf-security-policy { key policy-name; description "The container for the security policy."; leaf policy-name { type string; description "The name of the security policy."; } container path-configuration-rule { description "The container for path configuration rule."; leaf path-id { Wang, et al. Expires – October 2023 [Page 47] I2NSF Intelligent Detection March 2023 type string; description "Identify the different service function paths."; } container classifiers { description "The container for classifiers in the service function chain (SFC)."; list classifier { key classifier-name; description "The container for the classifier."; leaf classifier-name { type string; description "Use the name to identity the classifier."; } leaf classifier-ip { type inet:ip-address-no-zone; description "The IPv4 or IPv6 address of the classifier."; } } } container nsfs { description "The container for the nsfs in the service function chain (SFC)."; list nsf { key nsf-name; description "The container for the NSF."; leaf nsf-name { type string; description "Use the name to identify the NSF."; } leaf sequence-number { type uint64; description "Identifies the sequence of the NSF in the service function path."; } container ip-address { description "The IPv4 or IPv6 address of the NSF and the corresponding service function forwarder (SFF)."; leaf nsf-ip { description Wang, et al. Expires – October 2023 [Page 48] I2NSF Intelligent Detection March 2023 "The IPv4 or IPv6 address of the NSF."; type inet:ip-address-no-zone; } leaf sff-ip { description "The IPv4 or IPv6 address of the corresponding SFF."; type inet:ip-address-no-zone; } } } } } } } 5. XML Examples of I2NSF Framework for AID This section shows XML examples for the DDoS attacks [Two-Stage Intelligent Model for Detecting Malicious DDoS Behavior] intelligent detection, including XMLs of traffic flow features, path reconfiguration policy and path configuration rules. Refer to [RFC5277] for more detailed explanation of Event Streams. The XML examples in this document follow the line breaks as per [RFC8792]. +----------------------------------------------+ | Secure Network | | CF/SFF:192.168.14.0/24,DDoS-DM:172.17.0.0/16 | | +-------------------------+ | +-------------+ | +---+ | +---------+ | +---+ | |DDoS Attacker| | |CF1|-->| |SFF1 | |->|CF2| | |23.1.0.22, |DDoS | +---+ | |DDoS-DM-1| +---------+ | +---+ | |23.1.0.23, +----->| | +---------+ |SFF3 | | | | |23.1.0.24 |Attack| | +---------+ |DDoS-DM-3| | | | +-------------+ | | |SFF2 | |DDoS-DM-5| | v | | | |DDoS-DM-2| +---------+ | +------+ | | | |DDoS-DM-4| | |Server| | | | +---------+ | +------+ | | +-------------------------+ | +----------------------------------------------+ Figure 5: A Scenario Example of a DDoS Attack In this example, the scenario can be seen in Figure 5. This example contains five DDoS DMs to detect different types of DDoS attacks. The system presets an SFC path, path1= {DDoS-DM-2, DDoS-DM-1, DDoS-DM-4, DDoS-DM-3}. Wang, et al. Expires – October 2023 [Page 49] I2NSF Intelligent Detection March 2023 The entrance classifier (CF1) feeds back traffic features to the I2NSF Analyzer through the Extended Monitoring Interface. The following XML file shows the feedback traffic flow features: 2022-09-20T11:28:01.00Z CF1 subscription on-change on-repetition 5 400.18 450643.1 1126.1 3.27 1.71 3.17 5.34 4.44 5.02 5.02 2.5 0 Figure 6: The Feedback Traffic Flow Features by CF1 The XML file in Figure6 shows: o The NSF that sends the information is named "CF1". o The monitoring information is received by subscription method. o The monitoring information is emitted "on-change". o The monitoring information is dampened "on-repetition". o The measurement time is 5s. Wang, et al. Expires – October 2023 [Page 50] I2NSF Intelligent Detection March 2023 o The packets per second is 400.18. o The bytes per second is 450643.1. o The packet size mean is 1126.1. o The source IP entropy is 3.27. o The destination IP entropy is 1.71. o The TTL entropy is 3.17. o The TCP source port entropy is 5.34. o The TCP destination port entropy is 4.44. o The UDP source port entropy is 5.02. o The UDP destination port entropy is 5.02. o The packet size entropy is 2.5. o The packets variance is 0. I2NSF Analyzer analyzes traffic features and generates path reconfiguration policies for the current traffic. The policy is sent to the Security Controller through the Extended Analytics Interface. The following XML file shows the path reconfiguration policy: detection-path-reconfiguration-policy path2 DDoS-DM-5 1 DDoS-DM-3 2 Wang, et al. Expires – October 2023 [Page 51] I2NSF Intelligent Detection March 2023 DDoS-DM-4 3 Figure 7: The Path Reconfiguration Policy Generated by I2NSF Analyzer The XML file in Figure7 shows: o The policy name is "detection-path-reconfiguration-policy". o The path ID is "path2". o The NSFs in the path are named "DDoS-DM-5", "DDoS-DM-3" and "DDoS-DM-4". Their sequence numbers are "1", "2" and "3" respectively. The Security Controller translates this policy into path configuration rules and sends these rules to the SDN Controller through the Extended NSF-Facing Interface. The following XML file shows the path configuration rules for SDN Controller: detection-path-reconfiguration-policy path2 CF1 192.168.14.7 CF2 192.168.14.8 DDoS-DM-5 1 172.17.23.2 192.168.14.23 Wang, et al. Expires – October 2023 [Page 52] I2NSF Intelligent Detection March 2023 DDoS-DM-3 2 172.17.23.3 192.168.14.23 DDoS-DM-4 3 172.17.24.2 192.168.14.24 Figure 8: The Path Configuration Rules for SDN Controller The XML file in Figure8 shows: o The policy name is "detection-path-reconfiguration-policy". o The path ID is "path2". o The classifiers in the path are named "CF1" and "CF2". Their IP addresses are "192.168.14.7" and "192.168.14.8" respectively. o The first NSF in the path is named "DDoS-DM-5". Its IP address is "172.17.23.2", and its corresponding SFF IP address is "192.168.14.23". o The second NSF in the path is named "DDoS-DM-3". Its IP address is "172.17.23.3", and its corresponding SFF IP address is "192.168.14.23". o The third NSF in the path is named "DDoS-DM-4". Its IP address is "172.17.24.2", and its corresponding SFF IP address is "192.168.14.24". The SDN Controller generates flow tables according to the path configuration rules and sends them to CFs and SFFs to make the traffic pass the new detection path, path2= {DDoS-DM-5, DDoS-DM-3, DDoS-DM-4}. Through three extended interfaces, I2NSF Analyzer and Wang, et al. Expires – October 2023 [Page 53] I2NSF Intelligent Detection March 2023 Security Controller realize dynamic automatic adjustment of DDoS attack detection path policy based on the closed-loop feedback. 6. IANA Considerations This document has no IANA actions 7. Security Considerations The YANG module specified in this document defines a data schema designed to be accessed through network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the required secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the required secure transport is TLS [RFC8446]. The NETCONF access control model [RFC8341] provides a means of restricting access to specific NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/delectable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. The data models in this document uses the data model from NSF Monitoring data model, Analytics Interface YANG data model and NSF-Facing Interface data model, they MUST follow the Security Considerations mentioned in [I-D. ietf-i2nsf-nsf-monitoring- data-model], [I-D. lingga-i2nsf-analytics-interface-dm] and [I-D. ietf-i2nsf-nsf-facing-interface-dm]. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. Thus, it is important to control read access (e.g., via get, get-config, or notification) to these data nodes. This document MUST also follow the Security Considerations about the readable data nodes mentioned in [I-D. ietf-i2nsf-nsf-monitoring-data-model], [I-D. lingga-i2nsf- analytics-interface-dm] and [I-D. ietf-i2nsf-nsf-facing-interface- dm]. 8. References 8.1 Normative References Wang, et al. Expires – October 2023 [Page 54] I2NSF Intelligent Detection March 2023 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1983, . [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, . [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, . [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, DOI 10.17487/RFC2595, June 1999, . [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006,. [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, . Wang, et al. Expires – October 2023 [Page 55] I2NSF Intelligent Detection March 2023 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010, . [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, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", RFC 8341, DOI 10.17487/RFC8341, STD 91, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, . Wang, et al. Expires – October 2023 [Page 56] I2NSF Intelligent Detection March 2023 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet MessageAccess Protocol (IMAP) - Version 4rev2", RFC 9051, DOI 10.17487/RFC9051, August 2021, . [RFC9110] R. Fielding, M. Nottingham and J. Reschke, "HTTP Semantics", RFC9110, DOI 10.17487/RFC9110, June 2022, . [RFC9112] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP/1.1", RFC9112, DOI 10.17487/RFC9112, June 2022, . [RFC9113] Thomson, M. and C. Benfield, "HTTP/2", RFC9113, DOI 10.17487/RFC9113, June 2022, . [RFC9260] R. Stewart, M. Tüxen and K. Nielsen, "Stream Control Transmission Protocol", DOI 10.17487/RFC9260, June 2022, . [RFC9293] W. Eddy, "Transmission Control Protocol (TCP)", DOI 10.17487/RFC9293, August 2022, . [I-D. lingga-i2nsf-analytics-interface-dm] P. Lingga, Ed., J. Jeong, Ed. and Y. Choi, "I2NSF Analytics Interface YANG Data Model", Work in Progress, Internet-Draft, draft-lingga-i2nsf-analytics-interface-dm-00, 25 July 2022, < https://www.ietf.org/archive/id/draft-lingga-i2nsf-analytics- interface-dm-00.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. ietf-i2nsf-nsf-facing-interface-dm] Kim, J. T., Jeong, J. P., Park, J., Hares, S., and Q. Lin, "I2NSF Network Security Function-Facing Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietfi2nsf-nsf- facing-interface-dm-29, 1 June 2022, . Wang, et al. Expires – October 2023 [Page 57] I2NSF Intelligent Detection March 2023 [I-D. ietf-i2nsf-nsf-monitoring-data-model] Jeong, J. P., Lingga, P., Hares, S., Xia, L. F., and H. Birkholz, "I2NSF NSF Monitoring Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietfi2nsf-nsf- monitoring-data-model-20, 1 June 2022, . [I-D. jeong-i2nsf-security-management-automation] Jeong, J. (., Lingga, P., and J. Park, "An Extension of I2NSF Framework for Security Management Automation in Cloud-Based Security Services", Work in Progress, Internet-Draft, draft- jeong-i2nsf-security-managementautomation-04, 25 July 2022, . [ITU-TY.3300] International Telecommunications Union "Y.3300: Framework of software defined networking", June 2014, . 8.2 Informative References [RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, October 2015, . [RFC8192] Hares, S. Lopez, D. Zarny, M. Jacquenet, C. Kumar, R. and J. Jeong "Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases" RFC8192 DOI 10.17487/RFC8192 . [RFC8329] Lopez, D. Lopez, E. Dunbar, L. Strassner, J. R. Kumar "Framework for Interface to Network Security Functions", RFC 8329, DOI 10.17487/RFC8329, . [RFC8455] V. Bhuvaneswaran, A. Basil, M. Tassinari, V. Manral and S. Banks, "Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance", RFC8455, DOI 10.17487/RFC8455, . [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, . Wang, et al. Expires – October 2023 [Page 58] I2NSF Intelligent Detection March 2023 [Two-Stage Intelligent Model for Detecting Malicious DDoS Behavior] Li, M.; Zhou, H.; Qin, Y. Two-Stage Intelligent Model for Detecting Malicious DDoS Behavior. Sensors 2022, 22, 2532. https:// doi.org/10.3390/s22072532 Acknowledgments TBC Author's Addresses Weilin Wang Beijing Jiaotong University Beijing Phone: <86-15910887582> Email: 21111026@bjtu.edu.cn Huachun Zhou Beijing Jiaotong University Beijing Phone: <86-13718168186> Email: hchzhou@bjtu.edu.cn Man Li Beijing Jiaotong University Beijing Phone: <86-18810911698> Email: 20111018@bjtu.edu.cn Qi Guo Beijing Jiaotong University Beijing Phone: <86-18310379269> Email: 20120044@bjtu.edu.cn Shuangxing Deng Beijing Jiaotong University Beijing Phone: <86-13040062046> Email: 21120038@bjtu.edu.cn Wang, et al. Expires – October 2023 [Page 59]