draft-ietf-i2nsf-client-facing-interface-req-04.txt   draft-ietf-i2nsf-client-facing-interface-req-05.txt 
I2NSF Working Group R. Kumar I2NSF Working Group R. Kumar
Internet-Draft Lilac Cloud Internet-Draft Lilac Cloud
Intended status: Informational A. Lohiya Intended status: Informational A. Lohiya
Expires: July 20, 2018 Juniper Networks Expires: November 28, 2018 Juniper Networks
D. Qi D. Qi
Bloomberg Bloomberg
N. Bitar N. Bitar
S. Palislamovic S. Palislamovic
Nokia Nokia
L. Xia L. Xia
Huawei Huawei
January 16, 2018 May 27, 2018
Requirements for Client-Facing Interface to Security Controller Requirements for Client-Facing Interface to Security Controller
draft-ietf-i2nsf-client-facing-interface-req-04 draft-ietf-i2nsf-client-facing-interface-req-05
Abstract Abstract
This document captures requirements for Client-Facing interface to This document captures requirements for Client-Facing interface to
the Security Controller as defined by [I-D.ietf-i2nsf-framework]. the Security Controller as defined by [RFC8327]. The interface is
The interface is expressed using objects and constructs understood by expressed using objects and constructs understood by Security Admin
Security Admin as opposed to vendor or device specific expressions as opposed to vendor or device specific expressions associated with
associated with individual product and feature. This document individual product and feature. This document identifies a broad set
identifies a broad set of requirements needed to express Security of requirements needed to express Security Policies based on User-
Policies based on User-constructs which are well understood by the constructs which are well understood by the User Community. This
User Community. This gives ability to decouple policy definition gives ability to decouple policy definition from policy enforcement
from policy enforcement on a specific security functional element, be on a specific security functional element, be it a physical or
it a physical or virtual. 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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 July 20, 2018. This Internet-Draft will expire on November 28, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 principle for Client-Facing Interface definition . . 5 3. Guiding Principle for Client-Facing Interface Definition . . 5
3.1. User-construct based modeling . . . . . . . . . . . . . . 5 3.1. User-construct Based Modeling . . . . . . . . . . . . . . 5
3.2. Basic rules for Client-Facing 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-Facing interface 11 4.1. Requirement for Unified Model for Various Network Types . 11
4.2. Requirement for Authentication and Authorization of 4.2. Requirement for Multi-Tenancy in Client-Facing Interface 12
Client-Facing interface . . . . . . . . . . . . . . . . . 12 4.3. Requirement for Authentication and Authorization of
4.3. Requirement for Role-Based Access Control (RBAC) in Client-Facing Interface . . . . . . . . . . . . . . . . . 12
Client-Facing interface . . . . . . . . . . . . . . . . . 12 4.4. Requirement for Role-Based Access Control (RBAC) in
4.4. Requirement to protect Client-Facing interface from Client-Facing Interface . . . . . . . . . . . . . . . . . 13
attacks . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.5. Requirement to Protect Client-Facing Interface from
4.5. Requirement to protect Client-Facing interface from Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 13
misconfiguration . . . . . . . . . . . . . . . . . . . . 13 4.6. Requirement to protect Client-Facing Interface from
4.6. Requirement to manage policy lifecycle with rich set of Misconfiguration . . . . . . . . . . . . . . . . . . . . 13
controls . . . . . . . . . . . . . . . . . . . . . . . . 13 4.7. Requirement to Manage Policy Lifecycle with Rich Set of
4.7. Requirement to define dynamic Policy Endpoint Group . . . 14 Controls . . . . . . . . . . . . . . . . . . . . . . . . 14
4.8. Requirement to express rich set of Policy Rules . . . . . 16 4.8. Requirement to Define Dynamic Policy Endpoint Group . . . 15
4.9. Requirement to express rich set of Policy Actions . . . . 17 4.9. Requirement to Express Rich Set of Policy Rules . . . . . 17
4.10. Requirement for consistent policy enforcement . . . . . . 19 4.10. Requirement to Express Rich Set of Policy Actions . . . . 18
4.11. Requirement to detect and correct policy conflicts . . . 19 4.11. Requirement for Consistent Policy Enforcement . . . . . . 19
4.12. Requirement for backward compatibility . . . . . . . . . 19 4.12. Requirement to Detect and Correct Policy Conflicts . . . 20
4.13. Requirement for Third-Party integration . . . . . . . . . 20 4.13. Requirement for Backward Compatibility . . . . . . . . . 20
4.14. Requirement to collect telemetry data . . . . . . . . . . 20 4.14. Requirement for Third-Party Integration . . . . . . . . . 20
5. Operational Requirements for the Client-Facing Interface . . 20 4.15. Requirement to Collect Telemetry Data . . . . . . . . . . 20
5.1. API Versioning . . . . . . . . . . . . . . . . . . . . . 20 5. Operational Requirements for the Client-Facing Interface . . 21
5.1. API Versioning . . . . . . . . . . . . . . . . . . . . . 21
5.2. API Extensibility . . . . . . . . . . . . . . . . . . . . 21 5.2. API Extensibility . . . . . . . . . . . . . . . . . . . . 21
5.3. APIs and Data Model Transport . . . . . . . . . . . . . . 21 5.3. APIs and Data Model Transport . . . . . . . . . . . . . . 21
5.4. Notification and Monitoring . . . . . . . . . . . . . . . 21 5.4. Notification and Monitoring . . . . . . . . . . . . . . . 22
5.5. Affinity . . . . . . . . . . . . . . . . . . . . . . . . 21 5.5. Affinity . . . . . . . . . . . . . . . . . . . . . . . . 22
5.6. Test Interface . . . . . . . . . . . . . . . . . . . . . 21 5.6. Test Interface . . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
9. Normative References . . . . . . . . . . . . . . . . . . . . 22 9. Normative References . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 deep knowledge of vendor specific devices task that often requires deep knowledge of vendor specific devices
and features. This has been the biggest challenge for both Service and features. This has been the biggest challenge for both Service
Providers and Enterprises, henceforth named as Security Admins in Providers and Enterprises, henceforth named as Security Admins in
this document. This challenge is further amplified due to network this document. This challenge is further amplified due to network
virtualization with security functions deployed in physical and virtualization with security functions deployed in physical and
skipping to change at page 4, line 14 skipping to change at page 4, line 17
o An organization may choose all or part of their assets such as o An organization may choose all or part of their assets such as
routers, switches, firewalls, and overlay-networks as policy routers, switches, firewalls, and overlay-networks as policy
enforcement points for operational and cost efficiency. It would enforcement points for operational and cost efficiency. It would
be highly complex to manage policy enforcement with different tool be highly complex to manage policy enforcement with different tool
set for each type of device. set for each type of device.
In order to facilitate deployment of Security Policies across In order to facilitate deployment of Security Policies across
different vendor provided NSFs, the Interface to Network Security different vendor provided NSFs, the Interface to Network Security
Functions (I2NSF) working group in the IETF is defining a Client- Functions (I2NSF) working group in the IETF is defining a Client-
Facing interface to Security Controller [I-D. ietf-i2nsf-framework] Facing interface to Security Controller [RFC8327] [I-D.ietf-i2nsf-
[I-D. ietf-i2nsf-terminology]. Deployment facilitation should be terminology]. Deployment facilitation should be agnostic to the type
agnostic to the type of device, be it physical or virtual, or type of of device, be it physical or virtual, or type of enforcement point.
enforcement point. Using these interfaces, it becomes possible to Using these interfaces, it becomes possible to write different kinds
write different kinds of security management applications (e.g. GUI of security management applications (e.g. GUI portal, template
portal, template engine, etc.) allowing Security Admin to express engine, etc.) allowing Security Admin to express Security Policy in
Security Policy in an abstract form with choice of wide variety of an abstract form with choice of wide variety of NSF as policy
NSF as policy enforcement point. The implementation of security enforcement point. The implementation of security management
management applications or controller is out of scope for I2NSF applications or controller is out of scope for I2NSF working group.
working group.
This document captures the requirements for Client-Facing interface This document captures the requirements for Client-Facing interface
that can be easily used by Security Admin without a need for that can be easily used by Security Admin without a need for
expertise in vendor and device specific feature set. We refer to expertise in vendor and device specific feature set. We refer to
this as "User-construct" based interfaces. To further clarify, in this as "User-construct" based interfaces. To further clarify, in
the scope of this document, the "User-construct" here does not mean the scope of this document, the "User-construct" here does not mean
some free-from natural language input or an abstract intent such as some free-from natural language input or an abstract intent such as
"I want my traffic secure" or "I don't want DDoS attacks in my "I want my traffic secure" or "I don't want DDoS attacks in my
network"; rather the User-construct here means that Security Policies network"; rather the User-construct here means that Security Policies
are described using expressions such as application names, are described using expressions such as application names,
application groups, device groups, user groups etc. with a vocabulary application groups, device groups, user groups etc. with a vocabulary
of verbs (e.g., drop, tap, throttle), prepositions, conjunctions, of verbs (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 Security Controller or Controller: Used interchangeably with Security Controller or
management system throughout this document management system throughout this document
skipping to change at page 4, line 51 skipping to change at page 5, line 4
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 Security Controller or Controller: Used interchangeably with Security 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 [RFC8192]
[I-D.ietf-i2nsf-problem-and-use-cases]
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 principle for Client-Facing Interface definition VPN: Virtual Private Network
3. Guiding Principle for Client-Facing Interface Definition
Client-Facing Interface must ensure that a Security Admin can deploy Client-Facing Interface must ensure that a Security Admin can deploy
a NSF from any vendor and should still be able to use the same a NSF from any vendor and should still be able to use the same
consistent interface. In essence, this interface allows a Security consistent interface. In essence, this interface allows a Security
Admin to express a Security Policy enforced on the NSF to be Admin to express a Security Policy enforced on the NSFs to be
independent of vendor and its implementation. Henceforth, in this independent of vendor and its implementation. Henceforth, in this
document, we use "security policy management interface" document, we use "security policy management interface"
interchangeably when we refer to Client-Facing interface. interchangeably when we refer to Client-Facing interface.
3.1. User-construct based modeling 3.1. User-construct Based Modeling
Traditionally, Security Policies have been expressed using vendor Traditionally, Security Policies have been expressed using vendor
proprietary interface. The interface is defined by a vendor based on proprietary interface. The interface is defined by a vendor based on
proprietary command line text or a GUI based system with proprietary command line text or a GUI based system with
implementation specific constructs such IP address, protocol and implementation specific constructs such IP address, protocol and
L4-L7 information. This requires Security Admin to translate their L4-L7 information. This requires Security Admin to translate their
business objectives into vendor provided constructs in order to business objectives into vendor provided constructs in order to
express a Security Policy. But, this alone is not sufficient to express a Security Policy. But, this alone is not sufficient to
render a policy in the network; the admin must also understand render a policy in the network; the admin must also understand
network and application design to locate a specific policy network and application design to locate a specific policy
skipping to change at page 6, line 17 skipping to change at page 6, line 19
level constructs such as User-group, Application-group, Device-group, level constructs such as User-group, Application-group, Device-group,
Location-group, etcetera. A Security Admin would use these Location-group, etcetera. A Security Admin would use these
constructs to express a security policy instead of proprietary constructs to express a security policy instead of proprietary
implementation or feature specific constructs. The policy defined in implementation or feature specific constructs. The policy defined in
such a manner is referred to User-construct based policies in this such a manner is referred to User-construct based policies in this
draft. The idea is to enable Security Admin to use constructs they draft. The idea is to enable Security Admin to use constructs they
understand best in expressing Security Policies which simplify their understand best in expressing Security Policies which simplify their
tasks and help avoiding human errors in complex security tasks and help avoiding human errors in complex security
provisioning. provisioning.
3.2. Basic rules for Client-Facing 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 dependent on a particular network topology or the NSF location o Not dependent on a particular network topology or the NSF location
in the network in the network
o Not forced to express Security Policy with proprietary vendor o Not forced to express Security Policy with proprietary vendor
specific interfaces for a given NSFa€ specific interfaces for a given NSF
o Independent of NSF type that will implement a specific Security o Independent of NSF type that will implement a specific Security
Policy; e.g., the interface remains same no matter if a specific Policy; e.g., the interface remains same no matter if a specific
Security Policy is enforced on a stateful firewall,IDP, IDS, Security Policy is enforced on a stateful firewall, IDP, IDS,
Router or a Switch Router or a Switch
o Declarative/Descriptive model instead of Imperative/Prescriptive o Declarative/Descriptive model instead of Imperative/Prescriptive
model - What security policy need to be expressed (declarative) model - What security policy need to be expressed (declarative)
instead of how it is implemented (imperative) instead of how it is implemented (imperative)
o Not dependent on vendor's' implementation or form-factor o Not dependent on vendors' implementation or form-factor (physical,
(physical, virtual) of the NSF virtual) of the NSF
o Not dependent 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 dependent 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 one), e.g., cluster of NSFs active as one unified service for
scale and/ or resilience. scale and/ or resilience.
o Not depending on specific data plane implementation of NSF, e.g. o Not depending on specific data plane implementation of NSF, e.g.
encapsulation, service function chains. encapsulation, service function chains.
skipping to change at page 7, line 16 skipping to change at page 7, line 20
as topology awareness, capability of the NSF and its functions, as topology awareness, capability of the NSF and its functions,
supported encapsulations etc., to convert and apply the policies supported encapsulations etc., to convert and apply the policies
accurately on the NSF. accurately on the NSF.
3.3. Deployment Models for Implementing Security Policies 3.3. Deployment Models for Implementing Security Policies
Traditionally, medium and large Enterprises deploy vendor provided Traditionally, medium and large Enterprises deploy vendor provided
management systems to create Security Policies and any changes to management systems to create Security Policies and any changes to
these Security Policies are made manually over time by Security these Security Policies are made manually over time by Security
Admin. This approach may not be suitable and nor sufficient for Admin. This approach may not be suitable and nor sufficient for
modern highly automated data centers that are largely virtualized and modern highly automated campus network, and data centers that are
rely on various management systems and controllers to implement largely virtualized and rely on various management systems and
dynamic Security Policies over large number of NSF in the network. controllers to implement dynamic Security Policies over large number
of NSF in the network.
There are two distinct deployment models for Security Controller. There are two distinct deployment models for Security Controller.
Although, these have no direct impact on the Client-Facing interface, Although, these have no direct impact on the Client-Facing interface,
but illustrate the overall Security Policy management framework in an but illustrate the overall Security Policy management framework in an
organization and how the Client-Facing interface remain same which is organization and how the Client-Facing interface remain same which is
the main objective of this document. These models are: the main objective of this document. These models are:
a. Policy management without an explicit management system for a. Policy management without an explicit management system for
control of NSFs. In this deployment, Security Controller acts as control of NSFs. In this deployment, Security Controller acts as
a NSF management system; it takes information passed over Client- a NSF management system; it takes information passed over Client-
Facing interface and translates into data on I2NSF NSF-facing Facing interface and translates into data on I2NSF NSF-Facing
interface. The NSF-Facing interface is implemented by NSF interface. The NSF-Facing interface is implemented by NSF
vendors; this would usually be done by having an I2NSF agent vendors; this would usually be done by having an I2NSF agent
embedded in the NSF. This deployment model is shown in Figure 1. embedded in the 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 |
NSF 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 9, line 11 skipping to change at page 9, line 11
of NSFs. This model is similar to the model above except that of NSFs. This model is similar to the model above except that
Security Controller interacts with a vendor's dedicated Security Controller interacts with a vendor's dedicated
management system that proxy I2NSF NSF-Facing interfaces as NSF management system that proxy I2NSF NSF-Facing interfaces as NSF
may not support NSF-Facing interface. This is a useful model to may not support NSF-Facing interface. This is a useful model to
support legacy NSF. This deployment model is shown in Figure 2. support legacy NSF. 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) |
| |
------------------------------ ------------------------------
| | | |
| Security Controller | | Security Controller |
| | | |
------------------------------ ------------------------------
| ^ | ^
| I2NSF | | I2NSF |
NSF 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 33 skipping to change at page 10, line 33
declarative, expressed using User-construct, and driven by how declarative, expressed using User-construct, and driven by how
Security Admin view Security Policies from their business needs and Security Admin view Security Policies from their business needs and
objectives. objectives.
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
requirement for Client-Facing interface is as follows: requirement for Client-Facing interface is as follows:
o Unified model for various network types (i.e., campus network,
date center, operator core/metro network, etc)
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 35 skipping to change at page 11, line 37
interface. interface.
RECOMMENDED: This means, we recommend that Client-Facing interface RECOMMENDED: This means, we recommend that Client-Facing interface
support this requirement since it might be applicable to large support this requirement since it might be applicable to large
number of use-cases but some vendor may choose to omit if their number of use-cases but some vendor may choose to omit if their
focus is only certain market segments. focus is only certain market segments.
MAY: This means, the requirement is not mandatory for Client-Facing MAY: This means, the requirement is not mandatory for Client-Facing
interface but may be needed for specific use-cases. interface but may be needed for specific use-cases.
4.1. Requirement for Multi-Tenancy in Client-Facing interface 4.1. Requirement for Unified Model for Various Network Types
In terms of security management/control, different network types have
different focus and requirements. In general, campus network focuses
more on user and device management, as well as the access control
among them. But for data center, more focus are putted on the east-
west traffic control for various application, or workload isolation
with micro-segmentation.
Comparing to campus network and DC network, the other network types,
such as: operator core/metro network, VPN network, are relatively
simple in terms of security policies but still have their own
considerations. Despite their different focus on security policy,
one unified model is still necessary with the benefits of simplicity,
wide applicability and extensibility. More specifically, the unified
model here means all the policy objects are constructed with the same
structured method in the security policies for all the network types.
We classify this requirement in MUST category.
4.2. Requirement for Multi-Tenancy in Client-Facing Interface
An organization may have internal tenants and might want a framework An organization may have internal tenants and might want a framework
wherein each tenant manages its own Security Policies with isolation wherein each tenant manages its own Security Policies with isolation
from other tenants. This requirement may be applicable to Service from other tenants. This requirement may be applicable to Service
Providers and Large Enterprises so we classify this requirement in Providers and Large Enterprises so we classify this requirement in
RECOMMENDED category. If an implement does not support this RECOMMENDED category. If an implement does not support this
requirement, it must support a default implicit tenant created by requirement, it must support a default implicit tenant created by
Security Controller that owns all the Security Policies. Security Controller that owns all the Security Policies.
A Security Admin may be a Cloud Service Provider with multi-tenant A Security Admin may be a Cloud Service Provider with multi-tenant
skipping to change at page 12, line 19 skipping to change at page 12, line 41
Policy-Tenant: An entity that owns and manages Security Policies Policy-Tenant: An entity that owns and manages Security Policies
applied to its own asset and resources. applied to its own asset and 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-Facing 4.3. Requirement for Authentication and Authorization of Client-Facing
interface Interface
A Security Admin must be authenticated and authorized in order to A Security Admin must be authenticated and authorized in order to
manage Security Policies. We classify this requirement in MUST manage Security Policies. We classify this requirement in MUST
category since without proper authentication and authorization, the category since without proper authentication and authorization, the
security posture of entire organization can be easily compromised. security posture of entire organization can be easily compromised.
There must be methods defined for Policy-Administrator to be There must be methods defined for Policy-Administrator to be
authenticated and authorized to use Security Controller. There are authenticated and authorized to use Security Controller. There are
several authentication methods available such as OAuth [RFC6749], several authentication methods available such as OAuth [RFC6749],
XAuth and X.509 certificate based; the authentication may be mutual XAuth and X.509 certificate based; the authentication may be mutual
or single-sided based on business needs and outside the scope of or single-sided based on business needs and outside the scope of
I2NSF. In addition, there must be a method o authorize the Policy- I2NSF. In addition, there must be a method o authorize the Policy-
Administrator to perform certain action. It should be noted that, Administrator to perform certain action. It should be noted that,
Policy-Administrator authentication and authorization to perform Policy-Administrator authentication and authorization to perform
actions could be part of Security Controller or outside; this actions could be part of Security Controller or outside; this
document does not mandate any specific implementation but requires document does not mandate any specific implementation but requires
that such a scheme must be implemented. that such a scheme must be implemented.
4.3. Requirement for Role-Based Access Control (RBAC) in Client-Facing 4.4. Requirement for Role-Based Access Control (RBAC) in Client-Facing
interface Interface
A tenant in organization may have multiple users with each user given A tenant in organization may have multiple users with each user given
certain privileges. Some user such as "Admin" may have all the certain privileges. Some user such as "Admin" may have all the
permission but other may have limited permissions. We classify this permission but other may have limited permissions. We classify this
requirement in RECOMMENDED category since it aligns with Multi- requirement in RECOMMENDED category since it aligns with Multi-
Tenancy requirement. If this requirement is not supported, a default Tenancy requirement. If this requirement is not supported, a default
privilege must be assigned to all the users. privilege must be assigned to all the users.
The following objects are needed to fulfill this requirement: The following objects are needed to fulfill this requirement:
Policy-Authorization-Role: Defines the permissions assigned to a Policy-Authorization-Role: Defines the permissions assigned to a
user such as creating and managing policies on specified user such as creating and managing policies on specified
resources. A user may not be allowed to change existing policies resources. A user may not be allowed to change existing policies
but only view them. but only view them.
4.4. Requirement to protect Client-Facing interface from attacks 4.5. Requirement to Protect Client-Facing Interface from Attacks
The interface must be protections against attacks from malicious The interface must be protected against attacks from malicious
clients or a client impersonator. Potential attacks could come from clients or a client impersonator. Potential attacks could come from
Botnets, hosts infected with virus or some unauthorized entities. Botnets, hosts infected with virus or some unauthorized entities.
This requirement is highly RECOMMENDED since it may not be needed if This requirement is highly RECOMMENDED since it may not be needed if
the entire framework is deployed in very controlled environment. But the entire framework is deployed in very controlled environment. But
if needed, we recommend that Security Controller uses a out-of-band if needed, we recommend that Security Controller uses an out-of-band
communication channel for Client-Facing interface. In addition,it is communication channel for Client-Facing interface. In addition, it
also recommended that traffic Client-Facing interface communication is also recommended that traffic of Client-Facing interface
be encrypted; furthermore, some straightforward traffic/session communication are encrypted; Furthermore, some straightforward
control mechanisms (i.e., Rate-limit, ACL, White/Black list) can be traffic/session control mechanisms (i.e., Rate-limit, ACL, White/
employed on Security Controller to defend against DDoS flooding Black list) can be employed on Security Controller to protect against
attacks. DDoS flooding attacks.
4.5. Requirement to protect Client-Facing interface from 4.6. Requirement to protect Client-Facing Interface from
misconfiguration Misconfiguration
There must be protections from mis-configured clients. System and There must be measures to protect from mis-configured clients.
policy parameters validations should be implemented to detect this. System and policy parameters validations should be implemented to
Validation may be based on a set of default parameters or custom detect this. Validation may be based on a set of default parameters
tuned thresholds such as the number of policy changes submitted, or custom tuned thresholds such as the number of policy changes
number of objects requested in a given time interval, etc. We submitted, number of objects requested in a given time interval, etc.
consider this to be a MUST requirement but implementation aspects We consider this to be a MUST requirement but implementation aspects
would depend upon each individual API communication. would depend upon each individual API communication.
4.6. Requirement to manage policy lifecycle with rich set of controls 4.7. Requirement to Manage Policy Lifecycle with Rich Set of Controls
In order to provide more sophisticated security framework, there In order to provide more sophisticated and flexible security
should be a mechanism so that a policy becomes dynamically active/ framework, there should be a mechanism so that a policy becomes
enforced or inactive based on multiple different criteria such as dynamically active/enforced or inactive based on multiple different
Security Admin's manual intervention or some external event. We criteria such as Security Admin's manual intervention or some
consider requirement listed here to be a MUST for wide variety of external event. We consider requirement listed here to be a MUST for
use-cases. wide variety of use-cases.
One example of dynamic policy management is when Security Admin pre- One example of dynamic policy management is when Security Admin pre-
configures all the security policies, but the policies get activated configures all the security policies, but the policies get activated
or deactivated based on dynamic threat detection. Basically, a or deactivated based on dynamic threat detection. Basically, a
threat event may activate certain inactive policies, and once a new threat event may activate certain inactive policies, and once a new
event indicates that the threat has gone away, the policies become event indicates that the threat has gone away, the policies become
inactive again. inactive again.
There are following ways for dynamically activating policies: There are following ways for dynamically activating policies:
skipping to change at page 14, line 33 skipping to change at page 15, line 7
Otherwise, it is de-activated. Otherwise, it is de-activated.
Event-Enforced: A policy configuration specifies the event profile Event-Enforced: A policy configuration specifies the event profile
that determines when the policy is to be activated/enforced. It that determines when the policy is to be activated/enforced. It
also specifies the duration attribute of that policy once also specifies the duration attribute of that policy once
activated based on event. For instance, if the policy is activated based on event. For instance, if the policy is
activated upon detecting an application flow, the policy could be activated upon detecting an application flow, the policy could be
de-activated when the corresponding session is closed or the flow de-activated when the corresponding session is closed or the flow
becomes 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, which is composed of many
and subject to updates and modification. For the policy maintenance, rules, and subject to updates and modification. For the policy
enforcement, and audit-ability purposes, it becomes important to name maintenance, enforcement, and audit-ability purposes, it becomes
and version Security Policy. Thus, the policy definition SHALL important to name and version Security Policy. Thus, the policy
support policy naming and versioning. In addition, the i2NSF Client- definition SHALL support policy naming and versioning. In addition,
Facing interface SHALL support the activation, deactivation, the I2NSF Client-Facing interface SHALL support the activation,
programmability, and deletion of policies based on name and version. deactivation, programmability, and deletion of policies based on name
In addition, it should support reporting operational state of and version. In addition, it should support reporting operational
policies by name and version. For instance, a Security Admin may state of policies by name and version. For instance, a Security
probe Security Controller whether a Security Policy is enforced for a Admin may probe Security Controller whether a Security Policy is
tenant and/or a sub-tenant (organization) for audit-ability or enforced for a tenant and/or a sub-tenant (organization) for audit-
verification purposes. ability or verification purposes.
4.7. Requirement to define dynamic Policy Endpoint Group 4.8. Requirement to Define Dynamic Policy Endpoint Group
When Security Admin configures a Security Policy, it may have When Security Admin configures a Security Policy, it may have
requirement to apply this policy to certain subsets of the network. requirement to apply this policy to certain subsets of the network.
The subsets may be identified based on criteria such as Users, The subsets may be identified based on criteria such as Users,
Devices, and Applications. We refer to such a subset of the network Devices, and Applications, or combination of them. We refer to such
as a "Policy Endpoint Group". This requirement is the fundamental a subset of the network as a "Policy Endpoint Group". This
building block of Client-Facing interface; so making it a MUST requirement is the fundamental building block of Client-Facing
requirement. But object defined here may not support all use-cases interface; so making it a MUST requirement. But object defined here
and may not be required by everyone so it is left up to vendor may not support all use-cases and may not be required by everyone so
whether all or partial set of these object is supported. it is left up to vendor whether all or partial set of these object is
supported.
One of the biggest challenges for a Security Admin is how to make One of the biggest challenges for a Security Admin is how to make
sure that a Security Policy remain effective while constant changes sure that a Security Policy remain effective while constant changes
are happening to the "Policy Endpoint Group" for various reasons are happening to the "Policy Endpoint Group" for various reasons
(e.g., organizational, network and application changes). If a policy (e.g., organizational, network and application changes). If 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 (HR-users group), then each time the group of Human Resource users (HR-users group), then each time the
skipping to change at page 15, line 29 skipping to change at page 16, line 5
We call these dynamic Policy Endpoint Groups "Metadata Driven We call these dynamic Policy Endpoint Groups "Metadata Driven
Groups". The metadata is a tag associated with endpoint information Groups". The metadata is a tag associated with endpoint information
such as User, Application, or Device. The mapping from metadata to such as User, Application, or Device. The mapping from metadata to
dynamic content could come from a standards-based or proprietary dynamic content could come from a standards-based or proprietary
tools. Security Controller could use any available mechanisms to tools. Security Controller could use any available mechanisms to
derive this mapping and to make automatic updates to policy content derive this mapping and to make automatic updates to policy content
if the mapping information changes. The system SHOULD allow for if the mapping information changes. The system SHOULD allow for
multiple, or sets of tags to be applied to a single endpoint. multiple, or sets of tags to be applied to a single endpoint.
Client-Facing interface must support Endpoint Groups as a target for Client-Facing interface must support Policy Endpoint Groups as a
a Security Policy. The following metadata driven groups MAY be used target for a Security Policy. The following metadata driven groups
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
static information such as user-names. The tag identifying users, static information such as user-names. The tag identifying users,
is dynamically derived from systems such as Active Directory or is dynamically derived from systems such as Active Directory or
LDAP. For example, an organization may have different User- LDAP. For example, an organization may have different User-
groups,such as HR-users, Finance-users, Engineering-users, to groups,such as HR-users, Finance-users, Engineering-users, to
classify a set of users in each department. classify a set of 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 device information. The tag identifying the devices, is or device information. The tag identifying the devices, is
skipping to change at page 16, line 20 skipping to change at page 16, line 44
identify the application in the corresponding packets. The identify the application in the corresponding packets. The
mapping of application names/tags to signatures in the associated mapping of application names/tags to signatures in the associated
application packets should be defined and communicated to the NSF. application packets should be defined and communicated to the NSF.
The Client-Facing Interface shall support the communication of The Client-Facing Interface shall support the communication of
this information. this information.
Location-Group: This group identifies a set of locations. Tag may Location-Group: This group identifies a set of locations. Tag may
correspond 1:1 to location. The tag identifying locations is correspond 1:1 to location. The tag identifying locations 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 Admin may want to classify all as CMDB. For example, a Security Admin may want to classify all
sites/locations in a geographic region as one group. sites/locations in a geographic region as one group. Note that
the location can be both the geographic and abstract concept.
Some typical examples for the latter case are: branches and
headquarter for a large enterprise; different data center sites;
private cloud and public cloud.
4.8. Requirement to express rich set of Policy Rules 4.9. Requirement to Express Rich Set of Policy Rules
The Policy Rules is a central component of any Security Policy but The Policy Rules is a central component of any Security Policy but
rule requirements may vary based on use-cases and it is hard to rule requirements may vary based on use-cases and it is hard to
define a complete set that works for everyone. In order to build a define a complete set that works for everyone. In order to build a
rich interface, we are going to take a different approach; we will rich interface, we are going to take a different approach; we will
define the building block of rules and let Security Admin build rules define the building block of rules and let Security Admin build rules
using these construct so that Security Policies meet their using these construct so that Security Policies meet their
requirements: requirements divided into the following major categories:
Segmentation policies : This set of policies create rules for Segmentation policies : This set of policies create rules for
communication between two Endpoint Groups. An organization may communication between two Endpoint Groups. An organization may
restrict certain communication between a set of user and restrict certain communication between a set of user and
applications for example. The segmentation policy may be a micro- applications for example. The segmentation policy may be a micro-
segmentation rule between components of complex applications or segmentation rule between components of complex applications or
related to hybrid cloud deployment based on location. related to hybrid cloud deployment based on location.
Threat policies: This set of policies creates rules to prevent Threat policies: This set of policies creates rules to prevent
communication with externally or internally identified threats. communication with externally or internally identified threats.
skipping to change at page 17, line 5 skipping to change at page 17, line 36
the network. the network.
Governance and Compliance policies: This set of policies creates Governance and Compliance policies: This set of policies creates
rules to implement business requirement such as controlling access rules to implement business requirement such as controlling access
to internal or external resources for meeting regulatory to internal or external resources for meeting regulatory
compliance or business objectives. compliance or business objectives.
In order to build a generic rule engine to satisfy diverse set of In order to build a generic rule engine to satisfy diverse set of
Policy Rules, we propose following objects: Policy Rules, we propose following objects:
In order to build a generic rule engine to satisfy diverse set of
Policy Rules, we propose following objects:
Source Policy Endpoint Group: A source target of the Policy Rule. Source Policy Endpoint Group: A source target of the Policy Rule.
This may be special object "ALL" if all groups meet this criteria. This may be special object "ALL" if all groups meet this criteria.
Destination Policy Endpoint Group: A destination target of the Destination Policy Endpoint Group: A destination target of the
Policy Rule. This may be a special object "ALL", if all groups Policy Rule. This may be a special object "ALL", if all groups
meet this criteria. meet this criteria.
Direction: By default rules are applied in either direction but this Direction: By default rules are applied in both directions but this
object can be used to make rule definition uni-directional. object can be used to make rule definition uni-directional.
Threat Group: An object that represents a set of static or dynamic Threat Group: An object that represents a set of static or dynamic
threats such as Botnet, GeoIP, URL feeds or virus and malware threats such as Botnet, GeoIP, URL feeds or virus and malware
signatures detected dynamically. This object can be used as signatures detected dynamically. This object can be used as
source or destination target in a rule. source or destination target in a rule.
Match Condition: An object that represents a set of allowed Match Condition: An object that represents a set of allowed
interactions. It could be as simple as group of application names interactions. It could be as simple as group of application names
or L4 ports allowed between two Endpoint Groups. It could very or L4 ports allowed between two Endpoint Groups.
well that all traffic is allowed between two groups.
Exceptions: In order to truly build rules which are Security Admin Exceptions: In order to greatly simplify Security Admin's task, we
and built with user semantics, we should allow to specify should allow to specify exceptions to the match criteria. E.g.,
exceptions to the match criteria. This will greatly simplify we could build a rule that allows all traffic between two groups
Security Admin's task. E.g., we could build a rule that allows except a particular application or threat source.
all traffic between two groups except a particular application or
threat source.
Actions: Action is what makes rule and Policy work. The Action is Actions: Action is what makes rule and Policy work. The Action is
defined in details in next section. We RECOMMEND that there be a defined in details in next section. We RECOMMEND that there be a
one-to-one mapping between rule and action otherwise if multiple one-to-one mapping between rule and action otherwise if multiple
rules are associated with one action, it may be a difficult to rules are associated with one action, it may be a difficult to
manage Security Policy lifecycle as they evolve. manage Security Policy lifecycle as they evolve.
4.9. Requirement to express rich set of Policy Actions 4.10. Requirement to Express Rich Set of Policy Actions
Security Admin must be able to configure a variety of actions for a Security Admin must be able to configure a variety of actions for a
given Policy Rule. Typically, Security Policy specifies a simple given Policy Rule. Typically, Security Policy specifies a simple
action of "deny" or "permit" if a particular condition is matched. action of "deny" or "permit" if a particular condition is matched.
Although this may be enough for most use-cases, the I2NSF Client- Although this may be enough for most use-cases, the I2NSF Client-
Facing interface must provide a more comprehensive set of actions so Facing interface must provide a more comprehensive set of actions so
that the interface can be used effectively across various security that the interface can be used effectively across various security
needs. needs.
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.
default action.
Deny: This action means stop further packet processing and drop the Deny: This action means stop further packet processing and drop the
packet. packet.
Drop connection: This action means stop further packet processing, Drop connection: This action means stop further packet processing,
drop the packet, and drop connection (for example, by sending a drop the packet, and drop connection (for example, by sending a
TCP reset). TCP reset).
Log: This action means create a log entry whenever a rule is Log: This action means create a log entry whenever a rule is
matched. matched.
skipping to change at page 19, line 11 skipping to change at page 19, line 36
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, IPS, IDS, honeypot, or VPN, profile. An NSF can be any of the FW, IPS, IDS, honeypot, or VPN,
etc. etc.
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 consistent policy enforcement 4.11. Requirement for Consistent Policy Enforcement
As proposed in this document that the Client-Facing interface MUST be As proposed in this document, the Client-Facing interface MUST be
built using higher-level "User-Constructs" that are independent of built using higher-level "User-Constructs" that are independent of
network design and implementations. In order to achieve this, it network design and implementations. In order to achieve this goal,
becomes important that Security Controller functionality becomes more it becomes important that Security Controller functionality becomes
complex that keep track of various objects that are used to express more complex that keep track of various objects that are used to
Security Policies. The Security Controller MUST evaluate the express Security Policies. The Security Controller MUST evaluate the
Security Policies whenever these objects and network topology change Security Policies whenever these objects and network topology change
to make sure that Security Policy is consistently enforced as to make sure that Security Policy is consistently enforced as
expressed. expressed.
Although this document does not specify how Security Controller Although this document does not specify how Security Controller
achieve this and any implementation challenges. It is assumed that achieve this and any implementation challenges. It is assumed that
once Security Controller uses Client-Facing interface to accept once Security Controller uses Client-Facing interface to accept
Security Policies; it would maintain the security posture as per the Security Policies; it would maintain the security posture as per the
Security Policies during all changes in network or Endpoints and Security Policies during all changes in network or Endpoints and
other building blocks of the framework. other building blocks of the framework.
An event must be logged by Security Controller when a Security Policy An event must be logged by Security Controller when a Security Policy
is updated due to changes in it's building blocks such as Endpoint is updated due to changes in it's building blocks such as Endpoint
Group contents or the Security Policy is moved from one enforcement Group contents or the Security Policy is moved from one enforcement
point to another because the Endpoint has moved in the network. This point to another because the Endpoint has moved in the network. This
may help in debugging and auditing for compliance reasons. The may help in debugging and auditing for compliance reasons. The
Security Admin may optionally receive notifications if supported and Security Admin may optionally receive notifications if supported and
desired. desired.
4.11. Requirement to detect and correct policy conflicts 4.12. 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 a newly expressed Security Policy could conflict with For example a newly submitted Security Policy could conflict with
existing Security Policies applied to a set of Policy Endpoint existing Security Policies applied to a set of Policy Endpoint
Groups. This MUST be detected and Security Admin be allowed for Groups. This MUST be detected and Security Admin be allowed for
manual correction if needed. manual correction if needed.
4.12. Requirement for backward compatibility 4.13. 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.14. Requirement for Third-Party Integration
The security framework in a network may require the use of a The security framework in a network may require the use of some
specialty device such as honeypot, behavioral analytic, or SIEM for special devices such as honeypot, behavioral analytic, or SIEM for
threat detection; the device may provide threat information such as threat detection; the device may provide threat information such as
threat feeds, virus signatures, and malicious file hashes. threat feeds, virus signatures, and malicious file hashes.
The Client-Facing interface must allow Security Admin to include The Client-Facing interface must allow Security Admin to include
these devices under Security Controller's Client-Facing interface so these devices under Security Controller's Client-Facing interface so
that a Security Policy could be expressed using information from such that a Security Policy could be expressed using information from such
devices; basically it allows ability to integrate third part devices devices; basically it allows ability to integrate third part devices
into the Security Policy framework. into the Security Policy framework.
4.14. Requirement to collect telemetry data 4.15. 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 network. As threats become more sophisticated, Security into the network. As threats become more sophisticated, Security
Admin must be able to gather different types of telemetry data from Admin must be able to gather different types of telemetry data from
various NSFs in the network. The collected data could simply be various NSFs in the network. The collected data could simply be
logged or sent to security analysis engines for behavioral analysis, logged or sent to security analysis engines for application
policy violations, and for threat detection. identification, flow context and behavioral analysis, policy
violations, and for threat detection. Based on the analysis result,
the security controller can enforce the policy lifecycle management
and automatic optimization.
The Client-Facing interface MUST allow Security Admin to collect The Client-Facing interface MUST allow Security Admin to collect
various kinds of data from NSFs. The data source could be syslog, various kinds of data from NSFs. The data source could be syslog,
flow records, policy violation records, and other available data. flow records, policy violation records, and other available data.
Client-Facing interface must provide a set of telemetry data Client-Facing interface must provide a set of telemetry data
available to Security Admin from Security Controller. The Security available to Security Admin from Security Controller. The Security
Admin should be able to subscribe and receive to this data set. Admin should be able to subscribe and receive to this data set.
5. Operational Requirements for the Client-Facing Interface 5. Operational Requirements for the Client-Facing Interface
5.1. API Versioning 5.1. API Versioning
Client-Facing interface must support a version number for each Client-Facing interface must support a version number for each
RESTful API. This is important since Security Controller could be RESTful API. This is important since Security Controller could be
deployed by using multiple componenets and different pieces may come deployed by using multiple componenets and different pieces may come
from different vendors; it is difficult to isolate and debug issues from different vendors; it is difficult to isolate and debug issues
without ablility to track each component's operational behavior. without ability to track each component's operational behavior. Even
Even if the vendor is same for all the components, it is hard to if the vendor is same for all the components, it is hard to imagine
imagine that all pieces would be released in lock step by the vendor. that all pieces would be released in lock step by the vendor.
Without API versioning, it is hard to debug and figure out issues Without API versioning, it is hard to debug and figure out issues
when deploying Security Controller and its components built overtime when deploying Security Controller and its components built overtime
across multiple release cycles. Although API versioning does not across multiple release cycles. Although API versioning does not
guarantee that Security Controller would always work but it helps in guarantee that Security Controller would always work but it helps in
debugging if the problem is caused by an API mismatch. debugging if the problem is caused by an API mismatch.
5.2. API Extensibility 5.2. API Extensibility
Abstraction and standardization of Client-Facing interface is of Abstraction and standardization of Client-Facing interface is of
skipping to change at page 21, line 43 skipping to change at page 22, line 23
specific policy or associated with operating conditions of a specific specific policy or associated with operating conditions of a specific
NSF in general. The statistics may be a measure of potential NSF in general. The statistics may be a measure of potential
Security Policy violations or general data that reflect operational Security Policy violations or general data that reflect operational
behavior of a NSF. The events, alarms and statistics may also be behavior of a NSF. The events, alarms and statistics may also be
used as an input to automate Security Policy lifecycle management. used as an input to automate Security Policy lifecycle management.
5.5. Affinity 5.5. Affinity
Client-Facing interface must allow Security Admin to pass any Client-Facing interface must allow Security Admin to pass any
additional metadata that a user may want to provide with a Security additional metadata that a user may want to provide with a Security
Policy e.g., if the policy needs to be enforced by a very highly Policy e.g., whether the policy needs to be enforced by a very highly
secure NSF with Trusted Platform Module (TPM) chip. Another example secure NSF with Trusted Platform Module (TPM) chip. Another example
would be, if a policy can not be enforced by a multi-tenant NSF. would be, whether or not a policy can be enforced by a multi-tenant
This would Security Admin control on operating environment NSF. This would Security Admin control on operating environment
5.6. Test Interface 5.6. Test Interface
Client-Facing interface must support ability to test a Security Client-Facing interface must support ability to test a Security
Policy before it is enforced e.g., a user may want to verify whether Policy before it is enforced e.g., a user may want to verify whether
the policy creates any potential conflicts with existing policies or the policy creates any potential conflicts with existing policies or
if there are enough resources and capability to enforce this policy. if there are enough resources and capability to enforce this policy.
The test interface would provide a mechanism to Security Admin where The test interface would provide a mechanism to Security Admin where
policies could be tested in the actual environment before policies could be tested in the actual environment before
enforcement. enforcement.
skipping to change at page 23, line 5 skipping to change at page 23, line 29
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.
9. Normative References 9. Normative References
[I-D.ietf-i2nsf-framework] [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. and J. Jeong, "Interface to Network Security Functions
Kumar, "Framework for Interface to Network Security (I2NSF): Problem Statement and Use Cases", RFC 8192,
Functions", draft-ietf-i2nsf-framework-10 (work in DOI 10.17487/RFC8192, July 2017,
progress), November 2017. <https://www.rfc-editor.org/info/rfc8192>.
[I-D.ietf-i2nsf-problem-and-use-cases] [RFC8327] Hargrave, W., Griswold, M., Snijders, J., and N. Hilliard,
Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., "Mitigating the Negative Impact of Maintenance through BGP
and J. Jeong, "I2NSF Problem Statement and Use cases", Session Culling", BCP 214, RFC 8327, DOI 10.17487/RFC8327,
draft-ietf-i2nsf-problem-and-use-cases-16 (work in March 2018, <https://www.rfc-editor.org/info/rfc8327>.
progress), May 2017.
Authors' Addresses Authors' Addresses
Rakesh Kumar Rakesh Kumar
Lilac Cloud Lilac Cloud
14435 C Big Basin Way #104 14435 C Big Basin Way #104
Saratoga, CA 95070 Saratoga, CA 95070
US US
Email: rakeshkumarcloud@gmail.com Email: rakeshkumarcloud@gmail.com
 End of changes. 65 change blocks. 
173 lines changed or deleted 198 lines changed or added

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