draft-kumar-i2nsf-client-facing-interface-req-01.txt   draft-kumar-i2nsf-client-facing-interface-req-02.txt 
I2NSF Working Group R. Kumar I2NSF Working Group R. Kumar
Internet-Draft A. Lohiya Internet-Draft A. Lohiya
Intended status: Informational Juniper Networks Intended status: Informational Juniper Networks
Expires: April 12, 2017 D. Qi Expires: May 1, 2017 D. Qi
Bloomberg Bloomberg
N. Bitar N. Bitar
S. Palislamovic S. Palislamovic
Nokia Nokia
L. Xia L. Xia
Huawei Huawei
October 9, 2016 October 28, 2016
Requirements for Client-Facing Interface to Security Controller Requirements for Client-Facing Interface to Security Controller
draft-kumar-i2nsf-client-facing-interface-req-01 draft-kumar-i2nsf-client-facing-interface-req-02
Abstract Abstract
This document captures the requirements for the client-facing This document captures the requirements for the client-facing
interface to security controller. The interfaces are based on user- interface to the security controller. The interfaces are based on
intent instead of developer-specific or device-centric approaches user constructs understood by a security admin instead of a vendor or
that would require deep knowledge of specific products and their a device specific mechanism requiring deep knowledge of individual
security features. The document identifies the requirements needed products and features. This document identifies the requirements
to enforce the user-intent based policies onto network security needed to enforce the user-construct oriented policies onto network
functions (NSFs) irrespective of how those functions are realized. security functions (NSFs) irrespective of how those functions are
The function may be physical or virtual in nature and may be realized. The function may be physical or virtual in nature and may
implemented in networking or dedicated appliances. be implemented in networking or dedicated appliances.
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 April 12, 2017. This Internet-Draft will expire on May 1, 2017.
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 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in this Document . . . . . . . . . . . . . . 4 2. Conventions Used in this Document . . . . . . . . . . . . . . 4
3. Guiding principles for definition of Client-Facing Interfaces 5 3. Guiding principles for definition of Client-Facing Interfaces 5
3.1. User-intent based modeling . . . . . . . . . . . . . . . 5 3.1. User-construct based modeling . . . . . . . . . . . . . . 5
3.2. Basic rules for interface definition . . . . . . . . . . 6 3.2. Basic rules for client interface definition . . . . . . . 6
3.3. Independent of deployment models . . . . . . . . . . . . 6 3.3. Deployment Models for Implementing Security Policies . . 7
4. Functional Requirements for the Client-Facing Interface . . . 10 4. Functional Requirements for the Client-Facing Interface . . . 10
4.1. Requirement for Multi-Tenancy . . . . . . . . . . . . . . 11 4.1. Requirement for Multi-Tenancy in client interface . . . . 11
4.2. Requirement for Authentication and Authorization . . . . 12 4.2. Requirement for Authentication and Authorization of
4.3. Requirement for Role-Based Access Control (RBAC) . . . . 12 client interface . . . . . . . . . . . . . . . . . . . . 12
4.4. Requirement for Protection from Attacks . . . . . . . . . 12 4.3. Requirement for Role-Based Access Control (RBAC) in
4.5. Requirement for Protection from Misconfiguration . . . . 13 client interface . . . . . . . . . . . . . . . . . . . . 12
4.6. Requirement for Policy Lifecycle Management . . . . . . . 13 4.4. Requirement to protect client interface from attacks . . 12
4.7. Requirement for Dynamic Policy Endpoint Groups . . . . . 14 4.5. Requirement to protect client interface from
4.8. Requirement for Policy Rules . . . . . . . . . . . . . . 16 misconfiguration . . . . . . . . . . . . . . . . . . . . 13
4.9. Requirement for Policy Actions . . . . . . . . . . . . . 16 4.6. Requirement to manage policy lifecycle with diverse needs 13
4.10. Requirement for Generic Policy Models . . . . . . . . . . 18 4.7. Requirement to define dynamic policy Endpoint group . . . 14
4.11. Requirement for Policy Conflict Resolution . . . . . . . 18 4.8. Requirement to express rich set of policy rules . . . . . 15
4.12. Requirement for Backward Compatibility . . . . . . . . . 18 4.9. Requirement to express rich set of policy actions . . . . 16
4.13. Requirement for Third-Party Integration . . . . . . . . . 18 4.10. Requirement to express policy in a generic model . . . . 18
4.14. Requirement for Telemetry Data . . . . . . . . . . . . . 19 4.11. Requirement to detect and correct policy conflicts . . . 18
4.12. Requirement for backward compatibility . . . . . . . . . 18
4.13. Requirement for Third-Party integration . . . . . . . . . 19
4.14. Requirement to collect telemetry data . . . . . . . . . . 19
5. Operational Requirements for the Client-Facing Interface . . 19 5. Operational Requirements for the Client-Facing Interface . . 19
5.1. API Versioning . . . . . . . . . . . . . . . . . . . . . 19 5.1. API Versioning . . . . . . . . . . . . . . . . . . . . . 19
5.2. API Extensiblity . . . . . . . . . . . . . . . . . . . . 19 5.2. API Extensiblity . . . . . . . . . . . . . . . . . . . . 20
5.3. APIs and Data Model Transport . . . . . . . . . . . . . . 20 5.3. APIs and Data Model Transport . . . . . . . . . . . . . . 20
5.4. Notification . . . . . . . . . . . . . . . . . . . . . . 20 5.4. Notification . . . . . . . . . . . . . . . . . . . . . . 20
5.5. Affinity . . . . . . . . . . . . . . . . . . . . . . . . 20 5.5. Affinity . . . . . . . . . . . . . . . . . . . . . . . . 20
5.6. Test Interface . . . . . . . . . . . . . . . . . . . . . 20 5.6. Test Interface . . . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
8. Normative References . . . . . . . . . . . . . . . . . . . . 21 8. Normative References . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Programming security policies in a network has been a fairly complex Programming security policies in a network has been a fairly complex
task that often requires very deep knowledge of developers' specific task that often requires very deep knowledge of vendor specific
devices. This has been the biggest challenge for both service devices. This has been the biggest challenge for both service
providers and enterprises, henceforth named as security administrator providers and enterprises, henceforth named as security administrator
in this document. The challenge is amplified due to virtualization in this document. The challenge is amplified due to virtualization
because security appliances come in both physical and virtual forms with security appliances in physical and virtual form factor from a
and are supplied by a variety of developers who have their own wide variety of vendors; each vendor have their own proprietary
proprietary interfaces to manage and implement the security policies interfaces to express security policies on their devices.
on their devices.
Even if a security administrator deploys a single developer solution Even if a security administrator deploys a single vendor solution
with a set of one or more security functions across its entire with one or more security appliances across its entire network, it is
network, it is difficult to manage security policies due to the still difficult to manage security policies due to complexity of
complexity of network security features available in the developer security features, and difficulty in mapping business requirement to
devices, and the difficulty in mapping the user intent to developer- vendor specific configuration. The security administrator may use
specific configurations. The security administrator may use asset of either vendor provided CLIs or management system with some
developer-specific APIs or a developer-provided management system abstraction to help provision and manage security policies. But, the
that gives some abstraction in the form of GUI to help provision and single vendor approach is highly restrictive in today's network for
manage security policies. However, the single developer approach is the following reasons:
highly restrictive in today's network for the following reasons:
o The security administrator cannot rely on a single developer o The security administrator cannot rely on a single vendor because
because one developer may not be able keep up to date with the one vendor may not be able to keep up with their security
customer security needs or specific deployment models. requirements or specific deployment model.
o A large organization may have a presence across different sites o A large organization may have a presence across different sites
and regions; which means, it is not possible to have a complete and regions; which means, it may not be possible to deploy same
solution from a single developer due to technical, regulatory or solution from single vendor due to regulatory requirement or
business reasons. organizational policy.
o If and when the security administrator migrates from one developer o If and when security administrator migrates from one vendor to
to another, it is almost impossible to migrate security policies another, it is almost impossible to migrate security policies from
from one management system to another without complex manual work. one vendor solution to another without complex manual workflows.
o Security administrators are implementing various security o Security administrators deploy various security functions in
functions in virtual forms or physical forms to attain the virtual or physical forms to attain the flexibility, elasticity,
flexibility, elasticity, performance, and operational efficiency performance, and operational efficiency they require.
they require. Practically, that often requires different sources Practically, that often requires different sources (vendor, open
(developers and open source) that provide the best of breed for source) to get the best of breed for any such security function.
any such security function.
o The security administrator might choose various devices or network o The security administrator might choose various devices or network
services (such as routers, switches, firewall devices, and services (such as routers, switches, firewall devices, and
overlay-networks) as enforcement points for security policies for overlay-networks) as enforcement points for security policies.
any reason (such as network design simplicity, cost, most-
effective place, scale and performance). This my be for reason (such as network design simplicity, cost,
most-effective place, scale and performance).
In order to ease the deployment of security policies across different In order to ease the deployment of security policies across different
developers and devices, the Interface to Network Security Functions vendors and devices, the Interface to Network Security Functions
(I2NSF) working group in the IETF is defining a client-facing (I2NSF) working group in the IETF is defining a client-facing
interface from the security controller to clients [I-D. ietf-i2nsf- interface from the security controller to clients [I-D. ietf-i2nsf-
framework] [I-D. ietf-i2nsf-terminology]. The easiness of deployment framework] [I-D. ietf-i2nsf-terminology]. Deployment facilitation
should be agnostic to type of device, be it physical or virtual, or should be agnostic to the type of device, be it physical or virtual,
type of the policy, be it dynamic or static. Using these interfaces, or type of the policy, be it dynamic or static. Using these
a user can write any application (e.g. GUI portal, template engine, interfaces, it would become possible to write different kinds of
etc.) to control the implementation of security policies on security application (e.g. GUI portal, template engine, etc.) to control the
functional elements, but this is completely out of scope for the implementation of security policies on security functional elements,
I2NSF working group. though how these applications are implemente are completely out of
the scope of the I2NSF working group, which is only focused on the
interfaces.
This document captures the requirements for the client-facing This document captures the requirements for the client-facing
interface that can be easily used by security administrators without interface that can be easily used by security administrators without
knowledge of specific security devices or features. We refer to this knowledge of specific security devices or features. We refer to this
as "user-intent" based interfaces. To further clarify, in the scope as "user-construct" based interfaces. To further clarify, in the
of this document, the "user-intent" here does not mean some free-from scope of this document, the "user-construct" here does not mean some
natural language input or an abstract intent such as "I want my free-from natural language input or an abstract intent such as "I
traffic secure" or "I don't want DDoS attacks in my network"; rather want my traffic secure" or "I don't want DDoS attacks in my network";
the user-intent here means that policies are described using client- rather the user-construct here means that policies are described
oriented expressions such as application names, application groups, using client-oriented expressions such as application names,
device groups, user groups etc. with a vocabulary of verbs (e.g., application groups, device groups, user groups etc. with a vocabulary
drop, tap, throttle), prepositions, conjunctions, conditionals, of verbs (e.g., drop, tap, throttle), prepositions, conjunctions,
adjectives, and nouns instead of using standard n-tuples from the conditionals, adjectives, and nouns instead of using standard
packet header. n-tuples from the packet header.
2. Conventions Used in this Document 2. Conventions Used in this Document
BSS: Business Support System BSS: Business Support System
CLI: Command Line Interface CLI: Command Line Interface
CMDB: Configuration Management Database CMDB: Configuration Management Database
Controller: Used interchangeably with Service Provider Security Controller: Used interchangeably with Service Provider Security
skipping to change at page 5, line 24 skipping to change at page 5, line 26
SIEM: Security Information and Event Management SIEM: Security Information and Event Management
URL: Universal Resource Locator URL: Universal Resource Locator
vNSF: Refers to NSF being instantiated on Virtual Machines vNSF: Refers to NSF being instantiated on Virtual Machines
3. Guiding principles for definition of Client-Facing Interfaces 3. Guiding principles for definition of Client-Facing Interfaces
The "Client-Facing Interface" ensures that a security administrator The "Client-Facing Interface" ensures that a security administrator
can deploy any device from any developer and still be able to use can deploy any device from any vendor and still be able to use a
same consistent interface. In essence, these interfaces provide a consistent interface. In essence, this interface gives ability to
management framework to manage security administrator's security security admins to express their security policies independent of how
policies. Henceforth in this document, we use "security policy security functions are implemented in their deployment. Henceforth,
management interface" interchangeably when we refer to the client- in this document, we use "security policy management interface"
facing interface. interchangeably when we refer to the client-facing interface.
3.1. User-intent based modeling 3.1. User-construct based modeling
Traditionally, security policies have been expressed using Traditionally, security policies have been expressed using
proprietary interfaces. These interfaces are defined by a developer proprietary interfaces. These interface are defined by a vendor
either based on CLI or a GUI system; but more often these interfaces either based on CLI or a GUI system; but more often these interfaces
are built using developer specific networking construct such IP are built using vendor specific networking construct such IP address,
address, protocol and application constructs with L4-L7 information. protocol and application constructs with L4-L7 information. This
This requires security operators to translate their oragnzational requires security operator to translate their oragnzational business
business objectives into actionable security policies on security objectives into actionable security policies on the device using
device using developers policy constructs. But, this alone is not vendor specific configuration. But, this alone is not sufficient to
sufficient to render policies in the network as operator also need to render policies in the network as operator also need to identify the
identify the device where the policy need to be applied in a complex device in the network topology where a policy need to be enforced in
network environment with multiple policy enforcement points. a complex environment with potenial multiple policy enforcement
points.
The User-intent based framework defines constructs such as user- The User-construct based framework defines constructs such as user-
group, application-group, device-group and location group. The group, application-group, device-group and location-group. The
security operator would use these constructs to express a security security admin would use these constructs to express a security
policy instead of proprietary constructs. The policy defined in such policy instead of proprietary vendor specific constructs. The policy
a manner is referred to user-intent based policies in this draft. defined in such a manner is referred to user-construct based policies
The idea is to enable security operator to use constructs they knows in this draft. The idea is to enable security admin to use
best in expressing security policies; which simplify their tasks and constructs they understand best in expressing security policies;
help in avoiding human errors in complex security provisioing. which simplify their tasks and help avoiding human errors in complex
security provisioning.
3.2. Basic rules for interface definition 3.2. Basic rules for client interface definition
The basic rules in defining the client-facing interfaces are as The basic rules in defining the client-facing interfaces are as
following: follows:
o Agnostic of network topology and NSF location in the network.
o Agnostic to the features and capabilities supported in NSFs. o Not depending on particular network topology or the actual NSF
location in the network
o Agnostic to the resources available in NSFs or resources available o Not requiring the exact knowledge of the concrete features and
for various features/capabilities. capabilities supported in the deployed NSFsa€
o Agnostic to the network function type, be it stateful firewall, o Independent of the nature of the function that will apply the
IDP, IDS, Router, Switch. expressed policies be it stateful firewall,IDP, IDS, Router,
Switch
o Declarative/Descriptive model instead of Imperative/Prescriptive o Declarative/Descriptive model instead of Imperative/Prescriptive
model - What security policies need to enforce (declarative) model - What security policies need to be enforced (declarative)
instead of how they would be actually implemented (imperative). instead of how they would be actually implemented (imperative)
o Agnostic of developer, implementation and form-factor (physical,
virtual).
o Agnostic to how NSF is implemented and its hosting environment. o Not depending on any specific vendor implementation or form-factor
(physical, virtual) of the NSF
o Agnostic to how NSF becomes operational - Network connectivity and o Not depending on how a NSF becomes operational - Network
other hosting requirements connectivity and other hosting requirements.
o Agnostic to NSF control plane implementation (if there is one) o Not depending on NSF control plane implementation (if there is
E.g., cluster of NSF active as one unified service for scale and/ one) E.g., cluster of NSFs active as one unified service for scale
or resilience. and/ or resilience.
o Agnostic to NSF data plane implementation i.e. Encapsulation, o Not depending on specific data plane implementation of NSF i.e.
Service function chains. Encapsulation, Service function chains.
3.3. Independent of deployment models Note that the rules stated above only apply to the client-facing
interface where a user will define a high level policy. These rules
do not apply to the lower layers e.g. security controller that
convert the higher level policies into lower level constructs. The
lower layers may still need some intelligence such as topology
awareness, capability of the NSF and its functions, supported
encapsulations etc. to convert and apply the policies accurately on
the NSF devices.
This document does not describe requirements for NSF-facing 3.3. Deployment Models for Implementing Security Policies
interface; they are expected to be defined in a separate draft. This
draft does not mandate a specific deployment model but rather shows
how client interfaces remain the same and interact with the overall
security framework from security administrator's perspective.
Traditionally, medium and larger operators deploy management systems Traditionally, medium and larger operators deploy management systems
to manage their statically-defined security policies. This approach to manage their statically-defined security policies. This approach
may not be suitable nor sufficient for modern automated and dynamic may not be suitable nor sufficient for modern automated and dynamic
data centers that are largely virtualized and rely on various data centers that are largely virtualized and rely on various
management systems and controllers to dynamically implement security management systems and controllers to dynamically implement security
policies over any types of resources. policies over any types of resources.
There are two different deployment models in which the client-facing There are two different deployment models in which the client-facing
interface referred to in this document could be implemented. These interface referred to in this document could be implemented. These
models have no direct impact on the client-facing interface, but models have no direct impact on the client-facing interface, but
illustrate the overall security policy and management framework and illustrate the overall security policy and management framework and
where the various processing functions reside. These models are: where the various processing functions reside. These models are:
a. Management without an explicit management system for control of a. Management without an explicit management system for control of
devices and NSFs. In this deployment, the security controller devices and NSFs. In this deployment, the security controller
acts as a NSF policy management system that takes information acts as a NSF policy management system that takes information
passed over the client security policy interface and translates passed over the client security policy interface and translates
into data on the I2NSF southbound interface. The I2NSF into data on the I2NSF NSF-facing interface. The I2NSF
interfaces are implemented by security device/function interfaces are implemented by security device/function vendors.
developers. This would usually be done by having an I2NSF agent This would usually be done by having an I2NSF agent embedded in
embedded in the security device or NSF. This deployment model is the security device or NSF. This deployment model is shown in
shown in Figure 1. Figure 1.
RESTful API RESTful API
SUPA or I2NSF Policy Management SUPA or I2NSF Policy Management
^ ^
Client-facing | |
Security Policy Interface | Client-facing Interface |
(Independent of individual | (Independent of individual |
NSFs, devices,and developers)| NSFs, devices,and vendors)|
| |
------------------------------ ------------------------------
| | | |
| Security Controller | | Security Controller |
| | | |
------------------------------ ------------------------------
| ^ | ^
Southbound Security | I2NSF | | I2NSF |
Capability Interface | NSF-facing | NSF Interface | NSF-facing |
(Specific to NSFs) | Interface | (Specific to NSFs) | Interface |
.............................. ..............................
| | | |
v | v |
------------- ------------- ------------- -------------
| I2NSF Agent | | I2NSF Agent | | I2NSF Agent | | I2NSF Agent |
|-------------| |-------------| |-------------| |-------------|
| |---| | | |---| |
| NSF | | NSF | | NSF | | NSF |
skipping to change at page 8, line 49 skipping to change at page 8, line 49
| |---| | | |---| |
| NSF | | NSF | | NSF | | NSF |
| | | | | | | |
------------- ------------- ------------- -------------
Figure 1: Deployment without Management System Figure 1: Deployment without Management System
b. Management with an explicit management system for control of b. Management with an explicit management system for control of
devices and NSFs. This model is similar to the model above devices and NSFs. This model is similar to the model above
except that security controller interacts with a dedicated except that security controller interacts with a dedicated
management system which could either proxy I2NSF southbound management system which could either proxy I2NSF NSF-facing
interfaces or could provide a layer where security devices or interfaces or could provide a layer where security devices or
NSFs do not support an I2NSF agent to process I2NSF southbound NSFs do not support an I2NSF agent to process I2NSF NSF-facing
interfaces. This deployment model is shown in Figure 2. interfaces. This deployment model is shown in Figure 2.
RESTful API RESTful API
SUPA or I2NSF Policy Management SUPA or I2NSF Policy Management
^ ^
Client-facing | |
Security Policy Interface | Client-facing Interface |
(Independent of individual | (Independent of individual |
NSFs,devices,and developers) | NSFs,devices,and vendors) |
| |
------------------------------ ------------------------------
| | | |
| Security Controller | | Security Controller |
| | | |
------------------------------ ------------------------------
| ^ | ^
Southbound Security | I2NSF | | I2NSF |
Capability Interface | NSF-facing | NSF Interface | NSF-facing |
(Specific to NSFs) | Interface | (Specific to NSFs) | Interface |
.............................. ..............................
| | | |
v | v |
------------------------------ ------------------------------
| | | |
| I2NSF Proxy Agent / | | I2NSF Proxy Agent / |
| Management System | | Management System |
| | | |
------------------------------ ------------------------------
skipping to change at page 10, line 21 skipping to change at page 10, line 21
affect the client security policy interface, they do give an overall affect the client security policy interface, they do give an overall
context for defining a security policy interface based on context for defining a security policy interface based on
abstraction. abstraction.
4. Functional Requirements for the Client-Facing Interface 4. Functional Requirements for the Client-Facing Interface
As stated in the guiding principles for defining I2NSF client-facing As stated in the guiding principles for defining I2NSF client-facing
interface, the security policies and the client-facing interface interface, the security policies and the client-facing interface
shall be defined from a user/client perspective and abstracted away shall be defined from a user/client perspective and abstracted away
from the type of NSF, NSF specific implementation, controller from the type of NSF, NSF specific implementation, controller
implementation, NSF topology, NSF interfaces, controller southbound implementation, NSF topology, NSF interfaces, controller NSF-facing
interfaces. Thus, the security policy definition shall be interfaces. Thus, the security policy definition shall be
declarative, expressing the user/client intent, and driven by how declarative, expressing the user construct, and driven by how
security administrators view security policies from the definition, security administrators view security policies from the definition,
communication and deployment perspective. communication and deployment perspective.
The security controller's implementation is outside the scope of this The security controller's implementation is outside the scope of this
document and the I2NSF working group. document and the I2NSF working group.
At a high level, the requirements for the client-facing interface in In order to express and build security policies, high level
order to express and build security policies are as follows: requirements for the client-facing are as follows:
o Multi-Tenancy o Multi-Tenancy
o Authentication and Authorization o Authentication and Authorization
o Role-Based Access Control (RBAC) o Role-Based Access Control (RBAC)
o Protection from Attacks o Protection from Attacks
o Protection from Misconfiguration o Protection from Misconfiguration
skipping to change at page 11, line 14 skipping to change at page 11, line 14
o Generic Policy Model o Generic Policy Model
o Policy Conflict Resolution o Policy Conflict Resolution
o Backward Compatibility o Backward Compatibility
o Third-Party Integration o Third-Party Integration
o Telemetry Data o Telemetry Data
The above constructs are by no means a complete list and may not be The above requirements are by no means a complete list and may not be
sufficient for all use-cases and all operators, but should be a good sufficient for all use-cases and all operators, but should be a good
start for a wide variety of use-cases in both Service Provider starting point for a wide variety of use-cases in Service Provider
networks and Enterprise networks. and Enterprise networks.
4.1. Requirement for Multi-Tenancy 4.1. Requirement for Multi-Tenancy in client interface
A security administrator that uses security policies may have A security administrator that uses security policies may have
internal tenants and would like to have a framework wherein each internal tenants and would like to have a framework wherein each
tenant manages its own security policies to provide isolation across tenant manages its own security policies with isolation from other
different tenants. tenants.
An operator may be a cloud service provider with multi-tenant An operator may be a cloud service provider with multi-tenant
deployments where each tenant is a different organization and must deployments, where each tenant is a different customer. Each tenant
allow complete isolation across different tenants. or customer must be allowed to manage its own security policies.
It should be noted that tenants in turn can have their own tenants, It should be noted that tenants may have their own tenants, so a
so a recursive relation exists. For instance, a tenant in a cloud recursive relation may exist. For instance, a tenant in a cloud
service provider may have multiple departments or organizations that service provider may have multiple departments or organizations that
need to manage their own security rules. need to manage their own security rules.
Some key concepts are listed below and used throughout the document Some key concepts are listed below and used throughout the document
hereafter: hereafter:
Policy-Tenant: An entity that owns and manages the security Policies Policy-Tenant: An entity that owns and manages the security Policies
applied on itself. applied on its resources.
Policy-Administrator: A user authorized to manage the security Policy-Administrator: A user authorized to manage the security
policies for a Policy-Tenant. policies for a Policy-Tenant.
Policy-User: A user within a Policy-Tenant who is authorized to Policy-User: A user within a Policy-Tenant who is authorized to
access certain resources of that tenant according to the security access certain resources of that tenant according to the
policies of the Policy-Tenant. privileges assigned to it.
Policy-User-Group: A collection of Policy-Users. This group
identifies a set of users based on a policy tag or on static
information. The tag to identify the user is dynamically derived
from systems such as Active Directory or LDAP. For example, an
operator may have different user-groups, such as HR-users,
Finance-users, Engineering-users, to classify a set of users in
each department.
4.2. Requirement for Authentication and Authorization 4.2. Requirement for Authentication and Authorization of client
interface
Security administrators MUST authenticate to and be authorized by Security administrators MUST authenticate to and be authorized by the
security controller before they are able to issue control commands security controller before they are able to issue control commands
and any policy data exchange commences. and any policy data exchange commences.
There must be methods defined for Policy-Administrator be There must be methods defined for the Policy-Administrator to be
authenticated and authorized to use the security controller. There authenticated and authorized to use the security controller. There
are several authentication methods available such as OAuth, XAuth and are several authentication methods available such as OAuth, XAuth and
X.509 certificate based. The authentication scheme between Policy- X.509 certificate based. The authentication scheme between Policy-
Administrator and security controller may also be mutual instead of Administrator and security controller may also be mutual instead of
one-way. Any specific method may be determined based on one-way. Any specific method may be determined based on
organizational and deployment needs and outside the scope of I2NSF. organizational and deployment needs and outside the scope of I2NSF.
In addition, there must be a method to authorize the Policy- In addition, there must be a method to authorize the Policy-
Administrator for performing certain action. It should be noted Administrator for performing certain action. It should be noted
that, depending on the deployment model, Policy-Administrator that, depending on the deployment model, Policy-Administrator
authentication and authorization to perform actions communicated to authentication and authorization to perform actions communicated to
the controller could be performed as part of a portal or another the controller could be performed as part of a portal or another
system prior to communication the action to the controller. system prior to communication the action to the controller.
4.3. Requirement for Role-Based Access Control (RBAC) 4.3. Requirement for Role-Based Access Control (RBAC) in client
interface
Policy-Authorization-Role represents a role assigned to a Policy-User Policy-Authorization-Role represents a role assigned to a Policy-User
or Policy-User Group that determines whether the user or the user- that determines whether a user or has read-write access, read-only
group has read-write access, read-only access, or no access for access, or no access for certain resources. A User can be mapped to
certain resources. A User or a User-Group can be mapped to a Policy- a Policy-Authorization-Role using an internal or external identity
Authorization- Role using an internal or external identity provider provider or mapped statically.
or mapped statically.
4.4. Requirement for Protection from Attacks 4.4. Requirement to protect client interface from attacks
There Must be protections from attacks, malicious or otherwise, from There Must be protections from attacks, malicious or otherwise, from
clients or a client impersonator. Potential attacks could come from clients or a client impersonator. Potential attacks could come from
a botnet or a host or hosts infected with virus or some unauthorized a botnet or a host or hosts infected with virus or some unauthorized
entity. It is recommended that security controller use adedicated IP entity. It is recommended that security controller use a dedicated
interface for client-facing communications and those communications IP interface for client-facing communications and those
should be carried over an isolated out-of-band network. In addition, communications should be carried over an isolated out-of-band
it is recommended that traffic between clients and security network. In addition, it is recommended that traffic between clients
controllers be encrypted. Furthermore, some straightforward traffic/ and security controllers be encrypted. Furthermore, some
session control mechanisms (i.e., Rate-limit, ACL, White/Black list) straightforward traffic/session control mechanisms (i.e., Rate-limit,
can be employed on the security controller to defend against DDoS ACL, White/Black list) can be employed on the security controller to
flooding attacks. defend against DDoS flooding attacks.
4.5. Requirement for Protection from Misconfiguration 4.5. Requirement to protect client interface from misconfiguration
There Must be protections from mis-configured clients, unintentional There Must be protections from mis-configured clients. System and
or otherwise. System and policy validations should be implemented. policy validations should be implemented to detect this. Validation
Validation may be based on a set of default parameters or custom may be based on a set of default parameters or custom tuned
tuned thresholds such as # of policy changes submitted; # of objects thresholds such as the number of policy changes submitted, number of
requested in given time interval, etc. objects requested in a given time interval, etc.
4.6. Requirement for Policy Lifecycle Management 4.6. Requirement to manage policy lifecycle with diverse needs
In order to provide more sophisticated security framework, there In order to provide more sophisticated security framework, there
should be a mechanism to express that a policy becomes dynamically should be a mechanism to express that a policy becomes dynamically
active/enforced or inactive based on either security administrator active/enforced or inactive based on either security administrator's
intervention or an event. manual intervention or an event.
One example of dynamic policy management is when the security One example of dynamic policy management is when the security
administrator pre-configures all the security policies, but the administrator pre-configures all the security policies, but the
policies get activated/enforced or deactivated based on dynamic policies get activated or deactivated based on dynamic threats.
threats faced by the security administrator. Basically, a threat Basically, a threat event may activate certain inactive policies, and
event may activate certain inactive policies, and once a new event once a new event indicates that the threat has gone away, the
indicates that the threat has gone away, the policies become inactive policies become inactive again.
again.
There are four models for dynamically activating policies: There are following ways for dynamically activating policies:
o The policy may be dynamically activated by the I2NSF client or o The policy may be dynamically activated by the I2NSF client or
associated management entity, and dynamically communicated over the associated management entity, and dynamically communicated over the
I2NSF client-facing interface to the controller to program I2NSF I2NSF client-facing interface to the controller to program I2NSF
functions using the I2NSF NSF-facing interface functions using the I2NSF NSF-facing interface
o The policy may be pulled dynamically by the controller upon o The policy may be pulled dynamically by the controller upon
detecting an event over the I2NSF monitoring interface detecting an event over the I2NSF monitoring interface
o The policy may be statically pushed to the controller and o The policy may be statically pushed to the controller and
dynamically programmed on the NSFs upon potentially detecting another dynamically programmed on the NSFs upon potentially detecting another
event event
o The policy can be programmed in the N2SFs functions, and activated/ o The policy can be programmed in the NSF, and activated or
deactivated upon policy attributes, like time or admin enforced. deactivated upon policy attributes, like time or admin enforced.
The client-facing interface should support the following policy The client-facing interface should support the following policy
attributes for policy enforcement: attributes for policy enforcement:
Admin-Enforced: The policy, once configured, remains active/enforced Admin-Enforced: The policy, once configured, remains active/enforced
until removed by the security administrator. until removed by the security administrator.
Time-Enforced: The policy configuration specifies the time profile Time-Enforced: The policy configuration specifies the time profile
that determines when policy is activated/enforced. Otherwise, it that determines when policy is activated/enforced. Otherwise, it
skipping to change at page 14, line 18 skipping to change at page 14, line 14
Event-Enforced: The policy configuration specifies the event profile Event-Enforced: The policy configuration specifies the event profile
that determines when policy is activated/enforced. It also that determines when policy is activated/enforced. It also
specifies the duration attribute of that policy once activated specifies the duration attribute of that policy once activated
based on event. For instance, if the policy is activated upon based on event. For instance, if the policy is activated upon
detecting an application flow, the policy could be de-activated detecting an application flow, the policy could be de-activated
when the corresponding session is closed or the flow becomes when the corresponding session is closed or the flow becomes
inactive for certain time. inactive for certain time.
A policy could be a composite policy, that is composed of many rules, A policy could be a composite policy, that is composed of many rules,
and subject to updates and modification. For policy maintenance and subject to updates and modification. For the policy maintenance,
purposes, enforcement, and auditability, it becomes important to name enforcement, and auditability purposes, it becomes important to name
and version the policies. Thus, the policy definition SHALL support and version the policies. Thus, the policy definition SHALL support
policy naming and versioning. In addition, the i2NSF client-facing policy naming and versioning. In addition, the i2NSF client-facing
interface SHALL support the activation, deactivation, interface SHALL support the activation, deactivation,
programmability, and deletion of policies based on name and version. programmability, and deletion of policies based on name and version.
In addition, it Should support reporting on the state of policies by In addition, it should support reporting on the state of policies by
name and version. For instance, a client may probe the controller name and version. For instance, a client may probe the controller
about the current policies enforced for a tenant and/or a sub-tenant about the current policies enforced for a tenant and/or a sub-tenant
(organization) for auditability or verification purposes. (organization) for auditability or verification purposes.
4.7. Requirement for Dynamic Policy Endpoint Groups 4.7. Requirement to define dynamic policy Endpoint group
When the security administrator configures a security policy, the When the security administrator configures a security policy, it may
intention is to apply this policy to certain subsets of the network. have requirement to apply this policy to certain subsets of the
The subsets may be identified based on criteria such as users, network. The subsets may be identified based on criteria such as
devices, and applications. We refer to such a subset of the network users, devices, and applications. We refer to such a subset of the
as a "Policy Endpoint Group". network as a "Policy Endpoint Group".
One of the biggest challenges for a security administrator is how to One of the biggest challenges for a security administrator is how to
make sure that security policies remain effective while constant make sure that security policies remain effective while constant
changes are happening to the "Policy Endpoint Group" for various changes are happening to the "Policy Endpoint Group" for various
reasons (e.g., organizational changes). If the policy is created reasons (e.g., organizational, network and application changes). If
based on static information such as user names, application, or a policy is created based on static information such as user names,
network subnets, then every time that this static information changes application, or network subnets; then every time this static
policies would need to be updated. For example, if a policy is information change, policies need to be updated. For example, if a
created that allows access to an application only from the group of policy is created that allows access to an application only from the
Human Resource users (the HR-users group), then each time the HR- group of Human Resource users (the HR-users group), then each time
users group changes, the policy needs to be updated. the HR- users group changes, the policy needs to be updated.
Changes to policy could be highly taxing to the security
administrator for various operational reasons. The policy management
framework must allow "Policy Endpoint Group" to be dynamic in nature
so that changes to the group (HR-users in our example) automatically
result in updates to its content.
We call these dynamic Policy Endpoint Groups "Meta-data Driven We call these dynamic Policy Endpoint Groups "Meta-data Driven
Groups". The meta-data is a tag associated with endpoint information Groups". The meta-data is a tag associated with endpoint information
such as users, applications, and devices. The mapping from meta-data such as users, applications, and devices. The mapping from meta-data
to dynamic content could come either from standards-based or to dynamic content could come either from standards-based or
proprietary tools. The security controller could use any available proprietary tools. The security controller could use any available
mechanisms to derive this mapping and to make automatic updates to mechanisms to derive this mapping and to make automatic updates to
the policy content if the mapping information changes. The system the policy content if the mapping information changes. The system
SHOULD allow for multiple, or sets of tags to be applied to a single SHOULD allow for multiple, or sets of tags to be applied to a single
network object. network object.
The client-facing policy interface must support endpoint groups for The client-facing policy interface must support endpoint groups for
user-intent based policy management. The following meta-data driven user-construct based policy management. The following meta-data
groups MAY be used for configuring security polices: driven groups MAY be used for configuring security polices:
User-Group: This group identifies a set of users based on a tag or User-Group: This group identifies a set of users based on a tag or
on static information. The tag to identify user is dynamically on static information. The tag to identify user is dynamically
derived from systems such as Active Directory or LDAP. For derived from systems such as Active Directory or LDAP. For
example, an operator may have different user-groups, such as HR- example, an operator may have different user-groups, such as HR-
users, Finance-users, Engineering-users, to classify a set of users, Finance-users, Engineering-users, to classify a set of
users in each department. users in each department.
Device-Group: This group identifies a set of devices based on a tag Device-Group: This group identifies a set of devices based on a tag
or on static information. The tag to identify device is or on static information. The tag to identify device is
skipping to change at page 16, line 7 skipping to change at page 15, line 46
the associated application packets should be defined and the associated application packets should be defined and
communicated to the NSF. The client-facing Interface shall communicated to the NSF. The client-facing Interface shall
support the communication of this information. support the communication of this information.
Location-Group: This group identifies a set of location tags. Tag Location-Group: This group identifies a set of location tags. Tag
may correspond 1:1 to location. The tag to identify location is may correspond 1:1 to location. The tag to identify location is
either statically defined or dynamically derived from systems such either statically defined or dynamically derived from systems such
as CMDB. For example, a security administrator may want to as CMDB. For example, a security administrator may want to
classify all sites/locations in a geographic region as one group. classify all sites/locations in a geographic region as one group.
4.8. Requirement for Policy Rules 4.8. Requirement to express rich set of policy rules
The security policy rules can be as simple as specifying a match for The security policy rules can be as simple as specifying a match for
the user or application specified through "Policy Endpoint Group" and the user or application specified through "Policy Endpoint Group" and
take one of the "Policy Actions" or more complicated rules that take one of the "Policy Actions" or more complicated rules that
specify how two different "Policy Endpoint Groups" interact with each specify how two different "Policy Endpoint Groups" interact with each
other. The client-facing interface must support mechanisms to allow other. The client-facing interface must support mechanisms to allow
the following rule matches. the following rule matches.
Policy Endpoint Groups: The rule must allow a way to match either a Policy Endpoint Groups: The rule must allow a way to match either a
single or a member of a list of "Policy Endpoint Groups". single or a member of a list of "Policy Endpoint Groups".
There must be a way to express a match between two "Policy Endpoint There must be a way to express a match between two "Policy Endpoint
Groups" so that a policy can be effective for communication between Groups" so that a policy can be effective for communication between
two groups. two groups.
Direction: The rule must allow a way to express whether the security Direction: The rule must allow a way to express whether the security
administrator wants to match the "Policy Endpoint Group" as the administrator wants to match the "Policy Endpoint Group" as the
source or destination. The default should be to match both source or destination. The default should be to match both
directions if the direction rule is not specified in the policy. directions, if the direction rule is not specified in the policy.
Threats: The rule should allow the security administrator to express Threats: The rule should allow the security administrator to express
a match for threats that come either in the form of feeds (such as a match for threats that come either in the form of feeds (such as
botnet feeds, GeoIP feeds, URL feeds, or feeds from a SIEM) or botnet feeds, GeoIP feeds, URL feeds, or feeds from a SIEM) or
speciality security appliances. Threats could be identified by speciality security appliances. Threats could be identified by
Tags/names in policy rules. The tag is a label of one or more Tags/names in policy rules. The tag is a label of one or more
event types that may be detected by a threat detection system. event types that may be detected by a threat detection system.
The threat could be from malware and this requires a way to match for The threat could be from malware and this requires a way to match for
virus signatures or file hashes. virus signatures or file hashes.
4.9. Requirement for Policy Actions 4.9. Requirement to express rich set of policy actions
The security administrator must be able to configure a variety of The security administrator must be able to configure a variety of
actions within a security policy. Typically, security policy actions within a security policy. Typically, security policy
specifies a simple action of "deny" or "permit" if a particular specifies a simple action of "deny" or "permit" if a particular
condition is matched. Although this may be enough for most of the condition is matched. Although this may be enough for most of the
simple policies, the I2NSF client-facing interface must also provide simple policies, the I2NSF client-facing interface must also provide
a more comprehensive set of actions so that the interface can be used a more comprehensive set of actions so that the interface can be used
effectively across various security functions. effectively across various security functions.
Policy action MUST be extensible so that additional policy action Policy action MUST be extensible so that additional policy action
skipping to change at page 17, line 48 skipping to change at page 17, line 41
Decrypt: This action decrypts the packets on an identified flow. Decrypt: This action decrypts the packets on an identified flow.
The flow could be over an Ipsec tunnel, or TLS session for The flow could be over an Ipsec tunnel, or TLS session for
instance. instance.
Throttle: This action defines shaping a flow or a group of flows Throttle: This action defines shaping a flow or a group of flows
that match the rule condition to a designated traffic profile. that match the rule condition to a designated traffic profile.
Mark: This action defines traffic that matches the rule condition by Mark: This action defines traffic that matches the rule condition by
a designated DSCP value and/or VLAN 802.1p Tag value. a designated DSCP value and/or VLAN 802.1p Tag value.
Instantiate-NSF: Instantiate a NSF with predefined profile. A NSF Instantiate-NSF: This action instantiates an NSF with a predefined
can be any of FW, LB, IPS, IDS, honeypot, or VPN, etc. profile. An NSF can be any of the FW, LB, IPS, IDS, honeypot, or
VPN, etc.
WAN-Accelerate: This action optimize packet delivery using a set of WAN-Accelerate: This action optimizes packet delivery using a set of
predefined packet optimization methods. predefined packet optimization methods.
Load-Balance: This action load balance connections based on Load-Balance: This action load balances connections based on
predefined LB schemes or profiles. predefined LB schemes or profiles.
The policy actions should support combination of terminating actions The policy actions should support combination of terminating actions
and non-terminating actions. For example, Syslog and then Permit; and non-terminating actions. For example, Syslog and then Permit;
Count and then Redirect. Count and then Redirect.
Policy actions SHALL support any L2, L3, L4-L7 policy actions. Policy actions SHALL support any L2, L3, L4-L7 policy actions.
4.10. Requirement for Generic Policy Models 4.10. Requirement to express policy in a generic model
Client-facing interface SHALL provide a generic metadata model that Client-facing interface SHALL provide a generic metadata model that
defines once and then be used by appropriate model elements any defines once and then be used by appropriate model elements any
times, regardless of where they are located in the class hierarchy, times, regardless of where they are located in the class hierarchy,
as necessary. as necessary.
Client-facing interface SHALL provide a generic context model that Client-facing interface SHALL provide a generic context model that
enables the context of an entity, and its surrounding environment, to enables the context of an entity, and its surrounding environment, to
be measured, calculated, and/or inferred. be measured, calculated, and/or inferred.
Client-facing interface SHALL provide a generic policy model that Client-facing interface SHALL provide a generic policy model that
enables context-aware policy rules to be defined to change the enables context-aware policy rules to be defined to change the
configuration and monitoring of resources and services as context configuration and monitoring of resources and services as context
changes. changes.
4.11. Requirement for Policy Conflict Resolution Client-facing interface SHALL provide the ability to apply policy or
multiple sets of policies to any given object. Policy application
process SHALL allow for nesting capabilities of given policies or set
of policies. For example, an object or any given set of objects
could have application team applying certain set of policy rules,
while network team would apply different set of their policy rules.
Lastly, security team would have an ability to apply its set of
policy rules, being the last policy to be evaluated against.
4.11. Requirement to detect and correct policy conflicts
Client-facing interface SHALL be able to detect policy "conflicts", Client-facing interface SHALL be able to detect policy "conflicts",
and SHALL specify methods on how to resolve these "conflicts" and SHALL specify methods on how to resolve these "conflicts"
For example: two clients issues conflicting set of security policies For example: two clients issues conflicting set of security policies
to be applied to the same Policy Endpoint Group. to be applied to the same Policy Endpoint Group.
4.12. Requirement for Backward Compatibility 4.12. Requirement for backward compatibility
It MUST be possible to add new capabilities to client-facing It MUST be possible to add new capabilities to client-facing
interface in a backward compatible fashion. interface in a backward compatible fashion.
4.13. Requirement for Third-Party Integration 4.13. Requirement for Third-Party integration
The security policies in the security administrator's network may The security policies in the security administrator's network may
require the use of specialty devices such as honeypots, behavioral require the use of specialty devices such as honeypots, behavioral
analytics, or SIEM in the network, and may also involve threat feeds, analytics, or SIEM in the network, and may also involve threat feeds,
virus signatures, and malicious file hashes as part of comprehensive virus signatures, and malicious file hashes as part of comprehensive
security policies. security policies.
The client-facing interface must allow the security administrator to The client-facing interface must allow the security administrator to
configure these threat sources and any other information to provide configure these threat sources and any other information to provide
integration and fold this into policy management. integration and fold this into policy management.
4.14. Requirement for Telemetry Data 4.14. Requirement to collect telemetry data
One of the most important aspect of security is to have visibility One of the most important aspect of security is to have visibility
into the networks. As threats become more sophisticated, the into the networks. As threats become more sophisticated, the
security administrator must be able to gather different types of security administrator must be able to gather different types of
telemetry data from various devices in the network. The collected telemetry data from various devices in the network. The collected
data could simply be logged or sent to security analysis engines for data could simply be logged or sent to security analysis engines for
behavioral analysis, policy violations, and for threat detection. behavioral analysis, policy violations, and for threat detection.
The client-facing interface MUST allow the security administrator to The client-facing interface MUST allow the security administrator to
collect various kinds of data from NSFs. The data source could be collect various kinds of data from NSFs. The data source could be
skipping to change at page 19, line 36 skipping to change at page 19, line 44
client should be able to receive notifications when a policy is client should be able to receive notifications when a policy is
dynamically updated. dynamically updated.
5. Operational Requirements for the Client-Facing Interface 5. Operational Requirements for the Client-Facing Interface
5.1. API Versioning 5.1. API Versioning
The client-facing interface must support a version number for each The client-facing interface must support a version number for each
RESTful API. This is very important because the client application RESTful API. This is very important because the client application
and the controller application will most likely come from different and the controller application may most likely come from different
developers. Even if the developer is same, it is hard to imagine vendors. Even if the vendor is same, it is hard to imagine that two
that two different applications would be released in lock step. different applications would be released in lock step.
Without API versioning, it is hard to debug and figure out issues if Without API versioning, it is hard to debug and figure out issues if
application breaks. Although API versioning does not guarantee that application breaks. Although API versioning does not guarantee that
applications will always work, it helps in debugging if the problem applications will always work, it helps in debugging if the problem
is caused by an API mismatch. is caused by an API mismatch.
5.2. API Extensiblity 5.2. API Extensiblity
Abstraction and standardization of the client-facing interface is of Abstraction and standardization of the client-facing interface is of
tremendous value to security administrators as it gives them the tremendous value to security administrators as it gives them the
flexibility of deploying any developers' NSF without needing to flexibility of deploying any vendor's NSF without needing to redefine
redefine their policies or change the client interface. However this their policies or change the client interface. However this might
might also look like as an obstacle to innovation. also look like as an obstacle to innovation.
If an NSF developer comes up with new feature or functionality that If a vendor comes up with new feature or functionality that can't be
can't be expressed through the currently defined client-facing expressed through the currently defined client-facing interface,
interface, there must be a way to extend existing APIs or to create a there must be a way to extend existing APIs or to create a new API
new API that is relevant for that NSF developer only. that is relevant for that NSF vendor only.
5.3. APIs and Data Model Transport 5.3. APIs and Data Model Transport
The APIs for client interface must be derived from the YANG based The APIs for client interface must be derived from the YANG based
data model. The YANG data model for client interface must capture data model. The YANG data model for client interface must capture
all the requirements as defined in this document to express a all the requirements as defined in this document to express a
security policy. The interface between a client and controller must security policy. The interface between a client and controller must
be reliable to ensure robust policy enforcement. One such transport be reliable to ensure robust policy enforcement. One such transport
mechanism is RESTCONF that uses HTTP operations to provide necessary mechanism is RESTCONF that uses HTTP operations to provide necessary
CRUD operations for YANG data objects, but any other mechanism can be CRUD operations for YANG data objects, but any other mechanism can be
skipping to change at page 21, line 7 skipping to change at page 21, line 12
policy can be implemented. The test interface provides such policy can be implemented. The test interface provides such
capabilities without actually applying the policies. capabilities without actually applying the policies.
6. IANA Considerations 6. IANA Considerations
This document requires no IANA actions. RFC Editor: Please remove This document requires no IANA actions. RFC Editor: Please remove
this section before publication. this section before publication.
7. Acknowledgements 7. Acknowledgements
The editors would like to thank Adrian Farrel for helpful discussions The authors would like to thank Adrian Farrel, Linda Dunbar and Diego
and advice. R.Lopez from IETF I2NSF WG for helpful discussions and advice.
The authors would also like to thank Kunal Modasiya, Prakash T.
Sehsadri and Srinivas Nimmagadda from Juniper networks for helpful
discussions.
8. Normative References 8. Normative References
[I-D.ietf-i2nsf-problem-and-use-cases] [I-D.ietf-i2nsf-problem-and-use-cases]
Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C.
Jacquenet, "I2NSF Problem Statement and Use cases", draft- Jacquenet, "I2NSF Problem Statement and Use cases", draft-
ietf-i2nsf-problem-and-use-cases-02 (work in progress), ietf-i2nsf-problem-and-use-cases-02 (work in progress),
October 2016. October 2016.
Authors' Addresses Authors' Addresses
 End of changes. 92 change blocks. 
258 lines changed or deleted 265 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/