draft-ietf-i2nsf-client-facing-interface-req-00.txt   draft-ietf-i2nsf-client-facing-interface-req-01.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: May 1, 2017 D. Qi Expires: October 28, 2017 D. Qi
Bloomberg Bloomberg
N. Bitar N. Bitar
S. Palislamovic S. Palislamovic
Nokia Nokia
L. Xia L. Xia
Huawei Huawei
October 28, 2016 April 26, 2017
Requirements for Client-Facing Interface to Security Controller Requirements for Client-Facing Interface to Security Controller
draft-ietf-i2nsf-client-facing-interface-req-00 draft-ietf-i2nsf-client-facing-interface-req-01
Abstract Abstract
This document captures the requirements for the client-facing This document captures requirements for Client-Facing interface to
interface to the security controller. The interfaces are based on Security Controller. The interface is expressed using objects and
user constructs understood by a security admin instead of a vendor or constructs understood by Security Admin as opposed to vendor or
a device specific mechanism requiring deep knowledge of individual device specific expressions associated with individual product and
products and features. This document identifies the requirements feature. This document identifies a broad set of requirements needed
needed to enforce the user-construct oriented policies onto network to express security policies based on User-constructs which are well
security functions (NSFs) irrespective of how those functions are understood by User Community. This gives ability to decouple policy
realized. The function may be physical or virtual in nature and may definition from policy enforcement on a specific element, be it a
be implemented in networking or dedicated appliances. physical or virtual.
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 May 1, 2017. This Internet-Draft will expire on October 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 principle for Client-Facing Interface defintion . . . 5
3.1. User-construct based modeling . . . . . . . . . . . . . . 5 3.1. User-construct based modeling . . . . . . . . . . . . . . 5
3.2. Basic rules for client interface definition . . . . . . . 6 3.2. Basic rules for Client-Facing Interface definition . . . 6
3.3. Deployment Models for Implementing Security Policies . . 7 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 in client interface . . . . 11 4.1. Requirement for Multi-Tenancy in client interface . . . . 11
4.2. Requirement for Authentication and Authorization of 4.2. Requirement for Authentication and Authorization of
client interface . . . . . . . . . . . . . . . . . . . . 12 client interface . . . . . . . . . . . . . . . . . . . . 12
4.3. Requirement for Role-Based Access Control (RBAC) in 4.3. Requirement for Role-Based Access Control (RBAC) in
client interface . . . . . . . . . . . . . . . . . . . . 12 client interface . . . . . . . . . . . . . . . . . . . . 12
4.4. Requirement to protect client interface from attacks . . 12 4.4. Requirement to protect client interface from attacks . . 12
4.5. Requirement to protect client interface from 4.5. Requirement to protect client interface from
misconfiguration . . . . . . . . . . . . . . . . . . . . 13 misconfiguration . . . . . . . . . . . . . . . . . . . . 12
4.6. Requirement to manage policy lifecycle with diverse needs 13 4.6. Requirement to manage policy lifecycle with diverse needs 13
4.7. Requirement to define dynamic policy Endpoint group . . . 14 4.7. Requirement to define dynamic policy Endpoint group . . . 14
4.8. Requirement to express rich set of policy rules . . . . . 15 4.8. Requirement to express rich set of policy rules . . . . . 15
4.9. Requirement to express rich set of policy actions . . . . 16 4.9. Requirement to express rich set of policy actions . . . . 16
4.10. Requirement to express policy in a generic model . . . . 18 4.10. Requirement to express policy in a generic model . . . . 18
4.11. Requirement to detect and correct policy conflicts . . . 18 4.11. Requirement to detect and correct policy conflicts . . . 18
4.12. Requirement for backward compatibility . . . . . . . . . 18 4.12. Requirement for backward compatibility . . . . . . . . . 18
4.13. Requirement for Third-Party integration . . . . . . . . . 19 4.13. Requirement for Third-Party integration . . . . . . . . . 18
4.14. Requirement to collect telemetry data . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 20 5.2. API Extensiblity . . . . . . . . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Normative References . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
9. 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 vendor specific task that often requires very deep knowledge of vendor specific
devices. This has been the biggest challenge for both service device and features. This has been the biggest challenge for both
providers and enterprises, henceforth named as security administrator Service Provider and Enterprise, henceforth named as Security Admin
in this document. The challenge is amplified due to virtualization in this document. This challenge is further amplified due to network
with security appliances in physical and virtual form factor from a virtualization with security functions deployed in physical and
wide variety of vendors; each vendor have their own proprietary virtual form factor, henceforth named as network security function
interfaces to express security policies on their devices. (NSF) in this document, from multiple vendors with proprietary
interface.
Even if a security administrator deploys a single vendor solution Even if a Security Admin deploys a single vendor solution with one or
with one or more security appliances across its entire network, it is more security appliances across its entire network, it is still very
still difficult to manage security policies due to complexity of difficult to manage security policies due to complexity of security
security features, and difficulty in mapping business requirement to features, and mapping of business requirements to vendor specific
vendor specific configuration. The security administrator may use configuration. The Security Admin may use vendor provided management
either vendor provided CLIs or management system with some systems to provision and manage security policies. But, the single
abstraction to help provision and manage security policies. But, the vendor approach is highly restrictive in today's network for
single vendor approach is highly restrictive in today's network for following reasons:
the following reasons:
o The security administrator cannot rely on a single vendor because o An organization may not be able to rely on a single vendor because
one vendor may not be able to keep up with their security the changing security requirements may not align with vendor's
requirements or specific deployment model. release cycle.
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 may not be possible to deploy same and regions; which means, it may not be possible to deploy same
solution from single vendor due to regulatory requirement or solution from the same vendor because of regional regulatory and
organizational policy. compliance policy.
o If and when security administrator migrates from one vendor to o If and when an organization migrates from one vendor to another,
another, it is almost impossible to migrate security policies from it is almost impossible to migrate security policies from one
one vendor solution to another without complex manual workflows. vendor to another without complex and time consuming manual
workflows.
o Security administrators deploy various security functions in o An organization may deploy multiple network security functions in
virtual or physical forms to attain the flexibility, elasticity, virtual and physical forms to attain the flexibility, elasticity,
performance, and operational efficiency they require. performance scale, and operational efficiency they require.
Practically, that often requires different sources (vendor, open Practically, that often requires different sources (vendor, open
source) to get the best of breed for any such security function. source) to get the best of breed for any such security function.
o The security administrator might choose various devices or network o An organization may choose all or part of their assets such as
services (such as routers, switches, firewall devices, and routers, switches, firewalls, and overlay-networks as policy
overlay-networks) as enforcement points for security policies. enforcement points for operational and cost efficiency. It would
be highly complex to manage policy enforcement with different tool
This my be for reason (such as network design simplicity, cost, set for each type of device.
most-effective place, scale and performance).
In order to ease the deployment of security policies across different In order to facilitate deployment of security policies across
vendors and devices, the Interface to Network Security Functions different vendor provided NSFs, the Interface to Network Security
(I2NSF) working group in the IETF is defining a client-facing Functions (I2NSF) working group in the IETF is defining a Client-
interface from the security controller to clients [I-D. ietf-i2nsf- Facing interface to Security Controller [I-D. ietf-i2nsf-framework]
framework] [I-D. ietf-i2nsf-terminology]. Deployment facilitation [I-D. ietf-i2nsf-terminology]. Deployment facilitation should be
should be agnostic to the type of device, be it physical or virtual, agnostic to the type of device, be it physical or virtual, or type of
or type of the policy, be it dynamic or static. Using these enforcement point. Using these interfaces, it becomes possible to
interfaces, it would become possible to write different kinds of write different kinds of security management applications (e.g. GUI
application (e.g. GUI portal, template engine, etc.) to control the portal, template engine, etc.) allowing Security Admin to express
implementation of security policies on security functional elements, security policies in an abstract form with choice of wide variety of
though how these applications are implemente are completely out of NSF for policy enforcement. The implementation of security
the scope of the I2NSF working group, which is only focused on the management applications or controller is completely out of the scope
interfaces. of the I2NSF working group, which is only focused on interface
definition.
This document captures the requirements for the client-facing This document captures the requirements for Client-Facing interface
interface that can be easily used by security administrators without that can be easily used by Security Admin without a need for
knowledge of specific security devices or features. We refer to this expertise in vendor and device specific feature set. We refer to
as "user-construct" based interfaces. To further clarify, in the this as "User-construct" based interfaces. To further clarify, in
scope of this document, the "user-construct" here does not mean some the scope of this document, the "User-construct" here does not mean
free-from natural language input or an abstract intent such as "I some free-from natural language input or an abstract intent such as
want my traffic secure" or "I don't want DDoS attacks in my network"; "I want my traffic secure" or "I don't want DDoS attacks in my
rather the user-construct here means that policies are described network"; rather the User-construct here means that policies are
using client-oriented expressions such as application names, described using expressions such as application names, application
application groups, device groups, user groups etc. with a vocabulary groups, device groups, user groups etc. with a vocabulary of verbs
of verbs (e.g., drop, tap, throttle), prepositions, conjunctions, (e.g., drop, tap, throttle), prepositions, conjunctions,
conditionals, adjectives, and nouns instead of using standard conditionals, adjectives, and nouns instead of using standard
n-tuples from the 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 Security Controller or
Controller or management system throughout this document management system throughout this document
CRUD: Create, Retrieve, Update, Delete CRUD: Create, Retrieve, Update, Delete
FW: Firewall FW: Firewall
GUI: Graphical User Interface GUI: Graphical User Interface
IDS: Intrusion Detection System IDS: Intrusion Detection System
IPS: Intrusion Protection System IPS: Intrusion Protection System
LDAP: Lightweight Directory Access Protocol LDAP: Lightweight Directory Access Protocol
NSF: Network Security Function, defined by NSF: Network Security Function, defined by
[I-D.ietf-i2nsf-problem-and-use-cases] [I-D.ietf-i2nsf-problem-and-use-cases]
OSS: Operation Support System OSS: Operation Support System
skipping to change at page 5, line 23 skipping to change at page 5, line 27
OSS: Operation Support System OSS: Operation Support System
RBAC: Role Based Access Control RBAC: Role Based Access Control
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 principle for Client-Facing Interface defintion
The "Client-Facing Interface" ensures that a security administrator Client-Facing Interface must ensure that a Security Admin can deploy
can deploy any device from any vendor and still be able to use a any NSF from any vendor and should still be able to use the same
consistent interface. In essence, this interface gives ability to consistent interface. In essence, this interface must allow a
security admins to express their security policies independent of how Security Admin to express security policies independent of how NSFs
security functions are implemented in their deployment. Henceforth, are implemented in their deployment. Henceforth, in this document,
in this document, we use "security policy management interface" we use "security policy management interface" interchangeably when we
interchangeably when we refer to the client-facing interface. refer to Client-Facing interface.
3.1. User-construct 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 interface are defined by a vendor proprietary interface. The interface is defined by a vendor based on
either based on CLI or a GUI system; but more often these interfaces proprietary command line text or a GUI based system with
are built using vendor specific networking construct such IP address, implementation specific constructs such IP address, protocol and
protocol and application constructs with L4-L7 information. This L4-L7 information. This requires Security Admin to translate their
requires security operator to translate their oragnzational business business objectives into vendor provided constructs in order to
objectives into actionable security policies on the device using express a security policy. But, this alone is not sufficient to
vendor specific configuration. But, this alone is not sufficient to render a policy in the network; the admin must also understand
render policies in the network as operator also need to identify the network and application design to locate a specific policy
device in the network topology where a policy need to be enforced in enforcement point to make sure policy is effective. This may be
a complex environment with potenial multiple policy enforcement highly manual task based on specific network design and may become
points. unmanageable in virtualized networks.
The User-construct based framework defines constructs such as user- The User-construct based framework does not rely on lower level
group, application-group, device-group and location-group. The semantics due to problem explained above, but rather uses higher
security admin would use these constructs to express a security level constructs such as User-group, Application-group, Device-group,
policy instead of proprietary vendor specific constructs. The policy Location-group, etcetera. A Security Admin would use these
defined in such a manner is referred to user-construct based policies constructs to express a security policy instead of proprietary
in this draft. The idea is to enable security admin to use implementation or feature specific constructs. The policy defined in
constructs they understand best in expressing security policies; such a manner is referred to User-construct based policies in this
which simplify their tasks and help avoiding human errors in complex draft. The idea is to enable Security Admin to use constructs they
security provisioning. understand best in expressing security policies which simplify their
tasks and help avoiding human errors in complex security
provisioning.
3.2. Basic rules for client interface definition 3.2. Basic rules for Client-Facing Interface definition
The basic rules in defining the client-facing interfaces are as The basic rules in defining the Client-Facing interfaces are as
follows: follows:
o Not depending on particular network topology or the actual NSF o Not dependent on particular Network topology or the NSF location
location in the network in the network
o Not requiring the exact knowledge of the concrete features and o Not requiring deep knowledge of proprietary features and
capabilities supported in the deployed NSFsa€ capabilities supported in the deployed NSFsa€
o Independent of the nature of the function that will apply the o Independent of NSF type that will implement the user security
expressed policies be it stateful firewall,IDP, IDS, Router, policy be it a stateful firewall,IDP, IDS, Router, Switch
Switch
o Declarative/Descriptive model instead of Imperative/Prescriptive o Declarative/Descriptive model instead of Imperative/Prescriptive
model - What security policies need to be enforced (declarative) model - What security policy need to be enforced (declarative)
instead of how they would be actually implemented (imperative) instead of how it is implemented (imperative)
o Not depending on any specific vendor implementation or form-factor o Not dependent on any specific vendor implementation or form-factor
(physical, virtual) of the NSF (physical, virtual) of the NSF
o Not depending on how a NSF becomes operational - Network o Not dependent on how a NSF becomes operational - Network
connectivity and other hosting requirements. connectivity and other hosting requirements.
o Not depending on NSF control plane implementation (if there is o Not dependent on NSF control plane implementation (if there is
one) E.g., cluster of NSFs active as one unified service for scale one) E.g., cluster of NSFs active as one unified service for scale
and/ or resilience. and/ or resilience.
o Not depending on specific data plane implementation of NSF i.e. o Not depending on specific data plane implementation of NSF i.e.
Encapsulation, Service function chains. Encapsulation, Service function chains.
Note that the rules stated above only apply to the client-facing Note that the rules stated above only apply to the Client-Facing
interface where a user will define a high level policy. These rules interface, which a user would use to express a high level policy.
do not apply to the lower layers e.g. security controller that These rules do not apply to the lower layers e.g. Security
convert the higher level policies into lower level constructs. The Controller that convert higher level policies into lower level
lower layers may still need some intelligence such as topology constructs. The lower layers may still need some intelligence such
awareness, capability of the NSF and its functions, supported as topology awareness, capability of the NSF and its functions,
encapsulations etc. to convert and apply the policies accurately on supported encapsulations etc. to convert and apply the policies
the NSF devices. accurately on the NSF.
3.3. Deployment Models for Implementing Security Policies 3.3. Deployment Models for Implementing Security Policies
Traditionally, medium and larger operators deploy management systems Traditionally, medium and large Enterprise 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 NSF.
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 various processing functions reside. These models are:
a. Management without an explicit management system for control of a. Policy management without an explicit management system for
devices and NSFs. In this deployment, the security controller control of NSFs. In this deployment, Security Controller acts as
acts as a NSF policy management system that takes information a NSF management system; it takes information passed over Client-
passed over the client security policy interface and translates Facing interface and translates into data on I2NSF NSF-facing
into data on the I2NSF NSF-facing interface. The I2NSF interface. The NSF-Facing interface is implemented by NSF
interfaces are implemented by security device/function vendors. vendors; 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 NSF. This deployment model is shown in Figure 1.
the security device or NSF. This deployment model is shown in
Figure 1.
RESTful API RESTful API
SUPA or I2NSF Policy Management SUPA or I2NSF Policy Management
^ ^
| |
Client-facing Interface | Client-Facing Interface |
(Independent of individual | (Independent of individual |
NSFs, devices,and vendors)| NSFs, devices,and vendors)|
| |
------------------------------ ------------------------------
| | | |
| Security Controller | | Security Controller |
| | | |
------------------------------ ------------------------------
| ^ | ^
| I2NSF | | I2NSF |
skipping to change at page 8, line 46 skipping to change at page 8, line 46
-------------/ \------------- -------------/ \-------------
| I2NSF Agent | | I2NSF Agent | | I2NSF Agent | | I2NSF Agent |
|-------------| |-------------| |-------------| |-------------|
| |---| | | |---| |
| 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. Policy management with an explicit management system for control
devices and NSFs. This model is similar to the model above of NSFs. This model is similar to the model above except that
except that security controller interacts with a dedicated Security Controller interacts with a vendor's dedicated
management system which could either proxy I2NSF NSF-facing management system that proxy I2NSF NSF-Facing interfaces as NSF
interfaces or could provide a layer where security devices or may not support NSF-Facing interface. This is a useful model to
NSFs do not support an I2NSF agent to process I2NSF NSF-facing support legacy NSF. 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 Interface | Client-facing Interface |
(Independent of individual | (Independent of individual |
NSFs,devices,and vendors) | NSFs,devices,and vendors) |
| |
------------------------------ ------------------------------
skipping to change at page 10, line 11 skipping to change at page 10, line 11
| / \ | | / \ |
-------------/ \------------- -------------/ \-------------
| |---| | | |---| |
| NSF | | NSF | | NSF | | NSF |
| | | | | | | |
------------- ------------- ------------- -------------
Figure 2: Deployment with Management System or I2NSF Proxy Agent Figure 2: Deployment with Management System or I2NSF Proxy Agent
Although the deployment models discussed here don't necessarily Although the deployment models discussed here don't necessarily
affect the client security policy interface, they do give an overall affect the definition of Client-Facing interface, they do give an
context for defining a security policy interface based on overall 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 principle for defining the I2NSF Client-
interface, the security policies and the client-facing interface Facing interface, the security policies and the Client-Facing
shall be defined from a user/client perspective and abstracted away interface shall be defined from user's or client's perspective and
from the type of NSF, NSF specific implementation, controller abstracted away from type of NSF, NSF specific implementation,
implementation, NSF topology, NSF interfaces, controller NSF-facing controller implementation, network topology, controller NSF-Facing
interfaces. Thus, the security policy definition shall be interface. Thus, the security policy definition shall be
declarative, expressing the user construct, and driven by how declarative, expressed using User-construct, and driven by how
security administrators view security policies from the definition, Security Admin view security policies from definition, communication
communication and deployment perspective. and deployment perspective.
The security controller's implementation is outside the scope of this Security Controller's' implementation is outside the scope of this
document and the I2NSF working group. document and the I2NSF working group.
In order to express and build security policies, high level In order to express and build security policies, high level
requirements for the client-facing are as follows: requirement for Client-Facing interface is 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 15 skipping to change at page 11, line 15
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 requirements 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 Security Admins, but should be a
starting point for a wide variety of use-cases in Service Provider good starting point for a wide variety of use-cases in Service
and Enterprise networks. Provider and Enterprise networks.
4.1. Requirement for Multi-Tenancy in client interface 4.1. Requirement for Multi-Tenancy in client interface
A security administrator that uses security policies may have A Security Admin may have internal tenants and might want a framework
internal tenants and would like to have a framework wherein each wherein each tenant manages its own security policies with isolation
tenant manages its own security policies with isolation from other from other tenants.
tenants.
An operator may be a cloud service provider with multi-tenant A Security Admin may be a cloud service provider with multi-tenant
deployments, where each tenant is a different customer. Each tenant deployment, where each tenant is a different customer. Each tenant
or customer must be allowed to manage its own security policies. or customer must be allowed to manage its own security policies.
It should be noted that tenants may have their own tenants, so a It should be noted that tenants may have their own tenants, so a
recursive relation may exist. 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 for compliance.
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 its resources. 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 access certain resources of that tenant according to the
privileges assigned to it. privileges assigned to it.
4.2. Requirement for Authentication and Authorization of client 4.2. Requirement for Authentication and Authorization of client
interface interface
Security administrators MUST authenticate to and be authorized by the Security Admin MUST authenticate to and be authorized by Security
security controller before they are able to issue control commands Controller before they are able to issue control commands and any
and any policy data exchange commences. policy data exchange commands.
There must be methods defined for the Policy-Administrator to be There must be methods defined for Policy-Administrator to be
authenticated and authorized to use the security controller. There authenticated and authorized to use Security Controller. There are
are several authentication methods available such as OAuth, XAuth and several authentication methods available such as OAuth, XAuth and
X.509 certificate based. The authentication scheme between Policy- X.509 certificate based; the authentication may be mutual or single-
Administrator and security controller may also be mutual instead of sided based on business needs and outside the scope of I2NSF. In
one-way. Any specific method may be determined based on addition, there must be a method o authorize the Policy-Administrator
organizational and deployment needs and outside the scope of I2NSF. to perform certain action. It should be noted that, Policy-
In addition, there must be a method to authorize the Policy- Administrator authentication and authorization to perform actions
Administrator for performing certain action. It should be noted could be part of Security Controller or outside; this document does
that, depending on the deployment model, Policy-Administrator not mandate any specific implementation but requires that such a
authentication and authorization to perform actions communicated to scheme must be implemented.
the controller could be performed as part of a portal or another
system prior to communication the action to the controller.
4.3. Requirement for Role-Based Access Control (RBAC) in client 4.3. Requirement for Role-Based Access Control (RBAC) in client
interface interface
Policy-Authorization-Role represents a role assigned to a Policy-User Policy-Authorization-Role represents a role assigned to a Policy-User
that determines whether a user or has read-write access, read-only that determines whether a user has read-write access, read-only
access, or no access for certain resources. A User can be mapped to access, or no access for certain resources. A User can be mapped to
a Policy-Authorization-Role using an internal or external identity a Policy-Authorization-Role using an internal or external identity
provider or mapped statically. provider or mapped statically.
4.4. Requirement to protect client interface from attacks 4.4. Requirement to protect client interface from attacks
There Must be protections from attacks, malicious or otherwise, from The interface must be protections from attacks, malicious or
clients or a client impersonator. Potential attacks could come from otherwise, from clients or a client impersonator. Potential attacks
a botnet or a host or hosts infected with virus or some unauthorized could come from Botnets, hosts infected with virus or some
entity. It is recommended that security controller use a dedicated unauthorized entity. It is recommended that Security Controller use
IP interface for client-facing communications and those a dedicated IP interface for Client-Facing communications and those
communications should be carried over an isolated out-of-band communications should be carried over an isolated out-of-band
network. In addition, it is recommended that traffic between clients network. In addition, it is recommended that traffic between clients
and security controllers be encrypted. Furthermore, some and Security controller be encrypted. Furthermore, some
straightforward traffic/session control mechanisms (i.e., Rate-limit, straightforward traffic/session control mechanisms (i.e., Rate-limit,
ACL, White/Black list) can be employed on the security controller to ACL, White/Black list) can be employed on Security Controller to
defend against DDoS flooding attacks. defend against DDoS flooding attacks.
4.5. Requirement to protect client interface from misconfiguration 4.5. Requirement to protect client interface from misconfiguration
There Must be protections from mis-configured clients. System and There must be protections from mis-configured clients. System and
policy validations should be implemented to detect this. Validation policy validations should be implemented to detect this. Validation
may be based on a set of default parameters or custom tuned may be based on a set of default parameters or custom tuned
thresholds such as the number of policy changes submitted, number of thresholds such as the number of policy changes submitted, number of
objects requested in a given time interval, etc. objects requested in a given time interval, etc.
4.6. Requirement to manage policy lifecycle with diverse needs 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 so that a policy becomes dynamically active/
active/enforced or inactive based on either security administrator's enforced or inactive based on Security Admin's manual intervention or
manual intervention or an event. some external event.
One example of dynamic policy management is when the security One example of dynamic policy management is when Security Admin pre-
administrator pre-configures all the security policies, but the configures all the security policies, but the policies get activated
policies get activated or deactivated based on dynamic threats. or deactivated based on dynamic threats. Basically, a threat event
Basically, a threat event may activate certain inactive policies, and 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 following ways 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 Security Admin or
associated management entity, and dynamically communicated over the associated management entity
I2NSF client-facing interface to the controller to program I2NSF
functions using the I2NSF NSF-facing interface
o The policy may be pulled dynamically by the controller upon
detecting an event over the I2NSF monitoring interface
o The policy may be statically pushed to the controller and o The policy may be dynamically activated by Security Controller upon
dynamically programmed on the NSFs upon potentially detecting another detecting an external event or an event from I2NSF monitoring
event interface
o The policy can be programmed in the NSF, and activated or o The policy can be statically configured but activated or
deactivated upon policy attributes, like time or admin enforced. deactivated upon policy attributes, such as timing calendar
The client-facing interface should support the following policy 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: A policy, once configured, remains active/enforced
until removed by the security administrator. until removed by Security Admin.
Time-Enforced: The policy configuration specifies the time profile Time-Enforced: A policy configuration specifies the time profile
that determines when policy is activated/enforced. Otherwise, it that determines when the policy is to be activated/enforced.
is de-activated. Otherwise, it is de-activated.
Event-Enforced: The policy configuration specifies the event profile Event-Enforced: A policy configuration specifies the event profile
that determines when policy is activated/enforced. It also that determines when the policy is to be activated/enforced. It
specifies the duration attribute of that policy once activated also specifies the duration attribute of that policy once
based on event. For instance, if the policy is activated upon activated based on event. For instance, if the policy is
detecting an application flow, the policy could be de-activated activated upon detecting an application flow, the policy could be
when the corresponding session is closed or the flow becomes de-activated when the corresponding session is closed or the flow
inactive for certain time. becomes 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 the policy maintenance, and subject to updates and modification. For the policy maintenance,
enforcement, and auditability purposes, it becomes important to name enforcement, and audit-ability purposes, it becomes important to name
and version the policies. Thus, the policy definition SHALL support and version Security Policy. Thus, the policy definition SHALL
policy naming and versioning. In addition, the i2NSF client-facing support policy naming and versioning. In addition, the i2NSF Client-
interface SHALL support the activation, deactivation, Facing 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 operational state of
name and version. For instance, a client may probe the controller policies by name and version. For instance, a client may probe
about the current policies enforced for a tenant and/or a sub-tenant Security Controller whether a Security Policy is enforced for a
(organization) for auditability or verification purposes. tenant and/or a sub-tenant (organization) for audit-ability or
verification purposes.
4.7. Requirement to define dynamic policy Endpoint group 4.7. Requirement to define dynamic policy Endpoint group
When the security administrator configures a security policy, it may When Security Admin configures a Security Policy, it may have
have requirement to apply this policy to certain subsets of the requirement to apply this policy to certain subsets of the network.
network. The subsets may be identified based on criteria such as The subsets may be identified based on criteria such as Users,
users, devices, and applications. We refer to such a subset of the Devices, and Applications. We refer to such a subset of the network
network as a "Policy Endpoint Group". 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 Admin is how to make
make sure that security policies remain effective while constant sure that a Security Policy remain effective while constant changes
changes are happening to the "Policy Endpoint Group" for various are happening to the "Policy Endpoint Group" for various reasons
reasons (e.g., organizational, network and application changes). If (e.g., organizational, network and application changes). If a policy
a policy is created based on static information such as user names, is created based on static information such as user names,
application, or network subnets; then every time this static application, or network subnets; then every time this static
information change, policies need to be updated. For example, if a information change, policies need to be updated. For example, if a
policy is created that allows access to an application only from the policy is created that allows access to an application only from the
group of Human Resource users (the HR-users group), then each time group of Human Resource users (HR-users group), then each time the
the HR- users group changes, the policy needs to be updated. HR-users group changes, the policy needs to be updated.
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 User, Application, or Device. The mapping from meta-data to
to dynamic content could come either from standards-based or dynamic content could come from a standards-based or proprietary
proprietary tools. The security controller could use any available tools. Security Controller could use any available mechanisms to
mechanisms to derive this mapping and to make automatic updates to derive this mapping and to make automatic updates to policy content
the policy content if the mapping information changes. The system if the mapping information changes. The system SHOULD allow for
SHOULD allow for multiple, or sets of tags to be applied to a single 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 Client-Facing policy interface must support endpoint groups for
user-construct based policy management. The following meta-data expressing a Security Policy. The following meta-data driven groups
driven groups MAY be used for configuring security polices: 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 organization may have different User-groups, such as
users, Finance-users, Engineering-users, to classify a set of HR-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
dynamically derived from systems such as configuration mannagement dynamically derived from systems such as configuration management
database (CMDB). For example, a security administrator may want database (CMDB). For example, a Security Admin may want to
to classify all machines running one operating system into one classify all machines running a particular operating system into
group and machines running another operating system into another one group and machines running a different operating system into
group. another group.
Application-Group: This group identifies a set of applications based Application-Group: This group identifies a set of applications based
on a tag or on static information. The tag to identify on a tag or on static information. The tag to identify
application is dynamically derived from systems such as CMDB. For application is dynamically derived from systems such as CMDB. For
example, a security administrator may want to classify all example, a Security Admin may want to classify all applications
applications running in the Legal department into one group and running in the Legal department into one group and all
all applications running under a specific operating system into applications running in the HR department into another group. In
another group. In some cases, the application can semantically some cases, the application can semantically associated with a VM
associated with a VM or a device. However, in other cases, the or a device. However, in other cases, the application may need to
application may need to be associated with a set of identifiers be associated with a set of identifiers (e.g., transport numbers,
(e.g., transport numbers, signature in the application packet signature in the application packet payload) that identify the
payload) that identify the application in the corresponding application in the corresponding packets. The mapping of
packets. The mapping of application names/tags to signatures in application names/tags to signatures in the associated application
the associated application packets should be defined and packets should be defined and communicated to the NSF. The
communicated to the NSF. The client-facing Interface shall Client-Facing Interface shall support the communication of this
support the communication of this information. 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 Admin may want to classify all
classify all sites/locations in a geographic region as one group. sites/locations in a geographic region as one group.
4.8. Requirement to express rich set of 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 Security
administrator wants to match the "Policy Endpoint Group" as the Admin wants to match the "Policy Endpoint Group" as the source or
source or destination. The default should be to match both destination. The default should be to match both directions, if
directions, if the direction rule is not specified in the policy. 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 to express rich set of policy actions 4.9. Requirement to express rich set of policy actions
The security administrator must be able to configure a variety of Security Admin must be able to configure a variety of actions within
actions within a security policy. Typically, security policy a security policy. Typically, security policy specifies a simple
specifies a simple action of "deny" or "permit" if a particular action of "deny" or "permit" if a particular condition is matched.
condition is matched. Although this may be enough for most of the Although this may be enough for most of the simple policies, the
simple policies, the I2NSF client-facing interface must also provide I2NSF Client-Facing interface must also provide a more comprehensive
a more comprehensive set of actions so that the interface can be used set of actions so that the interface can be used effectively across
effectively across various security functions. various security functions.
Policy action MUST be extensible so that additional policy action Policy action MUST be extensible so that additional policy action
specifications can easily be added. specifications can easily be added.
The following list of actions SHALL be supported: The following list of actions SHALL be supported:
Permit: This action means continue processing the next rule or allow Permit: This action means continue processing the next rule or allow
the packet to pass if this is the last rule. This is often a the packet to pass if this is the last rule. This is often a
default action. default action.
skipping to change at page 17, line 28 skipping to change at page 17, line 21
redirect action must specify whether the packet is to be tunneled redirect action must specify whether the packet is to be tunneled
and in that case specify the tunnel or encapsulation method and and in that case specify the tunnel or encapsulation method and
destination identifier. destination identifier.
Netflow: This action creates a Netflow record; Need to define Netflow: This action creates a Netflow record; Need to define
Netflow server or local file and version of Netflow. Netflow server or local file and version of Netflow.
Count: This action counts the packets that meet the rule condition. Count: This action counts the packets that meet the rule condition.
Encrypt: This action encrypts the packets on an identified flow. Encrypt: This action encrypts 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.
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: This action instantiates an NSF with a predefined Instantiate-NSF: This action instantiates an NSF with a predefined
profile. An NSF can be any of the FW, LB, IPS, IDS, honeypot, or profile. An NSF can be any of the FW, LB, IPS, IDS, honeypot, or
skipping to change at page 18, line 13 skipping to change at page 18, line 7
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 to express policy in a generic model 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.
Client-facing interface SHALL provide the ability to apply policy or Client-Facing interface SHALL provide the ability to apply policy or
multiple sets of policies to any given object. Policy application multiple sets of policies to any given object. Policy application
process SHALL allow for nesting capabilities of given policies or set process SHALL allow for nesting capabilities of given policies or set
of policies. For example, an object or any given set of objects of policies. For example, an object or any given set of objects
could have application team applying certain set of policy rules, could have application team applying certain set of policy rules,
while network team would apply different set of their 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 Lastly, security team would have an ability to apply its set of
policy rules, being the last policy to be evaluated against. policy rules, being the last policy to be evaluated against.
4.11. Requirement to detect and correct policy conflicts 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 a network may require the use of specialty
require the use of specialty devices such as honeypots, behavioral devices such as honeypots, behavioral analytics, or SIEM in the
analytics, or SIEM in the network, and may also involve threat feeds, network, and may also involve threat feeds,virus signatures, and
virus signatures, and malicious file hashes as part of comprehensive 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 Security Admin to configure
configure these threat sources and any other information to provide these threat sources and any other information to provide integration
integration and fold this into policy management. and fold this into policy management.
4.14. Requirement to collect 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, Security
security administrator must be able to gather different types of Admin must be able to gather different types of telemetry data from
telemetry data from various devices in the network. The collected various devices in the network. The collected data could simply be
data could simply be logged or sent to security analysis engines for logged or sent to security analysis engines for behavioral analysis,
behavioral analysis, policy violations, and for threat detection. policy violations, and for threat detection.
The client-facing interface MUST allow the security administrator to The Client-Facing interface MUST allow Security Admin to collect
collect various kinds of data from NSFs. The data source could be various kinds of data from NSFs. The data source could be syslog,
syslog, flow records, policy violation records, and other available flow records, policy violation records, and other available data.
data.
Detailed client-facing interface telemetry data should be available Detailed Client-Facing interface telemetry data should be available
between clients and security controllers. Clients should be able to between clients and Security Controller. Clients should be able to
subscribe and receive these telemetry data. subscribe and receive these telemetry data.
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 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 may most likely come from different and the controller application may come from different vendors. Even
vendors. Even if the vendor is same, it is hard to imagine that two if the vendor is same, it is hard to imagine that two different
different applications would be released in lock step. 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 an application breaks. Although API versioning does not guarantee
applications will always work, it helps in debugging if the problem that applications will always work, it helps in debugging if the
is caused by an API mismatch. problem 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 Client-Facing interface is of
tremendous value to security administrators as it gives them the tremendous value to Security Admin as it gives them the flexibility
flexibility of deploying any vendor's NSF without needing to redefine of deploying any vendor's NSF without need to redefine their policies
their policies or change the client interface. However this might if or when a NSF is changed.
also look like as an obstacle to innovation.
If a vendor comes up with new feature or functionality that can't be If a vendor comes up with new feature or functionality that can't be
expressed through the currently defined client-facing interface, expressed through the currently defined Client-Facing interface,
there must be a way to extend existing APIs or to create a new API there must be a way to extend existing APIs or to create a new API
that is relevant for that NSF vendor 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
used. used.
5.4. Notification 5.4. Notification
The client-facing interface must allow the security administrator to Client-Facing interface must allow Security Admin to collect various
collect various alarms and events from the NSF in the network. The alarms and events from the NSF in the network. The events and alarms
events and alarms may be either related to security policy may be either related to security policy itself or related to NSF
enforcement or NSF operation. The events and alarms could also be where the policy is implemented. The events and alarms could also be
used as a input to the security policy for autonomous handling. used as an input to the security policy for autonomous handling as
specified in a given security policy.
5.5. Affinity 5.5. Affinity
The client-facing interface must allow the security administrator to Client-Facing interface must allow Security Admin to pass any
pass any additional metadata that a user may want to provide for a additional metadata that a user may want to provide for a security
security policy e.g. certain security policy needs to be applied only policy e.g. certain security policy needs to be implemented only on a
on linux machine or windows machine or that a security policy must be very highly secure NSF with Trusted Platform Module (TPM) chip. A
applied on the device with Trusted Platform Module chip. user may require Security Controller not to share the NSF with other
tenant, this must be expressed through the interface API.
5.6. Test Interface 5.6. Test Interface
The client-facing interface must allow the security administrator the Client-Facing interface must allow Security Admin ability to test a
ability to test the security policies before the policies are security policy before it is enforced e.g. a user may want to verify
actually applied e.g. a user may want to verify if a policy creates whether the policy creates any potential conflicts with the existing
potential conflicts with the existing policies or whether a certain policies or if there are even resources to enforce the policy. The
policy can be implemented. The test interface provides such test policy would provide such a capability without actually applying
capabilities without actually applying the policies. the policies.
6. IANA Considerations 6. Security Considerations
Client-Facing interface to Security controller must be protected to
ensure that entire security posture is not compromised. This draft
mandates that interface must have proper authentication and
authorization with Role Based Access Controls to address multi-
tenancy requirement. The draft does not specify a particular
mechanism as different organization may have different needs based on
their deployment. This has been discussed extensively in this draft.
Authentication and authorization alone may not be sufficient for
Client-Facing interface; the interface API must be validated for
proper inputs to guard against attacks. The type of checks and
verification may be specific to each interface API, but a careful
consideration must be made to ensure that Security Controller is not
compromised.
7. 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 8. Acknowledgements
The authors would like to thank Adrian Farrel, Linda Dunbar and Diego The authors would like to thank Adrian Farrel, Linda Dunbar and Diego
R.Lopez from IETF I2NSF WG for helpful discussions and advice. R.Lopez from IETF I2NSF WG for helpful discussions and advice.
The authors would also like to thank Kunal Modasiya, Prakash T. The authors would also like to thank Kunal Modasiya, Prakash T.
Sehsadri and Srinivas Nimmagadda from Juniper networks for helpful Sehsadri and Srinivas Nimmagadda from Juniper networks for helpful
discussions. discussions.
8. Normative References 9. 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., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
Jacquenet, "I2NSF Problem Statement and Use cases", draft- and J. Jeong, "I2NSF Problem Statement and Use cases",
ietf-i2nsf-problem-and-use-cases-02 (work in progress), draft-ietf-i2nsf-problem-and-use-cases-15 (work in
October 2016. progress), April 2017.
Authors' Addresses Authors' Addresses
Rakesh Kumar Rakesh Kumar
Juniper Networks Juniper Networks
1133 Innovation Way 1133 Innovation Way
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: rkkumar@juniper.net Email: rkkumar@juniper.net
 End of changes. 111 change blocks. 
365 lines changed or deleted 373 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/