Interface to Network Security Functions (i2nsf) Internet Drafts

      
 Applicability of Interfaces to Network Security Functions to Network-Based Security Services
 
 draft-ietf-i2nsf-applicability-18.txt
 Date: 16/09/2019
 Authors: Jaehoon Jeong, Sangwon Hyun, Tae-Jin Ahn, Susan Hares, Diego Lopez
 Working Group: Interface to Network Security Functions (i2nsf)
 This document describes the applicability of Interface to Network Security Functions (I2NSF) to network-based security services in Network Functions Virtualization (NFV) environments, such as firewall, deep packet inspection, or attack mitigation engines.
 I2NSF Consumer-Facing Interface YANG Data Model
 
 draft-ietf-i2nsf-consumer-facing-interface-dm-31.txt
 Date: 15/05/2023
 Authors: Jaehoon Jeong, Chaehong Chung, Tae-Jin Ahn, Rakesh Kumar, Susan Hares
 Working Group: Interface to Network Security Functions (i2nsf)
 This document describes a YANG data model of the Consumer-Facing Interface of the Security Controller in an Interface to Network Security Functions (I2NSF) system in a Network Functions Virtualization (NFV) environment. This document defines various types of managed objects and the relationship among them needed to build the flow policies from users' perspective. The YANG data model is based on the "Event-Condition-Action" (ECA) policy defined by a capability YANG data model for I2NSF. The YANG data model enables different users of a given I2NSF system to define, manage, and monitor flow policies within an administrative domain (e.g., user group).
 I2NSF Network Security Function-Facing Interface YANG Data Model
 
 draft-ietf-i2nsf-nsf-facing-interface-dm-29.txt
 Date: 01/06/2022
 Authors: Jinyong Kim, Jaehoon Jeong, J., PARK, Susan Hares, Qiushi Lin
 Working Group: Interface to Network Security Functions (i2nsf)
 This document defines a YANG data model for configuring security policy rules on Network Security Functions (NSF) in the Interface to Network Security Functions (I2NSF) framework. The YANG data model in this document is for the NSF-Facing Interface between a Security Controller and NSFs in the I2NSF framework. It is built on the basis of the YANG data model in the I2NSF Capability YANG Data Model document for the I2NSF framework.
 I2NSF Capability YANG Data Model
 
 draft-ietf-i2nsf-capability-data-model-32.txt
 Date: 23/05/2022
 Authors: Susan Hares, Jaehoon Jeong, Jinyong Kim, Robert Moskowitz, Qiushi Lin
 Working Group: Interface to Network Security Functions (i2nsf)
 This document defines an information model and the corresponding YANG data model for the capabilities of various Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework to centrally manage the capabilities of the various NSFs.
 I2NSF Registration Interface YANG Data Model for NSF Capability Registration
 
 draft-ietf-i2nsf-registration-interface-dm-26.txt
 Date: 10/05/2023
 Authors: Sangwon Hyun, Jaehoon Jeong, TaeKyun Roh, Sarang Wi, J., PARK
 Working Group: Interface to Network Security Functions (i2nsf)
 This document defines a YANG data model for the Registration Interface between Security Controller and Developer's Management System (DMS) in the Interface to Network Security Functions (I2NSF) framework to register Network Security Functions (NSF) of the DMS with the Security Controller. The objective of this data model is to support NSF capability registration and query via I2NSF Registration Interface.
 I2NSF NSF Monitoring Interface YANG Data Model
 
 draft-ietf-i2nsf-nsf-monitoring-data-model-20.txt
 Date: 01/06/2022
 Authors: Jaehoon Jeong, Patrick Lingga, Susan Hares, Liang Xia, Henk Birkholz
 Working Group: Interface to Network Security Functions (i2nsf)
 This document proposes an information model and the corresponding YANG data model of an interface for monitoring Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework. If the monitoring of NSFs is performed with the NSF monitoring interface in a standard way, it is possible to detect the indication of malicious activity, anomalous behavior, the potential sign of denial-of-service attacks, or system overload in a timely manner. This monitoring functionality is based on the monitoring information that is generated by NSFs. Thus, this document describes not only an information model for the NSF monitoring interface along with a YANG tree diagram, but also the corresponding YANG data model.

data-group-menu-data-url="/group/groupmenu.json">

Interface to Network Security Functions (i2nsf)

WG Name Interface to Network Security Functions
Acronym i2nsf
Area Security Area (sec)
State Active
Charter charter-ietf-i2nsf-01 Approved
Document dependencies
Additional resources Issue tracker, Wiki, Zulip stream
Personnel Chairs Linda Dunbar, Yoav Nir
Area Director Roman Danyliw
Mailing list Address i2nsf@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/i2nsf
Archive https://mailarchive.ietf.org/arch/browse/i2nsf/
Chat Room address https://zulip.ietf.org/#narrow/stream/i2nsf

Charter for Working Group

A Network Security Function (NSF) is a function used to ensure integrity, confidentiality, or availability of network communications, to detect unwanted network activity, or to block or at least mitigate the effects of unwanted activity. NSFs are provided and consumed in increasingly diverse environments. Users could consume network security services enforced by NSFs hosted by one or more providers, which may be their own enterprise, service providers, or a combination of both. Similarly, service providers may offer their customers network security services that are enforced by multiple security products, functions from different vendors, or open source technologies. NSFs may be provided by physical and/or virtualized infrastructure. Without standard interfaces to control and monitor the behavior of NSFs, it has become virtually impossible for providers of security services to automate service offerings that utilize different security functions from multiple vendors.

The goal of I2NSF is to define a set of software interfaces and data models for controlling and monitoring aspects of physical and virtual NSFs, enabling clients to specify rulesets. If the working group finds it necessary to work on an information model before the data models, to help provide guidance and derive the data models, it may do so. The working group will decide later whether the information model needs to be published as an RFC. Other aspects of NSFs, such as device or network provisioning and configuration, are out of scope. As there are many different security vendors or open source technologies supporting different features and functions on their devices, I2NSF will focus on flow-based NSFs that provide treatment to packets/flows, such as Intrusion Protection/Detection System (IPS/IDS), web filtering, flow filtering, deep packet inspection, or pattern matching and remediation.

Controlling and monitoring aspects of NSFs include the ability to specify rules (by a single controller at the first phase), query, and monitor NSFs by one or more management entities. The initial phase of I2NSF will only consider one single controller that can specify or change rules to NSFs because multi-headed control requires the coordination to avoid potential conflict of rules. The NSFs can be monitored by multiple entities, but the database update and synchronization among multiple management entities are out of scope for I2NSF.

I2NSF will specify interfaces at two functional levels for the control and monitoring of network security functions:

The I2NSF Capability Layer specifies how to control and monitor NSFs at a functional implementation level. The term "Functional Implementation" is used to emphasize that the rules (for control and monitor) of NSFs have to be implementable by most NSFs. I2NSF will standardize a set of interfaces by which a security controller can invoke, operate, and monitor NSFs.

The I2NSF Service Layer defines how clients' security policies may be expressed to a security controller. The controller implements its policies according to the various capabilities provided by the I2NSF Capability Layer. The I2NSF Service Layer also allows the client to monitor the client specific policies.

A client may leverage the I2NSF Service Layer interface to express security policies to a security controller, which in turn interacts with one or more NSFs through the I2NSF Capability Layer interface. Alternatively, a client may interact with one or more NSFs directly through the I2NSF Capability Layer interface.

Since there could be many depths or types of Service Layer policies, the following bullets further clarify the scope of I2NSF:
o Only the simple Service Layer policies that are modeled as closely as possible on the Capability Layer are within the scope.
Simple Service Layer policies can be directly translated to capability layer rules with a direct mapping that might include a customer ID to be translated to tags carried by packets, but might not specify the NSF. This flexibility in the simple Service Layer enables a security controller to handle issues like multi-tenancy and the choice between available NSFs for a given policy.
o I2NSF will not specify abstract or sophisticated policies from clients. Expressing policies in ways other than the model used by the Capability Layer is out of scope.
o The translation mechanism/methods from Service Layer policies to Capability layer commands are out of scope for I2NSF.
However, I2NSF will provide a discussion forum for Informational drafts on data models, APIs, etc. that demonstrate how more complex Service Layer policies and formats may be translated to Capability Layer functions. Such documents would be pursued outside the WG.

Standard interfaces for monitoring and controlling the behavior of NSFs are essential building blocks for providers of security service to automate the use of different NSFs from multiple vendors. This work will leverage the existing protocols and data models defined by the I2RS, NETCONF, and NETMOD working groups. If extensions to these protocols or data models are needed, requirements will be developed by this WG, and the extensions will be developed in cooperation with the working groups responsible for the protocols.

The I2NSF working group's deliverables include:

o A single document covering use cases, problem statement, and gap analysis document. This document will initially be produced for reference as a living list to track and record discussions: the working group may decide to not publish this document as an RFC.
o A framework document, presenting an overview of the use of NSFs and the purpose of the models developed by the working group. This document will also be a reference text to guide the main work and the working group may decide to not publish this document as an RFC.
o If the working group considers it necessary, a single, unified, Information Model to describe the control and monitoring of flow-based NSFs.
o YANG data models for the control and monitoring of NSFs.
o A vendor-neutral vocabulary  to enable the characteristics and behavior of NSFs to be specified without requiring the NSFs themselves to be standardized, so that "security controller" or "manager" have a common base to choose the appropriate NSFs (by different vendors) that can fulfill the requests requested by clients.
o An examination of existing secure communication mechanisms to identify the appropriate ones for carrying the controlling and monitoring information between the NSFs and their management entities. This document may also be produced as a working document that is not published as an RFC.

The working group may additionally choose to develop documents to describe requirements for extensions (if any) to existing protocols used by the working group, to explain how the data models are used to monitor and control flow-based NSFs, and to describe how to use I2RS and NETCONF to carry the content of the data models. These documents may be published as Informational RFCs or may be working documents that are discarded once they have triggered the necessary work.

The working group will work closely with the I2RS, NETCONF, and NETMOD WGs. The working group will communicate with external SDOs like ETSI NFV and will encourage open source code development related to the working group scope in organizations like ONF, OpenStack, ODL, and OPNFV.

The working group must have the above deliverables completed within 24 months. The responsible AD will close the working group at that time if they are not completed or close to completion. The working group may be closed earlier if substantial progress is not being made.

Milestones

Date Milestone Associated documents
Feb 2019 Working group re-charter or close
Feb 2019 Adopt IANA registry consideration as WG document
Dec 2018 Data Models and Applicability Statements to IESG for publication
Dec 2016 Adopt examination of existing secure communication mechanisms as WG document

Done milestones

Date Milestone Associated documents
Done All early drafts to IESG for publication (if WG decided to proceed): use cases, problem statement, and gap analysis document; framework document; information model requirements for extensions to protocols document; examination of existing secure communication mechanisms document
Done Adopt applicability statements as WG Document
Done Adopt data models as WG document
Done Adopt info model as WG document (if desired)
Done WG decides whether to progress adopted drafts for publication as RFCs (use cases, framework, information model, and examination of existing secure communication mechanisms)
Done Adopt requirements for extensions to protocols as WG document
Done Adopt framework as WG document
Done Adopt use Cases, problem statement, and gap analysis as WG document