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 DetectionStatus 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 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.
Wang, et al. Expires â October 2023 [Page 2]
I2NSF Intelligent Detection March 2023
2. Terminology 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 [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.
Wang, et al. Expires â October 2023 [Page 3]
I2NSF Intelligent Detection March 2023
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]. 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
Wang, et al. Expires â October 2023 [Page 4]
I2NSF Intelligent Detection March 2023
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 forthe 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. o start-time: The start time for the detection.
Wang, et al. Expires â October 2023 [Page 8]
I2NSF Intelligent Detection March 2023
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 | +--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
Wang, et al. Expires â October 2023 [Page 9]
I2NSF Intelligent Detection March 2023
| +--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? uint64Figure 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]. <CODE BEGINS> file "wang-i2nsf-extended-monitoring-interface@2023- 03-28.yang" module ietf-wang-i2nsf-extended-monitoring-interface{ yang-version 1.1; namespace
Wang, et al. Expires â October 2023 [Page 11]
I2NSF Intelligent Detection March 2023
"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: <https://datatracker.ietf.org/wg/i2nsf>
WG List: <mailto:i2nsf@ietf.org> Author: Weilin Wang
<mailto:21111026@bjtu.edu.cn>
Author: Huachun Zhou
<mailto:hchzhou@bjtu.edu.cn>
Author: Man Li
<mailto:20111018@bjtu.edu.cn>
Author: Qi Guo
<mailto:20120044@bjtu.edu.cn>
Author: Shuangxing Deng
<mailto:21120038@bjtu.edu.cn>";
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 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.";
Wang, et al. Expires â October 2023 [Page 12]
I2NSF Intelligent Detection March 2023
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 { base application-protocol; description
Wang, et al. Expires â October 2023 [Page 17]
I2NSF Intelligent Detection March 2023
"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."; } leaf language {
Wang, et al. Expires â October 2023 [Page 19]
I2NSF Intelligent Detection March 2023
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;
} description
Wang, et al. Expires â October 2023 [Page 20]
I2NSF Intelligent Detection March 2023
"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 { type uint64; description
Wang, et al. Expires â October 2023 [Page 23]
I2NSF Intelligent Detection March 2023
"Variance of packets measured over thepast '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.";
} leaf disk-space-left { type uint8; units "percent"; description
Wang, et al. Expires â October 2023 [Page 25]
I2NSF Intelligent Detection March 2023
"Specifies the available disk space left ofdisk-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 { type uint64; units "percent"; description
Wang, et al. Expires â October 2023 [Page 26]
I2NSF Intelligent Detection March 2023
"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 "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
Wang, et al. Expires â October 2023 [Page 27]
I2NSF Intelligent Detection March 2023
"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;
}
}
}
}
}
}
}
}
<CODE ENDS>
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: o name: The name of the reconfiguration policy. o path-id: Identify the different service function paths.
Wang, et al. Expires â October 2023 [Page 29]
I2NSF Intelligent Detection March 2023
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 | +--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)?
Wang, et al. Expires â October 2023 [Page 30]
I2NSF Intelligent Detection March 2023
+--:(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]. <CODE BEGINS> 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 { prefix yang; reference "RFC6991"; } organization
Wang, et al. Expires â October 2023 [Page 31]
I2NSF Intelligent Detection March 2023
"IETF I2NSF (Interface to Network Security Functions)Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/i2nsf>
WG List: <mailto:i2nsf@ietf.org>
Author: Weilin Wang <mailto:21111026@bjtu.edu.cn> Author: Qi Guo <mailto:20120044@bjtu.edu.cn> Author: Shuangxing Deng <mailto:21120038@bjtu.edu.cn>";
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 ProtocolRFC0792: 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";
} identity application-protocol { base protocol; description
Wang, et al. Expires â October 2023 [Page 34]
I2NSF Intelligent Detection March 2023
"Base identity for Application protocol. Notethat 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]-' + '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|'
Wang, et al. Expires â October 2023 [Page 37]
I2NSF Intelligent Detection March 2023
+ '[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 "Specify the time of the information
Wang, et al. Expires â October 2023 [Page 38]
I2NSF Intelligent Detection March 2023
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 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
Wang, et al. Expires â October 2023 [Page 42]
I2NSF Intelligent Detection March 2023
"The source IPv4 or IPv6 addressesof 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.";}
}
}
}
}
}
}
}
} <CODE ENDS>
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 +--rw classifiers | +--rw classifier* [classifier-name] | +--rw classifier-name string | +--rw classifier-ip? inet:ip-address-no-zone +--rw nsfs
Wang, et al. Expires â October 2023 [Page 45]
I2NSF Intelligent Detection March 2023
+--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].<CODE BEGINS> 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: <https://datatracker.ietf.org/wg/i2nsf>
WG List: <mailto:i2nsf@ietf.org> Author: Weilin Wang <mailto:21111026@bjtu.edu.cn> Author: Qi Guo <mailto:20120044@bjtu.edu.cn> Author: Shuangxing Deng <mailto:21120038@bjtu.edu.cn>";
Wang, et al. Expires â October 2023 [Page 46]
I2NSF Intelligent Detection March 2023
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;
}
}
}
}
}
}
} <CODE ENDS>
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 AttackIn 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}. 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: <?xml version="1.0" encoding="UTF-8"?> <notification
Wang, et al. Expires â October 2023 [Page 49]
I2NSF Intelligent Detection March 2023
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"><eventTime>2022-09-20T11:28:01.00Z</eventTime> <i2nsf-event
xmlns="urn:ietf:params:xml:ns:yang:wang-i2nsf-extended-
monitoring-interface">
<nsf-name>CF1</nsf-name> <acquisition-method>subscription</acquisition-method> <emission-type>on-change</emission-type> <dampening-type>on-repetition</dampening-type> <i2nsf-traffic-flow-features> <measurement-time>5</measurement-time> <packets-per-second>400.18</packets-per-second> <bytes-per-second>450643.1</bytes-per-second> <packet-size-mean>1126.1</packet-size-mean> <src-ip-entropy>3.27</src-ip-entropy> <dst-ip-entropy>1.71</dst-ip-entropy> <TTL-entropy>3.17</TTL-entropy> <tcp-src-port-entropy>5.34</tcp-src-port-entropy> <tcp-dst-port-entropy>4.44</tcp-dst-port-entropy> <udp-src-port-entropy>5.02</udp-src-port-entropy> <udp-dst-port-entropy>5.02</udp-dst-port-entropy> <packet-size-entropy>2.5</packet-size-entropy> <packets-variance>0</packets-variance>
</i2nsf-traffic-flow-features>
</i2nsf-event>
</notification>
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. o The packets per second is 400.18.
Wang, et al. Expires â October 2023 [Page 50]
I2NSF Intelligent Detection March 2023
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: <?xml version="1.0" encoding="UTF-8"?> <i2nsf-reconfiguration-policy
xmlns="urn:ietf:params:xml:ns:yang:wang-i2nsf-extension-analytics-
interface">
<name>detection-path-reconfiguration-policy</name> <path-reconfiguration-policy>
<service-function-path>
<path-id>path2</path-id> <nsfs>
<nsf>
<nsf-name>DDoS-DM-5</nsf-name> <sequence-number>1</sequence-number> </nsf> <nsf> <nsf-name>DDoS-DM-3</nsf-name> <sequence-number>2</sequence-number> </nsf> <nsf> <nsf-name>DDoS-DM-4</nsf-name> <sequence-number>3</sequence-number>
Wang, et al. Expires â October 2023 [Page 51]
I2NSF Intelligent Detection March 2023
</nsf></nsfs>
</service-function-path>
</path-reconfiguration-policy>
</i2nsf-reconfiguration-policy> 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: <?xml version="1.0" encoding="UTF-8"?> <i2nsf-security-policy
xmlns="urn:ietf:params:xml:ns:yang:wang-i2nsf-extension-nsf-facing-
interface">
<policy-name>detection-path-reconfiguration-policy</policy-name> <path-configuration-rule> <path-id>path2</path-id> <classifiers>
<classifier>
<classifier-name>CF1</classifier-name> <classifier-ip>192.168.14.7</classifier-ip> </classifier> <classifier> <classifier-name>CF2</classifier-name> <classifier-ip>192.168.14.8</classifier-ip>
</classifier>
</classifiers> <nsfs>
<nsf>
<nsf-name>DDoS-DM-5</nsf-name> <sequence-number>1</sequence-number> <ip-address> <nsf-ip>172.17.23.2</nsf-ip> <sff-ip>192.168.14.23</sff-ip>
Wang, et al. Expires â October 2023 [Page 52]
I2NSF Intelligent Detection March 2023
</ip-address></nsf> <nsf> <nsf-name>DDoS-DM-3</nsf-name> <sequence-number>2</sequence-number> <ip-address> <nsf-ip>172.17.23.3</nsf-ip> <sff-ip>192.168.14.23</sff-ip>
</ip-address>
</nsf> <nsf> <nsf-name>DDoS-DM-4</nsf-name> <sequence-number>3</sequence-number> <ip-address> <nsf-ip>172.17.24.2</nsf-ip> <sff-ip>192.168.14.24</sff-ip>
</ip-address>
</nsf>
</nsfs>
</path-configuration-rule>
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 Security Controller realize dynamic automatic adjustment of DDoS attack detection path policy based on the closed-loop feedback.
Wang, et al. Expires â October 2023 [Page 53]
I2NSF Intelligent Detection March 2023
6. IANA Considerations This document has no IANA actions7. 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, DOI10.17487/RFC0768, August 1980, <https://www.rfc- editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI
10.17487/RFC0791, September 1981, <https://www.rfc- editor.org/info/rfc791>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May 1983, <https://www.rfc-editor.org/info/rfc854>.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD
9, RFC 959, DOI 10.17487/RFC0959, October 1985, <https://www.rfc-editor.org/info/rfc959>.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, <https://www.rfc-editor.org/info/rfc1939>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc- editor.org/info/rfc2119>.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
DOI 10.17487/RFC2595, June 1999, <https://www.rfc- editor.org/info/rfc2595>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006,<https://www.rfc- editor.org/info/rfc4340>.
[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, <https://www.rfc- editor.org/info/rfc4443>.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications",
RFC 5277, DOI 10.17487/RFC5277, July 2008, <https://www.rfc-editor.org/info/rfc5277>.
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, <https://www.rfc- editor.org/info/rfc5321>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[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, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991,
DOI 10.17487/RFC6991, July 2013, <https://www.rfc- editor.org/info/rfc6991>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc- editor.org/info/rfc8200>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", RFC 8341, DOI 10.17487/RFC8341, STD 91, March 2018, <https://www.rfc-editor.org/info/rfc8341>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, <https://www.rfc-editor.org/info/rfc8641>.
Wang, et al. Expires â October 2023 [Page 56]
I2NSF Intelligent Detection March 2023
[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "InternetMessageAccess Protocol (IMAP) - Version 4rev2", RFC 9051, DOI 10.17487/RFC9051, August 2021, <https://www.rfc- editor.org/info/rfc9051>.
[RFC9110] R. Fielding, M. Nottingham and J. Reschke, "HTTP
Semantics", RFC9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.
[RFC9112] Fielding, R. T., Nottingham, M., and J. Reschke,
"HTTP/1.1", RFC9112, DOI 10.17487/RFC9112, June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[RFC9113] Thomson, M. and C. Benfield, "HTTP/2", RFC9113, DOI
10.17487/RFC9113, June 2022, <https://www.rfc- editor.org/info/rfc9113>.
[RFC9260] R. Stewart, M. Tüxen and K. Nielsen, "Stream Control
Transmission Protocol", DOI 10.17487/RFC9260, June 2022, <https://www.rfc-editor.org/info/rfc9260>.
[RFC9293] W. Eddy, "Transmission Control Protocol (TCP)", DOI
10.17487/RFC9293, August 2022, <https://www.rfc- editor.org/info/rfc9293>.
[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, <https://www.ietf.org/archive/id/draft-ietf-i2nsf- applicability-18.txt>.
[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, <https://www.ietf.org/archive/id/draft-ietf-i2nsf-nsffacing- interface-dm-29.txt>.
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, <https://www.ietf.org/archive/id/draft-ietf-i2nsf- nsfmonitoring-data-model-20.txt>.
[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, <https://www.ietf.org/archive/id/draft-jeong-i2nsfsecurity- management-automation-04.txt>.
[ITU-TY.3300]
International Telecommunications Union "Y.3300: Framework of software defined networking", June 2014, <https://www.itu.int/rec/T-REC-Y.3300/en>.
8.2 Informative References
[RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining(SFC) Architecture", RFC 7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[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 <https://www.rfc-editor.org/info/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, <https://www.rfc- editor.org/info/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, <https://www.rfc- editor.org/info/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, <https://www.rfc-editor.org/info/rfc8792>.
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]
