Network Working Group                                           S. Hares
INTERNET-DRAFT                                                    Huawei
Intended Status: Informational                                  D. Zhang

                                                            H. Moskowitz
                                                          HTT Consulting
                                                                H.Rafiee
                                                                 Rozanak
Expires: January 6, 2016                                    July 6, 2015


                   Analysis of Existing Work for I2NSF
                    <draft-zhang-gap-analysis-06.txt>

Abstract

   This document analyzes the status of the arts in industries and the
   existing IETF work/protocols that are relevant to I2NSF. 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.



Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF). Note that other groups may also distribute working
   documents as Internet-Drafts. The list of current Internet-Drafts is
   at http://datatracker.ietf.org/drafts/current.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 6, 2016.





Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors. All rights reserved. This document is subject to


Hares & el.       Expires January 6, 2016                       [Page 1]


INTERNET DRAFT                            NFV Security      July 6, 2015

   BCP 78 and the IETF Trust's Legal Provisions Relating to IETF
   Documents (http://trustee.ietf.org/license-info) in effect on the
   date of publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Table of Contents

   1.  Introduction   . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  What is I2NSF  . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Structure of this Document   . . . . . . . . . . . . . . .  5
     1.3.  Terms and Definitions  . . . . . . . . . . . . . . . . . .  5
       1.3.1.  Requirements Terminology   . . . . . . . . . . . . . .  5
       1.3.2.  Definitions  . . . . . . . . . . . . . . . . . . . . .  5
   2.  IETF Gap analysis  . . . . . . . . . . . . . . . . . . . . . .  7
     2.1.  Traffic Filters    . . . . . . . . . . . . . . . . . . . .  7
       2.1.1.  Overview   . . . . . . . . . . . . . . . . . . . . . .  7
         2.1.1.1.  Data Flow Filters in NETMOD and I2RS   . . . . . .  7
         2.1.1.2.  I2NSF Gap analysis   . . . . . . . . . . . . . . .  9
       2.1.2.  Middle-box Filters   . . . . . . . . . . . . . . . . .  9
         2.1.2.1.  Midcom   . . . . . . . . . . . . . . . . . . . . .  9
       2.1.3.  Security Work  . . . . . . . . . . . . . . . . . . . . 10
         2.1.3.1.  Overview   . . . . . . . . . . . . . . . . . . . . 10
         2.1.3.2.  Security Work and Filters    . . . . . . . . . . . 11
         2.1.3.3.  I2NSF interaction    . . . . . . . . . . . . . . . 11
         2.1.3.4.  Benefits from the Interaction    . . . . . . . . . 12
   3.  ETSI NFV   . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     3.1.  ETSI Overview    . . . . . . . . . . . . . . . . . . . . . 13
     3.2.  I2NSF Gap Analysis   . . . . . . . . . . . . . . . . . . . 14
   4.  OPNFV    . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     4.1.  OPNFV Moon Project   . . . . . . . . . . . . . . . . . . . 15
     4.2.  Gap Analysis for OPNFV Moon Project    . . . . . . . . . . 16
   5.  OpenStack Security Firewall    . . . . . . . . . . . . . . . . 16
     5.1.  Overview of API for Security Group   . . . . . . . . . . . 17
     5.2.  Overview of Firewalls as a Service   . . . . . . . . . . . 17
     5.3.  I2NSF Gap analysis   . . . . . . . . . . . . . . . . . . . 18
   6.  CSA Secure Cloud   . . . . . . . . . . . . . . . . . . . . . . 18
     6.1.  CSA Overview   . . . . . . . . . . . . . . . . . . . . . . 18
       6.1.1.  CSA Security as a Service(SaaS)    . . . . . . . . . . 19
       6.1.2.  Identity Access Management (IAM)   . . . . . . . . . . 20
       6.1.3.  Data Loss Prevention (DLP)   . . . . . . . . . . . . . 20
       6.1.4.  Web security(Web))   . . . . . . . . . . . . . . . . . 21
       6.1.5.  Email Security (email))    . . . . . . . . . . . . . . 22
       6.1.6.  Security Assessment    . . . . . . . . . . . . . . . . 24
       6.1.7.  Intrusion Detection    . . . . . . . . . . . . . . . . 24
       6.1.8.  Security Information and Event Management(SEIM)    . . 25
       6.1.9.  Encryption   . . . . . . . . . . . . . . . . . . . . . 26
       6.1.10.  Business Continuity and Disaster Recovery (BC/DR)   . 27


Hares & el.       Expires January 6, 2016                       [Page 2]


INTERNET DRAFT                            NFV Security      July 6, 2015

       6.1.11.  Network Security Devices    . . . . . . . . . . . . . 28
     6.2.  I2NSF Gap Analysis   . . . . . . . . . . . . . . . . . . . 29
   7.  In-depth Review of IETF protocols    . . . . . . . . . . . . . 29
     7.1.  NETCONF and RESTCONF   . . . . . . . . . . . . . . . . . . 29
     7.2.  I2RS Protocol    . . . . . . . . . . . . . . . . . . . . . 30
     7.3.  NETMOD Yang modules    . . . . . . . . . . . . . . . . . . 31
     7.4.  COPS   . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     7.5.  PCP    . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     7.6.  NSIS - Next steps in Signalling    . . . . . . . . . . . . 33
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 34
   10.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 34
     10.1.  Normative . . . . . . . . . . . . . . . . . . . . . . . . 34
     10.2.  Informative . . . . . . . . . . . . . . . . . . . . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42








































Hares & el.       Expires January 6, 2016                       [Page 3]


INTERNET DRAFT                            NFV Security      July 6, 2015


1.  Introduction

   This documents provides a gap analysis for I2NSF.


1.1.  What is I2NSF

   The Network Security Function (NSF) in a network ensures integrity,
   confidentiality and availability of network communications, detects
   unwanted activity, and blocks out or at least mitigates the effects
   of unwanted activity. NSF devices 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.

   The lack of standard interfaces to control and monitor the behaviour
   of NSFs, makes it virtually impossible for security service providers
   to automate service offerings that utilize different security
   functions from multiple vendors.

   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.

   There are two layers of interfaces envisioned in the I2NSF approach:

   o 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.

   o 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.

   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.



   The I2NSF work to define this protocol includes the following work:



Hares & el.       Expires January 6, 2016                       [Page 4]


INTERNET DRAFT                            NFV Security      July 6, 2015

   o defining an informational model that defines the concepts for
   standardizing the control and monitoring of NSFs,

   o defining a set of Yang data models from the information model that
   identifies the data that must be passed,

   o 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.

   o 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).


1.2.  Structure of this Document

   This document provides a analysis of the gaps in the state of art in
   the following industry forums:

   IETF working groups (section 2)

   ETSI Network Functions Virtualization Industry Specification Group
   (ETSI NFV ISG), (section 3)

   OPNFV Open Source Group (section 4)

   Open Stack - Firewall as a service (OpenStack Firewall FaaS)

   (section 5)
   (http://docs.openstack.org/admin-guide-cloud/content/install_neutron-fwaas-agent.html)

   Cloud Security Alliance Security (CSA)as a Service (section 6)

   (https://cloudsecurityalliance.org/research/secaas/#_overview)

   In-Depth Review of Some IETF Protocols (section 7)


1.3.  Terms and Definitions


1.3.1.  Requirements Terminology

   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.


1.3.2.  Definitions



Hares & el.       Expires January 6, 2016                       [Page 5]


INTERNET DRAFT                            NFV Security      July 6, 2015

   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.

   o Cloud-based security functions: Network Security Function (NSF)
   hosted and managed by service providers or different administrative
   entity.

   o DC: Data Center

   o Domain: The term Domain in this draft has the following different
   connotations in different scenarios:

   * Client--Provider relationship, i.e. client requesting some

   network security functions from its provider;

   * Domain A - Domain B relationship, i.e. one operator domain
   requesting some network security functions from another operator
   domain; or

   * Applications -- Network relationship, i.e. an application (e.g.
   cluster of servers) requesting some functions from network, etc.



   The domain context is important because it indicates the interactions
   the security is focused on.

   o NSF - Network Security function

   o 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.

   o 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)

   o 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.

   o Virtual Security Function: a security function that can be
   requested by one domain but may be owned or managed by another
   domain.


Hares & el.       Expires January 6, 2016                       [Page 6]


INTERNET DRAFT                            NFV Security      July 6, 2015



2.  IETF Gap analysis

   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.


2.1.  Traffic Filters


2.1.1.  Overview

   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:

   o COPS protocol [RFC2748] for controlling access to networks,

   o Next steps in Signalling (NSIS) work (architecture: [RFC4080]
   protocol: [RFC5973]), and

   o the Port Control Protocol (PCP) to enables IPv4 to IPv6 flexible
   address and port mapping for NATs and Firewalls,



   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.

   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 [I-D.shaikh-rtgwg-policy-model]

   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.


2.1.1.1.  Data Flow Filters in NETMOD and I2RS

   The current work on expanding these filters is focused oncombining a
   configuration and monitoring protocol with Yang data models.


Hares & el.       Expires January 6, 2016                       [Page 7]


INTERNET DRAFT                            NFV Security      July 6, 2015

   [I-D.ietf-netmod-acl-model] 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 [RFC6241],
   RESTCONF [I-D.ietf-netconf-restconf], 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
   [I-D.kini-i2rs-fb-rib-info-model] which controls the flow of traffic
   on interfaces specifically controlled by the I2RS filter-based FIB.

                         netconf
      +---------------+    /  \     +---------------+
      | Device: ACLs  |-- /     \---|Device: ACLS   |
      | I2RS FB RIB   |             | I2RS FIB RIB  |
      |routing policy |             | routing policy|
      |               |             |               |
   ===|===============|=============|===============|=
      +---------------+  data flow  +---------------+
           Figure 1

   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
   [I-D.ietf-i2rs-architecture]). Please see the background section on
   I2RS for additional details on the requirements for this extension to
   the NETCONF/RESTCONF protocol suite.

   The vocabulary set in [I-D.ietf-netmod-acl-model] is limited, so
   additional protocol independent filters were written for the I2RS
   Filter-Based RIBs in [I-D.hares-i2rs-bnp-eca-data-model], and
   protocol specific filters for SFC
   [I-D.dunbar-i2rs-discover-traffic-rules].

   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).

   +--------------------------------------------+
   |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          |


Hares & el.       Expires January 6, 2016                       [Page 8]


INTERNET DRAFT                            NFV Security      July 6, 2015

   | (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

2.1.1.2.  I2NSF Gap analysis

   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.

   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.

   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.

   What I2NSF can use from NETCONF/RESTCONF and I2RS I2NSF should
   consider using NETCONF/RESTCONF protocol and the I2RS proposed
   enhancement to the NETCONF/RESTCONF protocol.


2.1.2.  Middle-box Filters


2.1.2.1.  Midcom

   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


Hares & el.       Expires January 6, 2016                       [Page 9]


INTERNET DRAFT                            NFV Security      July 6, 2015

   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.

   Why I2NSF is different than Midcom

   MIDCOM is different than I2NSF because its SNMP scheme doesn't work
   with the virtual network security functions (vNSF) management.

   MidCom RFCs:

   [RFC3303] - Midcom architecture

   [RFC5189] - Midcom Protocol Semantics

   [RFC3304] - Midcom protocol requirements


2.1.3.  Security Work


2.1.3.1.  Overview

   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.

   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:

   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.)

   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.

   define the requirements for an I2NSF protocol to pass this traffic.
   (Hopefully re-using existing protocols.)

   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


Hares & el.       Expires January 6, 2016                      [Page 10]


INTERNET DRAFT                            NFV Security      July 6, 2015

   Signalling), and MILE (Management Incident Lightweight Exchange).


2.1.3.2.  Security Work and Filters

   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 x.x.
                +------------+
                | I2NSF      |
                | Client     |
                |            |
                | security   |
                | NMS system |
                +------------+
      +-----+    /  \    +-----+
      |I2NSF|--/     \---|I2NSF|
      |Agent|            |Agent|
      |     |            |     |
      | NSF |            | NSF |
    --| ----|------------|-----|-----
      +-----+  data flow +-----+

        Figure 2
   The other security protocols work to interact within the network to
   provide additional information in the following way:

   o SACM [I-D.ietf-sacm-architecture] describes an architecture which
   tries to determine if the end-point security policies and the reality
   (denoted as security posture) align. [I-D.ietf-sacm-terminology]
   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.

   o 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.

   o 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.


2.1.3.3.  I2NSF interaction

   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


Hares & el.       Expires January 6, 2016                      [Page 11]


INTERNET DRAFT                            NFV Security      July 6, 2015

   devices is compatible and synergistic with these existing efforts.


                +----------+    +------+
    +--------+  | 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
   Figure 3 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:

   o 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.

   o 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.

   o 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.


2.1.3.4.  Benefits from the Interaction



Hares & el.       Expires January 6, 2016                      [Page 12]


INTERNET DRAFT                            NFV Security      July 6, 2015

   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.

   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.

   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.


3.  ETSI NFV


3.1.  ETSI Overview

   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.

   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.

   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 4 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


Hares & el.       Expires January 6, 2016                      [Page 13]


INTERNET DRAFT                            NFV Security      July 6, 2015

   on the network security feature VNF.
        ....................
    +--:   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
   The ETSI proof of concept work has worked on the following security
   proof of concepts:

   o #16 - NFVIaas with Secure, SDN controlled WAN Gateway,


3.2.  I2NSF Gap Analysis

   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.

   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.

   Open source work (such as OPNFV) provides a common code base for


Hares & el.       Expires January 6, 2016                      [Page 14]


INTERNET DRAFT                            NFV Security      July 6, 2015

   providers to start their NFV work from. However, this code base faces
   the same problem. There is no defacto standard protocol.


4.  OPNFV

   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.


4.1.  OPNFV Moon Project

   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.


   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.

   The Moon project lists the following gaps in OpenStack:

   o 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.

   o No dynamic control so that if a user obtains the token, the is no
   way to obtain control over the user.



Hares & el.       Expires January 6, 2016                      [Page 15]


INTERNET DRAFT                            NFV Security      July 6, 2015

   o No customization or flexibility to allow integration into different
   vendors,

   o No fine grain authorization at user level. Authorization is only at
   the API

   Moon addresses these issues adding authorization, logging, IDS,
   enforcement of network policy, and storage protection. Moon is based
   on OpenStack Keystone.

   Deliverable time frame: 2S 2015



        ....................
    +--:   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

4.2.  Gap Analysis for OPNFV Moon Project

   OpenStack congress does not provide vendor independent systems.


5.  OpenStack Security Firewall



Hares & el.       Expires January 6, 2016                      [Page 16]


INTERNET DRAFT                            NFV Security      July 6, 2015

   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).

   This section provides an overview of this open stack work, and a gap
   analysis of how I2NSF provides additional functions


5.1.  Overview of API for Security Group

   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.


5.2.  Overview of Firewalls as a Service

   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:

   o identification of rule (id, name, description)

   o identification tenant rule associated with,

   o links to installed firewall policy,

   o IP protocol (tcp, udp, icmp, none)

   o source and destination IP address

   o source and destination port

   o action: allow or deny traffic

   o status: position and enable/disabled



   The firewall policies include the following information:

   o identification of the policy (id, name, description),

   o identification of tenant associated with,


Hares & el.       Expires January 6, 2016                      [Page 17]


INTERNET DRAFT                            NFV Security      July 6, 2015


   o ordered list of firewall rules,

   o indication if policy can be seen by tenants other than owner, and

   o indication if firewall rules have been audited.

   The firewall table provides the following information:

   o identification of firewall (id, name, description),

   o tenant associated with this firewall,

   o administrative state (up/down),

   o status (active, down, pending create, pending delete, pending
   update, pending error)

   o firewall policy ID this firewall is associated with


5.3.  I2NSF Gap analysis

   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.

   I2NSF is proposing rules that will include Event-Condition-matches
   (ECA) with the following matches packet based matches on L2, L3, and
   L4 headers and/or specific addresses within these headers, context
   based matches on schedule state and schedule, [Editor: Need more
   details here.]

   The I2NSF is proposing action for these ECA policies of:

   basic actions of deny, permit, and mirror,

   advanced actions of: IPS signature filtering and URL filtering.


6.  CSA Secure Cloud


6.1.  CSA Overview

   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


Hares & el.       Expires January 6, 2016                      [Page 18]


INTERNET DRAFT                            NFV Security      July 6, 2015

   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


6.1.1.  CSA Security as a Service(SaaS)

   The CSA SaaS working group defined the following ten categories, and
   provided implementation guidance on these categories:

   1. Identity Access Management (IAM)
   (https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_1_IAM_Implementation_Guidance.pdf)

   2. Data Loss Prevention (DLP)
   (https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_2_DLP_Implementation_Guidance.pdf)

   3. Web Security (web)
   (https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_3_Web_Security_Implementation_Guidance.pdf),

   4. Email Security (email)
   (https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_4_Email_Security_Implementation_Guidance.pdf),

   5. Security Assessments
   (https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_5_Security_Assessments_Implementation_Guidance.pdf),

   6. Intrusion Management
   (https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_6_Intrusion_Management_Implementation_Guidance.pdf),

   7. Security information and Event Management
   (https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_7_SIEM_Implementation_Guidance.pdf),


   8. Encryption
   (https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf),

   9. Business Continuity and Disaster Recovery (BCDR)
   https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_9_BCDR_Implementation_Guidance.pdf), and

   10. Network Security
   (https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_10_Network_Security_Implementation_Guidance.pdf).

   The sections below give an overview these implementation guidances


Hares & el.       Expires January 6, 2016                      [Page 19]


INTERNET DRAFT                            NFV Security      July 6, 2015



6.1.2.  Identity Access Management (IAM)

   document:

   (https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_1_IAM_Implementation_Guidance.pdf)

   The identity management systems include the following services:

   o Centralized Directory Services,

   o Access Management Services,

   o Identity Management Services,

   o Identity Federation Services,

   o Role-Based Access Control Services,

   o User Access Certification Services,

   o Privileged User and Access Management,

   o Separation of Duties Services, and

   o Identity and Access Reporting Services.

   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

    +------------+                      +--------+
    | IAM device | ---- SLA ------------| secure |
    |            |     Access review    | access |
    |            |    security events   |  NMS   |
    |            |    access tracing    |        |
    +---||-------+    Audit report      +---||---+
        ||                                  ||
        ||         +------------------+     ||
        ========== |Filter enforcement|=====||
                   +------------------+
      Figure 6

6.1.3.  Data Loss Prevention (DLP)

   Document:

   (https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_2_DLP_Implementation_Guidance.pdf)


Hares & el.       Expires January 6, 2016                      [Page 20]


INTERNET DRAFT                            NFV Security      July 6, 2015


   The data loss prevention (DLP)services must address:

   o origination verification,

   o integrity of data,

   o confidentiality and access control,

   o accountability,

   o avoiding false positives on detection, and

   o privacy concerns.

   The CSA SaaS DLP device communications require that it have the
   enforcement capabilities to do the following:

   alert and log data loss,

   delete data on system or passing through,

   filter out (block/quarantine) data,

   reroute data,

   encrypt data

    +------------+                      +--------+
    | DLP device | ---- SLA ------------| secure |
    |            |    Alert and log     | access |
    |            |    delete data       |  NMS   |
    |            |    filter/reroute    |        |
    +---||-------+    encrypt data      +---||---+
        ||                                  ||
        ||         +------------------+     ||
        ========== |Filter enforcement|=====||
                   +------------------+
      Figure 7

6.1.4.  Web security(Web))

   Document:

   https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_3_Web_Security_Implementation_Guidance.pdf

   The web security services must address:

   o Web 2.0/Social Media controls,

   o Malware and Anti-Virus controls,



Hares & el.       Expires January 6, 2016                      [Page 21]


INTERNET DRAFT                            NFV Security      July 6, 2015

   o Data Loss Prevention controls (over Web-based services like Gmail
   or Box.net),

   o XSS, JavaScript and other web specific attack controls

   o Web URL Filtering,

   o Policy control and administrative management,

   o Bandwidth management and quality of service (QoS) capability, and

   o Monitoring of SSL enabled traffic.

   The CSA SaaS Web services device communications require that it have
   the enforcement capabilities to do the following:

   alert and log malware or anti-virus data patterns,

   delete data (malware and virus) passing through systems,

   filter out (block/quarantine) data,

   filter Web URLs,

   interact with policy and network management systems,

   control bandwidth and QoS of traffic, and

   monitor encrypted (SSL enabled) traffic,

   All of these features either require the I2NSF standardized I2NSF
   client to I2NSF agent to provide multi-vendor interoperability.

    +------------+                      +--------+
    |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 8

6.1.5.  Email Security (email))

   Document:

   https://downloads.cloudsecurityalliance.org/initiatives/secaas/


Hares & el.       Expires January 6, 2016                      [Page 22]


INTERNET DRAFT                            NFV Security      July 6, 2015

   SecaaS_Cat_4_Email_Security_Implementation_Guidance.pdf

   The CSA Document recommends that email security services must
   address:

   o Common electronic mail components,

   o Electronic mail architecture protection,

   o Common electronic mail threats,

   o Peer authentication,

   o Electronic mail message standards,

   o Electronic mail encryption and digital signature,

   o Electronic mail content inspection and filtering,

   o Securing mail clients, and

   o Electronic mail data protection and availability assurance
   techniques

   The CSA SaaS Email security services requires that it have the
   enforcement capabilities to do the following:

   provide the malware and spam detection and removal,

   alert and provide rapid response to email threats,

   identify email users and secure remote access to email,

   do on-demand provisioning of email services,

   filter out (block/quarantine) email data,

   know where the email traffic or data is residing (to to regulatory
   issues), and

   be able to monitor encrypted email,

   be able to encrypt email,

   be able to retain email records (while abiding with privacy
   concerns), and

   interact with policy and network management systems.

   All of these features require the I2NSF standardized I2NSF client to
   I2NSF agent to provide multi-vendor interoperability.



Hares & el.       Expires January 6, 2016                      [Page 23]


INTERNET DRAFT                            NFV Security      July 6, 2015

    +------------+                      +--------+
    |   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

6.1.6.  Security Assessment

   Document:

   https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_5_Security_Assessments_Implementation_Guidance.pdf

   The CSA SaaS Security assessment indicates that assessments need to
   be done on the following devices:

   o hypervisor infrastructure,

   o network security compliance systems,

   o Servers and workstations,

   o applications,

   o network vulnerabilities systems,

   o internal auditor and intrusion detection/prevention systems (IDS/
   IPS), and

   o web application systems.

   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.


6.1.7.  Intrusion Detection

   Document:

   https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_6_Intrusion_Management_Implementation_Guidance.pdf)

   The CSA SaaS Intrusion detection management includes intrusion
   detection through: devices:


Hares & el.       Expires January 6, 2016                      [Page 24]


INTERNET DRAFT                            NFV Security      July 6, 2015


   o Network traffic inspection, behavioural analysis, and flow
   analysis,

   o Operating System, Virtualization Layer, and Host Process Events
   monitoring,

   o monitoring of Application Layer Events, and

   o Correlation Techniques, and other Distributed and Cloud-Based
   Capabilities

   Intrusion response includes both:

   o Automatic, Manual, or Hybrid Mechanisms,

   o Technical, Operational, and Process Mechanisms.

   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:

   Central reporting of events and alerts,

   administrator notification of intrusions,

   Mapping of alerts to Cloud-Layer Tenancy,

   Cloud sourcing information to prevent false positives in detection,
   and

   allowing for redirection of traffic to allow remote storage or
   transmission to prevent local evasion.

   All of these features require the I2NSF standardized I2NSF client to
   I2NSF agent to provide multi-vendor interoperability.

    +------------+                      +--------+
    |  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

6.1.8.  Security Information and Event Management(SEIM)


Hares & el.       Expires January 6, 2016                      [Page 25]


INTERNET DRAFT                            NFV Security      July 6, 2015


   Document:

   https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_7_SIEM_Implementation_Guidance.pdf)

   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.

   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.


6.1.9.  Encryption

   Document:

   https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf

   The CSA SaaS Encryption implementation guidance document considers
   how one implements and manages the following security systems:

   key management systems (KMS), control of keys, and key life cycle;

   Shared Secret encryption (Symmetric ciphers),

   No-Secret or Public Key Encryption (asymmetric ciphers),

   hashing algorithms,

   Digital Signature Algorithms,

   Key Establishment Schemes,

   Protection of Cryptographic Key Material (FIPS 140-2; 140-3),

   Interoperability of Encryption Systems, Key Conferencing, Key Escrow
   Systems, and others

   application of Encryption for Data at rest, data in transit, and data
   in use;



Hares & el.       Expires January 6, 2016                      [Page 26]


INTERNET DRAFT                            NFV Security      July 6, 2015

   PKI (including certificate revocation "CRL");

   Future application of such technologies as Homomorphic encryption,
   Quantum Cryptography, Identitybased Encryption, and others;

   Crypto-system Integrity (How bad implementations can under mind a
   crypto-system), and

   Cryptographic Security Standards and Guidelines

   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.


6.1.10.  Business Continuity and Disaster Recovery (BC/DR)

   Document:

   https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_9_BCDR_Implementation_Guidance.pdf

   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:

   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,

   Storage as a Service including object, volume, or block storage;

   old Site, Warm Site, Hot Site backup plans;

   IaaS (Infrastructure as a Service), PaaS (Platform as a Service), and
   SaaS (Software as a Service);

   Insurance (and insurance reporting programs)

   Business Partner Agents (business associate agreements);

   System Replication (for high availability);

   Fail-back to Live Systems mechanisms and management;

   Recovery Time Objective (RTO) and Recovery Point Objective (RPO);



Hares & el.       Expires January 6, 2016                      [Page 27]


INTERNET DRAFT                            NFV Security      July 6, 2015

   Encryption (data at rest [DAR], data in motion [DIM], field level);

   Realm-based Access Control;

   Service-level Agreements (SLA); and ISO/IEC 24762:2008, BS25999, ISO
   27031, and FINRA Rule 4370

   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.

   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.

   The CSA SaaS BC/BR documents indicate how important a standardized
   I2NSF protocol is.


6.1.11.  Network Security Devices

   Document:

   https://downloads.cloudsecurityalliance.org/initiatives/secaas/
   SecaaS_Cat_10_Network_Security_Implementation_Guidance.pdf

   The CSA SaaS Network Security implementation recommendation includes
   advice on:

   How to segment networks,

   Network security controls,

   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,

   Secure routing and time,

   Denial of Service (DoS) and Distributed Denial of Service (DDoS)
   Protection/Mitigation,

   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),


Hares & el.       Expires January 6, 2016                      [Page 28]


INTERNET DRAFT                            NFV Security      July 6, 2015


   Threat Management,

   Forensic Support, and

   Privileged User/Use Monitoring.

   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:

   "It is critical to understand what monitoring APIs are available from
   the CSP, and if they match risk and compliance requirements",

   "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."

   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."

   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.


6.2.  I2NSF Gap Analysis

   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.


7.  In-depth Review of IETF protocols


7.1.  NETCONF and RESTCONF

   The IETF NETCONF working group has developed the basics of the
   NETCONF protocol focusing on secure configuration and querying
   operational state. The NETCONF protocol [RFC6241] may be run over TLS
   [RFC6639] or SSH ([RFC6242]. NETCONF can be expanded to defaults


Hares & el.       Expires January 6, 2016                      [Page 29]


INTERNET DRAFT                            NFV Security      July 6, 2015

   [RFC6243], handling events ([RFC5277] and basic notification
   [RFC6470], and filtering writes/reads based on network access control
   models (NACM, [RFC6536]). 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.

   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. RFCs
   for NETCONF

   o NETCONF [RFC6242]

   o NETCONF monitoring [RFC6022]

   o NETCONF over SSH [RFC6242]

   o NETCONF over TLS [RFC5539]

   o NETCONF system notification> [RFC6470]

   o NETCONF access-control (NACM) [RFC6536]

   o RESTCONF [I-D.ietf-netconf-restconf]

   o NETCONF-RESTCONF call home [I-D.ietf-netconf-call-home]

   o RESTCONF collection protocol [I-D.ietf-netconf-restconf-collection]

   o NETCONF Zero Touch Provisioning [I-D.ietf-netconf-zerotouch]


7.2.  I2RS Protocol

   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).

   The required extensions for the I2RS protocol are in the following
   drafts:

   o Ephemeral state [I-D.ietf-i2rs-ephemeral-state],



Hares & el.       Expires January 6, 2016                      [Page 30]


INTERNET DRAFT                            NFV Security      July 6, 2015

   o Publication-Subscription notifications
   [I-D.ietf-i2rs-pub-sub-requirements],

   o Traceability [I-D.ietf-i2rs-traceability],

   o Security requirements [I-D.hares-i2rs-auth-trans]

   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.


7.3.  NETMOD Yang modules

   NETMOD developed initial Yang models for interfaces [RFC7223]), IP
   address ([RFC7277]), IPv6 Router advertisement ([RFC7277]), IP
   Systems ([RFC7317]) with system ID, system time management, DNS
   resolver, Radius client, SSH, syslog
   ([I-D.ietf-netmod-syslog-model]), ACLS ([I-D.ietf-netmod-acl-model]),
   and core routing blocks ([I-D.ietf-netmod-routing-cfg] The routing
   working group (rtgwg) has begun to examine policy for routing and
   tunnels.

   Protocol specific Working groups have developed yang models for ISIS
   ([I-D.ietf-isis-yang-isis-cfg]), OSPF ([I-D.ietf-ospf-yang]), and BGP
   ( merge of [I-D.shaikh-idr-bgp-model] and [I-D.zhdankin-idr-bgp-cfg]
   with the bgp policy proposed multiple Working groups (idr and
   rtgwg)). BGP Services yang models have been proposed for PPB EVPN
   ([I-D.tsingh-bess-pbb-evpn-yang-cfg]), EVPN
   ([I-D.zhuang-bess-evpn-yang]), L3VPN ([I-D.zhuang-bess-l3vpn-yang]),
   and multicast MPLS/BGP IP VPNs ([I-D.liu-bess-mvpn-yang]).


7.4.  COPS

   One early focus on flow filtering based on policy enforcement of
   traffic entering a network is the 1990s COPS [RFC2748] design (PEP
   and PDP) as shown in figure 1. 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. [RFC3084] describes COPS
   use for policy provisioning.

                PDP
      +-----+    /  \    +-----+
      |PEP1 |--/     \---|PEP2 |
      |     | ACL/policy |     |
      |     |                |     |
    --| ----|------------|-----|-----
      +-----+  data flow +-----+

              Figure 11


Hares & el.       Expires January 6, 2016                      [Page 31]


INTERNET DRAFT                            NFV Security      July 6, 2015

   COPS had a design of Policy Enforcement Points (PEP), and policy
   Decision Points (PDP) as shown in figure 11. These decision points
   controlled flow from PEP to PEP.

   Why COPS is no longer used

   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.

   COPs RFCs: [RFC4261], [RFC2940], , [RFC3084], , [RFC3483]

   Why I2NSF is different COPS

   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.


7.5.  PCP

   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.

   PCP RFCs:

   [RFC6887]

   [RFC7225]

   [I-D.ietf-pcp-authentication]

   [I-D.ietf-pcp-optimize-keepalives]

   [I-D.ietf-pcp-proxy]

   Why is I2NSF different from PCP:

   Here are some aspects that I2NSF is different from PCP:

   o PCP only supports the management of port and address information
   rather than any other security functions

   o Cover the proxy, firewall and NAT box proposals in I2NSF




Hares & el.       Expires January 6, 2016                      [Page 32]


INTERNET DRAFT                            NFV Security      July 6, 2015

7.6.  NSIS - Next steps in Signalling

   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.

   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).

   A diagram should be added here showing I2NSF and NSIS

   Why I2NSF is different than NSIS:

   o 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.

   o 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

   o I2NSF defines client (applications) oriented descriptors (profiles,
   or attributes) to request/negotiate/validate the network security
   functions that are not on the local premises.

   Why we belief I2NSF has a higher chance to be deployed than NSIS:

   o 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.

   o IETF has the expertise in security architecture and design for
   interoperable protocols that span controllers/routers, middle- boxes,
   and security end-systems.


Hares & el.       Expires January 6, 2016                      [Page 33]


INTERNET DRAFT                            NFV Security      July 6, 2015


   o 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].

8.  Security Considerations

   There is no security consideration



9.  IANA Considerations

   There is no IANA consideration





10.  References

10.1.  Normative References

   [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
             September 1981.

   [RFC2119] Bradner, S., "Key words for use in RFCs to
             Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.


10.2.  Informative References

   [I-D.dunbar-i2rs-discover-traffic-rules]
                            Dunbar, L. and S. Hares, "An
                            Information Model for Filter
                            Rules for Discovery and
                            Traffic for I2RS
                            Filter-Based RIB",
                            draft-dunbar-i2rs-discover-traffic-rules-00
                            (work in progress), March
                            2015.

   [I-D.hares-i2rs-auth-trans] Hares, S.,
                               Migault, D., and J. Halpern, "I2RS
                               Security Related Requirements",
                               draft-hares-i2rs-auth-trans-04 (work in
                               progress), July 2015.

   [I-D.hares-i2rs-bnp-eca-data-model]
                                       Hares, S., Wu, Q., Tantsura, J.,


Hares & el.       Expires January 6, 2016                      [Page 34]


INTERNET DRAFT                            NFV Security      July 6, 2015

                                and R. White, "An Information
                                Model for Basic Network Policy
                                and Filter Rules",
                                draft-hares-i2rs-bnp-eca-data-model-00
                                (work in progress), July 2015.

   [I-D.hares-i2rs-info-model-service-topo]
                                            Hares, S., Wu, W., Wang, Z.,
                                            and J. You, "An Information
                                            model for service topology",
                                            draft-hares-i2rs-info-model-
                                            service-topo-03 (work in
                                            progress), January 2015.

   [I-D.ietf-i2rs-architecture] Atlas, A.,
                              Halpern, J., Hares, S., Ward, D., and T.
                              Nadeau, "An Architecture for the
                              Interface to the Routing System",
                              draft-ietf-i2rs-architecture-09 (work in
                              progress), March 2015.

   [I-D.ietf-i2rs-ephemeral-state] Haas,
                                   J. and S. Hares, "I2RS Ephemeral
                                   State Requirements",
                                   draft-ietf-i2rs-ephemeral-state-00
                                   (work in progress), June 2015.

   [I-D.ietf-i2rs-problem-statement]
                                   Atlas, A., Nadeau, T., and D. Ward,
                                     "Interface to the Routing System
                                     Problem Statement",
                                     draft-ietf-i2rs-
                                     problem-statement-06 (work in
                                     progress), January 2015.


   [I-D.ietf-i2rs-pub-sub-requirements]
                                        Voit, E., Clemm, A., and A.
                                        Prieto, "Requirements for
                                        Subscription to YANG
                                        Datastores",
                                        draft-ietf-i2rs-pub-sub-
                                        requirements-02 (work in
                                        progress), March 2015.

   [I-D.ietf-i2rs-rib-data-model] Wang,
                                  L., Ananthakrishnan, H., Chen, M.,
                                  amit.dass@ericsson.com, a., Kini, S.,
                                  and N. Bahadur, "A YANG Data Model for
                                  Routing Information Base (RIB)",
                                  draft-ietf-i2rs-rib-data-model-00
                                  (work in progress), April 2015.


Hares & el.       Expires January 6, 2016                      [Page 35]


INTERNET DRAFT                            NFV Security      July 6, 2015


   [I-D.ietf-i2rs-rib-info-model]
                                  Bahadur, N., Folkes, R., Kini, S., and
                                  J. Medved, "Routing Information Base
                                  Info Model", draft-ietf-i2rs-rib-info-
                                  model-06 (work in progress), March
                                  2015.

   [I-D.ietf-i2rs-traceability] Clarke, J.,
                                Salgueiro, G., and C. Pignataro,
                                "Interface to the Routing System (I2RS)
                                Traceability: Framework and Information
                                Model", draft-ietf-i2rs-traceability-03
                                (work in progress), May 2015.

   [I-D.ietf-i2rs-usecase-reqs-summary]
                                Hares, S. and M. Chen, "Summary
                                of I2RS Use Case Requirements",
                                draft-ietf-i2rs-usecase-reqs-summary-01
                                (work in progress), May 2015.


   [I-D.ietf-i2rs-yang-l2-network-topology]
                                Dong, J. and X. Wei, "A YANG
                                Data Model for Layer-2
                                Network Topologies",
                                draft-ietf-i2rs-yang-l2-network-
                                topology-00 (work in
                                progress), April 2015.


   [I-D.ietf-i2rs-yang-network-topo]
                                Clemm, A., Medved, J., Varga, R.,
                                Tkacik, T., Bahadur, N., and H.
                                Ananthakrishnan, "A Data Model for
                                Network Topologies",
                                draft-ietf-i2rs-yang-network-topo-01
                                (work in progress), June 2015.

   [I-D.ietf-isis-yang-isis-cfg]
                                 Litkowski, S., Yeung, D., Lindem, A.,
                                 Zhang, J., and L. Lhotka, "YANG Data
                                 Model for ISIS protocol", draft-ietf-
                                 isis-yang-isis-cfg-02 (work in
                                 progress), March 2015.

   [I-D.ietf-netconf-call-home] Watsen, K.,
                                "NETCONF Call Home and RESTCONF Call
                                Home", draft-ietf-netconf-call-home-06
                                (work in progress), May 2015.

   [I-D.ietf-netconf-restconf] Bierman, A.,
                               Bjorklund, M., and K. Watsen, "RESTCONF


Hares & el.       Expires January 6, 2016                      [Page 36]


INTERNET DRAFT                            NFV Security      July 6, 2015

                               Protocol", draft-ietf-netconf-restconf-04
                               (work in progress), January 2015.

   [I-D.ietf-netconf-restconf-collection]
                                          Bierman, A., Bjorklund, M.,
                                          and K. Watsen, "RESTCONF
                                          Collection Resource",
                                          draft-ietf-netconf-restconf-
                                          collection-00 (work in
                                          progress), January 2015.

   [I-D.ietf-netconf-zerotouch] Watsen, K.,
                                Clarke, J., and M. Abrahamsson, "Zero
                                Touch Provisioning for NETCONF Call Home
                                (ZeroTouch)", draft-
                                ietf-netconf-zerotouch-02 (work in
                                progress), March 2015.

   [I-D.ietf-netmod-acl-model] Bogdanovic,
                               D., Sreenivasa, K., Huang, L., and D.
                               Blair, "Network Access Control List (ACL)
                               YANG Data Model",
                               draft-ietf-netmod-acl-model-02 (work in
                               progress), March 2015.

   [I-D.ietf-netmod-routing-cfg] Lhotka,
                                 L. and A. Lindem, "A YANG Data Model
                                 for Routing Management",
                                 draft-ietf-netmod-routing-cfg-19 (work
                                 in progress), May 2015.

   [I-D.ietf-netmod-syslog-model] Wildes,
                                  C. and K. Sreenivasa, "SYSLOG YANG
                                  model", draft-
                                  ietf-netmod-syslog-model-03 (work in
                                  progress), March 2015.

   [I-D.ietf-ospf-yang] Yeung, D., Qu, Y., Zhang,
                        J., Bogdanovic, D., and K. Sreenivasa, "Yang
                        Data Model for OSPF Protocol", draft-
                        ietf-ospf-yang-00 (work in progress), March
                        2015.

   [I-D.ietf-pcp-authentication]
                                 Wasserman, M., Hartman, S., Zhang, D.,
                                 and T. Reddy, "Port Control Protocol
                                 (PCP) Authentication Mechanism", draft-
                                 ietf-pcp-authentication-09 (work in
                                 progress), May 2015.

   [I-D.ietf-pcp-optimize-keepalives]
                                      Reddy, T., Patil, P., Isomaki, M.,
                                      and D. Wing, "Optimizing NAT and


Hares & el.       Expires January 6, 2016                      [Page 37]


INTERNET DRAFT                            NFV Security      July 6, 2015

                                   Firewall Keepalives Using Port
                                   Control Protocol (PCP)",
                                   draft-ietf-pcp-optimize-keepalives-06
                                   (work in progress), May 2015.

   [I-D.ietf-pcp-proxy] Perreault, S., Boucadair,
                        M., Penno, R., Wing, D., and S. Cheshire, "Port
                        Control Protocol (PCP) Proxy Function",
                        draft-ietf-pcp-proxy-08 (work in progress), May
                        2015.

   [I-D.ietf-sacm-architecture] Cam-Winget,
                                N., Lorenzin, L., McDonald, I., and l.
                                loxx@cisco.com, "Secure Automation and
                                Continuous Monitoring (SACM)
                                Architecture", draft-ietf-sacm-
                                architecture-03 (work in progress),
                                March 2015.

   [I-D.ietf-sacm-terminology] Waltermire,
                               D., Montville, A., Harrington, D.,
                               Cam-Winget, N., Lu, J., Ford, B., and M.
                               Kaeo, "Terminology for Security
                               Assessment",
                               draft-ietf-sacm-terminology-06 (work in
                               progress), February 2015.

   [I-D.kini-i2rs-fb-rib-info-model]
                                     Kini, S., Hares, S., Ghanwani, A.,
                                     Krishnan, R., Wu, Q., Bogdanovic,
                                     D., Tantsura, J., and R. White,
                                     "Filter-Based RIB Information
                                     Model",
                                     draft-kini-i2rs-fb-rib-info-
                                     model-00 (work in progress), March
                                     2015.

   [I-D.l3vpn-service-yang] Litkowski, S.,
                            Shakir, R., Tomotaki, L., and K. D'Souza,
                            "YANG Data Model for L3VPN service
                            delivery", draft-l3vpn- service-yang-00
                            (work in progress), February 2015.

   [I-D.liu-bess-mvpn-yang] Liu, Y. and F. Guo,
                            "Yang Data Model for Multicast in MPLS/BGP
                            IP VPNs", draft-liu-bess-mvpn-yang-00 (work
                            in progress), April 2015.

   [I-D.shaikh-idr-bgp-model] Shaikh, A.,
                              D'Souza, K., Bansal, D., and R. Shakir,
                              "BGP Model for Service Provider Networks",
                              draft-shaikh-idr- bgp-model-01 (work in
                              progress), March 2015.


Hares & el.       Expires January 6, 2016                      [Page 38]


INTERNET DRAFT                            NFV Security      July 6, 2015


   [I-D.shaikh-rtgwg-policy-model]
                                   Shaikh, A., Shakir, R., D'Souza, K.,
                                   and C. Chase, "Routing Policy
                                   Configuration Model for Service
                                   Provider Networks",
                                   draft-shaikh-rtgwg-policy-model-01
                                   (work in progress), July 2015.

   [I-D.tsingh-bess-pbb-evpn-yang-cfg]
                                       Tiruveedhula, K., Singh, T.,
                                       Sajassi, A., Kumar, D., and L.
                                       Jalil, "YANG Data Model for PBB
                                       EVPN protocol", draft-
                                       tsingh-bess-pbb-evpn-yang-cfg-00
                                       (work in progress), March 2015.


                                   [I-D.zhang-i2rs-l1-topo-yang-model]
                                   Zhang, X., Rao, B., and X. Liu,
                                   "A YANG Data Model for Layer 1
                                   Network Topology",
                                   draft-zhang-i2rs-l1-topo-yang-
                                   model-01 (work in progress),
                                   March 2015.

   [I-D.zhdankin-idr-bgp-cfg] Alex, A.,
                              Patel, K., Clemm, A., Hares, S.,
                              Jethanandani, M., and X. Liu, "Yang Data
                              Model for BGP Protocol", draft-
                              zhdankin-idr-bgp-cfg-00 (work in
                              progress), January 2015.

   [I-D.zhuang-bess-evpn-yang] Zhuang, S.
                               and Z. Li, "Yang Model for Ethernet VPN",
                               draft-zhuang-bess-evpn-yang-00 (work in
                               progress), December 2014.

   [I-D.zhuang-bess-l3vpn-yang] Zhuang, S.
                                and Z. Li, "Yang Data Model for BGP/MPLS
                                IP VPNs",
                                draft-zhuang-bess-l3vpn-yang-00 (work in
                                progress), December 2014.

   [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S.,
             Rajan, R., and A. Sastry, "The COPS (Common Open Policy
             Service) Protocol", RFC 2748, January 2000.

   [RFC2940] Smith, A., Partain, D., and J. Seligson,
             "Definitions of Managed Objects for Common Open Policy
             Service (COPS) Protocol Clients", RFC 2940, October 2000.

   [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S.,


Hares & el.       Expires January 6, 2016                      [Page 39]


INTERNET DRAFT                            NFV Security      July 6, 2015

             McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R.,
             and A. Smith, "COPS Usage for Policy Provisioning
             (COPS-PR)", RFC 3084, March 2001.

   [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J.,
             Molitor, A., and A. Rayhan, "Middlebox communication
             architecture and framework", RFC 3303, August 2002.

   [RFC3304] Swale, R., Mart, P., Sijben, P., Brim, S., and M.
             Shore, "Middlebox Communications (midcom) Protocol
             Requirements", RFC 3304, August 2002.

   [RFC3483] Rawlins, D., Kulkarni, A., Bokaemper, M., and K.
             Chan, "Framework for Policy Usage Feedback for Common Open
             Policy Service with Policy Provisioning (COPS-PR)", RFC
             3483, March 2003.

   [RFC3484] Draves, R., "Default Address Selection for
             Internet Protocol version 6 (IPv6)", RFC 3484, February
             2003.

   [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and
             S. Van den Bosch, "Next Steps in Signaling (NSIS):
             Framework", RFC 4080, June 2005.

   [RFC4261] Walker, J. and A. Kulkarni, "Common Open Policy
             Service (COPS) Over Transport Layer Security (TLS)", RFC
             4261, December 2005.

   [RFC4949] Shirey, R., "Internet Security Glossary, Version
             2", RFC 4949, August 2007.

   [RFC5189] Stiemerling, M., Quittek, J., and T. Taylor,
             "Middlebox Communication (MIDCOM) Protocol Semantics", RFC
             5189, March 2008.

   [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
             Notifications", RFC 5277, July 2008.

   [RFC5539] Badra, M., "NETCONF over Transport Layer Security
             (TLS)", RFC 5539, May 2009.

   [RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E.
             Davies, "NAT/Firewall NSIS Signaling Layer Protocol
             (NSLP)", RFC 5973, October 2010.

   [RFC6022] Scott, M. and M. Bjorklund, "YANG Module for
             NETCONF Monitoring", RFC 6022, October 2010.

   [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and
             A. Bierman, "Network Configuration Protocol (NETCONF)", RFC
             6241, June 2011.



Hares & el.       Expires January 6, 2016                      [Page 40]


INTERNET DRAFT                            NFV Security      July 6, 2015

   [RFC6242] Wasserman, M., "Using the NETCONF Protocol over
             Secure Shell (SSH)", RFC 6242, June 2011.

   [RFC6243] Bierman, A. and B. Lengyel, "With-defaults
             Capability for NETCONF", RFC 6243, June 2011.

   [RFC6436] Amante, S., Carpenter, B., and S. Jiang,
             "Rationale for Update to the IPv6 Flow Label
             Specification", RFC 6436, November 2011.

   [RFC6470] Bierman, A., "Network Configuration Protocol
             (NETCONF) Base Notifications", RFC 6470, February 2012.

   [RFC6536] Bierman, A. and M. Bjorklund, "Network
             Configuration Protocol (NETCONF) Access Control Model", RFC
             6536, March 2012.

   [RFC6639] King, D. and M. Venkatesan, "Multiprotocol Label
             Switching Transport Profile (MPLS-TP) MIB-Based Management
             Overview", RFC 6639, June 2012.

   [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R.,
             and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
             April 2013.

   [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
             Management", RFC 7223, May 2014.

   [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes
             Using the Port Control Protocol (PCP)", RFC 7225, May 2014.

   [RFC7277] Bjorklund, M., "A YANG Data Model for IP
             Management", RFC 7277, June 2014.

   [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model
             for System Management", RFC 7317, August 2014.



















Hares & el.       Expires January 6, 2016                      [Page 41]


INTERNET DRAFT                            NFV Security      July 6, 2015

Authors' Addresses

      Susan Hares
      Huawei
      7453 Hickory Hill
      Saline, MI  48176
      USA
      Email: shares@ndzh.com


      Bob Moskowitz
      HTT Consulting
      Oak Park, MI  48237
      Email: rgm@labs.htt-consult.com


      Hosnieh Rafiee
      http://www.rozanak.com
      Munich, Germany
      Phone: +49 (0) 17657587575
      Email: ietf@rozanak.com


      Dacheng Zhang
      Beijing
      China
      Email: dacheng.zdc@aliabab-inc.com


























Hares & el.       Expires January 6, 2016                      [Page 42]