One document matched: draft-hares-i2nsf-use-case-gap-analysis-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC791 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2748.xml">
<!ENTITY RFC2940 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2940.xml">
<!ENTITY RFC3084 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3084.xml">
<!ENTITY RFC3303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3303.xml">
<!ENTITY RFC3304 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3304.xml">
<!ENTITY RFC3483 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3483.xml">
<!ENTITY RFC3484 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml">
<!ENTITY RFC4080 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4080.xml">
<!ENTITY RFC4242 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4242.xml">
<!ENTITY RFC4261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4261.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC5189 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5189.xml">
<!ENTITY RFC5277 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5277.xml">
<!ENTITY RFC5539 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5539.xml">
<!ENTITY RFC5973 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5973.xml">
<!ENTITY RFC6022 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6022.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6242 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6242.xml">
<!ENTITY RFC6243 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6243.xml">
<!ENTITY RFC6436 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6436.xml">
<!ENTITY RFC6470 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6470.xml">
<!ENTITY RFC6536 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6536.xml">
<!ENTITY RFC6639 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6639.xml">
<!ENTITY RFC6887 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6887.xml">
<!ENTITY RFC7223 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7223.xml">
<!ENTITY RFC7225 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7225.xml">
<!ENTITY RFC7277 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7277.xml">
<!ENTITY RFC7317 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7317.xml">
<!ENTITY I-D.ietf-netmod-syslog-model SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netmod-syslog-model-03.xml">
<!ENTITY I-D.ietf-netmod-acl-model SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netmod-acl-model-02.xml">
<!ENTITY I-D.ietf-netmod-routing-cfg SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netmod-routing-cfg-19.xml">
<!ENTITY I-D.ietf-netconf-restconf SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netconf-restconf-04.xml">
<!ENTITY I-D.ietf-netconf-call-home SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netconf-call-home-06.xml">
<!ENTITY I-D.ietf-netconf-restconf-collection SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netconf-restconf-collection-00.xml">
<!ENTITY I-D.ietf-netconf-zerotouch SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netconf-zerotouch-02.xml">
<!ENTITY I-D.ietf-isis-yang-isis-cfg SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-isis-yang-isis-cfg-02.xml">
<!ENTITY I-D.ietf-ospf-yang SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ospf-yang-00.xml">
<!ENTITY I-D.shaikh-idr-bgp-model SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-shaikh-idr-bgp-model-01.xml">
<!ENTITY I-D.shaikh-rtgwg-policy-model SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-shaikh-rtgwg-policy-model-01.xml">
<!ENTITY I-D.zhdankin-idr-bgp-cfg SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zhdankin-idr-bgp-cfg.xml">
<!ENTITY I-D.tsingh-bess-pbb-evpn-yang-cfg SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-tsingh-bess-pbb-evpn-yang-cfg-00.xml">
<!ENTITY I-D.zhuang-bess-evpn-yang SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-zhuang-bess-evpn-yang-00.xml">
<!ENTITY I-D.zhuang-bess-l3vpn-yang SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-zhuang-bess-l3vpn-yang-00.xml">
<!ENTITY I-D.liu-bess-mvpn-yang SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-liu-bess-mvpn-yang-00.xml">
<!ENTITY I-D.l3vpn-service-yang SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-l3vpn-service-yang-00.xml">
<!ENTITY I-D.ietf-grow-bgp-gshut SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-grow-bgp-gshut-05.xml">
<!ENTITY I-D.white-grow-overlapping-routes SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-white-grow-overlapping-routes-01.xml">
<!ENTITY I-D.ietf-i2rs-problem-statement
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-problem-statement.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-i2rs-architecture-09.xml">
<!ENTITY I-D.ietf-i2rs-usecase-reqs-summary SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-i2rs-usecase-reqs-summary-01.xml">
<!ENTITY I-D.ietf-i2rs-rib-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-data-model.xml">
<!ENTITY I-D.ietf-i2rs-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-info-model.xml">
<!ENTITY I-D.ietf-i2rs-yang-network-topo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-yang-network-topo.xml">
<!ENTITY I-D.zhang-i2rs-l1-topo-yang-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zhang-i2rs-l1-topo-yang-model.xml">
<!ENTITY I-D.ietf-i2rs-yang-l2-network-topology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-yang-l2-network-topology.xml">
<!ENTITY I-D.kini-i2rs-fb-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kini-i2rs-fb-rib-info-model.xml">
<!ENTITY I-D.ietf-i2rs-ephemeral-state SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-ephemeral-state.xml">
<!ENTITY I-D.hares-i2rs-auth-trans SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-auth-trans.xml">
<!ENTITY I-D.dunbar-i2rs-discover-traffic-rules SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.dunbar-i2rs-discover-traffic-rules.xml">
<!ENTITY I-D.hares-i2rs-bnp-eca-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-bnp-eca-data-model.xml">
<!ENTITY I-D.hares-i2rs-info-model-service-topo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-info-model-service-topo.xml">
<!ENTITY I-D.ietf-i2rs-traceability SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-traceability.xml">
<!ENTITY I-D.ietf-i2rs-pub-sub-requirements
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-pub-sub-requirements.xml">
<!ENTITY I-D.mcpherson-irr-routing-policy-considerations SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-mcpherson-irr-routing-policy-considerations-01.xml">
<!ENTITY I-D.ietf-grow-bgp-gshut SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-grow-bgp-gshut-05.xml">
<!ENTITY I-D.ietf-pcp-authentication SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pcp-authentication-09.xml">
<!ENTITY I-D.ietf-pcp-optimize-keepalives SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pcp-optimize-keepalives-06.xml">
<!ENTITY I-D.ietf-pcp-proxy SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pcp-proxy-08.xml">
<!ENTITY I-D.ietf-pcp-sdn-firewall SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sdn-firewall-00.xml">
<!ENTITY I-D.ietf-sacm-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sacm-architecture-03.xml">
<!ENTITY I-D.ietf-sacm-terminology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sacm-terminology-06.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-hares-i2nsf-use-case-gap-analysis-00.txt" ipr="trust200902">
<front>
<title abbrev="I2NSF Existing Work Analysis">Analysis of Use Cases and Gaps in Technology for I2NSF</title>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Huawei</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<email>shares@ndzh.com</email>
</address>
</author>
<author fullname="Antonio Pastor" initials="A" surname="Pastor">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Don Ramon de la Cruz, 82</street>
<city>Madrid</city>
<code>28006</code>
<country>Spain</country>
</postal>
<email> antonio.pastorperales@telefonica.com</email>
</address>
</author>
<author fullname="Ke Wang" initials="K" surname="Wang">
<organization>China Mobile</organization>
<address>
<postal>
<street> 32 Xuanwumenxi Ave,Xicheng District </street>
<city>Beijing</city>
<region></region>
<code>100053</code>
<country>China</country>
</postal>
<email>wangkeyj@chinamobile.com</email>
</address>
</author>
<author fullname="Dacheng Zhang " initials="D" surname="Zhang">
<organization></organization>
<address>
<postal>
<street> </street>
<city>Beijing</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<email>dacheng.zdc@aliabab-inc.com</email>
</address>
</author>
<author fullname="Myo Zarny" initials="M" surname="Zarny">
<organization>Goldman Sachs</organization>
<address>
<postal>
<street>30 Hudson Street</street>
<city>Jersey City</city>
<region>NJ</region>
<code>07302</code>
<country>USA</country>
</postal>
<email>myo.zarny@gs.com</email>
</address>
</author>
<date year="2015" />
<area>Security Area</area>
<workgroup>I2NSF BOF</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>I2NSF</keyword>
<abstract>
<t> This document provides a summary of the I2NSF use cases
plus a summary of the stat of the art in industries and IETF work
which is relevant to the Interface to Network Security Function (I2NSF).
The I2NSF focus is to define data models and interfaces in order to control and monitor the physical
and virtual aspects of network security functions.
The use cases are organized in two basic scenarios. In the access network
scenario, mobile and residential users access NSF capabilities using
their network service provider infrastructure. In the data center
scenario customers manage NSFs hosted in the data center
infrastructure.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Enterprise, residential, and mobile customers are becoming more and
more aware of the need for network security,
just to find that security services are hard to operate and become
expensive in the case of reasonably sophisticated ones. This general
trend has caused numerous operators and security vendors to start to
leverage on cloud-based models to deliver security solutions. In
particular, the methods around Network Function Virtualization (NFV)
are meant to facilitate the elastic deployment of software images
providing the network services, and require the management of various
resources by customers, who may not own or physically host those
network functions.
</t>
<t>
There are numerous benefits by defining such interfaces. Operators
could provide more flexible and customized security services for
specific users and this would provide more efficient and secure
protection to each user.
</t>
<t>
This document provides an analysis of the use cases, gaps analysis
of existing technology, recommendations for requirements for I2NSF,
and security considerations.
</t>
<t>
<figure>
<artwork>
Customer + Access + PoP/Datacenter
| | +--------+
| ,-----+--. |Network |
| ,' | `-|Operator|
+-------------+ | /+----+ | |Mgmt Sys|
| Residential |-+------/-+vCPE+----+ +--------+
+-------------+ | / +----+ | \ | :
| / | \ | |
+-------+ | ; +----+ | +----+ |
| Cloud |---+---+----+ vPE+--+----+ NSF| |
+-------+ | : +----+ | +----+ |
| : | / |
+--------+ | : +----+ | / ;
| Mobile |-+-----\--+vEPC+----+ /
+--------+ | \ +----+ | ,-'
| `--. | _.-'
| `----+----''
+ +
Figure 1: NSF and actors
</artwork>
</figure>
</t>
<section title="What is I2NSF">
<t>
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.
</t>
</section>
<section title="I2NSF Standarization">
<t>
The Interface to NSF devices (I2NSF) work proposes to standardize a set of
software interfaces and data modules to control and monitor the physical and virtual NSFs.
Since different security vendors support different features and functions, the I2NSF
will focus on the flow-based NSFs that provide treatment to packets or flows such
found in IPS/IDS devices, web filtering devices, flow filtering devices, deep packet
inspection devices, pattern matching inspection devices, and re-mediation devices.
</t>
<t>
There are two layers of interfaces envisioned in the I2NSF approach:
<list style="symbols">
<t> The I2NSF Capability Layer specifies how to control and monitor NSFs at a functional
implementation level. This the focus for this phase of the I2NSF Work. </t>
<t>The I2NSF Service Layer defines how the security policies of clients may be expressed
and monitored. </t>
</list>
</t>
<t>
For the I2NSF capability layer, the I2NSF work proposes an interoperable protocol
that passes NSF provisioning rules and orchestration information
between I2NSF client on a network manager and I2NSF agent on an NSF device.
It is envisioned that clients of the I2NSF interfaces include
management applications, service orchestration systems, network
controllers, or user applications that may solicit network security
resources.
</t>
<t>The I2NSF work to define this protocol includes the following work:
<list style="symbols">
<t> defining an informational model that defines
the concepts for standardizing the control and monitoring of NSFs,
</t>
<t> defining a set of Yang data models from the information model
that identifies the data that must be passed, </t>
<t> creating a capability registry (an IANA registry) that identifies
the characteristics and behaviours of NSFs in vendor-neutral
vocabulary without requiring the NSFs to be standardized.
</t>
<t> examining existing secure communication mechanisms to
identify the appropriate ones for carrying the data that
provisions and monitors information between the NSFs and their
management entity (or entities).
</t>
</list>
</t>
</section>
<section title="Structure of the document">
<t>This document reviews the terminology (section 3), analyzes the use cases
(section 4) and gaps in current technology (section 5), recommends certain requirements
for I2NSF protocol(section 6), and discusses security consideration (section 8). </t>
</section>
</section>
<section title="Requirements Language">
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].</t>
<t> In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
</t>
</section>
<section title="Terminology">
<t>
<list style="symbols">
<t> Network Security Function (NSF): A functional block within a network
infrastructure to ensure integrity, confidentiality and availability
of network communications, to detect unwanted activity, and to deter
and block this unwanted activity or at least mitigate its effects on
the network</t>
<t>vNSF: Virtual Network Security Function: A network security function
that runs as a software image on a virtualized infrastructure, and
can be requested by one domain but may be owned or managed by another
domain.</t>
<t>type of NSFs: NSFs considered in this draft include virtualized and non-virtualized
NSFs.</t>
<t>Cloud DC: A data center that is not on premises of enterprises, but
has compute/storage resources that can be requested or purchased by the enterprises.
The enterprise is actually getting a virtual data center. The
Cloud Security Alliance (CSA) (http://cloudsecurityalliance.org)
focus on adding security to this environment. A specific research topic
is security as a service within the cloud data center. </t>
<t> Cloud-based security functions: Network Security Function (NSF) hosted and managed by
service providers or different administrative entity.</t>
<t> DC: Data Center
</t>
<t> Domain: The term Domain in this draft has the following different connotations
in different scenarios:
<list style="symbols">
<t> Client--Provider relationship, i.e. client requesting some
network security functions from its provider; </t>
<t> Domain A - Domain B relationship, i.e. one operator domain
requesting some network security functions from another operator domain; or
</t>
<t> Applications -- Network relationship, i.e. an application (e.g.
cluster of servers) requesting some functions from network, etc.
</t>
</list>
The domain context is important because it indicates the interactions
the security is focused on.
</t>
<t> I2NSF agent - a piece of software in a device that
implements a network security function which
receives provisioning information and requests for
operational data (monitoring data) across the I2NSF protocol
from an I2NSF client.
</t>
<t>I2NSF client - A security client software that utilizes the
I2NSF protocol to read, write or change the provisioning
network security device via software interface
using the I2NSF protocol (denoted as I2RS Agent)
</t>
<t>I2NSF Management System - I2NSF client operates
within an network management system which serves as a collections and
distribution point for security provisioning and filter data.
This management system is denoted as I2NS management system in this
document.
</t>
<t>Virtual Security Function: a security function that can be
requested by one domain but may be owned or managed by another
domain. </t>
</list>
</t>
</section>
<section title="Use Cases">
<t> This section discusses general use cases, access use cases, and
cloud use cases.
</t>
<section title="General Use Cases">
<t>
User request security services through specific clients (a customer
app, the NSP BSS/OSS or management platform...) and the appropriate
NSP network entity will invoke the (v)NSFs according to the user
service request. We will call this network entity the security
controller. The interaction between the entities discussed above
(client, security controller, NSF) is shown in the following diagram:
</t>
<t>
<figure>
<artwork>
+----------+
+-------+ | | +-------+
| | Interface 1 |Security | Interface 2 | NSF(s)|
|Client <-------------> <------------------> |
| | |Controller| | |
+-------+ | | +-------+
+----------+
Figure 2: Interaction between Entities
</artwork>
</figure>
</t>
<t>Interface 1 is used for receiving security requirements from client
and translating them into commands that NSFs can understand and
execute. Moreover, it is also responsible for giving feedback of the
NSF security statistics to client. Interface 2 is used for
interacting with NSFs according to commands, and collect status
information about NSFs.
</t>
<section title="Instantiation and Configuration of NSFs">
<t>
Client sends collected security requirements through Interface 1 to
the security controller in the NSP network, which then translates
them into a a set of security functions. Then the corresponding NSFs
are instantiated and configured through Interface 2.
</t>
<t>
As an example, consider an enterprise user A who wants to prevent a
certain kind of traffic from flowing to their network. Such a
requirement is sent from client to security controller through
Interface 1. The security controller translates the requirement into
a firewall function plus a rules for filtering out TCP and/or UDP
data packets. Then it instantiates a firewall NSF through Interface
2. The corresponding filter rules are also configured onto this
firewall NSF through Interface 2.
</t>
</section>
<section title="Updating of NSFs">
<t>
A user can direct the client to require the update of security
service functions, including adding/deleting a security service
function and updating configurations of former security service
function.
</t>
<t>
As an example, consider a user who has instantiated a security
service before and decides to enable an additional IDS service. This
requirement will be sent to the security controller through Interface
1 and be translated, so the security controller instantiates and
configures an IDS NSF through Interface 2.
</t>
</section>
<section title="Collecting the Status of NSFs">
<t>
When users want to get the executing status of security service, they
can request the status statistics information of NSFs from the
client. The security controller will collect NSF status statistics
information through Interface 2, consolidate them, and give feedback
to client through Interface 1. This interface can be used to collect
not only individual service information, but also aggregated data
suitable for tasks like infrastructure security assessment.
</t>
</section>
<section title="Validation of NSFs">
<t>
Customers may require to validate NSF availability, provenance, and
its correct execution. This validation process, especially relevant
for vNSFs, includes at least
<list>
<t>Integrity of the NSF. Ensure that the NSF is not manipulated.
</t>
<t>Isolation. The execution of the NSF is self-contained for privacy
requirements in multi-tenancy scenarios.
</t>
</list>
</t>
<t> In order to achieve this the security controller has to collect
security measurements and share them with an independent and trusted
third party, allowing the user to attest the NSF by using Interface 1
and the information of the trusted third party.
</t>
</section>
</section>
<section title="Access Networks">
<t>
This scenario describes use cases for users (enterprise user, network
administrator, residential user...) that request and manage security
services hosted in the network service provider (NSP) infrastructure.
Given that NSP customers are essentially users of their access
networks, the scenario is essentially associated with their
characteristics, as well as with the use of vNSFs.
</t>
<t>
The Virtual CPE described in [NFVUC] use cases #5 and #7 cover the
model of virtualization for mobile and residential access, where the
operator may offload security services from the customer local
environment (or even the terminal) to the operator infrastructure
supporting the access network.
</t>
<t>
These use cases defines the operator interaction with vNSFs through
automated interfaces, typically by B2B communications performed by
the operator management systems (OSS/BSS).
</t>
<section title="vNSF Deployment">
<t>
The deployment process consists of instantiating a NSF on a
Virtualization Infrastructure (NFVI), within the NSP administrative
domain(s) or with other external domain(s). This is a required step
before a customer can subscribe to a security service supported in
the vNSF.
</t>
</section>
<section title="vNSF Customer Provisioning">
<t>
Once a vNSF is deployed, any customer can subscribe to it. The
provisioning lifecycle includes:
<list>
<t>Customer enrollment and cancellation of the subscription to a
vNSF.
</t>
<t>Configuration of the vNSF, based on specific configurations, or
derived from common security policies defined by the NSP.</t>
<t>Retrieve and list of the vNSF functionalities, extracted from a
manifest or a descriptor. The NSP management systems can demand
this information to offer detailed information through the
commercial channels to the customer.
</t>
</list>
</t>
</section>
</section>
<section title="Cloud Datacenter Scenario">
<t>
In a datacenter, network security mechanisms such as firewalls may
need to be added or removed dynamically for a number of reasons. It
may be explicitly requested by the user, or triggered by a pre-
agreed-upon service level agreement (SLA) between the user and the
provider of the service. For example, the service provider may be
required to add more firewall capacity within a set timeframe
whenever the bandwidth utilization hits a certain threshold for a
specified period. This capacity expansion could result in adding new
instances of firewalls. Likewise, a service provider may need to
provision a new firewall instance in a completely new environment due
to a new requirement.
</t>
<t>
The on-demand, dynamic nature of deployment essentially requires that
the network security "devices" be in software or virtual form
factors, rather than in a physical appliance form. (This is a
provider-side concern. Users of the firewall service are agnostic,
as they should, as to whether or not the firewall service is run on a
VM or any other form factor. Indeed, they may not even be aware that
their traffic traverses firewalls.)
</t>
<t>
Furthermore, new firewall instances need to be placed in the "right
zone" (domain). The issue applies not only to multi-tenant
environments where getting the tenant right is of paramount
importance but also to environments owned and operated by a single
organization with its own service segregation policies. For example,
an enterprise may mandate that firewalls serving Internet traffic and
business-to-business (B2B) traffic be separate; or that IPS/IDS
services for investment banking and non-banking traffic be separate
for regulatory reasons.
</t>
<section title="On-Demand Virtual Firewall Deployment">
<t> A service provider operated cloud data center could serve tens of
thousands of clients. Clients' compute servers are typically hosted
on virtual machines (VMs), which could be deployed across different
server racks located in different parts of the data center. It is
often not technically and/or financially feasible to deploy dedicated
physical firewalls to suit each client's myriad security policy
requirements. What is needed is the ability to dynamically deploy
virtual firewalls for each client's set of servers based on
established security policies and underlying network topologies.
</t>
<t>
<figure>
<artwork>
---+-----------------------------+-----
| |
+---+ +-+-+
|vFW| |vFW|
+---+ +-+-+
| Client #1 | Client #2
---+-------+--- ---+-------+---
+-+-+ +-+-+ +-+-+ +-+-+
|vM | |vM | |vM | |vM |
+---+ +---+ +---+ +---+
Figure 3: NSF in DataCenter
</artwork>
</figure>
</t>
</section>
<section title="Firewall Policy Deployment Automation">
<t> Firewall configuration today is a highly complex process that
involves consulting established security policies, translating those
policies into firewall rules, further translating those rules into
vendor-specific configuration sets, identifying all the firewalls,
and pushing configurations to those firewalls.
</t>
<t>
This is often a time consuming, complex and error-prone process even
within a single organization/enterprise framework. It becomes far
more complex in provider-owned cloud networks that serve myriad
customers.
</t>
<t>
Automation can help address many of these issues. Automation works
best when it can leverage a common set of standards that will work
across multiple entities.
</t>
<section title=" Client-Specific Security Policy in Cloud VPNs">
<t>
Clients of service provider operated cloud data centers need not only
secure virtual private networks (VPNs) but also virtual security
functions that enforce the clients' security policies. The security
policies may govern communications within the clients' own virtual
networks and those with external networks. For example, VPN service
providers may need to provide firewall and other security services to
their VPN clients. Today, it is generally not possible for clients
to dynamically view, much less change, what, where and how security
policies are implemented on their provider-operated clouds. Indeed,
no standards-based framework that allows clients to retrieve/manage
security policies in a consistent manner across different providers
exists.
</t>
</section>
</section>
</section>
<section title="Considerations on Policy and Configuration">
<t>
NSF configurations can vary from simple rules (i.e. block a DDoS
attack) to very complex configuration ( i.e. define a user firewall
rules per application, protocol, source and destination port and
address). The possibility of using configuration templates per
control and management type is a common option as well.
</t>
<t>
A NSP can push security policies using complex configurations in
their managed vNSF through its management system. The open Control
and management interface has to accommodate this application-driven
behavior.
</t>
<t>
Computer-savvy customers may pursue a similar application-driven
configuration through the open Control and management interface, but
standard residential and mobile customers may prefer to use the
definition of security policies in the form of close-to-natural-
language sentences with high-level directives or a guide
configuration process. The representation for these policies will be
of the form:
</t>
<t>
<figure>
<artwork>
+-------+ +------+ +------+ +------------------+
|Subject| + |Action| + |Object| + |Field_type = Value|
+-------+ +------+ +------+ +------------------+
Figure 4: High-Level Security Policy Format
</artwork>
</figure>
</t>
<t>Subject indicates the customer or device in the access.
</t>
<t>
Action can include a variety of intent-based actions: check,
redirect, allow, block, record, inspect..
</t>
<t>
Object can be optional and specifies the nature of the action. The
default is all the customer traffic, but others possible values are
connections and connections attempts.
</t>
<t>
Field_type allows to create fine-grained policies, including
destinations list (i.e. IPs, domains), content types (i.e. files,
emails), windows of time (i.e. weekend), protocol or network service
(i.e. HTTP).
</t>
<t>
An example of a customer policy is:
<list>
<t>"My son is allowed to access Facebook from 18:30 to 20:00"</t>
</list>
</t>
<section title="Translating Policies into NSF Capabilities">
<t> Policies expressed in the above model are suitable for what we
depicted as Interface 1 in Figure 2. In order to allow the security
controller to deal with the different NSFs an intermediate
representation used for expressing specific configurations in a
device-independent format is required. For this purpose, the
definition of a set of security capabilities provides a means for
categorizing the actions performed by network security functions. An
initial, high-level set of such capabilities consists of:
<list style="symbols">
<t> Identity Management: Includes all services related with identity,
authentication and key management. Some examples are:
<list style="symbols">
<t>AAA (Authentication, Authorization, Accounting) services</t>
<t> Remote identity management</t>
<t> Remote identity management</t>
</list>
</t>
<t>Traffic Inspection: A common use case for customers accessing the
Internet or additional services through it is security
supervision. Control and Management interfaces will allow the
configuration of the vNSF inspection features: signatures updates,
behavioral parameters or type of traffic to supervise. Some
examples are:
<list style="symbols">
<t>IDS/IPS (Intrusion Detection System/Intrusion Prevention System,
</t>
<t>Deep packet inspection,
</t>
<t> Data leakage protection,
</t>
</list>
</t>
<t>Traffic Manipulation: A more intrusive use case of NSF includes
the capacity of manipulate the client traffic. Control and
Management interfaces will allow the configuration of the NSF
manipulation features, such as redirect and block rules. Some
examples are:
<list style="symbols">
<t>Redirect traffic, as in the case of captive portals,</t>
<t> Block traffic: Firewalls, intrusion prevention system, DDOS/
Anti-DOS (Distributed Denial-of-Service/Anti-Denial-of-Service), </t>
<t>Encrypt traffic: VPN services that encapsulate and encrypt the
user traffic. A SSL VPN is a representative example.</t>
</list>
</t>
<t>Impersonation:Some NSFs can impersonate a customer service or
Internet service to provide security functions. Control and
Management interfaces will allow the configuration of the service
to impersonate and his behavioral. Some examples are:
<list style="symbols">
<t>Honeypots, impersonating customer services, such as HTTP,
NetBios or SSH, </t>
<t>Anonymization services, hiding the source identity, as in the
case of TOR. </t>
</list>
</t>
</list>
Service Chain will allow for more than one of the aforementioned
functions to engage in a specific order to a particular flow
</t>
</section>
</section>
</section>
<section title="Gap Analysis">
<section title="Structure of the gap analysis">
<t> This document provides a analysis of the gaps in the state of art in the following
industry forums:
<list>
<t>IETF working groups (section 5.2)</t>
<t>ETSI Network Functions Virtualization Industry Specification Group (ETSI NFV ISG),
(section 5.3) </t>
<t> OPNFV Open Source Group (section 5.4)</t>
<t>Open Stack - Firewall as a service (OpenStack Firewall FaaS) (section 5.5)
(http://docs.openstack.org/admin-guide-cloud/content/install_neutron-fwaas-agent.html)</t>
<t>Cloud Security Alliance Security (CSA)as a Service (section 5.6)
(https://cloudsecurityalliance.org/research/secaas/#_overview)</t>
<t>In-Depth Review of Some IETF Protocols (section 5.7)</t>
</list>
</t>
</section>
<section title="IETF Gap analysis">
<t>The IETF gap analysis first examines the IETF mechanisms which
have been developed to secure the IP traffic flows through a network.
Traffic filters have been defined by IETF specifications at the
access points, the middle-boxes, or the routing systems.
Protocols have been defined to carry provisioning and filtering
traffic between a management system and an IP system (router or host
system). Current security work (SACM working group (WG), MILE WG, and DOTS WG)
is providing correlation of events monitored with
the policy set by filters. This section provides
a review the filter work, protocols, and security correlation
for monitors. </t>
<section title="Traffic Filters">
<section title="Overview">
<t>The earliest filters defined by IETF were access filters which
controlled the acceptance of IP packet data flows. Additional
policy filters were created as part of the following protocols:
<list style="symbols">
<t> COPS protocol <xref target="RFC2748"></xref> for controlling
access to networks, </t>
<t> Next steps in Signalling (NSIS) work
(architecture: <xref target="RFC4080"></xref>
protocol: <xref target="RFC5973"></xref>), and
</t>
<t> the Port Control Protocol (PCP) to enables
IPv4 to IPv6 flexible address and port mapping for
NATs and Firewalls, </t>
</list>
Today NETMOD and I2RS Working groups are
specifying additional filters in Yang modules to
be used as part of the NETCONF or I2RS enhancement
of NETCONF/RESTCONF.
</t>
<t>
The routing filtering is outside the scope of the
flow filtering, but flow filtering may be impacted
by route filtering. An initial model for the routing policy is in
<xref target="I-D.shaikh-rtgwg-policy-model"></xref>
</t>
<t>This section provides an overview of the
flow filtering as an introduction to the I2NSF GAP analysis.
Additional detail on NETCONF, NETMOD, I2RS, PCP, and
NSIS is available in the Detailed I2NSF analysis.
</t>
<section title="Data Flow Filters in NETMOD and I2RS">
<t>The current work on expanding
these filters is focused oncombining a configuration and monitoring protocol with
Yang data models. <xref target="I-D.ietf-netmod-acl-model"></xref> provides
a set of access lists filters which can permit or deny traffic
flow based on headers at the MAC, IP layer, and Transport layer.
The configuration and monitoring protocols which can pass the
filters are: NETCONF protocol <xref target="RFC6241"></xref>,
RESTCONF <xref target="I-D.ietf-netconf-restconf"></xref>, and
the I2RS protocol. The NETCONF and RESTCONF protocols install
these filters into forwarding tables. The I2RS protocol uses
the ACLs as part of the filters installed in an ephemeral
protocol-independent filter-based RIB
<xref target="I-D.kini-i2rs-fb-rib-info-model"></xref>
which controls the flow of traffic on interfaces specifically
controlled by the I2RS filter-based FIB.
</t>
<t>
<figure>
<artwork>
netconf
+---------------+ / \ +---------------+
| Device: ACLs |-- / \---|Device: ACLS |
| I2RS FB RIB | | I2RS FB RIB |
|routing policy | | routing policy|
| | | |
===|===============|=============|===============|=
+---------------+ data flow +---------------+
Figure 5 -I2RS Filter-Based RIB
</artwork>
</figure>
</t>
<t> The I2RS protocol is a programmatic interface to the
routing system. At this time, the I2RS is targeted to be extensions
to the NETCONF/RESTCONF protocols to allow the NETCONF/RESTCONF
protocol to support a highly programmatic interface with
high bandwidth of data, highly reliable notifications, and
ephemeral state (see <xref target="I-D.ietf-i2rs-architecture"></xref>).
Please see the background section on I2RS for additional
details on the requirements for this extension to the NETCONF/RESTCONF protocol
suite.
</t>
<t> The vocabulary set in <xref target="I-D.ietf-netmod-acl-model"></xref>
is limited, so additional protocol independent filters were written for
the I2RS Filter-Based RIBs in <xref target="I-D.hares-i2rs-bnp-eca-data-model"></xref>,
and protocol specific filters for SFC
<xref target="I-D.dunbar-i2rs-discover-traffic-rules"></xref>.
</t>
<t> One thing important to note is that
NETCONF and RESTCONF manage device layer yang models. However,
as figure 6 shows, there are multiple device level,
network-wide level, and application level yang modules.
The access lists defined by the device level forwarding
table may be impacted by the routing protocols,
the I2RS ephemeral protocol independent Filter-Based FIB,
or some network-wide security issue (IPS/IDS).
</t>
<t>
<figure>
<artwork>
+--------------------------------------------+
|Application Network Wide: Intent |
+--------------------------------------------+
|Network-wide level: L3SM L3VPN service model|
+--------------------------------------------+
|Device level: Protocol Independent: I2RS |
| RIB, Topology, Filter-Based RIB |
+--------------------------------------------+
|Device Level:Protocol Yang modules |
| (ISIS, OSPF, BGP, EVPN, L2VPN, L3VPN, etc.)
+--------------------------------------------+
| Device level: IP and System: NETMOD Models |
| (config and oper-state), tunnels, |
| forwarding filters |
+--------------------------------------------+
Figure 6 levels of Yang modules
</artwork>
</figure>
</t>
</section>
<section title="I2NSF Gap analysis ">
<t>
The gap is that none of the current work on these filters considers all the
variations of data necessary to do IPS/IDS, web-filters, stateful flow-based filtering,
security-based deep packet inspection, or pattern matching with re-mediation.
The I2RS Filter-Based RIB work is the closest associated work, but the
focus has not been on IDS/IPS, web-filters, security-based deep packet inspection,
or pattern matching with re-mediation. </t>
<t> The I2RS Working group (I2RS WG) is focused on the routing system so
security expertise for these IDP/IPS, Web-filter, security-based deep-packet inspection
has not been targeted for this WG.
</t>
<t>Another gap is there is no capability registry (an IANA registry)
that identifies the characteristics and behaviours of NSFs in vendor-neutral
vocabulary without requiring the NSFs to be standardized.
</t>
<t> What I2NSF can use from NETCONF/RESTCONF and I2RS </t>
<t>I2NSF should consider using NETCONF/RESTCONF protocol and the I2RS
proposed enhancement to the NETCONF/RESTCONF protocol.
</t>
</section>
</section>
<section title="Middle-box Filters">
<section title="Midcom">
<t> Midcom Summary:
MIDCOM developed the protocols for applications to communicate with
middle boxes. However, MIDCOM have not used by the industry for a
long time. This is because there was a lot of IPR encumbered technology and
IPR was likely a bigger problem for IETF than it is today. MIDCOM is
not specific to SIP. It was very much oriented to NAT/FW devices. SIP
was just one application that needed the functionality. MIDCOM is
reservation-oriented and there was an expectation that the primary
deployment environment would be VoIP and real-time conferencing,
including SIP, H.323, and other reservation-oriented protocols. There
was an assumption that there would be some authoritative service that
would have a view into endpoint sessions and be able to authorize (or
not) resource allocation requests. In other word, there's a trust
model there that may not be applicable to endpoint-driven requests
without some sort of trusted authorization mechanisms/tools.
Therefore, there is a specific information model applied to security
devices, and security device requests, that was developed in the
context of an SNMP MIB. There is also a two-stage reservation model,
which was specified in order to allow better resource management.
</t>
<t> Why I2NSF is different than Midcom
</t>
<t> MIDCOM is different than I2NSF because its SNMP scheme doesn't work
with the virtual network security functions (vNSF) management. </t>
<t> MidCom RFCs:</t>
<t>
<list>
<t> <xref target="RFC3303"></xref> - Midcom architecture </t>
<t> <xref target="RFC5189"></xref> - Midcom Protocol Semantics</t>
<t> <xref target="RFC3304"></xref> - Midcom protocol requirements </t>
</list>
</t>
</section>
</section>
<section title="Security Work" >
<section title="Overview">
<t>Today's NSFs in security devices can handle flow-based security
by providing treatment to packets/flows, such as IPS/IDS, Web filtering,
flow filtering, deep packet inspection, or pattern matching and re-mediation.
These flow-based security devices are managed and provisioned by
network management systems.
</t>
<t>
No standardized set of interoperable interfaces
control and manage the NSFs so that a central management system
can be used across security devices from multiple Vendors.
I2NSF work plan is to standardize a set of interfaces by which control
and management of NSFs may be invoked, operated, and monitored by:
<list>
<t>creating an information model that defines concepts required for standardizing the
control and monitoring of NSFs, and from the information model
create data models. (The information model will be used to get
early agreement on key technical points.)
</t>
<t>creating a capability registry (at IANA) that enables the characteristics and behavior
of NSFs to be specified using a vendor-neutral vocabulary without requiring the
NSFs themselves to be standardized.
</t>
<t>define the requirements for an I2NSF protocol to pass this traffic.
(Hopefully re-using existing protocols.)</t>
</list>
</t>
<t>The flow-filtering configuration and management must fit into
the existing security area's work plan. This section considers how the
I2NSF fits into the security area work under way in the SACM (security automation
and control), DOTS (DDoS Open Threat Signalling), and MILE (Management Incident
Lightweight Exchange).
</t>
</section>
<section title="Security Work and Filters">
<t>In the proposed I2NSF work plan, the I2NSF
security network management system
controls many NSF nodes via the I2NSF Agent.
This control of data flows is similar to the
COPS example in section 5.7.4.
</t>
<t>
<figure>
<artwork>
+------------+
| I2NSF |
| Client |
| |
| security |
| NMS system |
+------------+
+-----+ / \ +-----+
|I2NSF|--/ \---|I2NSF|
|Agent| |Agent|
| | | |
| NSF | | NSF |
--| ----|------------|-----|-----
+-----+ data flow +-----+
Figure 7
</artwork>
</figure>
</t>
<t> The other security protocols work to interact within the
network to provide additional information in the following way:
<list style="symbols">
<t> SACM <xref target="I-D.ietf-sacm-architecture"></xref>
describes an architecture which tries to determine if the
end-point security policies and the reality (denoted as security posture)
align. <xref target="I-D.ietf-sacm-terminology"></xref>
defines posture as the configuration and/or status of hardware
or software on an endpoint as it pertains to an organization's
security policy. Filters can be considered on the
configuration or status pieces that needs to be monitored.
</t>
<t>DOTS (DDoS Open Threat Signalling) - is working on
coordinating the mitigation of DDoS attacks. A part of
DDoS attach mitigation is to provide lists of
addresses to be filtered via IP header filters.
</t>
<t>
MILE (Managed Incident LIghtweight Exchange) - is working on
creating a standardized format for incident and indicator
reports, and creating a protocol to transport this information.
The incident information MILE collects may cause
changes in data-flow filters on one or more NSFs.
</t>
</list>
</t>
</section>
<section title="I2NSF interaction">
<t>The network management system that the
I2NSF client resides on may interact with
other clients or agents developed
for the work ongoing in the SACM,
DOTS, and MILES working groups.
This section describes how the addition
of I2NSF's ability to control and monitor
NSF devices is compatible and
synergistic with these existing
efforts.
</t>
<t>
<figure>
<artwork>
+----------+ +------+
+--------+ | security |====| DOTS |
|SACNM | | NMS | |client|---+
|consumer| |..........|\ +------+ |
+--------+==|SACM *1 | \ |
+----|repository| \ |
| |..........| +-------+ |
| | I2NSF | |MILES | |
+------|-+ | client | |client | |
|SACM | +----------+ +-----:-+ |
|Info. | / \ : |
|provider| / \ : |
+--------+ / \ : |
+-----+ / \ +-----+ : |
|I2NSF|--/ \---|I2NSF| : |
| | | | : |
| | |MILES|.: |
| | |Agent| |
| | |DOTS | |
| | |Agent|-------+
--| ----|----------------|-----|-----
+-----+ data flow +-----+
*1 - this is the SACM Controller (CR) with
its broker/proxy/repository show as
described in the SACM architecture.
Figure 8
</artwork>
</figure>
</t>
<t> Figure 8 provides a diagram of
a system the I2NSF, SACM,
DOTS and MILES client-agent or
consumer-broker-provider are deployed
together. The following are possible
positive interactions these
scenario might have:
<list style="symbols">
<t>An security network
management system (NMS) can contain
a SACM repository and be connected
to SACM information provider
and a SACM consumer.
The I2NSF may provide one of the ways
to change the forwarding filters.
</t>
<t>The security NMS may also be connected
to DOTS DDoS clients managing the information
and configuring the rules. The I2NSF
may provide one of the ways to change
forwarding filters. </t>
<t>The MILES client on a security network management system
talking to the MILES agent on the node may react
to the incidents by using I2NSF to set filters.
DOTS creates black-lists, but does not
have a complete set of filters.
</t>
</list>
</t>
</section>
<section title="Benefits from the Interaction">
<t>
I2NSF's ability to provide a common interoperable and vendor
neutral interface may allow the security NMS to use a
single change to change filters. SACM provides
an information model to describe end-points, but
does not link this directly to filters. </t>
<t>
DOTS creates black-lists based on source and destination
IP address, transport port number, protocol ID, and traffic rate.
Like NETMOD's, ACLS are not sufficient for all filters or
control desired by the NSF boxes.
</t>
<t>The incident data captured by MILES will not
have enough filter information to provide
NSF devices with general services.
The I2NSF will be able to handle the MILE
incident data and create alerts or reports
for other security systems.
</t>
</section>
</section>
</section>
</section>
<section title="ETSI NFV">
<section title="ETSI Overview">
<t> Network Function Virtualization (NFV) provides the service providers
with flexibility, cost effective and agility to offer their services
to customers. One such service is the network security function which
guards the exterior of a service provider or its customers.
</t>
<t> The flexibility and agility of NFV encourages service providers
to provide different products to address business trends in their
market to provide better service offerings to their end user.
A traditional product such as the network security function (NSF)
may be broken into multiple virtual devices each hosted from another
vendor. In the past, network security devices may have been single
sourced from a small set of vendors - but in the NFV version of NSF devices,
this reduced set of sources will not provide a competitive edge.
Due to this market shift, the network security device vendors are
realizing that the proprietary provisioning protocols and formats
of data may be a liability. Out of the NFV work has arisen
a desire for a single interoperable network security device
provisioning and control protocol.
</t>
<t>The I2NSF will be deployed along networks using other security
and NFV technology. As section 3 described, the NFV NSF
security is deployed along side other security functions
(AAA, SACM, DOTS, and MILE devices) or deep-packet-inspection.
The ETSI Network Functions Virtualization: NFV security: Security and Trust
guidance document (ETSI NFV SEC 003 1.1.1 (2014-12)) indicates that
multiple administrative domains will deployed in carrier networks.
One example of these multiple domains is hosting of multiple
tenant domains (telecom service providers) on a single
infrastructure domain (infrastructure service) as figure 9 shows.
The ETSI Inter inter-VNFM document (aka Ve-Vnfn) between the
element management system and the Virtual network function
is the equivalent of the interface between the
I2NSF client on a management system and the I2NSF agent
on the network security feature VNF.
</t>
<t>
<figure>
<artwork>
....................
+--: OSS/BSS :
| ....................
|
| +-------------------------+
| | |
| | ........ ........ |
| | : EMS1 : : EMS : | ETSI inter-VNFM
| | ....||... ...||... | (Ve-Vnfn)
| | || || ==========I2NSF interface
| | ....||... ...||... |
| | : VNF1 : : VNF1 : | Tenant domain
| | ....||... ...||... |
''''''''||'''''''''||''''''''''
| | ....||..... ...||...... | infrastructure
| | :virtual : :virtual : | domain
| | :computing: :computing: | with virtual
| | ........... ........... | network
| | +=====================+ ---------
| | | virtualization layer| |
| | +=====================+ |
| | ........... .......... .......... |
|====:computing: :storage : :network : |
| :hardware : :hardware: :hardware: |
| ........... .......... .......... |
| hardware resources |
+-----------------------------------+
Figure 9
</artwork>
</figure>
</t>
<t>
The ETSI proof of concept work has worked on the following
security proof of concepts:</t>
<t>
<list style="symbols">
<t>#16 - NFVIaas with Secure, SDN controlled WAN Gateway,</t>
</list>
</t>
</section>
<section title="I2NSF Gap Analysis">
<t>
The I2NSF will be deployed on top of virtual computing
linked together by virtual routers configured by
NETCONF/RESTCONF or I2RS which provision and monitoring the
L1, L2, l3 and service pathways
through the network.
</t>
<t>In the NFV-related productions, the current architecture does not
have a protocol to maintain an interoperability provisioning from
I2NSF client to I2NSF agent. The result is that service providers
have to manage the interoperability using private protocols. In
response to this problem, the device manufacturers and the service
providers have begun to discuss an I2NSF protocol for interoperable
passing of provisioning and filter in formation.
</t>
<t> Open source work (such as OPNFV) provides a common code base
for providers to start their NFV work from. However, this code
base faces the same problem. There is no defacto standard protocol.
</t>
</section>
</section>
<section title="OPNFV">
<t>The OPNFV (www.opnfv.org) is a carrier-grade integrated,
open source platform focused on accelerating the introduction of
new Network Function Virtualization (NFV) products and service.
The OPNFV Moon project is focused on adding the security interface for a network
management system within the Tenant NFVs and the infrastructure
NFVs (as shown in figure 4). This section provides an
overview of the OPNFV Moon project and a gap analysis between
I2NSF and the OPNFV Moon Project.</t>
<section title="OPNFV Moon Project">
<t> The OPNFV moon project (https://wiki.opnfv.org) is a security management
system. NFV uses cloud computing technologies to virtualize
the resources and automate the control. The Moon project is working on a
security manager for the Cloud computing infrastructure (https://wiki.opnfv.org/moon).
The Moon project proposes to provision a set of different cloud resources/services
for VNFs (Virtualized Network Functions) while managing the isolation of VNS,
protection of VNFs, and monitoring of VNS. Moon is creating a security management
system for OPNFV with security managers to protect different layers of the
NFV infrastructure. The Moon project is choosing various security project
mechanisms “a la cart” to enforcement related security managers.
A security management system integrates mechanisms of different security aspects.
This project will first propose a security manager that specifies users’ security requirements.
It will also enforce the security managers through various mechanisms
like authorization for access control, firewall for networking,
isolation for storage, logging for tractability, etc.
</t>
<t>The Moon security manager operates a VNF security manager
at the ETSI VeVnfm level where the I2NSF protocol is targeted
as figure 10 shows. Figure 10 also shows how the
OPNFV VNF Security project mixes the I2NSF level with the
device level.
</t>
<t> The Moon project lists the following gaps in OpenStack:
<list style="symbols">
<t>No centralized control for compute, storage, and networking.
Open Stack uses Nova for computing and Swift for software.
Each system has a configuration file and its own security policy.
This lacks the synchronization mechanism to build a complete
secure configuration for OPNF. </t>
<t>No dynamic control so that if a user obtains the token,
the is no way to obtain control over the user. </t>
<t>No customization or flexibility to allow integration into
different vendors, </t>
<t>No fine grain authorization at user level. Authorization is
only at the API</t>
</list> </t>
<t>
Moon addresses these issues adding authorization, logging, IDS, enforcement of
network policy, and storage protection. Moon is based on OpenStack Keystone.
</t>
<t>Deliverable time frame: 2S 2015</t>
<t>
<figure>
<artwork>
....................
+--: OSS/BSS :
| ....................
|
| +-------------------------+
| | |
| | ........ ........ |
| | : EMS1 : : EMS : | ETSI inter-VNFM
| | ....||... ...||... | (Ve-Vnfn)
| | || || ==========I2NSF interface
| | ....||... ...||... | Moon VNF === Moon VNF
| | : : : : | Security Security MGR
| | : VNF1 : : VNF1 : |
| | ....||... ...||... | Tenant domain
''''''''||'''''''''||''''''''''
| | ....||..... ...||...... | infrastructure
| | :virtual : :virtual : | domain
| | :computing: :computing: | with virtual
| | ........... ........... | network
| | +=====================+ |--------
| | | virtualization layer| |
| | +=====================+
| | =============Moon VNF ===Moon VI
| | security project Security MGR
| | ........... .......... .......... |
|====:computing: :storage : :network : |
| :hardware : :hardware: :hardware: |
| ........... .......... .......... |
| hardware resources |
+-----------------------------------+
Figure 10
</artwork>
</figure>
</t>
</section>
<section title="Gap Analysis for OPNFV Moon Project">
<t>OpenStack congress does not provide vendor independent systems. </t>
</section>
</section>
<section title="OpenStack Security Firewall">
<t>OpenStack has advanced features of: a) API for managing security groups
(http://docs.openstack.org/admin-guide-cloud/content/section_securitygroups.html)
and b) firewalls as a service
(http://docs.openstack.org/admin-guide-cloud/content/fwaas_api_abstractions.html).
</t>
<t>
This section provides an overview of this
open stack work, and a gap analysis of how I2NSF provides additional functions</t>
<section title="Overview of API for Security Group">
<t>The security group with the security group rules provides ingress
and egress traffic filters based on port. The default group drops
all ingress traffic and allows all egress traffic. The groups
with additional filters are added to change this behaviour.
To utilize the security groups, the networking plug-in for
Open Stack must implement the security group API. The following
plug-ins in OpenSTsack currently implement this security:
ML2, Open vSwitch, Linux Bridge, NEC, and VMware NSX.
In addition, the correct firewall driver must be added to
make this functional.
</t>
</section>
<section title="Overview of Firewalls as a Service">
<t>Firewall as a service is an early release of an
API that allows early adopters to test network implementations.
It contains APIs with parameters for firewall rules, firewall policies,
and firewall identifiers. The firewall rules include the following
information:
<list style="symbols">
<t> identification of rule (id, name, description)</t>
<t> identification tenant rule associated with, </t>
<t> links to installed firewall policy, </t>
<t> IP protocol (tcp, udp, icmp, none) </t>
<t> source and destination IP address</t>
<t> source and destination port </t>
<t>action: allow or deny traffic</t>
<t>status: position and enable/disabled </t>
</list>
</t>
<t>The firewall policies include the following information:
<list style="symbols">
<t>identification of the policy (id, name, description),</t>
<t>identification of tenant associated with, </t>
<t>ordered list of firewall rules, </t>
<t> indication if policy can be seen by tenants other
than owner, and </t>
<t>indication if firewall rules have been audited.</t>
</list>
</t>
<t>The firewall table provides the following information:
<list style="symbols">
<t>identification of firewall (id, name, description),</t>
<t>tenant associated with this firewall, </t>
<t>administrative state (up/down),</t>
<t>status (active, down, pending create, pending
delete, pending update, pending error)</t>
<t>firewall policy ID this firewall is associated with</t>
</list>
</t>
</section>
<section title="I2NSF Gap analysis">
<t>
The OpenStack work is preliminary (security groups and firewall
as a service). This work does not allow any of the
existing network security vendors provide a management interface.
Security devices take time to be tested for functionality and
their detection of security issues. The OpenStack work provides
an interesting simple set of filters, and may in the future
provide some virtual filter service. However, at this time
this open source work does not address the single management
interfaces for a variety of security devices.
</t>
<t>I2NSF is proposing rules that will include Event-Condition-matches (ECA)
with the following matches
<list>
<t> packet based matches on L2, L3, and L4 headers and/or
specific addresses within these headers,</t>
<t>context based matches on schedule state and schedule,
[Editor: Need more details here.]
</t>
</list>
</t>
<t>The I2NSF is proposing action for these ECA policies of:
<list>
<t>basic actions of deny, permit, and mirror,</t>
<t>advanced actions of: IPS signature filtering and
URL filtering.</t>
</list>
</t>
</section>
</section>
<section title="CSA Secure Cloud ">
<section title="CSA Overview">
<t>The Cloud Security Alliance (CSA)(www.cloudsecurityaliance.org) defined
security as a service (SaaS) in their Security as a Service working group (SaaS WG)
during 2010-2012. The CSA SaaS group defined ten categories of
network security
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_V1_0.pdf)
and provides implementation guidance for each
of these ten categories This section provides an overview
of the CSA SaaS working groups documentation and a
Gap analysis for I2NSF</t>
<section title="CSA Security as a Service(SaaS)">
<t>
The CSA SaaS working group defined the following ten
categories, and provided implementation guidance on these categories:
<list style="numbers">
<t>Identity Access Management (IAM)
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_1_IAM_Implementation_Guidance.pdf)
</t>
<t>Data Loss Prevention (DLP)
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_2_DLP_Implementation_Guidance.pdf)
</t>
<t>Web Security (web)
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_3_Web_Security_Implementation_Guidance.pdf),
</t>
<t>Email Security (email)
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_4_Email_Security_Implementation_Guidance.pdf),
</t>
<t>Security Assessments
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_5_Security_Assessments_Implementation_Guidance.pdf),
</t>
<t>Intrusion Management
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_6_Intrusion_Management_Implementation_Guidance.pdf),
</t>
<t>Security information and Event Management
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_7_SIEM_Implementation_Guidance.pdf),
</t>
<t> Encryption
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf),
</t>
<t>Business Continuity and Disaster Recovery (BCDR)
https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_9_BCDR_Implementation_Guidance.pdf), and
</t>
<t>Network Security
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_10_Network_Security_Implementation_Guidance.pdf).
</t>
</list>
</t>
<t>
The sections below give an overview these implementation guidances
</t>
</section>
<section title="Identity Access Management (IAM)">
<t>document:
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_1_IAM_Implementation_Guidance.pdf)
</t>
<t>
The identity management systems include the following services:
<list style="symbols">
<t> Centralized Directory Services, </t>
<t> Access Management Services, </t>
<t> Identity Management Services, </t>
<t> Identity Federation Services, </t>
<t> Role-Based Access Control Services, </t>
<t> User Access Certification Services, </t>
<t> Privileged User and Access Management, </t>
<t> Separation of Duties Services, and </t>
<t> Identity and Access Reporting Services.
</t>
</list>
</t>
<t>
The IAM device communications with the security
management system that controls the filtering
of data. The CSA SaaS IAM specification states
that interoperability between IAM devices
and secure access network management systems
is a a problem. This 2012 implementation
report confirms there is a gap with I2NSF
<figure>
<artwork>
+------------+ +--------+
| IAM device | ---- SLA ------------| secure |
| | Access review | access |
| | security events | NMS |
| | access tracing | |
+---||-------+ Audit report +---||---+
|| ||
|| +------------------+ ||
========== |Filter enforcement|=====||
+------------------+
Figure 11
</artwork>
</figure>
</t>
</section>
<section title="Data Loss Prevention (DLP)">
<t>Document:
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_2_DLP_Implementation_Guidance.pdf)
</t>
<t>
The data loss prevention (DLP)services must address:
<list style="symbols">
<t>origination verification,</t>
<t>integrity of data,</t>
<t>confidentiality and access control,</t>
<t>accountability, </t>
<t>avoiding false positives on detection, and
</t>
<t> privacy concerns. </t>
</list>
</t>
<t>
The CSA SaaS DLP device communications require that it
have the enforcement capabilities to do the following:
<list>
<t> alert and log data loss,</t>
<t>delete data on system or passing through, </t>
<t>filter out (block/quarantine) data,</t>
<t>reroute data, </t>
<t> encrypt data</t>
</list>
</t>
<t>
<figure>
<artwork>
+------------+ +--------+
| DLP device | ---- SLA ------------| secure |
| | Alert and log | access |
| | delete data | NMS |
| | filter/reroute | |
+---||-------+ encrypt data +---||---+
|| ||
|| +------------------+ ||
========== |Filter enforcement|=====||
+------------------+
Figure 12
</artwork>
</figure>
</t>
</section>
<section title="Web security(Web))">
<t>Document:
https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_3_Web_Security_Implementation_Guidance.pdf
</t>
<t>
The web security services must address:
<list style="symbols">
<t> Web 2.0/Social Media controls, </t>
<t> Malware and Anti-Virus controls, </t>
<t>Data Loss Prevention controls (over Web-based services like Gmail or Box.net), </t>
<t> XSS, JavaScript and other web specific attack controls </t>
<t> Web URL Filtering, </t>
<t> Policy control and administrative management, </t>
<t> Bandwidth management and quality of service (QoS) capability, and </t>
<t> Monitoring of SSL enabled traffic. </t>
</list>
</t>
<t>
The CSA SaaS Web services device communications require that it
have the enforcement capabilities to do the following:
<list>
<t> alert and log malware or anti-virus data patterns,</t>
<t>delete data (malware and virus) passing through systems, </t>
<t>filter out (block/quarantine) data,</t>
<t>filter Web URLs, </t>
<t>interact with policy and network management systems,</t>
<t>control bandwidth and QoS of traffic, and </t>
<t>monitor encrypted (SSL enabled) traffic, </t>
</list>
</t>
<t>
All of these features either require the I2NSF
standardized I2NSF client to I2NSF agent to provide
multi-vendor interoperability.
<figure>
<artwork>
+------------+ +--------+
|Web security| ---- SLA ------------| secure |
| | Alert and log | access |
| | delete data | NMS |
| | filter/reroute data | |
| | ensure bandwdith/QOS | |
| | monitor encrypted | |
| | data | |
+---||-------+ encrypt data +---||---+
|| ||
|| +------------------+ ||
========== |Filter enforcement|=====||
+------------------+
Figure 13
</artwork>
</figure>
</t>
</section>
<section title="Email Security (email))">
<t>Document:
https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_4_Email_Security_Implementation_Guidance.pdf
</t>
<t>
The CSA Document recommends that email security services must address:
<list style="symbols">
<t>Common electronic mail components, </t>
<t> Electronic mail architecture protection, </t>
<t> Common electronic mail threats, </t>
<t> Peer authentication, </t>
<t> Electronic mail message standards, </t>
<t> Electronic mail encryption and digital signature, </t>
<t> Electronic mail content inspection and filtering, </t>
<t> Securing mail clients, and </t>
<t> Electronic mail data protection and availability assurance techniques</t>
</list>
</t>
<t>
The CSA SaaS Email security services requires that it
have the enforcement capabilities to do the following:
<list>
<t> provide the malware and spam detection and removal, </t>
<t> alert and provide rapid response to email threats, </t>
<t> identify email users and secure remote access to email, </t>
<t>do on-demand provisioning of email services, </t>
<t>filter out (block/quarantine) email data,</t>
<t> know where the email traffic or data is residing
(to to regulatory issues), and </t>
<t>be able to monitor encrypted email, </t>
<t>be able to encrypt email, </t>
<t>be able to retain email records (while
abiding with privacy concerns), and </t>
<t>interact with policy and network management systems.</t>
</list>
</t>
<t>
All of these features require the I2NSF
standardized I2NSF client to I2NSF agent to provide
multi-vendor interoperability.
<figure>
<artwork>
+------------+ +--------+
| Email | ---- SLA ------------| secure |
| security | alert/log malware | access |
| | alert/log email spam | NMS |
| | filter/reroute data | |
| | ensure bandwidth/QOS | |
| | monitor encrypted | |
| | data | |
+---||-------+ encrypt data +---||---+
|| ||
|| +------------------+ ||
========== |Filter enforcement|=====||
+------------------+
Figure 14
</artwork>
</figure>
</t>
</section>
<section title="Security Assessment">
<t>Document:
https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_5_Security_Assessments_Implementation_Guidance.pdf
</t>
<t>
The CSA SaaS Security assessment indicates that assessments need to be done on
the following devices:
<list style="symbols">
<t>hypervisor infrastructure, </t>
<t> network security compliance systems, </t>
<t> Servers and workstations, </t>
<t> applications, </t>
<t> network vulnerabilities systems, </t>
<t> internal auditor and intrusion detection/prevention systems (IDS/IPS), and </t>
<t> web application systems. </t>
</list>
</t>
<t>
All of these features require the I2NSF working group
standardize the way to pass these assessments to and from
the I2NSF client on the I2NSF management system and the I2NSF
Agent.
</t>
</section>
<section title="Intrusion Detection">
<t>Document:
https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_6_Intrusion_Management_Implementation_Guidance.pdf)
</t>
<t>
The CSA SaaS Intrusion detection management includes intrusion detection through:
devices:
<list style="symbols">
<t> Network traffic inspection, behavioural analysis, and flow analysis,
</t>
<t> Operating System, Virtualization Layer, and Host Process Events monitoring,
</t>
<t> monitoring of Application Layer Events, and </t>
<t> Correlation Techniques, and other Distributed and Cloud-Based Capabilities
</t>
</list>
</t>
<t>
Intrusion response includes both:
<list style="symbols">
<t> Automatic, Manual, or Hybrid Mechanisms,
</t>
<t> Technical, Operational, and Process Mechanisms.
</t>
</list>
</t>
<t>
The CSA SaaS recommends the intrusion security management systems include
provisioning and monitoring of all of these types of intrusion detection
(IDS) or intrusion protection devices. The management of these systems
requires also requires:
<list>
<t> Central reporting of events and alerts,</t>
<t>administrator notification of intrusions, </t>
<t> Mapping of alerts to Cloud-Layer Tenancy, </t>
<t> Cloud sourcing information to prevent false
positives in detection, and </t>
<t> allowing for redirection of traffic to
allow remote storage or transmission to
prevent local evasion.</t>
</list>
</t>
<t>
All of these features require the I2NSF
standardized I2NSF client to I2NSF agent to provide
multi-vendor interoperability.
<figure>
<artwork>
+------------+ +--------+
| IDS/IPS | ---- Info ----------| secure |
| security | alert/log intrusion | access |
| | notify administrator | NMS |
| | Map alerts to Tenant | |
| |filter/reroute traffic| |
| | remote data storage | |
+---||-------+ +---||---+
|| ||
|| +------------------+ ||
========== |Filter enforcement|=====||
+------------------+
Figure 15
</artwork>
</figure>
</t>
</section>
<section title="Security Information and Event Management(SEIM)">
<t>Document:
https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_7_SIEM_Implementation_Guidance.pdf)
</t>
<t>
The Security Information and Event Management (SEIM) receives data from a wide
range of security systems such as Identity management systems (IAM),
data loss prevention (DLP), web security (Web), email security (email),
intrusion detection/prevision (IDS/IPS)), encryption, disaster recovery,
and network security. The SEIM combines this data into a single streams.
All the requirements for data to/from these systems are replicated
in these systems needs to give a report to the SIEM system.
</t>
<t>
A SIEM system would be prime candidate to have a
I2NSF client that gathers data from an I2NSF Agent associated
with these various types of security systems. The CSA SaaS SIEM
functionality document suggests that one concern is to
have standards that allow timely recording and sharing of data.
I2NSF can provide this.
</t>
</section>
<section title="Encryption">
<t>Document:
https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf
</t>
<t>
The CSA SaaS Encryption implementation guidance document considers how one
implements and manages the following security systems:
<list>
<t> key management systems (KMS), control of keys, and key life cycle;</t>
<t> Shared Secret encryption (Symmetric ciphers), </t>
<t> No-Secret or Public Key Encryption (asymmetric ciphers), </t>
<t> hashing algorithms, </t>
<t> Digital Signature Algorithms, </t>
<t> Key Establishment Schemes, </t>
<t> Protection of Cryptographic Key Material (FIPS 140-2; 140-3), </t>
<t>Interoperability of Encryption Systems, Key Conferencing, Key Escrow Systems, and
others </t>
<t> application of Encryption for Data at rest, data in transit, and data in use; </t>
<t> PKI (including certificate revocation “CRL”); </t>
<t> Future application of such technologies as Homomorphic encryption, Quantum Cryptography, Identitybased
Encryption, and others; </t>
<t> Crypto-system Integrity (How bad implementations can under mind a crypto-system), and </t>
<t> Cryptographic Security Standards and Guidelines </t>
</list>
</t>
<t>
The wide variety of encryption services require the security management
systems be able to provision, monitor, and control the systems that
are being used to encrypt data. This document indicates in the implementation
sections that the standardization of interfaces to/from management systems are key
to good key management systems, encryption systems, and crypto-systems.
</t>
</section>
<section title="Business Continuity and Disaster Recovery (BC/DR)">
<t>Document:
https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_9_BCDR_Implementation_Guidance.pdf
</t>
<t>
The CSA SaaS Business Continuity and Disaster Recovery (BC/DR) implementation
guidance document considers the systems that implement the
the contingency plans and measures designed and
implemented to ensure operational resiliency in the event of any service interruptions. BC/DR
systems includes:
<list>
<t> Business Continuity and Disaster Recovery BC/DR as a service, including categories such as complete
Disaster Recovery as a Service (DRaaS), and subsets such as file recovery, backup and archive, </t>
<t> Storage as a Service including object, volume, or block storage; </t>
<t> old Site, Warm Site, Hot Site backup plans; </t>
<t> IaaS (Infrastructure as a Service), PaaS (Platform as a Service), and SaaS (Software as a Service); </t>
<t> Insurance (and insurance reporting programs)</t>
<t> Business Partner Agents (business associate agreements); </t>
<t> System Replication (for high availability); </t>
<t> Fail-back to Live Systems mechanisms and management; </t>
<t> Recovery Time Objective (RTO) and Recovery Point Objective (RPO); </t>
<t> Encryption (data at rest [DAR], data in motion [DIM], field level); </t>
<t> Realm-based Access Control; </t>
<t> Service-level Agreements (SLA); and
</t>
<t>ISO/IEC 24762:2008, BS25999, ISO 27031, and FINRA Rule 4370
</t>
</list>
</t>
<t>
These BC/DR systems must handle data backup and recovery,
server backup/recovery, and data center (virtual/physical)
backup and recovery. Recovery as a service (RaaS) means that the BC/DR
services are being handled by management systems outside the enterprise.
</t>
<t>
The wide variety of BC/DR requires the security management
systems to be able to communicate provisioning, monitor, and control those systems that
are being used to back-up and restore data. An interoperable protocol that
allows provision and control of data center's data, servers, and data center management devices
devices is extremely important to this application. Recovery as a Service (SaaS)
indicates that these services need to be able to be remotely management.
</t>
<t>
The CSA SaaS BC/BR documents indicate how important a standardized
I2NSF protocol is.
</t>
</section>
<section title="Network Security Devices">
<t>Document:
https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_10_Network_Security_Implementation_Guidance.pdf
</t>
<t>
The CSA SaaS Network Security implementation recommendation includes advice on:
<list>
<t> How to segment networks, </t>
<t> Network security controls, </t>
<t> Controlling ingress and egress controls such as Firewalls (Stateful), Content Inspection and Control (Network-based),
Intrusion Detection System/Intrusion Prevention Systems (IDS/IPS), and Web Application Firewalls, </t>
<t> Secure routing and time, </t>
<t> Denial of Service (DoS) and Distributed Denial of Service (DDoS) Protection/Mitigation, </t>
<t> Virtual Private Network (VPN) with Multiprotocol Label Switching (MPLS) Connectivity (over SSL),
Internet Protocol Security (IPsec) VPNs, Virtual Private LAN Service (VPLS), and Ethernet Virtual
Private Line (EVPL), </t>
<t> Threat Management, </t>
<t> Forensic Support, and </t>
<t> Privileged User/Use Monitoring. </t>
</list>
</t>
<t>
These network security systems require provisioning, monitoring, and the ability for the
security management system to subscribe to receive logs, snapshots of capture data, and
time synchronization. This document states the following:
<list>
<t> "It is critical to understand what monitoring APIs are available from the CSP, and if they match risk and
compliance requirements",
</t>
<t>"Network security auditors are challenged by the need to track a server and its
identity from creation to deletion. Audit tracking is challenging in even the most mature cloud environments, but
the challenges are greatly complicated by cloud server sprawl, the situation where the number of cloud servers
being created is growing more quickly than a cloud environments ability to manage them." </t>
<t> A valid threat vector for cloud is the API access. Since a majority of CSPs today support public API interfaces
available within their networks and likely over the Internet."
</t>
</list>
The CSA SaaS network security indicates that the I2NSF must be secure so that the I2NSF Client-Agent protocol
does not become a valid threat vector. In additions, the need for the management protocol like I2NSF is critical
in the sprawl of Cloud environment.
</t>
</section>
</section>
<section title="I2NSF Gap Analysis">
<t> The CSA Security as a Service (SaaS) document show clearly
that there is a gap between the ability of the CSA SaaS devices
to have a vendor neutral, inoperable protocol that
allow the multiple of network security devices to communicate
passing provisioning and informational data. Each of the
10 implementation agreements points to this as a shortage.
The I2NSF yang models and protocol is needed according to the
CSA SaaS documents. </t>
</section>
</section>
<section title="In-depth Review of IETF protocols">
<section title="NETCONF and RESTCONF">
<t>
The IETF NETCONF working group has developed the basics
of the NETCONF protocol focusing on secure configuration and
querying operational state. The NETCONF protocol <xref target="RFC6241"></xref> may be
run over TLS <xref target="RFC6639"></xref> or SSH (<xref target="RFC6242"></xref>.
NETCONF can be expanded to defaults <xref target="RFC6243"></xref>,
handling events (<xref target="RFC5277"></xref> and basic notification
<xref target="RFC6470"></xref>, and filtering writes/reads based on
network access control models (NACM, <xref target="RFC6536"></xref>).
The NETCONF configuration must be committed to a configuration data store
(denoted as config=TRUE). Yang models identify nodes within a configuration data store
or an operational data store using a XPath expression (document root ---to --- target source).
NETCONF uses an RPC model and provides protocol for handling configs (get-config, edit-config, copy-config, delete-config, lock, unlock, get) and sessions (close-session, kill-session).
The NETCONF Working Group has developed RESTCONF, which is an
HTTP-based protocol that provides a programmatic interface for
accessing data defined in YANG, using the datastores defined in NETCONF.
</t>
<t>
RESTCONF supports “two edit condition detections” – time stamp and entity tag.
RESTCONF uses a URI encoded path expressions. RESTCONF provides operations to
get remote servers options (OPTIONS), retrieve data headers (HEAD), get data (GET),
create resource/invoke operation (POST), patch data (PATCH),
delete resource (DELETE), or query.
</t>
<t> RFCs for NETCONF </t>
<t>
<list style="symbols">
<t> <xref target="RFC6242">NETCONF </xref> </t>
<t> <xref target="RFC6022">NETCONF monitoring </xref> </t>
<t> <xref target="RFC6242">NETCONF over SSH </xref></t>
<t> <xref target="RFC5539">NETCONF over TLS </xref></t>
<t> <xref target="RFC6470">NETCONF system notification></xref></t>
<t> <xref target="RFC6536">NETCONF access-control (NACM)</xref></t>
<t> <xref target="I-D.ietf-netconf-restconf">RESTCONF </xref></t>
<t> <xref target="I-D.ietf-netconf-call-home">NETCONF-RESTCONF call home </xref></t>
<t> <xref target="I-D.ietf-netconf-restconf-collection">RESTCONF collection protocol </xref></t>
<t> <xref target="I-D.ietf-netconf-zerotouch">NETCONF Zero Touch Provisioning </xref></t>
</list>
</t>
</section>
<section title="I2RS Protocol">
<t>
Based on input from the NETCONF working group, the
I2RS working group decided to re-use the NETCONF or RESTCONF protocols
and specify additions to these protocols rather than create yet another protocol (YAP).
</t>
<t>
The required extensions for the I2RS protocol are in the following drafts:
<list style="symbols">
<t><xref target="I-D.ietf-i2rs-ephemeral-state">Ephemeral state</xref>,
</t>
<t><xref target="I-D.ietf-i2rs-pub-sub-requirements">Publication-Subscription notifications</xref>,
</t>
<t><xref target="I-D.ietf-i2rs-traceability">Traceability</xref>,
</t>
<t><xref target="I-D.hares-i2rs-auth-trans">Security requirements</xref></t>
</list>
</t>
<t>
At this time, NETCONF and RESTCONF cannot handle the ephemeral data store proposed by I2RS,
the publication and subscription requirements, the traceability, or the security
requirements for the transport protocol and message integrity.
</t>
</section>
<section title="NETMOD Yang modules">
<t>NETMOD developed initial Yang models for interfaces <xref target="RFC7223"></xref>),
IP address (<xref target="RFC7277"></xref>),
IPv6 Router advertisement (<xref target="RFC7277"></xref>),
IP Systems (<xref target="RFC7317"></xref>) with system ID,
system time management, DNS resolver, Radius client, SSH,
syslog (<xref target="I-D.ietf-netmod-syslog-model"></xref>),
ACLS (<xref target="I-D.ietf-netmod-acl-model"></xref>),
and core routing blocks (<xref target="I-D.ietf-netmod-routing-cfg"></xref>
The routing working group (rtgwg) has begun to examine policy for routing and tunnels.
</t>
<t>
Protocol specific Working groups have developed yang models for
ISIS (<xref target="I-D.ietf-isis-yang-isis-cfg"></xref>),
OSPF (<xref target="I-D.ietf-ospf-yang"></xref>), and
BGP ( merge of <xref target="I-D.shaikh-idr-bgp-model"></xref> and
<xref target="I-D.zhdankin-idr-bgp-cfg"></xref> with the bgp policy
proposed multiple Working groups (idr and rtgwg)). BGP Services yang models
have been proposed for PPB EVPN (<xref target="I-D.tsingh-bess-pbb-evpn-yang-cfg"></xref>),
EVPN (<xref target="I-D.zhuang-bess-evpn-yang"></xref>),
L3VPN (<xref target="I-D.zhuang-bess-l3vpn-yang"></xref>),
and multicast MPLS/BGP IP VPNs (<xref target="I-D.liu-bess-mvpn-yang"></xref>).
</t>
</section>
<section title="COPS">
<t>One early focus on flow filtering based on policy
enforcement of traffic entering a
network is the 1990s COPS <xref target="RFC2748"></xref>
design (PEP and PDP) as shown in figure 16.
The Policy decision point kept network-wide policy (E.g. ACLs) and sent it to
Policy enforcements who then would control what data flows between the two
These decision points controlled data flow from PEP to PEP.
<xref target="RFC3084"></xref> describes COPS use for policy provisioning.
</t>
<t>
<figure>
<artwork>
PDP
+-----+ / \ +-----+
|PEP1 |--/ \---|PEP2 |
| | ACL/policy | |
| | | |
--| ----|------------|-----|-----
+-----+ data flow +-----+
Figure 16
</artwork>
</figure>
</t>
<t>COPS had a design of Policy Enforcement Points (PEP), and policy Decision Points (PDP)
as shown in figure 16. These decision points controlled flow from PEP to PEP.
</t>
<t> Why COPS is no longer used </t>
<t> Security in the network in 2015 uses specific devices
(IDS/IPS, NAT firewall, etc) with specific policies and profiles
for each types of device. No common protocol or
policy format exists between the
policy manager (PDP) and security enforcement points. </t>
<t> COPs RFCs: <xref target="RFC4261"></xref>, <xref target="RFC2940"></xref>,
<xref target="RFC3084">,</xref>, <xref target="RFC3483">,</xref>
</t>
<t> Why I2NSF is different COPS </t>
<t> COPS was a protocol for policy related to Quality of Service (QoS)
and signalling protocols (e.g. RSVP) (security, flow, and others).
I2NSF creates a common protocol between security policy decision points (SPDP)
and security enforcement points (SEP). Today's security devices currently only use
proprietary protocols. Manufacturers would like a security specific policy enforcement
protocol rather than a generic policy protocol.
</t>
</section>
<section title="PCP">
<t>
As indicated by the name, the Port Control Protocol (PCP) enables an
IPv4 or IPv6 host to flexibly manage the IP address and port mapping
information on Network Address Translators (NATs) or firewalls, to
facilitate communication with remote hosts. </t>
<t> PCP RFCs:
<list>
<t><xref target="RFC6887"></xref>
</t>
<t> <xref target="RFC7225"></xref>
</t>
<t><xref target="I-D.ietf-pcp-authentication"></xref>
</t>
<t><xref target="I-D.ietf-pcp-optimize-keepalives"></xref>
</t>
<t> <xref target="I-D.ietf-pcp-proxy"></xref>
</t>
</list>
</t>
<t> Why is I2NSF different from PCP: </t>
<t> Here are some aspects that I2NSF is different from PCP:
<list style="symbols">
<t> PCP only supports the management of port and address information
rather than any other security functions
</t>
<t> Cover the proxy, firewall and NAT box proposals in I2NSF </t>
</list></t>
</section>
<section title="NSIS - Next steps in Signalling">
<t> NSIS is for standardizing an IP signalling protocol (RSVP) along data
path for end points to request its unique QoS characteristics, unique
FW policies or NAT needs (RFC5973) that are different from the FW/NAT
original setting. The requests are communicated directly to the
FW/NAT devices. NSIS is like east-west protocols that require all
involved devices to fully comply to make it work. </t>
<t> NSIS is path-coupled, it is possible to message every participating
device along a path without having to know its location, or its
location relative to other devices (this is particularly a pressing
issue when you've got one or more NATs present in the network, or
when trying to locate appropriate tunnel endpoints).
</t>
<t>A diagram should be added here showing I2NSF and NSIS
</t>
<t> Why I2NSF is different than NSIS:
<list style="symbols">
<t> The I2NSF requests from clients do not go directly to network
security devices, but instead to controller or orchestrator that can
translate the application/user oriented policies to the involved devices
in the interface that they support. </t>
<t> The I2NSF request does not require all network functions in a path to comply,
but it is a protocol between the I2NSF client and the I2NSF Agent in the controller
and orchestrator </t>
<t> I2NSF defines client (applications) oriented descriptors (profiles, or
attributes) to request/negotiate/validate the network security functions that
are not on the local premises. </t>
</list>
</t>
<t> Why we belief I2NSF has a higher chance to be deployed than NSIS:
<list style="symbols">
<t> Open Stack already has a proof-of-concept/preliminary implementation, but the specification
is not complete. IETF can play an active role to make the specification for I2NSF is
complete. IETF can complete and extend the OpenStack implementation to
provide an interoperable specification that can meet the needs and requirements of
operators and is workable for suppliers of the technology. The combination of a
carefully designed interoperable IETF specification with an open-source code development
Open Stack will leverage the strengths of the two communities, and expand the informal
ties between the two groups. A software development cycle has the following components:
architecture, design specification, coding, and interoperability testing. The
IETF can take ownership of the first two steps, and provide expertise and
a good working atmosphere (in hack-a-thons) in the last two steps for OpenSTack or
other open-source coders.
</t>
<t> IETF has the expertise in security architecture and design for interoperable protocols that
span controllers/routers, middle-boxes, and security end-systems.
</t>
<t> IETF has a history of working on interoperable protocols or virtualized
network functions (L2VPN, L3VPN) that are deployed by operators in
large scale devices. IETF has a strong momentum to create virtualized network
functions (see SFC WG in routing) to be deployed in network boxes.
[Note: We need to add SACM and others here].
</t>
</list>
</t>
</section>
</section>
</section>
<section title="Summarized Requirements">
<t>
The I2NSF framework should provide a set of standard interfaces that
facilitate:
<list style="symbols">
<t> Dynamic creation, enablement, disablement, and removal of network
security functions;</t>
<t>Policy-driven placement of new function instances in the right
administrative domain;
</t>
<t>Attachment of appropriate security and traffic policies to the
function instances
</t>
<t>Management of deployed instances in terms of fault monitoring,
utilization monitoring, event logging, inventory, etc.</t>
</list>
</t>
<t>Moreover, an I2NSF must support different deployment scenarios:
<list style="symbols">
<t>Single and multi-tenant environments: The term multi-tenant does
not mean just different companies subscribing to a provider's
offering. It can for instance cover administrative domains/
departments within a single firm that require different security
and traffic policies.
</t>
<t> Premise-agnostic: Said network security functions may be deployed
on premises or off premises of an organization.
</t>
</list>
</t>
<t>
The I2NSF framework should provide a standard set of interfaces that
enable:
<list style="symbols">
<t>Translation of security policies into functional tasks. Security
policies may be carried out by one or more security functions.
For example, a security policy may be translated into an IDS/IPS
policy and a firewall policy for a given application type.
</t>
<t>
Translation of functional tasks into vendor-specific configuration
sets. For example, a firewall policy needs to be converted to
vendor-specific configurations.
</t>
<t>
Retrieval of information such as configuration, utilization,
status, etc. Such information may be used for monitoring,
auditing, troubleshooting purposes. The above functionality
should be available in single- or multi-tenant environments as
well as on-premise or off-premise clouds.
</t>
</list>
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>No IANA considerations exist for this document. </t>
</section>
<section title="Security Considerations">
<t>The relationship between different actors define the security level
for the different use cases and must be associated with
administrative domains:
<list style="symbols">
<t> Closed environments where there is only one administrative network
domain. More permissive access controls and lighter validation
shall be allowed inside the domain because of the protected
environment. Integration with existing identity management
systems is also possible.
</t>
<t>Open environments where some NSFs can be hosted in different
administrative domains, and more restrictive security controls are
required. The interfaces to the NSFs must use trusted channels.
Identity frameworks and federations are common models for
authentication and Authorization. Security controllers will be in
charge of this functionalities.
</t>
</list>
</t>
<t> Virtualization applied to NSF environment (vNSF) generate several
concerns in security, being one of the most relevant the attestation
of the vNSF by the clients. A holistic analysis has been done in
[NFVSEC].
</t>
</section>
<section title="Contributors">
<t>I2NSF is a group effort. The following people contributed actively to the
initial use case text: Diego R. Lopez (Telefonica I+D), Xiaojun Zhuang (China Mobile),
Minpeng Qi (China Mobile), Sumandra Majee (F5), Nic Leymann (Deutsche Telekom),
Linda Dunbar (Huawei).
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC791;
&RFC2119;
</references>
<references title="Informative References">
&RFC2748;
&RFC2940;
&RFC3084;
&RFC3303;
&RFC3304;
&RFC3483;
&RFC3484;
&RFC4080;
&RFC4261;
&RFC4949;
&RFC5189;
&RFC5277;
&RFC5539;
&RFC5973;
&RFC6022;
&RFC6241;
&RFC6242;
&RFC6243;
&RFC6436;
&RFC6470;
&RFC6536;
&RFC6639;
&RFC6887;
&RFC7223;
&RFC7225;
&RFC7277;
&RFC7317;
&I-D.ietf-netmod-syslog-model;
&I-D.ietf-netmod-acl-model;
&I-D.ietf-netmod-routing-cfg;
&I-D.ietf-netconf-restconf;
&I-D.ietf-netconf-call-home;
&I-D.ietf-netconf-restconf-collection;
&I-D.ietf-netconf-zerotouch;
&I-D.ietf-isis-yang-isis-cfg;
&I-D.ietf-ospf-yang;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-i2rs-usecase-reqs-summary;
&I-D.ietf-i2rs-problem-statement;
&I-D.ietf-i2rs-rib-data-model;
&I-D.ietf-i2rs-rib-info-model;
&I-D.ietf-i2rs-yang-network-topo;
&I-D.zhang-i2rs-l1-topo-yang-model;
&I-D.ietf-i2rs-yang-l2-network-topology;
&I-D.kini-i2rs-fb-rib-info-model;
&I-D.ietf-i2rs-ephemeral-state;
&I-D.hares-i2rs-auth-trans;
&I-D.dunbar-i2rs-discover-traffic-rules;
&I-D.hares-i2rs-bnp-eca-data-model;
&I-D.hares-i2rs-info-model-service-topo;
&I-D.ietf-i2rs-traceability;
&I-D.ietf-i2rs-pub-sub-requirements;
&I-D.shaikh-idr-bgp-model;
&I-D.shaikh-rtgwg-policy-model;
&I-D.ietf-sacm-architecture;
&I-D.ietf-sacm-terminology;
&I-D.zhdankin-idr-bgp-cfg;
&I-D.tsingh-bess-pbb-evpn-yang-cfg;
&I-D.zhuang-bess-evpn-yang;
&I-D.zhuang-bess-l3vpn-yang;
&I-D.liu-bess-mvpn-yang;
&I-D.ietf-pcp-proxy;
&I-D.ietf-pcp-optimize-keepalives;
&I-D.ietf-pcp-authentication;
&I-D.l3vpn-service-yang;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 04:09:26 |