draft-ietf-i2nsf-gap-analysis-00.txt   draft-ietf-i2nsf-gap-analysis-01.txt 
I2NSF WG S. Hares I2NSF WG S. Hares
Internet-Draft R. Moskowitz Internet-Draft R. Moskowitz
Intended status: Standards Track Huawei Intended status: Informational Huawei
Expires: August 5, 2016 D. Zhang Expires: October 6, 2016 D. Zhang
February 2, 2016 April 4, 2016
Analysis of Existing work for I2NSF Analysis of Existing work for I2NSF
draft-ietf-i2nsf-gap-analysis-00.txt draft-ietf-i2nsf-gap-analysis-01.txt
Abstract Abstract
This document analyzes the status of the arts in industries and the This document analyzes the current state of the art for security
existing IETF work/protocols that are relevant to the Interface to management devices and security devices technologies in industries
Network Security Function (I2NSF). The I2NSF focus is to define data and the existing IETF work/protocols that are relevant to the
models and interfaces in order to control and monitor the physical Interface to Network Security Function (I2NSF). The I2NSF focus is
and virtual aspects of network security functions. 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 5, 2016. This Internet-Draft will expire on October 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
1.3. Terms and Definitions . . . . . . . . . . . . . . . . . . 5 1.3. Terms and Definitions . . . . . . . . . . . . . . . . . . 5
1.3.1. Requirements Terminology . . . . . . . . . . . . . . 5 1.3.1. Requirements Terminology . . . . . . . . . . . . . . 5
1.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 5 1.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 5
2. IETF Gap analysis . . . . . . . . . . . . . . . . . . . . . . 6 2. IETF Gap analysis . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Traffic Filters . . . . . . . . . . . . . . . . . . . . . 6 2.1. Traffic Filters . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Middle-box Filters . . . . . . . . . . . . . . . . . 9 2.1.2. Middle-box Filters . . . . . . . . . . . . . . . . . 9
2.1.3. Security Work . . . . . . . . . . . . . . . . . . . . 9 2.1.3. Security Work . . . . . . . . . . . . . . . . . . . . 9
3. ETSI NFV . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3. ETSI NFV . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. ETSI Overview . . . . . . . . . . . . . . . . . . . . . . 13 3.1. ETSI Overview . . . . . . . . . . . . . . . . . . . . . . 13
3.2. I2NSF Gap Analysis . . . . . . . . . . . . . . . . . . . 14 3.2. I2NSF Gap Analysis . . . . . . . . . . . . . . . . . . . 15
4. OPNFV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. OPNFV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. OPNFV Moon Project . . . . . . . . . . . . . . . . . . . 15 4.1. OPNFV Moon Project . . . . . . . . . . . . . . . . . . . 15
4.2. Gap Analysis for OPNFV Moon Project . . . . . . . . . . . 17 4.2. Gap Analysis for OPNFV Moon Project . . . . . . . . . . . 17
5. OpenStack Security Firewall . . . . . . . . . . . . . . . . . 17 5. OpenStack Security Firewall . . . . . . . . . . . . . . . . . 17
5.1. Overview of API for Security Group . . . . . . . . . . . 18 5.1. Overview of API for Security Group . . . . . . . . . . . 18
5.2. Overview of Firewalls as a Service . . . . . . . . . . . 18 5.2. Overview of Firewall as a Service . . . . . . . . . . . . 18
5.3. I2NSF Gap analysis . . . . . . . . . . . . . . . . . . . 19 5.3. I2NSF Gap analysis . . . . . . . . . . . . . . . . . . . 19
6. CSA Secure Cloud . . . . . . . . . . . . . . . . . . . . . . 19 6. CSA Secure Cloud . . . . . . . . . . . . . . . . . . . . . . 19
6.1. CSA Overview . . . . . . . . . . . . . . . . . . . . . . 19 6.1. CSA Overview . . . . . . . . . . . . . . . . . . . . . . 19
6.1.1. CSA Security as a Service(SaaS) . . . . . . . . . . . 20 6.1.1. CSA Security as a Service (SaaS) . . . . . . . . . . 20
6.1.2. Identity Access Management (IAM) . . . . . . . . . . 21 6.1.2. Identity Access Management (IAM) . . . . . . . . . . 21
6.1.3. Data Loss Prevention (DLP) . . . . . . . . . . . . . 22 6.1.3. Data Loss Prevention (DLP) . . . . . . . . . . . . . 22
6.1.4. Web security(Web)) . . . . . . . . . . . . . . . . . 23 6.1.4. Web Security (Web) . . . . . . . . . . . . . . . . . 23
6.1.5. Email Security (email)) . . . . . . . . . . . . . . . 24 6.1.5. Email Security (email)) . . . . . . . . . . . . . . . 24
6.1.6. Security Assessment . . . . . . . . . . . . . . . . . 25 6.1.6. Security Assessment . . . . . . . . . . . . . . . . . 25
6.1.7. Intrusion Detection . . . . . . . . . . . . . . . . . 26 6.1.7. Intrusion Detection . . . . . . . . . . . . . . . . . 26
6.1.8. Security Information and Event Management(SEIM) . . . 27 6.1.8. Security Information and Event Management(SIEM) . . . 27
6.1.9. Encryption . . . . . . . . . . . . . . . . . . . . . 28 6.1.9. Encryption . . . . . . . . . . . . . . . . . . . . . 28
6.1.10. Business Continuity and Disaster Recovery (BC/DR) . . 29 6.1.10. Business Continuity and Disaster Recovery (BC/DR) . . 29
6.1.11. Network Security Devices . . . . . . . . . . . . . . 30 6.1.11. Network Security Devices . . . . . . . . . . . . . . 30
6.2. I2NSF Gap Analysis . . . . . . . . . . . . . . . . . . . 31 6.2. I2NSF Gap Analysis . . . . . . . . . . . . . . . . . . . 31
7. In-depth Review of IETF protocols . . . . . . . . . . . . . . 31 7. In-depth Review of IETF protocols . . . . . . . . . . . . . . 31
7.1. NETCONF and RESTCONF . . . . . . . . . . . . . . . . . . 31 7.1. NETCONF and RESTCONF . . . . . . . . . . . . . . . . . . 31
7.2. I2RS Protocol . . . . . . . . . . . . . . . . . . . . . . 32 7.2. I2RS Protocol . . . . . . . . . . . . . . . . . . . . . . 32
7.3. NETMOD Yang modules . . . . . . . . . . . . . . . . . . . 33 7.3. NETMOD YANG modules . . . . . . . . . . . . . . . . . . . 33
7.4. COPS . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.4. COPS . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.5. PCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.5. PCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.6. NSIS - Next steps in Signalling . . . . . . . . . . . . . 35 7.6. NSIS - Next Steps in Signaling . . . . . . . . . . . . . 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 37
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
11.1. Normative References . . . . . . . . . . . . . . . . . . 36 11.1. Normative References . . . . . . . . . . . . . . . . . . 37
11.2. Informative References . . . . . . . . . . . . . . . . . 37 11.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
This documents provides a gap analysis for I2NSF. This documents provides a gap analysis for I2NSF.
1.1. What is I2NSF 1.1. What is I2NSF
The Network Security Function (NSF) in a network ensures integrity, A Network Security Function (NSF) ensures integrity, confidentiality
confidentiality and availability of network communications, detects and availability of network communications, detects unwanted
unwanted activity, and blocks out or at least mitigates the effects activity, and/or blocks out or at least mitigates the effects of
of unwanted activity. NSF devices are provided and consumed in unwanted activity. NSFs are provided and consumed in increasingly
increasingly diverse environments. For example, users of NSFs could diverse environments. For example, users of NSFs could consume
consume network security services offered on multiple security network security services offered on multiple security products
products hosted one or more service provider,their own enterprises, hosted one or more service provider,their own enterprises, or a
or a combination of the two. combination of the two.
The lack of standard interfaces to control and monitor the behaviour The lack of standard interfaces to control and monitor the behavior
of NSFs, makes it virtually impossible for security service providers of NSFs makes it virtually impossible for security service providers
to automate service offerings that utilize different security to automate service offerings that utilize different security
functions from multiple vendors. functions from multiple vendors.
The Interface to NSF devices (I2NSF) work proposes to standardize a The Interface to Network Service Functions (I2NSF) work proposes to
set of software interfaces and data modules to control and monitor standardize a set of software interfaces to control and monitor the
the physical and virtual NSFs. Since different security vendors physical and virtual NSFs. Since different security vendors support
support different features and functions, the I2NSF will focus on the different features and functions, the I2NSF will focus on the flow-
flow-based NSFs that provide treatment to packets or flows such found based NSFs that provide treatment to packets or flows such found in
in IPS/IDS devices, web filtering devices, flow filtering devices, IPS/IDS devices, web filtering devices, flow filtering devices, deep
deep packet inspection devices, pattern matching inspection devices, packet inspection devices, pattern matching inspection devices, and
and re-mediation devices. re-mediation devices.
There are two layers of interfaces envisioned in the I2NSF approach: There are two layers of interfaces envisioned in the I2NSF approach:
o The I2NSF Capability Layer specifies how to control and monitor o The I2NSF Capability Layer specifies how to control and monitor
NSFs at a functional implementation level. This the focus for NSFs at a functional implementation level. This is the focus for
this phase of the I2NSF Work. this phase of the I2NSF Work.
o The I2NSF Service Layer defines how the security policies of o The I2NSF Service Layer defines how the security policies of
clients may be expressed and monitored. The Service Layer is out clients may be expressed and monitored. The Service Layer is out
of scope for this phase of I2NSF's work. of scope for this phase of I2NSF's work.
For the I2NSF capability layer, the I2NSF work proposes an For the I2NSF Capability Layer, the I2NSF work proposes an
interoperable protocol that passes NSF provisioning rules and interoperable protocol that passes NSF provisioning rules and
orchestration information between I2NSF client on a network manager orchestration information between the I2NSF client on a network
and I2NSF agent on an NSF device. It is envisioned that clients of manager and the I2NSF agent on an NSF. It is envisioned that clients
the I2NSF interfaces include management applications, service of the I2NSF interfaces include management applications, service
orchestration systems, network controllers, or user applications that orchestration systems, network controllers, or user applications that
may solicit network security resources. may solicit network security resources.
The I2NSF work to define this protocol includes the following work: The I2NSF work to define this protocol includes the following work:
o defining an informational model that defines the concepts for o defining an informational model that defines the concepts for
standardizing the control and monitoring of NSFs, standardizing the control and monitoring of NSFs,
o defining a set of Yang data models from the information model that o defining a set of YANG data models from the information model that
identifies the data that must be passed, identifies the data that must be passed,
o creating a capability registry (an IANA registry) that identifies o creating a capability registry (an IANA registry) that identifies
the characteristics and behaviours of NSFs in vendor-neutral the characteristics and behaviours of NSFs in vendor-neutral
vocabulary without requiring the NSFs to be standardized. vocabulary without requiring the NSFs to be standardized.
o examining existing secure communication mechanisms to identify the o examining existing secure communication mechanisms to identify the
appropriate ones for carrying the data that provisions and appropriate ones for carrying the data that provisions and
monitors information between the NSFs and their management entity monitors information between the NSFs and their management entity
(or entities). (or entities).
1.2. Structure of this Document 1.2. Structure of this Document
This document provides a analysis of the gaps in the state of art in This document provides an analysis of the gaps in the state of art in
the following industry forums: the following industry forums:
IETF working groups (section 2) IETF working groups (Section 2)
ETSI Network Functions Virtualization Industry Specification Group ETSI Network Functions Virtualization Industry Specification Group
(ETSI NFV ISG), (section 3) (ETSI NFV ISG), (Section 3)
OPNFV Open Source Group (section 4) OPNFV Open Source Group (Section 4)
Open Stack - Firewall as a service (OpenStack Firewall FaaS) Open Stack - Firewall as a service (OpenStack Firewall FaaS)
(section 5) (http://docs.openstack.org/admin-guide-cloud/content/ (Section 5) (http://docs.openstack.org/admin-guide-cloud/content/
install_neutron-fwaas-agent.html) install_neutron-fwaas-agent.html)
Cloud Security Alliance Security (CSA)as a Service (section 6) Cloud Security Alliance Security (CSA)as a Service (Section 6)
(https://cloudsecurityalliance.org/research/secaas/#_overview) (https://cloudsecurityalliance.org/research/secaas/#_overview)
In-Depth Review of Some IETF Protocols (section 7) In-Depth Review of Some IETF Protocols (Section 7)
1.3. Terms and Definitions 1.3. Terms and Definitions
1.3.1. Requirements Terminology 1.3.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119, BCP 14 document are to be interpreted as described in RFC 2119, BCP 14
[RFC2119] and indicate requirement levels for compliant CoAP. [RFC2119] and indicate requirement levels for compliant CoAP.
1.3.2. Definitions 1.3.2. Definitions
NSF: Network security function. An NSF is a function that that The following are a few definitions out of the terminology draft
detects unwanted activity and blocks/mitigates the effect of such utilized in this draft. For additional definitions please see:
unwanted activity in order to support availability of a network. [I-D.hares-i2nsf-terminology].
In addition, the NSF can help in supporting communication stream
integrity and confidentiality.
Cloud Data Center (DC): A data center that is not on premises of Network Security Function (NSF): is a function that is provided as
enterprises, but has compute/storage resources that can be a set of security-related service function. Typically, an NSF may
requested or purchased by the enterprises. The enterprise is be responsible for detecting unwanted activity and blocking/
actually getting a virtual data center. The Cloud Security mitigating the effect of such unwanted activity in order to fulfil
Alliance (CSA) (http://cloudsecurityalliance.org) focus on adding the service requirements. The NSF can help in supporting
security to this environment. A specific research topic is communication stream integrity and confidentiality.
security as a service within the cloud data center.
Cloud-based security functions: Network Security Function (NSF) Cloud Data Center (DC): A data center that may/may not be run on
hosted and managed by service providers or different the premises of enterprises, but has compute/storage resources
that can be requested or purchased by the enterprises. The
enterprise is actually getting a virtual data center. The Cloud
Security Alliance (CSA) (http://cloudsecurityalliance.org) focuses
on adding security to this environment. A specific research topic
is security as a service within the cloud data center.
Cloud-based security functions: Network Security Functions (NSFs)
that may be hosted and managed by service providers or a different
administrative entity. administrative entity.
Domain: The term Domain in this draft has the following different Domain: The term Domain in this draft has the following different
connotations in different scenarios: connotations in different scenarios:
* Client--Provider relationship, i.e. client requesting some * Client--Provider relationship, i.e. client requesting some
network security functions from its provider; network security functions from its provider;
* Domain A - Domain B relationship, i.e. one operator domain * Domain A - Domain B relationship, i.e. one operator domain
requesting some network security functions from another requesting some network security functions from another
operator domain; or operator domain; or
* Applications -- Network relationship, i.e. an application (e.g. * Applications -- Network relationship, i.e. an application (e.g.
cluster of servers) requesting some functions from network, cluster of servers) requesting some functions from network,
etc. etc.
The domain context is important because it indicates the The domain context is important because it indicates the
interactions the security is focused on. interactions the security is focused on.
I2NSF agent: a piece of software in a device that implements a I2NSF server/agent: A software instance that implements a network
network security function which receives provisioning information security function that receives provisioning information and
and requests for operational data (monitoring data) across the requests operational data (e.g. monitoring data) from an I2NSF
I2NSF protocol from an I2NSF client. client. It is also responsible for enforcing the policies that it
receives from an I2NSF client.
I2NSF client: A security client software that utilizes the I2NSF I2NSF client: A security client software that utilizes the I2NSF
protocol to read, write or change the provisioning network protocol to read, write or change the provisioning network
security device via software interface using the I2NSF protocol security device via software interface using the I2NSF protocol
(denoted as I2RS Agent) (denoted as I2RS Agent)
I2NSF Management System: I2NSF client operates within an network I2NSF Management System: I2NSF Client operates within an network
management system which serves as a collections and distribution management system which serves as a collections and distribution
point for security provisioning and filter data. This management point for security provisioning and filter data.
system is denoted as I2NS management system in this document.
Virtual Security Function: is a security function that can be
requested by one domain but may be owned or managed by another
domain.
2. IETF Gap analysis 2. IETF Gap analysis
The IETF gap analysis first examines the IETF mechanisms which have The IETF gap analysis first examines the IETF mechanisms which have
been developed to secure the IP traffic flows through a network. been developed to secure the IP traffic flows through a network.
Traffic filters have been defined by IETF specifications at the Traffic filters have been defined by IETF specifications at the
access points, the middle-boxes, or the routing systems. Protocols access points, the middle-boxes, or the routing systems. Protocols
have been defined to carry provisioning and filtering traffic between have been defined to carry provisioning and filtering traffic between
a management system and an IP system (router or host system). a management system and an IP system (router or host system).
Current security work (SACM working group (WG), MILE WG, and DOTS WG) Current security work (SACM working group (WG), MILE WG, and DOTS WG)
skipping to change at page 6, line 44 skipping to change at page 6, line 46
2.1. Traffic Filters 2.1. Traffic Filters
2.1.1. Overview 2.1.1. Overview
The earliest filters defined by IETF were access filters which The earliest filters defined by IETF were access filters which
controlled the acceptance of IP packet data flows. Additional policy controlled the acceptance of IP packet data flows. Additional policy
filters were created as part of the following protocols: filters were created as part of the following protocols:
o COPS protocol [RFC2748] for controlling access to networks, o COPS protocol [RFC2748] for controlling access to networks,
o Next steps in Signalling (NSIS) work (architecture: [RFC4080] o Next Steps in Signalling (NSIS) work (architecture: [RFC4080]
protocol: [RFC5973]), and protocol: [RFC5973]) - for supporting signaling about a data flow
along its path, and
o the Port Control Protocol (PCP) to enables IPv4 to IPv6 flexible o Port Control Protocol (PCP) - allows the IPv4/IPv6 host to control
address and port mapping for NATs and Firewalls, how IPv6/IPv4 packets are translated and forwarded by NATS and
firewalls.
Today NETMOD and I2RS Working groups are specifying additional Today NETMOD and I2RS Working groups are specifying additional
filters in Yang modules to be used as part of the NETCONF or I2RS filters in YANG modules to be used as part of the NETCONF or I2RS
enhancement of NETCONF/RESTCONF. enhancement of NETCONF/RESTCONF.
The routing filtering is outside the scope of the flow filtering, but Route filtering is outside the scope of the flow filtering, but the
flow filtering may be impacted by route filtering. An initial model flow filtering may be impacted by route filtering. An initial model
for the routing policy is in [I-D.shaikh-rtgwg-policy-model] for routing policy is in [I-D.ietf-rtgwg-policy-model]
This section provides an overview of the flow filtering as an This section provides an overview of the flow filtering as an
introduction to the I2NSF GAP analysis. Additional detail on introduction to the I2NSF Gap analysis. Additional detail on
NETCONF, NETMOD, I2RS, PCP, and NSIS is available in the Detailed NETCONF, NETMOD, I2RS, PCP, and NSIS is available in Section 7.
I2NSF analysis.
2.1.1.1. Data Flow Filters in NETMOD and I2RS 2.1.1.1. Data Flow Filters in NETMOD and I2RS
The current work on expanding these filters is focused oncombining a The current work on expanding these filters is focused oncombining a
configuration and monitoring protocol with Yang data models. configuration and monitoring protocol with YANG data models.
[I-D.ietf-netmod-acl-model] provides a set of access lists filters [I-D.ietf-netmod-acl-model] provides a set of access list filters
which can permit or deny traffic flow based on headers at the MAC, IP which can permit or deny traffic flow based on headers at the MAC
layer, and Transport layer. The configuration and monitoring Layer, IP Layer, and Transport Layer. The configuration and
protocols which can pass the filters are: NETCONF protocol [RFC6241], monitoring protocols which can pass the filters are: NETCONF protocol
RESTCONF [I-D.ietf-netconf-restconf], and the I2RS protocol. The [RFC6241], RESTCONF [I-D.ietf-netconf-restconf], and the I2RS
NETCONF and RESTCONF protocols install these filters into forwarding protocol. The NETCONF and RESTCONF protocols install these filters
tables. The I2RS protocol uses the ACLs as part of the filters into forwarding tables. The I2RS protocol uses the ACLs as part of
installed in an ephemeral protocol-independent filter-based RIB the filters installed in an ephemeral protocol-independent filter-
[I-D.kini-i2rs-fb-rib-info-model] which controls the flow of traffic based RIB [I-D.kini-i2rs-fb-rib-info-model] which controls the flow
on interfaces specifically controlled by the I2RS filter-based FIB. of traffic on interfaces specifically controlled by the I2RS filter-
based FIB.
netconf netconf
+---------------+ / \ +---------------+ +---------------+ / \ +---------------+
| Device: ACLs |-- / \---|Device: ACLS | | Device: ACLs |-- / \---|Device: ACLS |
| I2RS FB RIB | | I2RS FIB RIB | | I2RS FB RIB | | I2RS FIB RIB |
|routing policy | | routing policy| |routing policy | | routing policy|
| | | | | | | |
===|===============|=============|===============|= ===|===============|=============|===============|=
+---------------+ data flow +---------------+ +---------------+ data flow +---------------+
Figure 1 Figure 1
The I2RS protocol is a programmatic interface to the routing system. The I2RS protocol is a programmatic interface to the routing system.
At this time, the I2RS is targeted to be extensions to the NETCONF/ At this time, the I2RS is targeted to be extensions to the NETCONF/
RESTCONF protocols to allow the NETCONF/RESTCONF protocol to support RESTCONF protocols to allow the NETCONF/RESTCONF protocol to support
a highly programmatic interface with high bandwidth of data, highly a highly programmatic interface with high bandwidth of data, highly
reliable notifications, and ephemeral state (see reliable notifications, and ephemeral state (see
[I-D.ietf-i2rs-architecture]). Please see the background section on [I-D.ietf-i2rs-architecture]). See Section 7.2 on I2RS for
I2RS for additional details on the requirements for this extension to additional details on I2RS.
the NETCONF/RESTCONF protocol suite.
The vocabulary set in [I-D.ietf-netmod-acl-model] is limited, so The vocabulary of the [I-D.ietf-netmod-acl-model] is limited, so
additional protocol independent filters were written for the I2RS additional protocol independent filters has been written for the I2RS
Filter-Based RIBs in [I-D.hares-i2rs-bnp-eca-data-model]. Filter-Based RIBs in [I-D.hares-i2rs-pkt-eca-data-model].
One thing important to note is that NETCONF and RESTCONF manage One thing important to note is that NETCONF and RESTCONF manage
device layer yang models. However, as figure 2 shows, there are device layer YANG models. However, as Figure 2 shows, there are
multiple device level, network-wide level, and application level yang multiple device level, network-wide level, and application level YANG
modules. The access lists defined by the device level forwarding modules. The access lists defined by the device level forwarding
table may be impacted by the routing protocols, the I2RS ephemeral table may be impacted by the routing protocols, the I2RS ephemeral
protocol independent Filter-Based FIB, or some network-wide security protocol independent Filter-Based FIB, or some network-wide security
issue (IPS/IDS). issue (IPS/IDS).
+--------------------------------------------+ +--------------------------------------------+
|Application Network Wide: Intent | |Application Network Wide: Intent |
+--------------------------------------------+ +--------------------------------------------+
|Network-wide level: L3SM L3VPN service model| |Network-wide level: L3SM L3VPN service model|
+--------------------------------------------+ +--------------------------------------------+
|Device level: Protocol Independent: I2RS | |Device level: Protocol Independent: I2RS |
| RIB, Topology, Filter-Based RIB | | RIB, Topology, Filter-Based RIB |
+--------------------------------------------+ +--------------------------------------------+
|Device Level:Protocol Yang modules | |Device Level:Protocol YANG modules |
| (ISIS, OSPF, BGP, EVPN, L2VPN, L3VPN, etc.) | (ISIS, OSPF, BGP, EVPN, L2VPN, L3VPN, etc.)
+--------------------------------------------+ +--------------------------------------------+
| Device level: IP and System: NETMOD Models | | Device level: IP and System: NETMOD Models |
| (config and oper-state), tunnels, | | (config and oper-state), tunnels, |
| forwarding filters | | forwarding filters |
+--------------------------------------------+ +--------------------------------------------+
Figure 2 levels of Yang modules Figure 2 Levels of YANG modules
2.1.1.2. I2NSF Gap analysis 2.1.1.2. I2NSF Gap analysis
The gap is that none of the current work on these filters considers 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, all the variations of data necessary to do IPS/IDS, web-filters,
stateful flow-based filtering, security-based deep packet inspection, stateful flow-based filtering, security-based deep packet inspection,
or pattern matching with re-mediation. The I2RS Filter-Based RIB or pattern matching with re-mediation. The I2RS Filter-Based RIB
work is the closest associated work, but the focus has not been on work is the closest associated work, but the focus has not been on
IDS/IPS, web-filters, security-based deep packet inspection, or IDS/IPS, web-filters, security-based deep packet inspection, or
pattern matching with re-mediation. pattern matching with re-mediation.
The I2RS Working group (I2RS WG) is focused on the routing system so The I2RS Working group (I2RS WG) is focused on the routing system so
security expertise for these IDP/IPS, Web-filter, security-based the requisite security expertise for such NSFs (IDP/IPS, Web-filter,
deep-packet inspection has not been targeted for this WG. security-based deep-packet inspection, etc.) has not been targeted
for this WG.
Another gap is there is no capability registry (an IANA registry) Another gap is there is no capability registry (an IANA registry)
that identifies the characteristics and behaviours of NSFs in vendor- that identifies the characteristics and behaviours of NSFs in vendor-
neutral vocabulary without requiring the NSFs to be standardized. neutral vocabulary without requiring the NSFs to be standardized.
What I2NSF can use from NETCONF/RESTCONF and I2RS What I2NSF can use from NETCONF/RESTCONF and I2RS
I2NSF should consider using NETCONF/RESTCONF protocol and the I2RS I2NSF should consider using NETCONF/RESTCONF protocol and the I2RS
proposed enhancement to the NETCONF/RESTCONF protocol. proposed enhancement to the NETCONF/RESTCONF protocol.
2.1.2. Middle-box Filters 2.1.2. Middle-box Filters
2.1.2.1. Midcom 2.1.2.1. Midcom
Midcom Summary: MIDCOM developed the protocols for applications to Midcom Summary: MIDCOM developed the protocols for applications to
communicate with middle boxes. However, MIDCOM have not used by the communicate with middle boxes. However, MIDCOM have not been used by
industry for a long time. This is because there was a lot of IPR the industry for a long time. A main reason is that MIDCOM had a lot
encumbered technology and IPR was likely a bigger problem for IETF of IPR encumbered technology and IPR was likely a bigger problem for
than it is today. MIDCOM is not specific to SIP. It was very much IETF at that time than it is today. MIDCOM is not specific to SIP.
oriented to NAT/FW devices. SIP was just one application that needed It was very much oriented to NAT/FW devices. SIP was just one
the functionality. MIDCOM is reservation-oriented and there was an application that needed the functionality. MIDCOM is reservation-
expectation that the primary deployment environment would be VoIP and oriented and there was an expectation that the primary deployment
real-time conferencing, including SIP, H.323, and other reservation- environment would be VoIP and real-time conferencing, including SIP,
oriented protocols. There was an assumption that there would be some H.323, and other reservation-oriented protocols. There was an
authoritative service that would have a view into endpoint sessions assumption that there would be some authoritative service that would
and be able to authorize (or not) resource allocation requests. In have a view into endpoint sessions and be able to authorize (or not)
other word, there's a trust model there that may not be applicable to resource allocation requests. In other words, there is a trust model
endpoint-driven requests without some sort of trusted authorization in MIDCOM that may not be applicable to endpoint-driven requests
mechanisms/tools. Therefore, there is a specific information model without some sort of trusted authorization mechanisms/tools.
applied to security devices, and security device requests, that was Therefore, there is a specific information model applied to security
developed in the context of an SNMP MIB. There is also a two-stage devices, and security device requests, that was developed in the
reservation model, which was specified in order to allow better context of an SNMP MIB. There is also a two-stage reservation model,
resource management. which was specified in order to allow better resource management.
Why I2NSF is different than Midcom Why I2NSF is Different from Midcom
MIDCOM is different than I2NSF because its SNMP scheme doesn't work MIDCOM is different from I2NSF because its SNMP scheme does not work
with the virtual network security functions (vNSF) management. with the virtual network security functions (vNSF) management.
MidCom RFCs: MidCom RFCs:
[RFC3303] - Midcom architecture [RFC3303] - Midcom architecture
[RFC5189] - Midcom Protocol Semantics [RFC5189] - Midcom Protocol Semantics
[RFC3304] - Midcom protocol requirements [RFC3304] - Midcom protocol requirements
skipping to change at page 10, line 18 skipping to change at page 10, line 18
flow filtering, deep packet inspection, or pattern matching and re- flow filtering, deep packet inspection, or pattern matching and re-
mediation. These flow-based security devices are managed and mediation. These flow-based security devices are managed and
provisioned by network management systems. provisioned by network management systems.
No standardized set of interoperable interfaces control and manage No standardized set of interoperable interfaces control and manage
the NSFs so that a central management system can be used across the NSFs so that a central management system can be used across
security devices from multiple Vendors. I2NSF work plan is to security devices from multiple Vendors. I2NSF work plan is to
standardize a set of interfaces by which control and management of standardize a set of interfaces by which control and management of
NSFs may be invoked, operated, and monitored by: NSFs may be invoked, operated, and monitored by:
creating an information model that defines concepts required for Creating an information model that defines concepts required for
standardizing the control and monitoring of NSFs, and from the standardizing the control and monitoring of NSFs, and from the
information model create data models. (The information model will information model create data models. (The information model will
be used to get early agreement on key technical points.) be used to get early agreement on key technical points.)
creating a capability registry (at IANA) that enables the Creating a capability registry (at IANA) that enables the
characteristics and behavior of NSFs to be specified using a characteristics and behavior of NSFs to be specified using a
vendor-neutral vocabulary without requiring the NSFs themselves to vendor-neutral vocabulary without requiring the NSFs themselves to
be standardized. be standardized.
define the requirements for an I2NSF protocol to pass this Defining the requirements for an I2NSF protocol to pass this
traffic. (Hopefully re-using existing protocols.) traffic. (Ideally by re-using existing protocols.)
The flow-filtering configuration and management must fit into the The flow-filtering configuration and management must fit into the
existing security area's work plan. This section considers how the existing security area's work plan. This section considers how the
I2NSF fits into the security area work under way in the SACM I2NSF fits into the security area work under way in the SACM
(security automation and control), DOTS (DDoS Open Threat (Security Automation and Continuous Monitoring), DOTS (DDoS Open
Signalling), and MILE (Management Incident Lightweight Exchange). Threat Signalling), and MILE (Management Incident Lightweight
Exchange).
2.1.3.2. Security Work and Filters 2.1.3.2. Security Work and Filters
In the proposed I2NSF work plan, the I2NSF security network In the proposed I2NSF work plan, the I2NSF security network
management system controls many NSF nodes via the I2NSF Agent. This 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. control of data flows is similar to the COPS example in Section 7.4.
+------------+ +------------+
| I2NSF | | I2NSF |
| Client | | Client |
| | | |
| security | | security |
| NMS system | | NMS system |
+------------+ +------------+
+-----+ / \ +-----+ +-----+ / \ +-----+
|I2NSF|--/ \---|I2NSF| |I2NSF|--/ \---|I2NSF|
skipping to change at page 11, line 39 skipping to change at page 11, line 39
and/or status of hardware or software on an endpoint as it and/or status of hardware or software on an endpoint as it
pertains to an organization's security policy. Filters can be pertains to an organization's security policy. Filters can be
considered on the configuration or status pieces that needs to be considered on the configuration or status pieces that needs to be
monitored. monitored.
o DOTS (DDoS Open Threat Signalling) - is working on coordinating o DOTS (DDoS Open Threat Signalling) - is working on coordinating
the mitigation of DDoS attacks. A part of DDoS attach mitigation the mitigation of DDoS attacks. A part of DDoS attach mitigation
is to provide lists of addresses to be filtered via IP header is to provide lists of addresses to be filtered via IP header
filters. filters.
o MILE (Managed Incident LIghtweight Exchange) - is working on o MILE (Managed Incident Lightweight Exchange) - is working on
creating a standardized format for incident and indicator reports, creating a standardized format for incident and indicator reports,
and creating a protocol to transport this information. The and creating a protocol to transport this information. The
incident information MILE collects may cause changes in data-flow incident information MILE collects may cause changes in data-flow
filters on one or more NSFs. filters on one or more NSFs.
2.1.3.3. I2NSF interaction 2.1.3.3. I2NSF interaction
The network management system that the I2NSF client resides on may The network management system that the I2NSF client resides on may
interact with other clients or agents developed for the work ongoing interact with other clients or agents developed for the work ongoing
in the SACM, DOTS, and MILES working groups. This section describes in the SACM, DOTS, and MILES working groups. This section describes
skipping to change at page 12, line 34 skipping to change at page 12, line 34
| | |Agent|-------+ | | |Agent|-------+
--| ----|----------------|-----|----- --| ----|----------------|-----|-----
+-----+ data flow +-----+ +-----+ data flow +-----+
*1 - this is the SACM Controller (CR) with *1 - this is the SACM Controller (CR) with
its broker/proxy/repository show as its broker/proxy/repository show as
described in the SACM architecture. described in the SACM architecture.
Figure 3 Figure 3
Figure 3 provides a diagram of a system the I2NSF, SACM, DOTS and Figure 3 provides a diagram of a system in which the I2NSF, SACM,
MILES client-agent or consumer-broker-provider are deployed together. DOTS and MILE client-agent or consumer-broker-provider are deployed
The following are possible positive interactions these scenario might together. The following are possible positive interactions these
have: scenario might have:
o An security network management system (NMS) can contain a SACM o An security network management system (NMS) can contain a SACM
repository and be connected to SACM information provider and a repository and be connected to SACM information providers and SACM
SACM consumer. The I2NSF may provide one of the ways to change consumers. The I2NSF may provide one of the ways to change the
the forwarding filters. forwarding filters.
o The security NMS may also be connected to DOTS DDoS clients o The security NMS may also be connected to DOTS DDoS clients
managing the information and configuring the rules. The I2NSF may managing the information and configuring the rules. The I2NSF may
provide one of the ways to change forwarding filters. provide one of the ways to change forwarding filters.
o The MILES client on a security network management system talking o The MILE client on a security network management system talking to
to the MILES agent on the node may react to the incidents by using the MILE agent on the node may react to the incidents by using
I2NSF to set filters. DOTS creates black-lists, but does not have I2NSF to set filters. DOTS creates black-lists, but does not have
a complete set of filters. a complete set of filters.
2.1.3.4. Benefits from the Interaction 2.1.3.4. Benefits from the Interaction
I2NSF's ability to provide a common interoperable and vendor neutral I2NSF's ability to provide a common interoperable and vendor neutral
interface may allow the security NMS to use a single change to change interface may allow the security NMS to use a single change to change
filters. SACM provides an information model to describe end-points, filters. SACM provides an information model to describe end-points,
but does not link this directly to filters. but does not link this directly to filters.
DOTS creates black-lists based on source and destination IP address, DOTS creates black-lists based on source and destination IP address,
transport port number, protocol ID, and traffic rate. Like NETMOD's, transport port number, protocol ID, and traffic rate. Like ACLs
ACLS are not sufficient for all filters or control desired by the NSF defined NETMOD, the DOTS black-lists are not sufficient for all
boxes. filters or control desired by the NSF boxes.
The incident data captured by MILES will not have enough filter The incident data captured by MILE will not have enough filter
information to provide NSF devices with general services. The I2NSF information to provide NSF devices with general services. The I2NSF
will be able to handle the MILE incident data and create alerts or will be able to handle the MILE incident data and create alerts or
reports for other security systems. reports for other security systems.
3. ETSI NFV 3. ETSI NFV
3.1. ETSI Overview 3.1. ETSI Overview
Network Function Virtualization (NFV) provides the service providers Network Functions Virtualization (NFV) provides service providers
with flexibility, cost effective and agility to offer their services with flexibility, cost effective and agility to offer their services
to customers. One such service is the network security function to customers. One such service is the network security function
which guards the exterior of a service provider or its customers. which guards the exterior of a service provider or its customers.
However, the exterior network beyond the service provider NSFs or its
customer's NSFs is becoming extremely narrow as NSFs are becoming
more pervasive in any portion of networks (service providers,
customers, or access networks).
The flexibility and agility of NFV encourages service providers to The flexibility and agility of NFV encourages service providers to
provide different products to address business trends in their market provide different products to address business trends in their market
to provide better service offerings to their end user. A traditional to provide better service offerings to their end user. A traditional
product such as the network security function (NSF) may be broken product such as the network security function (NSF) may be broken
into multiple virtual devices each hosted from another vendor. In into multiple virtual devices each hosted from another vendor. In
the past, network security devices may have been single sourced from the past, network security devices may have been sourced from a small
a small set of vendors - but in the NFV version of NSF devices, this set of vendors - but in the NFV version of NSF devices, this reduced
reduced set of sources will not provide a competitive edge. Due to set of sources will not provide a competitive edge. Due to this
this market shift, the network security device vendors are realizing market shift, the network security vendors are realizing that the
that the proprietary provisioning protocols and formats of data may proprietary provisioning protocols and formats of data may be a
be a liability. Out of the NFV work has arisen a desire for a single liability. Out of the NFV work has arisen a desire for a single
interoperable network security device provisioning and control interoperable network security device provisioning and control
protocol. protocol.
The I2NSF will be deployed along networks using other security and The I2NSF framework is complementary to the NFV and other security
NFV technology. As section 3 described, the NFV NSF security is frameworks. The I2NSF management protocol will be deployed in
deployed along side other security functions (AAA, SACM, DOTS, and networks to provide a common management protocol to manage NSF
MILE devices) or deep-packet-inspection. The ETSI Network Functions software/devices whether the devices are physical or virtual. The
Virtualization: NFV security: Security and Trust guidance document ETSI NFV security is also deployed along-side other security
(ETSI NFV SEC 003 1.1.1 (2014-12)) indicates that multiple functions (AAA, SACM, DOTS, or MILE devices) and deep-packet stateful
administrative domains will deployed in carrier networks. One inspections.
example of these multiple domains is hosting of multiple tenant
domains (telecom service providers) on a single infrastructure domain The ETSI Network Functions Virtualization: NFV security: Security and
(infrastructure service) as figure 4 shows. The ETSI Inter inter- Trust Guidance document (ETSI NFV SEC 003 1.1.1 (2014-12)) indicates
VNFM document (aka Ve-Vnfn) between the element management system and that multiple administrative domains will deployed in carrier
the Virtual network function is the equivalent of the interface networks. One example of these multiple domains is hosting of
between the I2NSF client on a management system and the I2NSF agent multiple tenant domains (telecom service providers) on a single
on the network security feature VNF. infrastructure domain (infrastructure service) as Figure 4 shows.
The ETSI Inter-VNFM document (aka Ve-Vnfn) between the element
management system and the Virtual network function is the equivalent
of the interface between the I2NSF client on a management system and
the I2NSF agent on the network security feature VNF.
.................... ....................
+--: OSS/BSS : +--: OSS/BSS :
| .................... | ....................
| |
| +-------------------------+ | +-------------------------+
| | | | | |
| | ........ ........ | | | ........ ........ |
| | : EMS1 : : EMS : | ETSI inter-VNFM | | : EMS1 : : EMS : | ETSI inter-VNFM
| | ....||... ...||... | (Ve-Vnfn) | | ....||... ...||... | (Ve-Vnfn)
skipping to change at page 14, line 39 skipping to change at page 14, line 47
| | +=====================+ --------- | | +=====================+ ---------
| | | virtualization layer| | | | | virtualization layer| |
| | +=====================+ | | | +=====================+ |
| | ........... .......... .......... | | | ........... .......... .......... |
|====:computing: :storage : :network : | |====:computing: :storage : :network : |
| :hardware : :hardware: :hardware: | | :hardware : :hardware: :hardware: |
| ........... .......... .......... | | ........... .......... .......... |
| hardware resources | | hardware resources |
+-----------------------------------+ +-----------------------------------+
figure 4 Figure 4
The ETSI proof of concept work has worked on the following security The ETSI proof-of-concept demonstrations have been done for the
proof of concepts: security proof of concepts:
o #16 - NFVIaas with Secure, SDN controlled WAN Gateway, o #16 - NFVIaaS with Secure, SDN controlled WAN Gateway,
3.2. I2NSF Gap Analysis 3.2. I2NSF Gap Analysis
The I2NSF will be deployed on top of virtual computing linked The I2NSF protocol/interface can be deployed for security devices
together by virtual routers configured by NETCONF/RESTCONF or I2RS along-side the network/host configuration done by NETCONF/RESTCONF or
which provision and monitoring the L1, L2, l3 and service pathways the routing system interface provided by I2RS that handles.
through the network.
In the NFV-related productions, the current architecture does not In the current NFV-related architecture, there is no interoperable
have a protocol to maintain an interoperability provisioning from protocol defined between a security manager and various NSF devices
I2NSF client to I2NSF agent. The result is that service providers to provision security functions. The result is that service
have to manage the interoperability using private protocols. In providers have to manage the interoperability security manager and
response to this problem, the device manufacturers and the service different NSF devices using proprietary protocols. In response to
providers have begun to discuss an I2NSF protocol for interoperable this problem, the device manufacturers and the service providers have
passing of provisioning and filter in formation. 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 Open source work (such as OPNFV) provides a common code base on which
providers to start their NFV work from. However, this code base providers may start their NFV development work. However, this code
faces the same problem. There is no defacto standard protocol. base faces the same problem. There is no defacto standard protocol.
4. OPNFV 4. OPNFV
The OPNFV (www.opnfv.org) is a carrier-grade integrated, open source The OPNFV (www.opnfv.org) is a carrier-grade integrated, open source
platform focused on accelerating the introduction of new Network platform focused on accelerating the introduction of new Network
Function Virtualization (NFV) products and service. The OPNFV Moon Functions Virtualization (NFV) products and service. The OPNFV Moon
project is focused on adding the security interface for a network project is focused on adding the security interface for a network
management system within the Tenant NFVs and the infrastructure NFVs management system within the tenant NFVs and the infrastructure NFVs
(as shown in figure 4). This section provides an overview of the (as shown in Figure 4). This section provides an overview of the
OPNFV Moon project and a gap analysis between I2NSF and the OPNFV OPNFV Moon project and a gap analysis between I2NSF and the OPNFV
Moon Project. Moon Project.
4.1. OPNFV Moon Project 4.1. OPNFV Moon Project
The OPNFV moon project (https://wiki.opnfv.org) is a security The OPNFV Moon project (https://wiki.opnfv.org) is a security
management system. NFV uses cloud computing technologies to management system. NFV uses cloud computing technologies to
virtualize the resources and automate the control. The Moon project virtualize the resources and automate the control. The Moon project
is working on a security manager for the Cloud computing is working on a security manager for the cloud computing
infrastructure (https://wiki.opnfv.org/moon). The Moon project infrastructure (https://wiki.opnfv.org/moon). The Moon project
proposes to provision a set of different cloud resources/services for proposes to provision a set of different cloud resources/services for
VNFs (Virtualized Network Functions) while managing the isolation of VNFs (Virtualized Network Functions) while managing the isolation of
VNS, protection of VNFs, and monitoring of VNS. Moon is creating a VNS, protection of VNFs, and monitoring of VNS. Moon is creating a
security management system for OPNFV with security managers to security management system for OPNFV with security managers to
protect different layers of the NFV infrastructure. The Moon project protect different layers of the NFV infrastructure. The Moon project
is choosing various security project mechanisms "a la cart" to is choosing various security project mechanisms "a la carte" to
enforcement related security managers. A security management system enforcement related security managers. A security management system
integrates mechanisms of different security aspects. This project integrates mechanisms of different security aspects. This project
will first propose a security manager that specifies users' security intends propose a security manager that specifies users' security
requirements. It will also enforce the security managers through requirements. It will also enforce the security managers through
various mechanisms like authorization for access control, firewall various mechanisms like authorization for access control, firewall
for networking, isolation for storage, logging for tractability, etc. for networking, isolation for storage, logging for tractability, etc.
The Moon security manager operates a VNF security manager at the ETSI The Moon security manager operates a VNF security manager at the ETSI
VeVnfm level where the I2NSF protocol is targeted as figure 5 shows. VeVnfm level where the I2NSF protocol is targeted as Figure 5 shows.
This figure also shows how the OPNFV VNF Security project mixes the This figure also shows how the OPNFV VNF Security project mixes the
I2NSF level with the device level. I2NSF level with the device level.
The Moon project lists the following gaps in OpenStack: The Moon project lists the following gaps in OpenStack:
o No centralized control for compute, storage, and networking. Open o No centralized control for compute, storage, and networking. Open
Stack uses Nova for computing and Swift for software. Each system Stack uses Nova for compute and Swift for object storage. Each
has a configuration file and its own security policy. This lacks system has a configuration file and its own security policy. The
the synchronization mechanism to build a complete secure system lacks a synchronization mechanism to build a complete
configuration for OPNF. secure configuration for OPNFV.
o No dynamic control so that if a user obtains the token, the is no o No dynamic control so that if a user obtains the token, so there
way to obtain control over the user. is no way to obtain control over the user.
o No customization or flexibility to allow integration into o No customization or flexibility to allow integration into
different vendors, different vendors,
o No fine grain authorization at user level. Authorization is only o No fine grained authorization at user level. Authorization is
at the API only at the API level.
Moon addresses these issues adding authorization, logging, IDS, Moon addresses these issues adding authorization, logging, IDS,
enforcement of network policy, and storage protection. Moon is based enforcement of network policy, and storage protection. Moon release
on OpenStack Keystone. C (2016) plans to:
o Define an identity federation scenario between OpenStack and
OpenDaylight,
o Implement an authentication driver in ODL to delegate
authentication to OpenStack/Keystone,
o Implement a command line tool for administration and testing,
o Implement a graphic interface for identity management for both
OpenStack and OpenDaylight,
o Set up identity federation testbed,
o Define identity federation scenarios with other SDN controllers,
and
o Define authorization federation scenarios with OpenDaylight.
Deliverable time frame: Moon Release 3 (mid-year 2016)
Deliverable time frame: 2S 2015
.................... ....................
+--: OSS/BSS : +--: OSS/BSS :
| .................... | ....................
| |
| +-------------------------+ | +-------------------------+
| | | | | |
| | ........ ........ | | | ........ ........ |
| | : EMS1 : : EMS : | ETSI inter-VNFM | | : EMS1 : : EMS : | ETSI inter-VNFM
| | ....||... ...||... | (Ve-Vnfn) | | ....||... ...||... | (Ve-Vnfn)
| | || || ==========I2NSF interface | | || || ==========I2NSF interface
skipping to change at page 17, line 35 skipping to change at page 17, line 38
| | +=====================+ | | +=====================+
| | =============Moon VNF ===Moon VI | | =============Moon VNF ===Moon VI
| | security project Security MGR | | security project Security MGR
| | ........... .......... .......... | | | ........... .......... .......... |
|====:computing: :storage : :network : | |====:computing: :storage : :network : |
| :hardware : :hardware: :hardware: | | :hardware : :hardware: :hardware: |
| ........... .......... .......... | | ........... .......... .......... |
| hardware resources | | hardware resources |
+-----------------------------------+ +-----------------------------------+
figure 5 Figure 5
4.2. Gap Analysis for OPNFV Moon Project 4.2. Gap Analysis for OPNFV Moon Project
OpenStack congress does not provide vendor independent systems. OpenStack Congress does not provide vendor independent systems.
5. OpenStack Security Firewall 5. OpenStack Security Firewall
OpenStack has advanced features of: a) API for managing security OpenStack has advanced features of: a) API for managing security
groups (http://docs.openstack.org/admin-guide-cloud/content/ groups (http://docs.openstack.org/admin-guide-cloud/content/
section_securitygroups.html) and b) firewalls as a service section_securitygroups.html) and b) firewalls as a service
(http://docs.openstack.org/admin-guide-cloud/content/ (http://docs.openstack.org/admin-guide-cloud/content/
fwaas_api_abstractions.html). fwaas_api_abstractions.html).
This section provides an overview of this open stack work, and a gap This section provides an overview of this open stack work, and a gap
analysis of how I2NSF provides additional functions analysis of how I2NSF provides additional functions
5.1. Overview of API for Security Group 5.1. Overview of API for Security Group
The security group with the security group rules provides ingress and The security group rules provide ingress and egress traffic filters
egress traffic filters based on port. The default group drops all based on port. The default rule for the group policy drops all
ingress traffic and allows all egress traffic. The groups with ingress traffic and allows all egress traffic. The group policy
additional filters are added to change this behaviour. To utilize allows users to add additional groups with additional filters that
the security groups, the networking plug-in for Open Stack must change the default behaviour. To utilize the security groups, the
implement the security group API. The following plug-ins in networking plug-in for OpenStack must implement the security group
OpenSTsack currently implement this security: ML2, Open vSwitch, API. The following plug-ins in OpenStack currently implement this
Linux Bridge, NEC, and VMware NSX. In addition, the correct firewall security: ML2, Open vSwitch, Linux Bridge, NEC, and VMware NSX. In
driver must be added to make this functional. addition, the correct firewall driver must be added to make this
functional.
5.2. Overview of Firewalls as a Service 5.2. Overview of Firewall as a Service
Firewall as a service is an early release of an API that allows early Firewall as a service is an early release of an API that allows early
adopters to test network implementations. It contains APIs with adopters to test network implementations. It contains APIs with
parameters for firewall rules, firewall policies, and firewall parameters for firewall rules, firewall policies, and firewall
identifiers. The firewall rules include the following information: identifiers. The firewall rules include the following information:
o identification of rule (id, name, description) o identification of rule (id, name, description)
o identification tenant rule associated with, o identification tenant rule associated with,
o links to installed firewall policy, o links to installed firewall policy,
o IP protocol (tcp, udp, icmp, none) o IP protocol (TCP, UDP, ICMP, or none)
o source and destination IP address o source and destination IP address
o source and destination port o source and destination port
o action: allow or deny traffic o action: allow or deny traffic
o status: position and enable/disabled o status: position and enable/disabled
The firewall policies include the following information: The firewall policies include the following information:
skipping to change at page 19, line 20 skipping to change at page 19, line 23
o status (active, down, pending create, pending delete, pending o status (active, down, pending create, pending delete, pending
update, pending error) update, pending error)
o firewall policy ID this firewall is associated with o firewall policy ID this firewall is associated with
5.3. I2NSF Gap analysis 5.3. I2NSF Gap analysis
The OpenStack work is preliminary (security groups and firewall as a The OpenStack work is preliminary (security groups and firewall as a
service). This work does not allow any of the existing network service). This work does not allow any of the existing network
security vendors provide a management interface. Security devices security vendors provide a management interface. The OpenStack work
take time to be tested for functionality and their detection of provides an interesting simple set of filters, and may in the future
security issues. The OpenStack work provides an interesting simple provide some virtual filter service. However, at this time this open
set of filters, and may in the future provide some virtual filter source work does not address the need for a single management
service. However, at this time this open source work does not interfaces for a variety of security devices.
address the single management interfaces for a variety of security
devices.
I2NSF is proposing rules that will include Event-Condition-matches Phase 1 of I2NSF is proposes rules that will include Event-Condition-
(ECA) with the following matches Action matches (ECA) rules with:
packet based matches on L2, L3, and L4 headers and/or specific packet based matches on L2, L3, and L4 headers and/or specific
addresses within these headers, addresses within these headers, and
context based matches on schedule state and schedule, [Editor:
Need more details here.]
The I2NSF is proposing action for these ECA policies of: context based matches on schedule state and schedule.
basic actions of deny, permit, and mirror, basic ations of deny, permit, and mirror,
advanced actions of: IPS signature filtering and URL filtering. advanced actions of: IPS signature filtering and URL filtering.
[Editorial note: do we need more matches or actions?]
6. CSA Secure Cloud 6. CSA Secure Cloud
6.1. CSA Overview 6.1. CSA Overview
The Cloud Security Alliance (CSA)(www.cloudsecurityaliance.org) The Cloud Security Alliance (CSA)(www.cloudsecurityaliance.org)
defined security as a service (SaaS) in their Security as a Service defined security as a service (SaaS) in their Security as a Service
working group (SaaS WG) during 2010-2012. The CSA SaaS group defined working group (SaaS WG) during 2010-2012. The CSA SaaS group defined
ten categories of network security ten categories of network security
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/ (https://downloads.cloudsecurityalliance.org/initiatives/secaas/
SecaaS_V1_0.pdf) and provides implementation guidance for each of SecaaS_V1_0.pdf) and provides implementation guidance for each of
these ten categories This section provides an overview of the CSA these ten categories. This section provides an overview of the CSA
SaaS working groups documentation and a Gap analysis for I2NSF SaaS working groups documentation and a gap analysis for I2NSF
6.1.1. CSA Security as a Service(SaaS) 6.1.1. CSA Security as a Service (SaaS)
The CSA SaaS working group defined the following ten categories, and The CSA SaaS working group defined the following ten categories, and
provided implementation guidance on these categories: provided implementation guidance on these categories:
1. Identity Access Management (IAM) 1. Identity Access Management (IAM)
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/ (https://downloads.cloudsecurityalliance.org/initiatives/secaas/
SecaaS_Cat_1_IAM_Implementation_Guidance.pdf) SecaaS_Cat_1_IAM_Implementation_Guidance.pdf)
2. Data Loss Prevention (DLP) 2. Data Loss Prevention (DLP)
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/ (https://downloads.cloudsecurityalliance.org/initiatives/secaas/
skipping to change at page 21, line 5 skipping to change at page 21, line 5
SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf), SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf),
9. Business Continuity and Disaster Recovery (BCDR) 9. Business Continuity and Disaster Recovery (BCDR)
https://downloads.cloudsecurityalliance.org/initiatives/secaas/ https://downloads.cloudsecurityalliance.org/initiatives/secaas/
SecaaS_Cat_9_BCDR_Implementation_Guidance.pdf), and SecaaS_Cat_9_BCDR_Implementation_Guidance.pdf), and
10. Network Security 10. Network Security
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/ (https://downloads.cloudsecurityalliance.org/initiatives/secaas/
SecaaS_Cat_10_Network_Security_Implementation_Guidance.pdf). SecaaS_Cat_10_Network_Security_Implementation_Guidance.pdf).
The sections below give an overview these implementation guidances The sections below give an overview these implementation guidelines.
6.1.2. Identity Access Management (IAM) 6.1.2. Identity Access Management (IAM)
document: document:
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/ (https://downloads.cloudsecurityalliance.org/initiatives/secaas/
SecaaS_Cat_1_IAM_Implementation_Guidance.pdf) SecaaS_Cat_1_IAM_Implementation_Guidance.pdf)
The identity management systems include the following services: The identity management systems include the following services:
o Centralized Directory Services, o Centralized Directory Services,
skipping to change at page 21, line 36 skipping to change at page 21, line 36
o Privileged User and Access Management, o Privileged User and Access Management,
o Separation of Duties Services, and o Separation of Duties Services, and
o Identity and Access Reporting Services. o Identity and Access Reporting Services.
The IAM device communications with the security management system The IAM device communications with the security management system
that controls the filtering of data. The CSA SaaS IAM specification that controls the filtering of data. The CSA SaaS IAM specification
states that interoperability between IAM devices and secure access states that interoperability between IAM devices and secure access
network management systems is a a problem. This 2012 implementation network management systems is a problem. This 2012 implementation
report confirms there is a gap with I2NSF report confirms there is a gap with IAM.
+------------+ +--------+ +------------+ +--------+
| IAM device | ---- SLA ------------| secure | | IAM device | ---- SLA ------------| secure |
| | Access review | access | | | Access review | access |
| | security events | NMS | | | security events | NMS |
| | access tracing | | | | access tracing | |
+---||-------+ Audit report +---||---+ +---||-------+ Audit report +---||---+
|| || || ||
|| +------------------+ || || +------------------+ ||
========== |Filter enforcement|=====|| ========== |Filter enforcement|=====||
+------------------+ +------------------+
Figure 6 Figure 6
6.1.3. Data Loss Prevention (DLP) 6.1.3. Data Loss Prevention (DLP)
Document: Document:
(https://downloads.cloudsecurityalliance.org/initiatives/secaas/ (https://downloads.cloudsecurityalliance.org/initiatives/secaas/
SecaaS_Cat_2_DLP_Implementation_Guidance.pdf) SecaaS_Cat_2_DLP_Implementation_Guidance.pdf)
The data loss prevention (DLP)services must address: The data loss prevention (DLP) services must address:
o origination verification, o origination verification,
o integrity of data, o integrity of data,
o confidentiality and access control, o confidentiality and access control,
o accountability, o accountability,
o avoiding false positives on detection, and o avoiding false positives on detection, and
skipping to change at page 23, line 5 skipping to change at page 23, line 5
| | Alert and log | access | | | Alert and log | access |
| | delete data | NMS | | | delete data | NMS |
| | filter/reroute | | | | filter/reroute | |
+---||-------+ encrypt data +---||---+ +---||-------+ encrypt data +---||---+
|| || || ||
|| +------------------+ || || +------------------+ ||
========== |Filter enforcement|=====|| ========== |Filter enforcement|=====||
+------------------+ +------------------+
Figure 7 Figure 7
6.1.4. Web security(Web)) 6.1.4. Web Security (Web)
Document: Document:
https://downloads.cloudsecurityalliance.org/initiatives/secaas/ https://downloads.cloudsecurityalliance.org/initiatives/secaas/
SecaaS_Cat_3_Web_Security_Implementation_Guidance.pdf SecaaS_Cat_3_Web_Security_Implementation_Guidance.pdf
The web security services must address: The web security services must address:
o Web 2.0/Social Media controls, o Web 2.0/Social Media controls,
o Malware and Anti-Virus controls, o Malware and Anti-Virus controls,
skipping to change at page 24, line 10 skipping to change at page 24, line 10
monitor encrypted (SSL enabled) traffic, monitor encrypted (SSL enabled) traffic,
All of these features either require the I2NSF standardized I2NSF All of these features either require the I2NSF standardized I2NSF
client to I2NSF agent to provide multi-vendor interoperability. client to I2NSF agent to provide multi-vendor interoperability.
+------------+ +--------+ +------------+ +--------+
|Web security| ---- SLA ------------| secure | |Web security| ---- SLA ------------| secure |
| | Alert and log | access | | | Alert and log | access |
| | delete data | NMS | | | delete data | NMS |
| | filter/reroute data | | | | filter/reroute data | |
| | ensure bandwdith/QOS | | | | ensure bandwidth/QOS | |
| | monitor encrypted | | | | monitor encrypted | |
| | data | | | | data | |
+---||-------+ encrypt data +---||---+ +---||-------+ encrypt data +---||---+
|| || || ||
|| +------------------+ || || +------------------+ ||
========== |Filter enforcement|=====|| ========== |Filter enforcement|=====||
+------------------+ +------------------+
Figure 8 Figure 8
6.1.5. Email Security (email)) 6.1.5. Email Security (email))
skipping to change at page 26, line 36 skipping to change at page 26, line 36
The CSA SaaS Intrusion detection management includes intrusion The CSA SaaS Intrusion detection management includes intrusion
detection through: devices: detection through: devices:
o Network traffic inspection, behavioural analysis, and flow o Network traffic inspection, behavioural analysis, and flow
analysis, analysis,
o Operating System, Virtualization Layer, and Host Process Events o Operating System, Virtualization Layer, and Host Process Events
monitoring, monitoring,
o monitoring of Application Layer Events, and o Monitoring of Application Layer Events, and
o Correlation Techniques, and other Distributed and Cloud-Based o Correlation Techniques, and other Distributed and Cloud-Based
Capabilities Capabilities
Intrusion response includes both: Intrusion response includes both:
o Automatic, Manual, or Hybrid Mechanisms, o Automatic, Manual, or Hybrid Mechanisms,
o Technical, Operational, and Process Mechanisms. o Technical, Operational, and Process Mechanisms.
The CSA SaaS recommends the intrusion security management systems The CSA SaaS recommends the intrusion security management systems
include provisioning and monitoring of all of these types of include provisioning and monitoring of all of these types of
intrusion detection (IDS) or intrusion protection devices. The intrusion detection or intrusion protection devices. Management of
management of these systems requires also requires: these systems requires:
Central reporting of events and alerts, Central reporting of events and alerts,
administrator notification of intrusions, Administrator notification of intrusions,
Mapping of alerts to Cloud-Layer Tenancy, Mapping of alerts to Cloud-Layer Tenancy,
Cloud sourcing information to prevent false positives in Cloud sourcing information to prevent false positives in
detection, and detection, and
allowing for redirection of traffic to allow remote storage or Allowing for redirection of traffic to allow remote storage or
transmission to prevent local evasion. transmission to prevent local evasion.
All of these features require the I2NSF standardized I2NSF client to In order to be able performing these management actions on NSF
I2NSF agent to provide multi-vendor interoperability. devices from different vendors, the intrusion security management
systems need a standard mangement protocol that all the NSF vendors
support.
+------------+ +--------+ +------------+ +--------+
| IDS/IPS | ---- Info ----------| secure | | IDS/IPS | ---- Info ----------| secure |
| security | alert/log intrusion | access | | security | alert/log intrusion | access |
| | notify administrator | NMS | | | notify administrator | NMS |
| | Map alerts to Tenant | | | | Map alerts to Tenant | |
| |filter/reroute traffic| | | |filter/reroute traffic| |
| | remote data storage | | | | remote data storage | |
+---||-------+ +---||---+ +---||-------+ +---||---+
|| || || ||
|| +------------------+ || || +------------------+ ||
========== |Filter enforcement|=====|| ========== |Filter enforcement|=====||
+------------------+ +------------------+
Figure 10 Figure 10
6.1.8. Security Information and Event Management(SEIM) The I2NSF manager - I2NSF (server/agent) protocol is designed to fill
this gap.
6.1.8. Security Information and Event Management(SIEM)
Document: Document:
https://downloads.cloudsecurityalliance.org/initiatives/secaas/ https://downloads.cloudsecurityalliance.org/initiatives/secaas/
SecaaS_Cat_7_SIEM_Implementation_Guidance.pdf) SecaaS_Cat_7_SIEM_Implementation_Guidance.pdf)
The Security Information and Event Management (SEIM) receives data The Security Information and Event Management (SIEM) receives data
from a wide range of security systems such as Identity management from a wide range of security systems such as Identity management
systems (IAM), data loss prevention (DLP), web security (Web), email systems (IAM), data loss prevention (DLP), web security (Web), email
security (email), intrusion detection/prevision (IDS/IPS)), security (email), intrusion detection/prevision (IDS/IPS)),
encryption, disaster recovery, and network security. The SEIM encryption, disaster recovery, and network security. The SIEM
combines this data into a single streams. All the requirements for combines this data into a single streams. All the requirements for
data to/from these systems are replicated in these systems needs to data to/from these systems are replicated in these systems needs to
give a report to the SIEM system. give a report to the SIEM system.
A SIEM system would be prime candidate to have a I2NSF client that A SIEM system would be a prime candidate to have an I2NSF client that
gathers data from an I2NSF Agent associated with these various types gathers data from an I2NSF Agent associated with these various types
of security systems. The CSA SaaS SIEM functionality document of security systems. The CSA SaaS SIEM functionality document
suggests that one concern is to have standards that allow timely suggests that one concern is to have standards that allow timely
recording and sharing of data. I2NSF can provide this. recording and sharing of data. I2NSF can provide this.
6.1.9. Encryption 6.1.9. Encryption
Document: Document:
https://downloads.cloudsecurityalliance.org/initiatives/secaas/ https://downloads.cloudsecurityalliance.org/initiatives/secaas/
SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf SecaaS_Cat_8_Encryption_Implementation_Guidance.pdf
The CSA SaaS Encryption implementation guidance document considers The CSA SaaS encryption implementation guidance document considers
how one implements and manages the following security systems: how one implements and manages the following security systems:
key management systems (KMS), control of keys, and key life cycle; Key management systems (KMS), control of keys, and key life cycle;
Shared Secret encryption (Symmetric ciphers), Shared Secret encryption (Symmetric ciphers),
No-Secret or Public Key Encryption (asymmetric ciphers), No-Secret or Public Key Encryption (asymmetric ciphers),
hashing algorithms, Hashing algorithms,
Digital Signature Algorithms, Digital Signature Algorithms,
Key Establishment Schemes, Key Establishment Schemes,
Protection of Cryptographic Key Material (FIPS 140-2; 140-3), Protection of Cryptographic Key Material (FIPS 140-2; 140-3),
Interoperability of Encryption Systems, Key Conferencing, Key Interoperability of Encryption Systems, Key Conferencing, Key
Escrow Systems, and others Escrow Systems, and others
application of Encryption for Data at rest, data in transit, and Application of Encryption for Data at rest, data in transit, and
data in use; data in use;
PKI (including certificate revocation "CRL"); PKI (including certificate revocation "CRL");
Future application of such technologies as Homomorphic encryption, Future application of such technologies as Homomorphic encryption,
Quantum Cryptography, Identitybased Encryption, and others; Quantum Cryptography, Identity-based Encryption, and others;
Crypto-system Integrity (How bad implementations can under mind a Crypto-system Integrity (How bad implementations can under mind a
crypto-system), and crypto-system), and
Cryptographic Security Standards and Guidelines Cryptographic Security Standards and Guidelines
The wide variety of encryption services require the security Encryption services typically require that security management
management systems be able to provision, monitor, and control the systems be able to provision, monitor, and control the systems that
systems that are being used to encrypt data. This document indicates are being used to encrypt data. This document indicates in the
in the implementation sections that the standardization of interfaces implementation sections that the standardization of interfaces to/
to/from management systems are key to good key management systems, from management systems are key to good key management systems,
encryption systems, and crypto-systems. encryption systems, and crypto-systems.
6.1.10. Business Continuity and Disaster Recovery (BC/DR) 6.1.10. Business Continuity and Disaster Recovery (BC/DR)
Document: Document:
https://downloads.cloudsecurityalliance.org/initiatives/secaas/ https://downloads.cloudsecurityalliance.org/initiatives/secaas/
SecaaS_Cat_9_BCDR_Implementation_Guidance.pdf SecaaS_Cat_9_BCDR_Implementation_Guidance.pdf
The CSA SaaS Business Continuity and Disaster Recovery (BC/DR) The CSA SaaS Business Continuity and Disaster Recovery (BC/DR)
implementation guidance document considers the systems that implement implementation guidance document considers the systems that implement
the the contingency plans and measures designed and implemented to the contingency plans and measures designed and implemented to ensure
ensure operational resiliency in the event of any service operational resiliency in the event of any service interruptions.
interruptions. BC/DR systems includes: BC/DR systems includes:
Business Continuity and Disaster Recovery BC/DR as a service, Business Continuity and Disaster Recovery BC/DR as a Service,
including categories such as complete Disaster Recovery as a including categories such as complete Disaster Recovery as a
Service (DRaaS), and subsets such as file recovery, backup and Service (DRaaS), and subsets such as file recovery, backup and
archive, archive,
Storage as a Service including object, volume, or block storage; Storage as a Service including object, volume, or block storage;
old Site, Warm Site, Hot Site backup plans; Cold Site, Warm Site, Hot Site backup plans;
IaaS (Infrastructure as a Service), PaaS (Platform as a Service), IaaS (Infrastructure as a Service), PaaS (Platform as a Service),
and SaaS (Software as a Service); and SaaS (Software as a Service);
Insurance (and insurance reporting programs) Insurance (and insurance reporting programs)
Business Partner Agents (business associate agreements); Business Partner Agents (business associate agreements);
System Replication (for high availability); System Replication (for high availability);
skipping to change at page 29, line 50 skipping to change at page 30, line 7
level); level);
Realm-based Access Control; Realm-based Access Control;
Service-level Agreements (SLA); and Service-level Agreements (SLA); and
ISO/IEC 24762:2008, BS25999, ISO 27031, and FINRA Rule 4370 ISO/IEC 24762:2008, BS25999, ISO 27031, and FINRA Rule 4370
These BC/DR systems must handle data backup and recovery, server These BC/DR systems must handle data backup and recovery, server
backup/recovery, and data center (virtual/physical) backup and backup/recovery, and data center (virtual/physical) backup and
recovery. Recovery as a service (RaaS) means that the BC/DR services recovery. Recovery as a Service (RaaS) means that the BC/DR services
are being handled by management systems outside the enterprise. are being handled by management systems outside the enterprise.
The wide variety of BC/DR requires the security management systems to BC/DR requires security management systems to be able to communicate
be able to communicate provisioning, monitor, and control those provisioning, monitor, and control those systems that are being used
systems that are being used to back-up and restore data. An to back-up and restore data. An interoperable protocol that allows
interoperable protocol that allows provision and control of data provision and control of data center's data, servers, and data center
center's data, servers, and data center management devices devices is management devices devices is extremely important to this
extremely important to this application. Recovery as a Service application. Recovery as a Service (SaaS) indicates that these
(SaaS) indicates that these services need to be able to be remotely services need to be able to be remotely management.
management.
The CSA SaaS BC/BR documents indicate how important a standardized The CSA SaaS BC/BR documents indicate how important a standardized
I2NSF protocol is. I2NSF protocol is.
6.1.11. Network Security Devices 6.1.11. Network Security Devices
Document: Document:
https://downloads.cloudsecurityalliance.org/initiatives/secaas/ https://downloads.cloudsecurityalliance.org/initiatives/secaas/
SecaaS_Cat_10_Network_Security_Implementation_Guidance.pdf SecaaS_Cat_10_Network_Security_Implementation_Guidance.pdf
skipping to change at page 31, line 34 skipping to change at page 31, line 38
threat vector. In additions, the need for the management protocol threat vector. In additions, the need for the management protocol
like I2NSF is critical in the sprawl of Cloud environment. like I2NSF is critical in the sprawl of Cloud environment.
6.2. I2NSF Gap Analysis 6.2. I2NSF Gap Analysis
The CSA Security as a Service (SaaS) document show clearly that there 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 is a gap between the ability of the CSA SaaS devices to have a vendor
neutral, inoperable protocol that allow the multiple of network neutral, inoperable protocol that allow the multiple of network
security devices to communicate passing provisioning and security devices to communicate passing provisioning and
informational data. Each of the 10 implementation agreements points informational data. Each of the 10 implementation agreements points
to this as a shortage. The I2NSF yang models and protocol is needed to this as a shortcoming. Standard I2NSF YANG models and an I2NSF
according to the CSA SaaS documents. protocol are needed according to the CSA SaaS documents.
7. In-depth Review of IETF protocols 7. In-depth Review of IETF protocols
7.1. NETCONF and RESTCONF 7.1. NETCONF and RESTCONF
The IETF NETCONF working group has developed the basics of the The IETF NETCONF working group has developed the basics of the
NETCONF protocol focusing on secure configuration and querying NETCONF protocol focusing on secure configuration and querying
operational state. The NETCONF protocol [RFC6241] may be run over operational state. The NETCONF protocol [RFC6241] may be run over
TLS [RFC6639] or SSH ([RFC6242]. NETCONF can be expanded to defaults TLS [RFC6639] or SSH ([RFC6242]. NETCONF can be expanded to defaults
[RFC6243], handling events ([RFC5277] and basic notification [RFC6243], handling events ([RFC5277] and basic notification
[RFC6470], and filtering writes/reads based on network access control [RFC6470], and filtering writes/reads based on network access control
models (NACM, [RFC6536]). The NETCONF configuration must be models (NACM, [RFC6536]). The NETCONF configuration must be
committed to a configuration data store (denoted as config=TRUE). committed to a configuration data store (denoted as config=TRUE).
Yang models identify nodes within a configuration data store or an YANG models identify nodes within a configuration data store or an
operational data store using a XPath expression (document root ---to operational data store using a XPath expression (document root ---to
--- target source). NETCONF uses an RPC model and provides protocol --- target source). NETCONF uses an RPC model and provides protocol
for handling configs (get-config, edit-config, copy-config, delete- for handling configs (get-config, edit-config, copy-config, delete-
config, lock, unlock, get) and sessions (close-session, kill- config, lock, unlock, get) and sessions (close-session, kill-
session). The NETCONF Working Group has developed RESTCONF, which is session). The NETCONF Working Group has developed RESTCONF, which is
an HTTP-based protocol that provides a programmatic interface for an HTTP-based protocol that provides a programmatic interface for
accessing data defined in YANG, using the datastores defined in accessing data defined in YANG, using the data stores defined in
NETCONF. NETCONF.
RESTCONF supports "two edit condition detections" - time stamp and RESTCONF supports "two edit condition detections" - time stamp and
entity tag. RESTCONF uses a URI encoded path expressions. RESTCONF entity tag. RESTCONF uses URI encoded path expressions. RESTCONF
provides operations to get remote servers options (OPTIONS), retrieve provides operations to get remote servers options (OPTIONS), retrieve
data headers (HEAD), get data (GET), create resource/invoke operation data headers (HEAD), get data (GET), create resource/invoke operation
(POST), patch data (PATCH), delete resource (DELETE), or query. (POST), patch data (PATCH), delete resource (DELETE), or query.
RFCs for NETCONF RFCs for NETCONF
o NETCONF [RFC6242] o NETCONF [RFC6242]
o NETCONF monitoring [RFC6022] o NETCONF monitoring [RFC6022]
skipping to change at page 33, line 16 skipping to change at page 33, line 22
o [I-D.ietf-i2rs-traceability] o [I-D.ietf-i2rs-traceability]
o [I-D.ietf-i2rs-protocol-security-requirements] o [I-D.ietf-i2rs-protocol-security-requirements]
At this time, NETCONF and RESTCONF cannot handle the ephemeral data At this time, NETCONF and RESTCONF cannot handle the ephemeral data
store proposed by I2RS, the publication and subscription store proposed by I2RS, the publication and subscription
requirements, the traceability, or the security requirements for the requirements, the traceability, or the security requirements for the
transport protocol and message integrity. transport protocol and message integrity.
7.3. NETMOD Yang modules 7.3. NETMOD YANG modules
NETMOD developed initial Yang models for interfaces [RFC7223]), IP NETMOD developed initial YANG models for interfaces [RFC7223]), IP
address ([RFC7277]), IPv6 Router advertisement ([RFC7277]), IP address ([RFC7277]), IPv6 Router advertisement ([RFC7277]), IP
Systems ([RFC7317]) with system ID, system time management, DNS Systems ([RFC7317]) with system ID, system time management, DNS
resolver, Radius client, SSH, syslog resolver, Radius client, SSH, syslog
([I-D.ietf-netmod-syslog-model]), ACLS ([I-D.ietf-netmod-acl-model]), ([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 and core routing blocks ([I-D.ietf-netmod-routing-cfg] The routing
working group (rtgwg) has begun to examine policy for routing and working group (rtgwg) has begun to examine policy for routing and
tunnels. tunnels.
Protocol specific Working groups have developed yang models for ISIS 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 ([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] ([I-D.ietf-idr-bgp-model].
with the bgp policy proposed multiple Working groups (idr and
rtgwg)). BGP Services yang models have been proposed for PPB EVPN BGP Services YANG models have been proposed for
([I-D.tsingh-bess-pbb-evpn-yang-cfg]), EVPN
([I-D.zhuang-bess-evpn-yang]), L3VPN ([I-D.zhuang-bess-l3vpn-yang]), o EVPN [I-D.brissette-bess-evpn-yang],
and multicast MPLS/BGP IP VPNs ([I-D.liu-bess-mvpn-yang]).
o L2VPN [I-D.shah-bess-l2vpn-yang],
o L3VPN [I-D.li-bess-l3vpn-yang] and
[I-D.hu-bess-l2vpn-service-yang],
TEAS working group has proposed [I-D.ietf-teas-yang-te-topo], and
[I-D.ietf-teas-yang-rsvp].
MPLS/PCE/CCAMP groups have proposed the following Yang modules:
o [I-D.raza-mpls-ldp-mldp-yang]
o [I-D.saad-mpls-static-yang],
o [I-D.zheng-mpls-lsp-ping-yang-cfg],
o [I-D.pkd-pce-pcep-yang], and
o [I-D.zhang-ccamp-transport-ctrlnorth-yang].
7.4. COPS 7.4. COPS
One early focus on flow filtering based on policy enforcement of One early focus on flow filtering based on policy enforcement of
traffic entering a network is the 1990s COPS [RFC2748] design (PEP traffic entering a network is the 1990s COPS [RFC2748] design (PEP
and PDP) as shown in figure 1. The Policy decision point kept and PDP) as shown in Figure 11. The COPS policy decision points
network-wide policy (E.g. ACLs) and sent it to Policy enforcements (PDP) managed network-wide policy (e.g. ACLs) by installing this
who then would control what data flows between the two These decision policy in policy enforcement points (PEPs) on the edge of the
points controlled data flow from PEP to PEP. [RFC3084] describes network. These PEPs had firewall-like functions that control what
COPS use for policy provisioning. data flows into the network at a PEP point, and data flow out of a
network at a PEP. [RFC3084] describes COPS usages for policy
provisioning.
PDP PDP
+-----+ / \ +-----+ +-----+ / \ +-----+
|PEP1 |--/ \---|PEP2 | |PEP1 |--/ \---|PEP2 |
| | ACL/policy | | | | ACL/policy | |
| | | | | | | |
--| ----|------------|-----|----- --| ----|------------|-----|-----
+-----+ data flow +-----+ +-----+ data flow +-----+
Figure 11 Figure 11
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 Why COPS is no longer used
Security in the network in 2015 uses specific devices (IDS/IPS, NAT Network security today uses specific devices (IDS/IPS, NAT firewall,
firewall, etc) with specific policies and profiles for each types of etc.) with specific policies and profiles for each types of device.
device. No common protocol or policy format exists between the No common protocol or policy format exists between the policy manager
policy manager (PDP) and security enforcement points. (PDP) and security enforcement points.
COPs RFCs: [RFC4261], [RFC2940], , [RFC3084], , [RFC3483] COPs RFCs: [RFC4261], [RFC2940], [RFC3084], and [RFC3483].
Why I2NSF is different COPS Why I2NSF is Different from COPS
COPS was a protocol for policy related to Quality of Service (QoS) COPS was a protocol for policy related to Quality of Service (QoS)
and signalling protocols (e.g. RSVP) (security, flow, and others). and signaling protocols (e.g. RSVP) (security, flow, and others).
I2NSF creates a common protocol between security policy decision I2NSF creates a common protocol between security policy decision
points (SPDP) and security enforcement points (SEP). Today's points (SPDP) and security enforcement points (SEP). Today's
security devices currently only use proprietary protocols. security devices currently only use proprietary protocols.
Manufacturers would like a security specific policy enforcement Manufacturers would like a security specific policy enforcement
protocol rather than a generic policy protocol. protocol rather than a generic policy protocol.
7.5. PCP 7.5. PCP
As indicated by the name, the Port Control Protocol (PCP) enables an 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 IPv4 or IPv6 host to flexibly manage the IP address and port mapping
skipping to change at page 35, line 9 skipping to change at page 35, line 24
[RFC6887] [RFC6887]
[RFC7225] [RFC7225]
[I-D.ietf-pcp-authentication] [I-D.ietf-pcp-authentication]
[I-D.ietf-pcp-optimize-keepalives] [I-D.ietf-pcp-optimize-keepalives]
[I-D.ietf-pcp-proxy] [I-D.ietf-pcp-proxy]
Why is I2NSF different from PCP: Why is I2NSF Different from PCP:
Here are some aspects that I2NSF is different from PCP: Here are some aspects that I2NSF is different from PCP:
o PCP only supports the management of port and address information o PCP only supports management of port and address information
rather than any other security functions rather than any other security functions
o Cover the proxy, firewall and NAT box proposals in I2NSF 7.6. NSIS - Next Steps in Signaling
7.6. NSIS - Next steps in Signalling
NSIS is for standardizing an IP signalling protocol (RSVP) along data NSIS aims to standardize an IP signaling protocol (RSVP) along the
path for end points to request its unique QoS characteristics, unique data path for end points to request their unique QoS characteristics,
FW policies or NAT needs (RFC5973) that are different from the FW/NAT unique FW policies or NAT needs (RFC5973) that are different from the
original setting. The requests are communicated directly to the FW/ FW/NAT original settings. The requests are communicated directly to
NAT devices. NSIS is like east-west protocols that require all the FW/NAT devices. NSIS is like east-west protocols that require
involved devices to fully comply to make it work. all involved devices to fully comply to make it work.
NSIS is path-coupled, it is possible to message every participating NSIS is path-coupled; it is possible to message every participating
device along a path without having to know its location, or its device along a path without having to know its location, or its
location relative to other devices (this is particularly a pressing location relative to other devices (This is particularly a pressing
issue when you've got one or more NATs present in the network, or issue when one or more NATs present in the network, or when trying to
when trying to locate appropriate tunnel endpoints). locate appropriate tunnel endpoints).
A diagram should be added here showing I2NSF and NSIS
Why I2NSF is different than NSIS: clients----I2NSF controller
| client
|
| I2NSF
| server/agent
+--------+ +--------+ +--------+
| host | |firewall| | host |
|device-1|-------|device-2|-------|device-3|
+--------+ RSVP +--------+ RSVP +--------+
-----NSIS-----------------------
o The I2NSF requests from clients do not go directly to network Why I2NSF is Different from NSIS:
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 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 to comply, but it is a protocol between the I2NSF client and the
I2NSF Agent in the controller and orchestrator I2NSF Agent/Server
o I2NSF defines client (applications) oriented descriptors o I2NSF defines client (applications) oriented descriptors
(profiles, or attributes) to request/negotiate/validate the (profiles, or attributes) to request/negotiate/validate the
network security functions that are not on the local premises. network security functions that are not on the local premises.
Why we belief I2NSF has a higher chance to be deployed than NSIS: Why I2NSF may have higher chance to be deployed than NSIS:
o Open Stack already has a proof-of-concept/preliminary o OpenStack already has a proof-of-concept/preliminary
implementation, but the specification is not complete. IETF can implementation, but the specification is not complete. IETF can
play an active role to make the specification for I2NSF is play an active role to make the specification for I2NSF is
complete. IETF can complete and extend the OpenStack complete. IETF can complete and extend the OpenStack
implementation to provide an interoperable specification that can implementation to provide an interoperable specification that can
meet the needs and requirements of operators and is workable for meet the needs and requirements of operators and is workable for
suppliers of the technology. The combination of a carefully suppliers of the technology. The combination of a carefully
designed interoperable IETF specification with an open-source code designed interoperable IETF specification with an open-source code
development Open Stack will leverage the strengths of the two development OpenStack will leverage the strengths of the two
communities, and expand the informal ties between the two groups. communities, and expand the informal ties between the two groups.
A software development cycle has the following components: A software development cycle has the following components:
architecture, design specification, coding, and interoperability architecture, design specification, coding, and interoperability
testing. The IETF can take ownership of the first two steps, and testing. The IETF can take ownership of the first two steps, and
provide expertise and a good working atmosphere (in hack-a-thons) provide expertise and a good working atmosphere (in hack-a-thons)
in the last two steps for OpenSTack or other open-source coders. in the last two steps for OpenStack or other open-source coders.
o IETF has the expertise in security architecture and design for o IETF has the expertise in security architecture and design for
interoperable protocols that span controllers/routers, middle- interoperable protocols that span controllers/routers, middle-
boxes, and security end-systems. boxes, and security end-systems.
o IETF has a history of working on interoperable protocols or o IETF has a history of working on interoperable protocols or
virtualized network functions (L2VPN, L3VPN) that are deployed by virtualized network functions (L2VPN, L3VPN) that are deployed by
operators in large scale devices. IETF has a strong momentum to operators in large scale devices. IETF has a strong momentum to
create virtualized network functions (see SFC WG in routing) to be create virtualized network functions (see SFC WG in routing) to be
deployed in network boxes. [Note: We need to add SACM and others deployed in network boxes. [Note: We need to add SACM and others
skipping to change at page 36, line 43 skipping to change at page 37, line 18
No IANA considerations exist for this document. No IANA considerations exist for this document.
9. Security Considerations 9. Security Considerations
No security considerations are involved with a gap analysis. No security considerations are involved with a gap analysis.
10. Contributors 10. Contributors
The following people have contributed to this document: Hosnieh The following people have contributed to this document: Hosnieh
Rafiee. Rafiee, and Myo Zarny. Myo Zarny provided the authors with extensive
comments, great suggestions, and valuable insights on alternative
views.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
11.2. Informative References 11.2. Informative References
[I-D.hares-i2rs-bnp-eca-data-model] [I-D.brissette-bess-evpn-yang]
Hares, S., Wu, Q., and R. White, "An Information Model for Brissette, P., Shah, H., Li, Z., Tiruveedhula, K., Singh,
Basic Network Policy and Filter Rules", draft-hares-i2rs- T., and I. Hussain, "Yang Data Model for EVPN", draft-
bnp-eca-data-model-03 (work in progress), January 2016. brissette-bess-evpn-yang-01 (work in progress), December
2015.
[I-D.hares-i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., and L. Xia, "I2NSF
Terminology", draft-hares-i2nsf-terminology-00 (work in
progress), March 2016.
[I-D.hares-i2rs-info-model-service-topo] [I-D.hares-i2rs-info-model-service-topo]
Hares, S., Wu, W., Wang, Z., and J. You, "An Information Hares, S., Wu, W., Wang, Z., and J. You, "An Information
model for service topology", draft-hares-i2rs-info-model- model for service topology", draft-hares-i2rs-info-model-
service-topo-03 (work in progress), January 2015. service-topo-03 (work in progress), January 2015.
[I-D.hares-i2rs-pkt-eca-data-model]
Hares, S., Wu, Q., and R. White, "Filter-Based Packet
Forwarding ECA Policy", draft-hares-i2rs-pkt-eca-data-
model-02 (work in progress), February 2016.
[I-D.hu-bess-l2vpn-service-yang]
hu, f., Chen, R., and J. Yao, "L2VPN Service YANG Model",
draft-hu-bess-l2vpn-service-yang-00 (work in progress),
March 2016.
[I-D.ietf-i2rs-architecture] [I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-11 (work in System", draft-ietf-i2rs-architecture-11 (work in
progress), December 2015. progress), December 2015.
[I-D.ietf-i2rs-ephemeral-state] [I-D.ietf-i2rs-ephemeral-state]
Haas, J. and S. Hares, "I2RS Ephemeral State Haas, J. and S. Hares, "I2RS Ephemeral State
Requirements", draft-ietf-i2rs-ephemeral-state-02 (work in Requirements", draft-ietf-i2rs-ephemeral-state-05 (work in
progress), September 2015. progress), March 2016.
[I-D.ietf-i2rs-problem-statement] [I-D.ietf-i2rs-problem-statement]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Problem Statement", draft-ietf-i2rs- Routing System Problem Statement", draft-ietf-i2rs-
problem-statement-09 (work in progress), January 2016. problem-statement-10 (work in progress), February 2016.
[I-D.ietf-i2rs-protocol-security-requirements] [I-D.ietf-i2rs-protocol-security-requirements]
Hares, S., Migault, D., and J. Halpern, "I2RS Security Hares, S., Migault, D., and J. Halpern, "I2RS Security
Related Requirements", draft-ietf-i2rs-protocol-security- Related Requirements", draft-ietf-i2rs-protocol-security-
requirements-02 (work in progress), December 2015. requirements-03 (work in progress), March 2016.
[I-D.ietf-i2rs-pub-sub-requirements] [I-D.ietf-i2rs-pub-sub-requirements]
Voit, E., Clemm, A., and A. Prieto, "Requirements for Voit, E., Clemm, A., and A. Prieto, "Requirements for
Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub-
requirements-04 (work in progress), January 2016. requirements-05 (work in progress), February 2016.
[I-D.ietf-i2rs-rib-data-model] [I-D.ietf-i2rs-rib-data-model]
Wang, L., Ananthakrishnan, H., Chen, M., Wang, L., Ananthakrishnan, H., Chen, M.,
amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A
YANG Data Model for Routing Information Base (RIB)", YANG Data Model for Routing Information Base (RIB)",
draft-ietf-i2rs-rib-data-model-04 (work in progress), draft-ietf-i2rs-rib-data-model-05 (work in progress),
November 2015. March 2016.
[I-D.ietf-i2rs-rib-info-model] [I-D.ietf-i2rs-rib-info-model]
Bahadur, N., Kini, S., and J. Medved, "Routing Information Bahadur, N., Kini, S., and J. Medved, "Routing Information
Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work
in progress), October 2015. in progress), October 2015.
[I-D.ietf-i2rs-traceability] [I-D.ietf-i2rs-traceability]
Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
the Routing System (I2RS) Traceability: Framework and the Routing System (I2RS) Traceability: Framework and
Information Model", draft-ietf-i2rs-traceability-06 (work Information Model", draft-ietf-i2rs-traceability-07 (work
in progress), January 2016. in progress), February 2016.
[I-D.ietf-i2rs-usecase-reqs-summary] [I-D.ietf-i2rs-usecase-reqs-summary]
Hares, S. and M. Chen, "Summary of I2RS Use Case Hares, S. and M. Chen, "Summary of I2RS Use Case
Requirements", draft-ietf-i2rs-usecase-reqs-summary-01 Requirements", draft-ietf-i2rs-usecase-reqs-summary-01
(work in progress), May 2015. (work in progress), May 2015.
[I-D.ietf-i2rs-yang-l2-network-topology] [I-D.ietf-i2rs-yang-l2-network-topology]
Dong, J. and X. Wei, "A YANG Data Model for Layer-2 Dong, J. and X. Wei, "A YANG Data Model for Layer-2
Network Topologies", draft-ietf-i2rs-yang-l2-network- Network Topologies", draft-ietf-i2rs-yang-l2-network-
topology-02 (work in progress), December 2015. topology-02 (work in progress), December 2015.
[I-D.ietf-i2rs-yang-network-topo] [I-D.ietf-i2rs-yang-network-topo]
Clemm, A., Medved, J., Varga, R., Tkacik, T., Bahadur, N., Clemm, A., Medved, J., Varga, R., Tkacik, T., Bahadur, N.,
and H. Ananthakrishnan, "A Data Model for Network and H. Ananthakrishnan, "A Data Model for Network
Topologies", draft-ietf-i2rs-yang-network-topo-02 (work in Topologies", draft-ietf-i2rs-yang-network-topo-02 (work in
progress), December 2015. progress), December 2015.
[I-D.ietf-idr-bgp-model]
Shaikh, A., Shakir, R., Patel, K., Hares, S., D'Souza, K.,
Bansal, D., Clemm, A., Alex, A., Jethanandani, M., and X.
Liu, "BGP Model for Service Provider Networks", draft-
ietf-idr-bgp-model-01 (work in progress), January 2016.
[I-D.ietf-isis-yang-isis-cfg] [I-D.ietf-isis-yang-isis-cfg]
Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L. Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L.
Lhotka, "YANG Data Model for ISIS protocol", draft-ietf- Lhotka, "YANG Data Model for ISIS protocol", draft-ietf-
isis-yang-isis-cfg-02 (work in progress), March 2015. isis-yang-isis-cfg-02 (work in progress), March 2015.
[I-D.ietf-l3sm-l3vpn-service-model]
Litkowski, S., Shakir, R., Tomotaki, L., Ogaki, K., and K.
D'Souza, "YANG Data Model for L3VPN service delivery",
draft-ietf-l3sm-l3vpn-service-model-05 (work in progress),
March 2016.
[I-D.ietf-netconf-call-home] [I-D.ietf-netconf-call-home]
Watsen, K., "NETCONF Call Home and RESTCONF Call Home", Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
draft-ietf-netconf-call-home-06 (work in progress), May draft-ietf-netconf-call-home-06 (work in progress), May
2015. 2015.
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-04 (work in Protocol", draft-ietf-netconf-restconf-04 (work in
progress), January 2015. progress), January 2015.
skipping to change at page 40, line 5 skipping to change at page 41, line 5
Reddy, T., Patil, P., Isomaki, M., and D. Wing, Reddy, T., Patil, P., Isomaki, M., and D. Wing,
"Optimizing NAT and Firewall Keepalives Using Port Control "Optimizing NAT and Firewall Keepalives Using Port Control
Protocol (PCP)", draft-ietf-pcp-optimize-keepalives-06 Protocol (PCP)", draft-ietf-pcp-optimize-keepalives-06
(work in progress), May 2015. (work in progress), May 2015.
[I-D.ietf-pcp-proxy] [I-D.ietf-pcp-proxy]
Perreault, S., Boucadair, M., Penno, R., Wing, D., and S. Perreault, S., Boucadair, M., Penno, R., Wing, D., and S.
Cheshire, "Port Control Protocol (PCP) Proxy Function", Cheshire, "Port Control Protocol (PCP) Proxy Function",
draft-ietf-pcp-proxy-08 (work in progress), May 2015. draft-ietf-pcp-proxy-08 (work in progress), May 2015.
[I-D.ietf-rtgwg-policy-model]
Shaikh, A., Shakir, R., D'Souza, K., and C. Chase,
"Routing Policy Configuration Model for Service Provider
Networks", draft-ietf-rtgwg-policy-model-00 (work in
progress), September 2015.
[I-D.ietf-sacm-architecture] [I-D.ietf-sacm-architecture]
Cam-Winget, N., Lorenzin, L., McDonald, I., and l. Cam-Winget, N., Lorenzin, L., McDonald, I., and l.
loxx@cisco.com, "Secure Automation and Continuous loxx@cisco.com, "Secure Automation and Continuous
Monitoring (SACM) Architecture", draft-ietf-sacm- Monitoring (SACM) Architecture", draft-ietf-sacm-
architecture-03 (work in progress), March 2015. architecture-05 (work in progress), October 2015.
[I-D.ietf-sacm-terminology] [I-D.ietf-sacm-terminology]
Waltermire, D., Montville, A., Harrington, D., Cam-Winget, Birkholz, H., Lu, J., and N. Cam-Winget, "Secure
N., Lu, J., Ford, B., and M. Kaeo, "Terminology for Automation and Continuous Monitoring (SACM) Terminology",
Security Assessment", draft-ietf-sacm-terminology-06 (work draft-ietf-sacm-terminology-09 (work in progress), March
in progress), February 2015. 2016.
[I-D.kini-i2rs-fb-rib-info-model] [I-D.ietf-teas-yang-rsvp]
Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan, Beeram, V., Saad, T., Gandhi, R., Liu, X., Shah, H., Chen,
R., Bogdanovic, D., Tantsura, J., and R. White, "Filter- X., Jones, R., and B. Wen, "A YANG Data Model for Resource
Based RIB Information Model", draft-kini-i2rs-fb-rib-info- Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp-03
model-02 (work in progress), October 2015. (work in progress), March 2016.
[I-D.l3vpn-service-yang] [I-D.ietf-teas-yang-te-topo]
Litkowski, S., Shakir, R., Tomotaki, L., and K. D'Souza, Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
"YANG Data Model for L3VPN service delivery", draft-l3vpn- O. Dios, "YANG Data Model for TE Topologies", draft-ietf-
service-yang-00 (work in progress), February 2015. teas-yang-te-topo-04 (work in progress), March 2016.
[I-D.liu-bess-mvpn-yang] [I-D.kini-i2rs-fb-rib-info-model]
Liu, Y. and F. Guo, "Yang Data Model for Multicast in Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan,
MPLS/BGP IP VPNs", draft-liu-bess-mvpn-yang-00 (work in R., Bogdanovic, D., and R. White, "Filter-Based RIB
progress), April 2015. Information Model", draft-kini-i2rs-fb-rib-info-model-03
(work in progress), February 2016.
[I-D.shaikh-idr-bgp-model] [I-D.li-bess-l3vpn-yang]
Shaikh, A., D'Souza, K., Bansal, D., and R. Shakir, "BGP Li, Z., Zhuang, S., Liu, X., Haas, J., Esale, S., and B.
Model for Service Provider Networks", draft-shaikh-idr- Wen, "Yang Data Model for BGP/MPLS IP VPN", draft-li-bess-
bgp-model-01 (work in progress), March 2015. l3vpn-yang-00 (work in progress), October 2015.
[I-D.shaikh-rtgwg-policy-model] [I-D.pkd-pce-pcep-yang]
Shaikh, A., Shakir, R., D'Souza, K., and C. Chase, Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
"Routing Policy Configuration Model for Service Provider YANG Data Model for Path Computation Element
Networks", draft-shaikh-rtgwg-policy-model-01 (work in Communications Protocol (PCEP)", draft-pkd-pce-pcep-
progress), July 2015. yang-05 (work in progress), January 2016.
[I-D.tsingh-bess-pbb-evpn-yang-cfg] [I-D.raza-mpls-ldp-mldp-yang]
Tiruveedhula, K., Singh, T., Sajassi, A., Kumar, D., and Raza, K., Asati, R., Liu, X., Esale, S., Chen, X., and H.
L. Jalil, "YANG Data Model for PBB EVPN protocol", draft- Shah, "YANG Data Model for MPLS LDP and mLDP", draft-raza-
tsingh-bess-pbb-evpn-yang-cfg-00 (work in progress), March mpls-ldp-mldp-yang-03 (work in progress), March 2016.
2015.
[I-D.zhang-i2rs-l1-topo-yang-model] [I-D.saad-mpls-static-yang]
Zhang, X., Rao, B., and X. Liu, "A YANG Data Model for Raza, K., Gandhi, R., Liu, X., Beeram, V., Saad, T., Chen,
Layer 1 Network Topology", draft-zhang-i2rs-l1-topo-yang- X., Jones, R., and B. Wen, "A YANG Data Model for MPLS
model-01 (work in progress), March 2015. Base and Static LSPs", draft-saad-mpls-static-yang-02
(work in progress), March 2016.
[I-D.zhdankin-idr-bgp-cfg] [I-D.shah-bess-l2vpn-yang]
Alex, A., Patel, K., Clemm, A., Hares, S., Jethanandani, Shah, H., Brissette, P., Rahman, R., Raza, K., Li, Z.,
M., and X. Liu, "Yang Data Model for BGP Protocol", draft- Zhuang, S., Wang, H., Chen, I., Ahmed, S., Bocci, M.,
zhdankin-idr-bgp-cfg-00 (work in progress), January 2015. Hardwick, J., Esale, S., Tiruveedhula, K., Singh, T.,
Hussain, I., Wen, B., Walker, J., Delregno, N., Jalil, L.,
and M. Joecylyn, "YANG Data Model for MPLS-based L2VPN",
draft-shah-bess-l2vpn-yang-01 (work in progress), March
2016.
[I-D.zhuang-bess-evpn-yang] [I-D.zhang-ccamp-transport-ctrlnorth-yang]
Zhuang, S. and Z. Li, "Yang Model for Ethernet VPN", Zhang, X., Jing, R., Jian, W., Ryoo, J., Xu, Y., and D.
draft-zhuang-bess-evpn-yang-00 (work in progress), King, "YANG Models for the Northbound Interface of a
December 2014. Transport Network Controller: Requirements, Functions, and
a List of YANG Models", draft-zhang-ccamp-transport-
ctrlnorth-yang-00 (work in progress), March 2016.
[I-D.zhuang-bess-l3vpn-yang] [I-D.zheng-mpls-lsp-ping-yang-cfg]
Zhuang, S. and Z. Li, "Yang Data Model for BGP/MPLS IP Zheng, L., Aldrin, S., Zheng, G., Mirsky, G., and R.
VPNs", draft-zhuang-bess-l3vpn-yang-00 (work in progress), Rahman, "Yang Data Model for LSP-PING", draft-zheng-mpls-
December 2014. lsp-ping-yang-cfg-03 (work in progress), March 2016.
[RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan, [RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan,
R., and A. Sastry, "The COPS (Common Open Policy Service) R., and A. Sastry, "The COPS (Common Open Policy Service)
Protocol", RFC 2748, DOI 10.17487/RFC2748, January 2000, Protocol", RFC 2748, DOI 10.17487/RFC2748, January 2000,
<http://www.rfc-editor.org/info/rfc2748>. <http://www.rfc-editor.org/info/rfc2748>.
[RFC2940] Smith, A., Partain, D., and J. Seligson, "Definitions of [RFC2940] Smith, A., Partain, D., and J. Seligson, "Definitions of
Managed Objects for Common Open Policy Service (COPS) Managed Objects for Common Open Policy Service (COPS)
Protocol Clients", RFC 2940, DOI 10.17487/RFC2940, October Protocol Clients", RFC 2940, DOI 10.17487/RFC2940, October
2000, <http://www.rfc-editor.org/info/rfc2940>. 2000, <http://www.rfc-editor.org/info/rfc2940>.
 End of changes. 169 change blocks. 
404 lines changed or deleted 499 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/