Interface to Network Security Functions
charter-ietf-i2nsf-01

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.