One document matched: draft-ietf-i2nsf-gap-analysis-02.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 RFC3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.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.ietf-idr-bgp-model SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-idr-bgp-model-01.xml">
<!ENTITY I-D.ietf-rtgwg-policy-model SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-policy-model-00.xml">
<!ENTITY I-D.brissette-bess-evpn-yang SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-brissette-bess-evpn-yang-01.xml">
<!ENTITY I-D.shah-bess-l2vpn-yang SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-shah-bess-l2vpn-yang-01.xml">
<!ENTITY I-D.li-bess-l3vpn-yang SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-li-bess-l3vpn-yang-00.xml">
<!ENTITY I-D.hu-bess-l2vpn-service-yang SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-hu-bess-l2vpn-service-yang-00.xml">
<!ENTITY I-D.ietf-l3sm-l3vpn-service-model SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-l3sm-l3vpn-service-model-05.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-11.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-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.ietf-i2rs-ephemeral-state SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-ephemeral-state.xml">
<!ENTITY I-D.ietf-i2rs-protocol-security-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-protocol-security-requirements.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.hares-i2rs-pkt-eca-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-pkt-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-teas-yang-te-topo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-teas-yang-te-topo.xml">
<!ENTITY I-D.ietf-teas-yang-rsvp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-teas-yang-rsvp.xml">
<!ENTITY I-D.raza-mpls-ldp-mldp-yang SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.raza-mpls-ldp-mldp-yang.xml">
<!ENTITY I-D.pkd-pce-pcep-yang SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.pkd-pce-pcep-yang.xml">
<!ENTITY I-D.zhang-ccamp-transport-ctrlnorth-yang
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zhang-ccamp-transport-ctrlnorth-yang.xml">
<!ENTITY I-D.saad-mpls-static-yang
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.saad-mpls-static-yang.xml">
<!ENTITY I-D.zheng-mpls-lsp-ping-yang-cfg
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zheng-mpls-lsp-ping-yang-cfg.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-05.xml">
<!ENTITY I-D.ietf-sacm-terminology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sacm-terminology-09.xml">
<!ENTITY I-D.hares-i2nsf-terminology SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-hares-i2nsf-terminology-00.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="info" docName="draft-ietf-i2nsf-gap-analysis-02.txt" ipr="trust200902">
<front>
<title abbrev="I2NSF Gap analysis">Analysis of Existing work 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="Bob Moskowitz" initials="R" surname="Moskowitz">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<city>Oak Park</city>
<region>MI</region>
<code>48237</code>
</postal>
<email>rgm@labs.htt-consult.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>
<date year="2016" />
<area>Security Area</area>
<workgroup>I2NSF WG</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>I2NSF</keyword>
<abstract>
<t> This document analyzes the current state of the
art for security management devices and security devices
technologies in industries and the
existing IETF work/protocols that are 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.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
This documents provides a gap analysis for I2NSF.
</t>
<section title="What is I2NSF">
<t>A Network Security Function (NSF) ensures integrity, confidentiality and availability
of network communications, detects unwanted activity, and/or blocks out or at least mitigates
the effects of unwanted activity. NSFs are provided and consumed in increasingly
diverse environments. For example, users of NSFs could consume network security services
offered on multiple security products hosted one or more service provider,their own enterprises, or
a combination of the two.</t>
<t>
The lack of standard interfaces to control and monitor the behavior of NSFs
makes it virtually impossible for security service providers to automate service
offerings that utilize different security functions from multiple vendors.
</t>
<t>
The Interface to Network Service Functions (I2NSF) work
proposes to standardize a set of software interfaces 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 is 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. The Service Layer is out of scope for this phase of I2NSF’s work.</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 the I2NSF client on a network manager and the I2NSF agent on an NSF.
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 this Document">
<t> This document provides an analysis of the gaps in the state of art in the following
industry forums:
<list>
<t>IETF working groups (Section 2)</t>
<t>ETSI Network Functions Virtualization Industry Specification Group (ETSI NFV ISG),
(Section 3) </t>
<t> OPNFV Open Source Group (Section 4)</t>
<t>Open Stack - Firewall as a service (OpenStack Firewall FaaS) (Section 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 6)
(https://cloudsecurityalliance.org/research/secaas/#_overview)</t>
<t>In-Depth Review of Some IETF Protocols (Section 7)</t>
</list>
</t>
</section>
<section anchor="terms" title="Terms and Definitions">
<t></t>
<section title="Requirements Terminology">
<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 RFC 2119, BCP 14
[RFC2119] and indicate requirement levels for compliant CoAP. </t>
</section>
<section title="Definitions">
<t>
The following are a few definitions out of the terminology draft utilized
in this draft. For additional definitions please see:
<xref target="I-D.hares-i2nsf-terminology"></xref>.
</t>
<t>
<list style="hanging">
<t hangText="Network Security Function (NSF): ">is a function that is provided as a
set of security-related service function. Typically, an NSF may
be responsible for detecting unwanted activity and blocking/
mitigating the effect of such unwanted activity in order to fulfil
the service requirements. The NSF can help in supporting
communication stream integrity and confidentiality.
</t>
<t hangText="Cloud Data Center (DC): ">A data center
that may/may not be run on the 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)
focuses on adding security to this environment. A specific research topic
is security as a service within the cloud data center. </t>
<t hangText="Cloud-based security functions: ">Network Security Functions
(NSFs) that may be hosted and managed by service providers or a different
administrative entity.</t>
<t hangText="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 hangText="I2NSF server/agent: ">A software instance that implements a network
security function that receives provisioning information and
requests operational data (e.g. monitoring data) from an I2NSF
client. It is also responsible for enforcing the policies that it
receives from an I2NSF client.
</t>
<t hangText="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 hangText="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.
</t>
</list>
</t>
</section>
</section>
</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>) - for supporting
signaling about a data flow along its path, and
</t>
<t>Port Control Protocol (PCP) - allows the IPv4/IPv6 host
to control how IPv6/IPv4 packets are translated and forwarded
by 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>
Route filtering is outside the scope of the
flow filtering, but the flow filtering may be impacted
by route filtering. An initial model for routing policy is in
<xref target="I-D.ietf-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 Section 7.
</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 list filters which can permit or deny traffic
flow based on headers at the MAC Layer, 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 FIB RIB |
|routing policy | | routing policy|
| | | |
===|===============|=============|===============|=
+---------------+ data flow +---------------+
Figure 1
</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>).
See Section 7.2 on I2RS for additional details on I2RS.
</t>
<t> The vocabulary of the <xref target="I-D.ietf-netmod-acl-model"></xref>
is limited, so additional protocol independent filters has been written for
the I2RS Filter-Based RIBs in <xref target="I-D.hares-i2rs-pkt-eca-data-model"></xref>.
</t>
<t> One thing important to note is that
NETCONF and RESTCONF manage device layer YANG models. However,
as Figure 2 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 2 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
the requisite security expertise for such NSFs (IDP/IPS,
Web-filter, security-based deep-packet inspection, etc.)
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 been used by the industry for a
long time. A main reason is that MIDCOM had a lot of IPR encumbered technology and
IPR was likely a bigger problem for IETF at that time 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 words, there is a trust
model in MIDCOM 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 from Midcom
</t>
<t> MIDCOM is different from I2NSF because its SNMP scheme does not 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>Defining the requirements for an I2NSF protocol to pass this traffic.
(Ideally by 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 Continuous Monitoring), 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 7.4.
</t>
<t>
<figure>
<artwork>
+------------+
| I2NSF |
| Client |
| |
| security |
| NMS system |
+------------+
+-----+ / \ +-----+
|I2NSF|--/ \---|I2NSF|
|Agent| |Agent|
| | | |
| NSF | | NSF |
--| ----|------------|-----|-----
+-----+ data flow +-----+
Figure 2
</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 3
</artwork>
</figure>
</t>
<t> Figure 3 provides a diagram of a system in which the I2NSF, SACM,
DOTS and MILE 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 providers
and SACM consumers.
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 MILE client on a security network management system
talking to the MILE 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 ACLs defined NETMOD, the DOTS black-lists are not sufficient
for all filters or control desired by the NSF boxes.
</t>
<t>The incident data captured by MILE 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 Functions Virtualization (NFV) provides 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. However, the
exterior network beyond the service provider NSFs or its customer's NSFs
is becoming extremely narrow as NSFs are becoming more pervasive in any
portion of networks (service providers, customers, or access networks).
</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
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 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 framework is complementary to the NFV and other security
frameworks. The I2NSF management protocol will be deployed in networks
to provide a common management protocol to manage NSF software/devices
whether the devices are physical or virtual. The ETSI NFV security
is also deployed along-side other security functions (AAA, SACM, DOTS,
or MILE devices) and deep-packet stateful inspections.
</t>
<t>
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 4 shows.
The ETSI 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 4
</artwork>
</figure>
</t>
<t>
The ETSI proof-of-concept demonstrations have been done for the
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 protocol/interface can be deployed for security devices
along-side the network/host configuration done by NETCONF/RESTCONF or the routing
system interface provided by I2RS that handles.
</t>
<t>In the current NFV-related architecture, there is no
interoperable protocol defined between a security manager and various
NSF devices to provision security functions. The result is that service providers
have to manage the interoperability security manager and
different NSF devices using proprietary 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
on which providers may start their NFV development work. 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 Functions 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 carte” to enforcement related security managers.
A security management system integrates mechanisms of different security aspects.
This project intends 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 5 shows. This figure 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 compute and Swift for object storage.
Each system has a configuration file and its own security policy.
The system lacks a synchronization mechanism to build a complete
secure configuration for OPNFV. </t>
<t>No dynamic control so that if a user obtains the token,
so there 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 grained authorization at user level. Authorization is
only at the API level.</t>
</list> </t>
<t>
Moon addresses these issues adding authorization, logging, IDS, enforcement of
network policy, and storage protection. Moon release C (2016) plans to:
<list style="symbols">
<t>Define an identity federation scenario between OpenStack and OpenDaylight,
</t>
<t>Implement an authentication driver in ODL to delegate authentication to
OpenStack/Keystone,
</t>
<t>Implement a command line tool for administration and testing,
</t>
<t>Implement a graphic interface for identity management for both OpenStack and OpenDaylight,
</t>
<t>Set up identity federation testbed,
</t>
<t>Define identity federation scenarios with other SDN controllers, and
</t>
<t>Define authorization federation scenarios with OpenDaylight.
</t>
</list>
</t>
<t>Deliverable time frame: Moon Release 3 (mid-year 2016)
</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 5
</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 rules provide ingress
and egress traffic filters based on port. The default rule
for the group policy drops all ingress traffic and
allows all egress traffic. The group policy allows users
to add additional groups with additional filters that change
the default behaviour.
To utilize the security groups, the networking plug-in for
OpenStack must implement the security group API. The following
plug-ins in OpenStack 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 Firewall 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, or 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.
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 need for a single management interfaces for a variety of security devices.
</t>
<t>Phase 1 of I2NSF is proposes rules that will include Event-Condition-Action
matches (ECA) rules with:
<list>
<t> packet based matches on L2, L3, and L4 headers and/or
specific addresses within these headers, and </t>
<t>context based matches on schedule state and schedule.
</t>
<t>basic ations of deny, permit, and mirror,
</t>
<t>advanced actions of: IPS signature filtering and
URL filtering.
</t>
<t>[Editorial note: do we need more matches or actions?] </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 guidelines.
</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 problem. This 2012 implementation
report confirms there is a gap with IAM.
<figure>
<artwork>
+------------+ +--------+
| IAM device | ---- SLA ------------| secure |
| | Access review | access |
| | security events | NMS |
| | access tracing | |
+---||-------+ Audit report +---||---+
|| ||
|| +------------------+ ||
========== |Filter enforcement|=====||
+------------------+
Figure 6
</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 7
</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 bandwidth/QOS | |
| | monitor encrypted | |
| | data | |
+---||-------+ encrypt data +---||---+
|| ||
|| +------------------+ ||
========== |Filter enforcement|=====||
+------------------+
Figure 8
</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 9
</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
or intrusion protection devices. Management of these systems
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>
In order to be able performing these management
actions on NSF devices from different vendors,
the intrusion security management systems need
a standard mangement protocol that all the NSF vendors support.
<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 10
</artwork>
</figure>
The I2NSF manager - I2NSF (server/agent) protocol
is designed to fill this gap.
</t>
</section>
<section title="Security Information and Event Management(SIEM)">
<t>Document:
https://downloads.cloudsecurityalliance.org/initiatives/secaas/SecaaS_Cat_7_SIEM_Implementation_Guidance.pdf)
</t>
<t>
The Security Information and Event Management (SIEM) 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 SIEM 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 a prime candidate to have an
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, Identity-based
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>
Encryption services typically require that 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
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> Cold 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>
BC/DR requires 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 shortcoming.
Standard I2NSF YANG models and an I2NSF protocol are needed according to the
CSA SaaS documents. </t>
</section>
</section>
<section title="IEEE security">
<section title=" Port-based Network Access Control [802.1X]">
<t>
802.1x defines encapsulation of Extensible Authentication Protocol (EAP)
<xref target="RFC3748"></xref> over IEEE 802 (EAP over LAN, or EAPOL).
It is widely deployed on both wired and Wi-Fi Networks.
</t>
<t>EAP provides support for security from passwords to challenge-response
tokens and public-key infrastructure certificates.
</t>
<t> 802.1 has three concepts:
<list style="symbols">
<t>the supplicant - the user or client who wants to be authenticated
</t>
<t> authentication server - the server doing the authrentication (e.g. radius server), and
</t>
<t> the authenticator - the device in-between authentication server and supplicant (e.g. wireless Access Point (AP).
</t>
</list>
</t>
<t>
A normal sequence is below:
</t>
<t>
<figure>
<artwork>
supplicant authenticator authentication server
=========== =================== ========================
<---- EAP-Request/Identity
EAP-Response/Identity---->
EAP-Response/Identity---gt;
<---------Challenge
<------Challenge
Challenge
response --------->
Challenge
Response --------->
</artwork>
</figure>
</t>
<t>Gap:
</t>
<t>
This basic service provides access, but
today's access use cases are more complex.
IEEE 801.X has ben attched using the
Man-in-the-middle attacks. Another
weakness of 802.1X is the speed of the
EAP protocols processing with the radius server.
</t>
<t>Note: Editor - more is needed here
</t>
</section>
<section title="MAC security (802.1AE)">
<t>
MACsec security secures a link rather than a
conversation for 802.1 LANs (VLANs 802.1Q, Provider
Bridges 802.1AD). MACsec counters the 802.1X
man-in the middle attacks.
</t>
<t> MACsec (in 802.1AE) provides MAC-layer encryption over wired networks by using
out-of-band methods for encryption keying. The MACsec Key Agreement (MKA) Protocol provides the
required session keys and manages the required encryption keys. MKA and MACsec are implemented
after successful authentication using the 802.1x Extensible Authentication Protocol (EAP) framework.
Only hosts link which face the network can be secured with MACSec. These links
connect the host to the network access devices.
</t>
<t>
Switch using MACsec accepts either MACsec or non-MACsec frames based on policy set.
The NSF controller can set within the switches configuration whether MACSec frames are
accepted. Accepted MACsec frames are encrypted and protected with an integrity check value
(ICV). The switch after receiving frames from the client, decrypts them and calculates the correct ICV
by using session keys provided by MKA. The switch compares that ICV to the ICV within the frame. If
they are not identical, the frame is dropped. The switch also encrypts and adds an ICV to any frames sent
over the secured port (the access point used to provide the secure MAC service to a client) using the
current session key.
</t>
<t>The MKA Protocol manages the encryption keys used by the underlying MACsec protocol. The basic
requirements of MKA are defined in 802.1x-REV. The MKA Protocol extends 802.1x to allow peer
discovery with confirmation of mutual authentication and sharing of MACsec secret keys to protect data
exchanged by the peers. MKA protocol ues EAP-over-LAN (EAPOL) packet. EAP
authentication produces a master session key (MSK) shared by both partners in the data exchange.
Entering the EAP session ID generates a secure connectivity association key name (CKN). Because the
switch is the authenticator, and the key serer, it can generating a random 128-bit secure association key
(SAK), which it sends it to the client partner. The client is never a key server and can only interact with
a single MKA entity, the key server. After key derivation and generati
</t>
<t>
Gap Analysis:
</t>
<t>I2NSF Devices must handle the existence of MSEC within the network.
</t>
</section>
<section title="Secure Device Identity [802.1AR]">
<t>
802.1AR does the following:
<list>
<t>Supports trail of trust from manufacturer to user, and
</t>
<t>Defines how a Secure Device Identifier (DevId) may be cryptographically bound to
a device to support device identity authentication.
</t>
<t>DevIDs are composed of a secure device identifier secret and a secure device identifier credential.
These IDs can be controlled by the product manufacturer (IDevID, an initially installed identity)
or by the end-user (LDevID, a subsequent locally significant identity derived from the IDevID).
DevIDs cannot be be changed by the end-user.
</t>
<t>One attack mitigation can be to disable support for DeVIDs or limit to know DeVIDs.
</t>
</list>
</t>
<t>GAP analysis: </t>
<t>I2NSF controllers need to support 802.1AR device management.
</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 data stores defined in NETCONF.
</t>
<t>
RESTCONF supports “two edit condition detections” – time stamp and entity tag.
RESTCONF uses 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"></xref>,
</t>
<t><xref target="I-D.ietf-i2rs-pub-sub-requirements"></xref> (Publication-Subscription notifications,
</t>
<t><xref target="I-D.ietf-i2rs-traceability"></xref>
</t>
<t><xref target="I-D.ietf-i2rs-protocol-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 (<xref target="I-D.ietf-idr-bgp-model"></xref>.
</t>
<t>
BGP Services YANG models have been proposed for
<list style="symbols">
<t> EVPN <xref target="I-D.brissette-bess-evpn-yang"></xref>,
</t>
<t> L2VPN <xref target="I-D.shah-bess-l2vpn-yang"></xref>,
</t>
<t>L3VPN <xref target="I-D.li-bess-l3vpn-yang"></xref> and
<xref target="I-D.hu-bess-l2vpn-service-yang"></xref>,
</t>
</list>
</t>
<t>TEAS working group has proposed <xref target="I-D.ietf-teas-yang-te-topo"></xref>,
and <xref target="I-D.ietf-teas-yang-rsvp"></xref>.
</t>
<t>MPLS/PCE/CCAMP groups have proposed the following Yang modules:
<list style="symbols">
<t><xref target="I-D.raza-mpls-ldp-mldp-yang"></xref>
</t>
<t><xref target="I-D.saad-mpls-static-yang"></xref>,
</t>
<t><xref target="I-D.zheng-mpls-lsp-ping-yang-cfg"></xref>,
</t>
<t><xref target="I-D.pkd-pce-pcep-yang"></xref>, and
</t>
<t><xref target="I-D.zhang-ccamp-transport-ctrlnorth-yang"></xref>.
</t>
</list>
</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 11.
The COPS policy decision points (PDP) managed
network-wide policy (e.g. ACLs) by installing this
policy in policy enforcement points (PEPs) on the edge of
the network. These PEPs had firewall-like functions that
control what data flows into the network at a PEP point, and
data flow out of a network at a PEP.
<xref target="RFC3084"></xref> describes COPS usages for policy provisioning.
</t>
<t>
<figure>
<artwork>
PDP
+-----+ / \ +-----+
|PEP1 |--/ \---|PEP2 |
| | ACL/policy | |
| | | |
--| ----|------------|-----|-----
+-----+ data flow +-----+
Figure 11
</artwork>
</figure>
</t>
<t> Why COPS is no longer used </t>
<t>Network security today 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>, and <xref target="RFC3483"></xref>.
</t>
<t> Why I2NSF is Different from COPS </t>
<t> COPS was a protocol for policy related to Quality of Service (QoS)
and signaling 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 management of port and address information
rather than any other security functions
</t>
</list></t>
</section>
<section title="NSIS - Next Steps in Signaling">
<t> NSIS aims to standardize an IP signaling protocol (RSVP) along
the data path for end points to request their unique QoS characteristics, unique
FW policies or NAT needs (RFC5973) that are different from the FW/NAT
original settings. 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 one or more NATs present in the network, or
when trying to locate appropriate tunnel endpoints).
</t>
<t>
<figure>
<artwork>
clients----I2NSF controller
| client
|
| I2NSF
| server/agent
+--------+ +--------+ +--------+
| host | |firewall| | host |
|device-1|-------|device-2|-------|device-3|
+--------+ RSVP +--------+ RSVP +--------+
-----NSIS-----------------------
</artwork>
</figure>
</t>
<t> Why I2NSF is Different from NSIS:
<list style="symbols">
<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/Server</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 I2NSF may have higher chance to be deployed than NSIS:
<list style="symbols">
<t> OpenStack 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
OpenStack 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 anchor="IANA" title="IANA Considerations">
<t>No IANA considerations exist for this document. </t>
</section>
<section title="Security Considerations">
<t> No security considerations are involved with
a gap analysis.</t>
</section>
<section title="Contributors">
<t>
The following people have contributed to this document:
Hosnieh Rafiee, and Myo Zarny. Myo Zarny provided the
authors with extensive comments, great suggestions, and
valuable insights on alternative views.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC791;
&RFC2119;
</references>
<references title="Informative References">
&RFC2748;
&RFC2940;
&RFC3084;
&RFC3303;
&RFC3304;
&RFC3483;
&RFC3484;
&RFC3748;
&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-problem-statement;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-i2rs-usecase-reqs-summary;
&I-D.ietf-i2rs-protocol-security-requirements;
&I-D.ietf-i2rs-traceability;
&I-D.ietf-i2rs-pub-sub-requirements;
&I-D.ietf-i2rs-ephemeral-state;
&I-D.ietf-i2rs-rib-data-model;
&I-D.ietf-i2rs-rib-info-model;
&I-D.ietf-i2rs-yang-l2-network-topology;
&I-D.ietf-i2rs-yang-network-topo;
&I-D.hares-i2rs-pkt-eca-data-model;
&I-D.hares-i2rs-info-model-service-topo;
&I-D.kini-i2rs-fb-rib-info-model;
&I-D.ietf-idr-bgp-model;
&I-D.ietf-rtgwg-policy-model;
&I-D.ietf-sacm-architecture;
&I-D.ietf-sacm-terminology;
&I-D.brissette-bess-evpn-yang;
&I-D.shah-bess-l2vpn-yang;
&I-D.li-bess-l3vpn-yang;
&I-D.hu-bess-l2vpn-service-yang;
&I-D.ietf-teas-yang-te-topo;
&I-D.ietf-teas-yang-rsvp;
&I-D.raza-mpls-ldp-mldp-yang;
&I-D.pkd-pce-pcep-yang;
&I-D.zhang-ccamp-transport-ctrlnorth-yang;
&I-D.saad-mpls-static-yang;
&I-D.zheng-mpls-lsp-ping-yang-cfg;
&I-D.ietf-pcp-proxy;
&I-D.ietf-pcp-optimize-keepalives;
&I-D.ietf-pcp-authentication;
&I-D.ietf-l3sm-l3vpn-service-model;
&I-D.hares-i2nsf-terminology;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 02:40:47 |