One document matched: draft-kumar-i2nsf-client-facing-interface-req-02.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<!--
vim: set softtabstop=2 shiftwidth=2 expandtab
version=20150108
-->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC7491 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7491.xml">
]>
<rfc category="info"
docName="draft-kumar-i2nsf-client-facing-interface-req-02"
ipr="trust200902">
<front>
<title abbrev="Client Interface Requirements">Requirements for
Client-Facing Interface to Security Controller</title>
<author fullname="Rakesh Kumar" initials="R." surname="Kumar">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1133 Innovation Way</street>
<city>Sunnyvale</city>
<region>CA</region>
<country>US</country>
<code>94089</code>
</postal>
<email>rkkumar@juniper.net</email>
</address>
</author>
<author fullname="Anil Lohiya" initials="A." surname="Lohiya">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1133 Innovation Way</street>
<city>Sunnyvale</city>
<region>CA</region>
<country>US</country>
<code>94089</code>
</postal>
<email>alohiya@juniper.net</email>
</address>
</author>
<author fullname="Dave Qi" initials="D." surname="Qi">
<organization>Bloomberg</organization>
<address>
<postal>
<street>731 Lexington Avenue</street>
<city>New York</city>
<region>NY</region>
<country>US</country>
<code>10022</code>
</postal>
<email>DQI@bloomberg.net</email>
</address>
</author>
<author fullname="Nabil Bitar" initials="N." surname="Bitar">
<organization>Nokia</organization>
<address>
<postal>
<street>755 Ravendale Drive</street>
<city>Mountain View</city>
<region>CA</region>
<country>US</country>
<code>94043</code>
</postal>
<email>nabil.bitar@nokia.com</email>
</address>
</author>
<author fullname="Senad Palislamovic" initials="S." surname="Palislamovic">
<organization>Nokia</organization>
<address>
<postal>
<street>755 Ravendale Drive</street>
<city>Mountain View</city>
<region>CA</region>
<country>US</country>
<code>94043</code>
</postal>
<email>senad.palislamovic@nokia.com</email>
</address>
</author>
<author fullname="Liang Xia" initials="L." surname="Xia">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<country>China</country>
<code>210012</code>
</postal>
<email>Frank.Xialiang@huawei.com</email>
</address>
</author>
<date year="2016"/>
<area>Security</area>
<workgroup>I2NSF Working Group</workgroup>
<keyword>I2NSF</keyword>
<abstract>
<t>This document captures the requirements for the client-facing
interface to the security controller. The interfaces are based on
user constructs understood by a security admin instead of a vendor or a device
specific mechanism requiring deep knowledge of individual products and
features. This document identifies the requirements needed to enforce the
user-construct oriented policies onto network security functions (NSFs)
irrespective of how those functions are realized. The function may be
physical or virtual in nature and may be implemented in networking or
dedicated appliances.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>Programming security policies in a network has been a fairly complex
task that often requires very deep knowledge of vendor specific
devices. This has been the biggest challenge for both service providers
and enterprises, henceforth named as security administrator in this
document. The challenge is amplified due to virtualization with
security appliances in physical and virtual form factor from a wide
variety of vendors; each vendor have their own proprietary interfaces to
express security policies on their devices. </t>
<t>Even if a security administrator deploys a single vendor solution
with one or more security appliances across its entire network, it is
still difficult to manage security policies due to complexity of
security features, and difficulty in mapping business requirement to
vendor specific configuration. The security administrator may use either
vendor provided CLIs or management system with some abstraction to help
provision and manage security policies. But, the single vendor approach
is highly restrictive in today's network for the following reasons: <list
style="symbols">
<t>The security administrator cannot rely on a single vendor
because one vendor may not be able to keep up with their
security requirements or specific deployment model.</t>
<t>A large organization may have a presence across different sites
and regions; which means, it may not be possible to deploy same
solution from single vendor due to regulatory requirement or
organizational policy.</t>
<t>If and when security administrator migrates from one
vendor to another, it is almost impossible to migrate security
policies from one vendor solution to another without complex
manual workflows.</t>
<t>Security administrators deploy various security
functions in virtual or physical forms to attain the
flexibility, elasticity, performance, and operational efficiency
they require. Practically, that often requires different sources
(vendor, open source) to get the best of breed for any
such security function.</t>
<t>The security administrator might choose various devices or
network services (such as routers, switches, firewall devices, and
overlay-networks) as enforcement points for security policies. This
my be for reason (such as network design simplicity, cost,
most-effective place, scale and performance).</t>
</list></t>
<t>In order to ease the deployment of security policies across different
vendors and devices, the Interface to Network Security Functions
(I2NSF) working group in the IETF is defining a client-facing interface
from the security controller to clients [I-D. ietf-i2nsf-framework]
[I-D. ietf-i2nsf-terminology]. Deployment facilitation should be
agnostic to the type of device, be it physical or virtual, or type of the
policy, be it dynamic or static. Using these interfaces, it would
become possible to write different kinds of application (e.g.
GUI portal, template engine, etc.) to control the implementation of
security policies on security functional elements, though how these
applications are implemente are completely out of the scope of the I2NSF
working group, which is only focused on the interfaces. </t>
<t>This document captures the requirements for the client-facing
interface that can be easily used by security administrators without
knowledge of specific security devices or features. We refer to this as
"user-construct" based interfaces. To further clarify, in the scope of this
document, the "user-construct" here does not mean 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 network"; rather the user-construct
here means that policies are described using client-oriented expressions
such as application names, application groups, device groups, user
groups etc. with a vocabulary of verbs (e.g., drop, tap, throttle),
prepositions, conjunctions, conditionals, adjectives, and nouns instead
of using standard n-tuples from the packet header.</t>
</section>
<section anchor="conventions" title="Conventions Used in this Document">
<t><list style="hanging">
<t hangText="BSS:">Business Support System</t>
<t hangText="CLI:">Command Line Interface</t>
<t hangText="CMDB:">Configuration Management Database</t>
<t hangText="Controller:">Used interchangeably with Service Provider
Security Controller or management system throughout this
document</t>
<t hangText="CRUD:">Create, Retrieve, Update, Delete</t>
<t hangText="FW:">Firewall</t>
<t hangText="GUI:">Graphical User Interface</t>
<t hangText="IDS:">Intrusion Detection System</t>
<t hangText="IPS:">Intrusion Protection System</t>
<t hangText="LDAP:">Lightweight Directory Access Protocol</t>
<t hangText="NSF:">Network Security Function, defined by <xref
target="I-D.ietf-i2nsf-problem-and-use-cases"/></t>
<t hangText="OSS:">Operation Support System</t>
<t hangText="RBAC:">Role Based Access Control</t>
<t hangText="SIEM:">Security Information and Event Management</t>
<t hangText="URL:">Universal Resource Locator</t>
<t hangText="vNSF:">Refers to NSF being instantiated on Virtual
Machines</t>
</list></t>
</section>
<section anchor="fwk" title="Guiding principles for definition of Client-Facing Interfaces">
<t>The "Client-Facing Interface" ensures that a security administrator
can deploy any device from any vendor and still be able to use a
consistent interface. In essence, this interface gives ability to
security admins to express their security policies independent of how
security functions are implemented in their deployment. Henceforth,
in this document, we use "security policy management interface"
interchangeably when we refer to the client-facing interface.</t>
<section anchor="user-construct"
title="User-construct based modeling">
<t>Traditionally, security policies have been expressed using proprietary
interfaces. These interface are defined by a vendor either based on CLI
or a GUI system; but more often these interfaces are built using vendor
specific networking construct such IP address, protocol and application
constructs with L4-L7 information. This requires security operator to
translate their oragnzational business objectives into actionable security
policies on the device using vendor specific configuration. But, this alone
is not sufficient to render policies in the network as operator also need to
identify the device in the network topology where a policy need to be
enforced in a complex environment with potenial multiple policy enforcement
points.</t>
<t>The User-construct based framework defines constructs such as user-group,
application-group, device-group and location-group. The security admin would
use these constructs to express a security policy instead of proprietary
vendor specific constructs. The policy defined in such a manner is referred
to user-construct based policies in this draft. The idea is to enable security
admin to use constructs they understand best in expressing security policies;
which simplify their tasks and help avoiding human errors in complex
security provisioning. </t>
</section>
<section anchor="guide"
title="Basic rules for client interface definition">
<t>The basic rules in defining the client-facing interfaces are as
follows: <list style="symbols">
<t>Not depending on particular network topology or the actual NSF
location in the network</t>
<t>Not requiring the exact knowledge of the concrete features and
capabilities supported in the deployed NSFs”</t>
<t>Independent of the nature of the function that will apply the
expressed policies be it stateful firewall,IDP, IDS, Router, Switch</t>
<t>Declarative/Descriptive model instead of
Imperative/Prescriptive model - What security policies need to be
enforced (declarative) instead of how they would be actually
implemented (imperative)</t>
<t>Not depending on any specific vendor implementation or form-factor
(physical, virtual) of the NSF</t>
<t>Not depending on how a NSF becomes operational - Network connectivity
and other hosting requirements.</t>
<t>Not depending on NSF control plane implementation (if there is one)
E.g., cluster of NSFs active as one unified service for scale and/
or resilience.</t>
<t>Not depending on specific data plane implementation of NSF i.e.
Encapsulation, Service function chains.</t>
</list></t>
<t>Note that the rules stated above only apply to the client-facing
interface where a user will define a high level policy. These rules
do not apply to the lower layers e.g. security controller that convert
the higher level policies into lower level constructs. The lower layers
may still need some intelligence such as topology awareness, capability
of the NSF and its functions, supported encapsulations etc. to convert
and apply the policies accurately on the NSF devices.</t>
</section>
<section anchor="models"
title="Deployment Models for Implementing Security Policies">
<t>Traditionally, medium and larger operators deploy management
systems to manage their statically-defined security policies. This
approach may not be suitable nor sufficient for modern automated and
dynamic data centers that are largely virtualized and rely on various
management systems and controllers to dynamically implement security
policies over any types of resources.</t>
<t>There are two different deployment models in which the
client-facing interface referred to in this document could be
implemented. These models have no direct impact on the client-facing
interface, but illustrate the overall security policy and management
framework and where the various processing functions reside. These
models are: <list style="letters">
<t>Management without an explicit management system for control of
devices and NSFs. In this deployment, the security controller acts
as a NSF policy management system that takes information passed
over the client security policy interface and translates into data on
the I2NSF NSF-facing interface. The I2NSF interfaces are
implemented by security device/function vendors. This would
usually be done by having an I2NSF agent embedded in the security
device or NSF. This deployment model is shown in <xref
target="without"/>. <figure anchor="without"
title="Deployment without Management System">
<artwork>
RESTful API
SUPA or I2NSF Policy Management
^
|
Client-facing Interface |
(Independent of individual |
NSFs, devices,and vendors)|
|
------------------------------
| |
| Security Controller |
| |
------------------------------
| ^
| I2NSF |
NSF Interface | NSF-facing |
(Specific to NSFs) | Interface |
..............................
| |
v |
------------- -------------
| I2NSF Agent | | I2NSF Agent |
|-------------| |-------------|
| |---| |
| NSF | | NSF |
NSFs | | | |
(virtual -------------\ /-------------
and | \ / |
physical) | X |
| / \ |
-------------/ \-------------
| I2NSF Agent | | I2NSF Agent |
|-------------| |-------------|
| |---| |
| NSF | | NSF |
| | | |
------------- -------------
</artwork>
</figure></t>
<t>Management with an explicit management system for control of
devices and NSFs. This model is similar to the model above except
that security controller interacts with a dedicated management
system which could either proxy I2NSF NSF-facing interfaces or
could provide a layer where security devices or NSFs do not
support an I2NSF agent to process I2NSF NSF-facing interfaces.
This deployment model is shown in <xref target="with"/>. <figure
anchor="with"
title="Deployment with Management System or I2NSF Proxy Agent">
<artwork>
RESTful API
SUPA or I2NSF Policy Management
^
|
Client-facing Interface |
(Independent of individual |
NSFs,devices,and vendors) |
|
------------------------------
| |
| Security Controller |
| |
------------------------------
| ^
| I2NSF |
NSF Interface | NSF-facing |
(Specific to NSFs) | Interface |
..............................
| |
v |
------------------------------
| |
| I2NSF Proxy Agent / |
| Management System |
| |
------------------------------
| ^
| Proprietary |
| Functional |
| Interface |
..............................
| |
v |
------------- -------------
| |---| |
| NSF | | NSF |
NSFs | | | |
(virtual -------------\ /-------------
and | \ / |
physical) | X |
| / \ |
-------------/ \-------------
| |---| |
| NSF | | NSF |
| | | |
------------- -------------
</artwork>
</figure></t>
</list></t>
<t>Although the deployment models discussed here don't necessarily
affect the client security policy interface, they do give an
overall context for defining a security policy interface based on
abstraction.</t>
</section>
</section>
<section anchor="requirements"
title="Functional Requirements for the Client-Facing Interface">
<t>As stated in the guiding principles for defining I2NSF client-facing
interface, the security policies and the client-facing interface shall
be defined from a user/client perspective and abstracted away from the
type of NSF, NSF specific implementation, controller implementation, NSF
topology, NSF interfaces, controller NSF-facing interfaces. Thus, the
security policy definition shall be declarative, expressing the
user construct, and driven by how security administrators view
security policies from the definition, communication and deployment
perspective.</t>
<t>The security controller's implementation is outside the scope of this
document and the I2NSF working group.</t>
<t>In order to express and build security policies, high level requirements for the client-facing are as follows: <list
style="symbols">
<t>Multi-Tenancy</t>
<t>Authentication and Authorization</t>
<t>Role-Based Access Control (RBAC)</t>
<t>Protection from Attacks</t>
<t>Protection from Misconfiguration</t>
<t>Policy Lifecycle Management</t>
<t>Dynamic Policy Endpoint Groups</t>
<t>Policy Rules</t>
<t>Policy Actions</t>
<t>Generic Policy Model</t>
<t>Policy Conflict Resolution</t>
<t>Backward Compatibility</t>
<t>Third-Party Integration</t>
<t>Telemetry Data</t>
</list></t>
<t>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
starting point for a wide variety of use-cases in Service Provider and
Enterprise networks.</t>
<section anchor="tenancy" title="Requirement for Multi-Tenancy in client interface">
<t>A security administrator that uses security policies may have
internal tenants and would like to have a framework wherein each
tenant manages its own security policies with isolation from
other tenants.</t>
<t>An operator may be a cloud service provider with multi-tenant
deployments, where each tenant is a different customer. Each tenant
or customer must be allowed to manage its own security policies.</t>
<t>It should be noted that tenants may have their own tenants,
so a recursive relation may exist. For instance, a tenant in a cloud
service provider may have multiple departments or organizations that
need to manage their own security rules. </t>
<t>Some key concepts are listed below and used throughout the document
hereafter:<list style="hanging">
<t hangText="Policy-Tenant:">An entity that owns and manages the
security Policies applied on its resources. </t>
<t hangText="Policy-Administrator:">A user authorized to manage
the security policies for a Policy-Tenant.</t>
<t hangText="Policy-User:">A user within a Policy-Tenant who is
authorized to access certain resources of that tenant according to
the privileges assigned to it.</t>
</list></t>
</section>
<section anchor="Authentication"
title="Requirement for Authentication and Authorization of client interface">
<t>Security administrators MUST authenticate to and be authorized by
the security controller before they are able to issue control commands
and any policy data exchange commences. </t>
<t>There must be methods defined for the Policy-Administrator to be
authenticated and authorized to use the security controller. There are
several authentication methods available such as OAuth, XAuth and
X.509 certificate based. The authentication scheme between
Policy-Administrator and security controller may also be mutual
instead of one-way. Any specific method may be determined based on
organizational and deployment needs and outside the scope of I2NSF. In
addition, there must be a method to authorize the Policy-Administrator
for performing certain action. It should be noted that, depending on
the deployment model, Policy-Administrator authentication and
authorization to perform actions communicated to the controller could
be performed as part of a portal or another system prior to
communication the action to the controller. </t>
</section>
<section anchor="RBAC"
title="Requirement for Role-Based Access Control (RBAC) in client interface">
<t>Policy-Authorization-Role represents a role assigned to a
Policy-User that determines whether a user or has read-write access,
read-only access, or no access for certain resources. A User can be
mapped to a Policy-Authorization-Role using an internal or external
identity provider or mapped statically. </t>
</section>
<section anchor="Attacks"
title="Requirement to protect client interface from attacks">
<t>There Must be protections from attacks, malicious or otherwise,
from clients or a client impersonator. Potential attacks could come
from a botnet or a host or hosts infected with virus or some
unauthorized entity. It is recommended that security controller use
a dedicated IP interface for client-facing communications and those
communications should be carried over an isolated out-of-band network.
In addition, it is recommended that traffic between clients and
security controllers be encrypted. Furthermore, some straightforward
traffic/session control mechanisms (i.e., Rate-limit, ACL, White/Black
list) can be employed on the security controller to defend against
DDoS flooding attacks.</t>
</section>
<section anchor="Misconfiguration"
title="Requirement to protect client interface from misconfiguration">
<t>There Must be protections from mis-configured clients. System and policy
validations should be implemented to detect this. Validation may be based on
a set of default parameters or custom tuned thresholds such as the number of
policy changes submitted, number of objects requested in a given time interval, etc.</t>
</section>
<section anchor="Lifecycle"
title="Requirement to manage policy lifecycle with diverse needs">
<t>In order to provide more sophisticated security framework, there
should be a mechanism to express that a policy becomes dynamically
active/enforced or inactive based on either security administrator's
manual intervention or an event.</t>
<t>One example of dynamic policy management is when the security
administrator pre-configures all the security policies, but the
policies get activated or deactivated based on dynamic threats.
Basically, a threat event may activate certain inactive policies,
and once a new event indicates that the threat has gone away, the
policies become inactive again.</t>
<t>There are following ways for dynamically activating policies:</t>
<t>o The policy may be dynamically activated by the I2NSF client or
associated management entity, and dynamically communicated over the
I2NSF client-facing interface to the controller to program I2NSF
functions using the I2NSF NSF-facing interface </t>
<t>o The policy may be pulled dynamically by the controller upon
detecting an event over the I2NSF monitoring interface</t>
<t>o The policy may be statically pushed to the controller and
dynamically programmed on the NSFs upon potentially detecting another
event</t>
<t>o The policy can be programmed in the NSF, and activated or deactivated
upon policy attributes, like time or admin enforced.</t>
<t>The client-facing interface should support the following policy
attributes for policy enforcement: <list style="hanging">
<t hangText="Admin-Enforced:">The policy, once configured, remains
active/enforced until removed by the security administrator.</t>
<t hangText="Time-Enforced:">The policy configuration specifies
the time profile that determines when policy is
activated/enforced. Otherwise, it is de-activated.</t>
<t hangText="Event-Enforced:">The policy configuration specifies
the event profile that determines when policy is
activated/enforced. It also specifies the duration attribute of
that policy once activated based on event. For instance, if the
policy is activated upon detecting an application flow, the policy
could be de-activated when the corresponding session is closed or
the flow becomes inactive for certain time.</t>
</list></t>
<t>A policy could be a composite policy, that is composed of many
rules, and subject to updates and modification. For the policy maintenance,
enforcement, and auditability purposes, it becomes important to name
and version the policies. Thus, the policy definition SHALL support
policy naming and versioning. In addition, the i2NSF client-facing
interface SHALL support the activation, deactivation, programmability,
and deletion of policies based on name and version. In addition, it
should support reporting on the state of policies by name and version.
For instance, a client may probe the controller about the current
policies enforced for a tenant and/or a sub-tenant (organization) for
auditability or verification purposes.</t>
</section>
<section anchor="endpoint"
title="Requirement to define dynamic policy Endpoint group">
<t>When the security administrator configures a security policy, it may have requirement
to apply this policy to certain subsets of the network.
The subsets may be identified based on criteria such as users,
devices, and applications. We refer to such a subset of the network as
a "Policy Endpoint Group".</t>
<t>One of the biggest challenges for a security administrator is how
to make sure that security policies remain effective while constant
changes are happening to the "Policy Endpoint Group" for various
reasons (e.g., organizational, network and application changes). If a
policy is created based on static information such as user names,
application, or network subnets; then every time this static information
change, policies need to be updated. For example, if a policy is created that
allows access to an application only from the group of Human Resource
users (the HR-users group), then each time the HR- users group
changes, the policy needs to be updated.</t>
<t>We call these dynamic Policy Endpoint Groups "Meta-data Driven
Groups". The meta-data is a tag associated with endpoint information
such as users, applications, and devices. The mapping from meta-data
to dynamic content could come either from standards-based or
proprietary tools. The security controller could use any available
mechanisms to derive this mapping and to make automatic updates to the
policy content if the mapping information changes. The system SHOULD
allow for multiple, or sets of tags to be applied to a single network
object.</t>
<t>The client-facing policy interface must support endpoint groups for
user-construct based policy management. The following meta-data driven
groups MAY be used for configuring security polices: <list
style="hanging">
<t hangText="User-Group:">This group identifies a set of users
based on a tag or on static information. The tag to identify user
is dynamically derived from systems such as Active Directory or
LDAP. For example, an operator may have different user-groups,
such as HR-users, Finance-users, Engineering-users, to classify a
set of users in each department.</t>
<t hangText="Device-Group:">This group identifies a set of devices
based on a tag or on static information. The tag to identify
device is dynamically derived from systems such as configuration
mannagement database (CMDB). For example, a security administrator
may want to classify all machines running one operating system
into one group and machines running another operating system into
another group.</t>
<t hangText="Application-Group:">This group identifies a set of
applications based on a tag or on static information. The tag to
identify application is dynamically derived from systems such as
CMDB. For example, a security administrator may want to classify
all applications running in the Legal department into one group
and all applications running under a specific operating system
into another group. In some cases, the application can
semantically associated with a VM or a device. However, in other
cases, the application may need to be associated with a set of
identifiers (e.g., transport numbers, signature in the application
packet payload) that identify the application in the corresponding
packets. The mapping of application names/tags to signatures in
the associated application packets should be defined and
communicated to the NSF. The client-facing Interface shall support
the communication of this information.</t>
<t hangText="Location-Group:">This group identifies a set of
location tags. Tag may correspond 1:1 to location. The tag to
identify location is either statically defined or dynamically
derived from systems such as CMDB. For example, a security
administrator may want to classify all sites/locations in a
geographic region as one group.</t>
</list></t>
</section>
<section anchor="Rules" title="Requirement to express rich set of policy rules">
<t>The security policy rules can be as simple as specifying a match
for the user or application specified through "Policy Endpoint Group"
and take one of the "Policy Actions" or more complicated rules that
specify how two different "Policy Endpoint Groups" interact with each
other. The client-facing interface must support mechanisms to allow
the following rule matches.</t>
<t>Policy Endpoint Groups: The rule must allow a way to match either a
single or a member of a list of "Policy Endpoint Groups".</t>
<t>There must be a way to express a match between two "Policy Endpoint
Groups" so that a policy can be effective for communication between
two groups. <list style="hanging">
<t hangText="Direction:">The rule must allow a way to express
whether the security administrator wants to match the "Policy
Endpoint Group" as the source or destination. The default should
be to match both directions, if the direction rule is not specified
in the policy.</t>
<t hangText="Threats:">The rule should allow the security
administrator to express 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 speciality security appliances. Threats
could be identified by 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.</t>
</list></t>
<t>The threat could be from malware and this requires a way to match
for virus signatures or file hashes.</t>
</section>
<section anchor="Actions" title="Requirement to express rich set of policy actions">
<t>The security administrator must be able to configure a variety of
actions within a security policy. Typically, security policy specifies
a simple action of "deny" or "permit" if a particular condition is
matched. Although this may be enough for most of the simple policies,
the I2NSF client-facing interface must also provide a more
comprehensive set of actions so that the interface can be used
effectively across various security functions.</t>
<t>Policy action MUST be extensible so that additional policy action
specifications can easily be added.</t>
<t>The following list of actions SHALL be supported: <list
style="hanging">
<t hangText="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 default action.</t>
<t hangText="Deny:">This action means stop further packet
processing and drop the packet.</t>
<t hangText="Drop connection:">This action means stop further
packet processing, drop the packet, and drop connection (for
example, by sending a TCP reset).</t>
<t hangText="Log:">This action means create a log entry whenever a
rule is matched.</t>
<t hangText="Authenticate connection:">This action means that
whenever a new connection is established it should be
authenticated.</t>
<t hangText="Quarantine/Redirect:">This action may be relevant for
event driven policy where certain events would activate a
configured policy that quarantines or redirects certain packets or
flows. The redirect action must specify whether the packet is to
be tunneled and in that case specify the tunnel or encapsulation
method and destination identifier.</t>
<t hangText="Netflow:">This action creates a Netflow record; Need
to define Netflow server or local file and version of Netflow.</t>
<t hangText="Count:">This action counts the packets that meet the
rule condition.</t>
<t hangText="Encrypt:">This action encrypts the packets on an
identified flow. The flow could be over an Ipsec tunnel, or TLS
session for instance.</t>
<t hangText="Decrypt:">This action decrypts the packets on an
identified flow. The flow could be over an Ipsec tunnel, or TLS
session for instance.</t>
<t hangText="Throttle:">This action defines shaping a flow or a
group of flows that match the rule condition to a designated
traffic profile.</t>
<t hangText="Mark:">This action defines traffic that matches the
rule condition by a designated DSCP value and/or VLAN 802.1p Tag
value.</t>
<t hangText="Instantiate-NSF:">This action instantiates an NSF with a predefined
profile. An NSF can be any of the FW, LB, IPS, IDS, honeypot, or VPN,
etc.</t>
<t hangText="WAN-Accelerate:">This action optimizes packet delivery
using a set of predefined packet optimization methods.</t>
<t hangText="Load-Balance:">This action load balances connections
based on predefined LB schemes or profiles.</t>
</list></t>
<t>The policy actions should support combination of terminating
actions and non-terminating actions. For example, Syslog and then
Permit; Count and then Redirect.</t>
<t>Policy actions SHALL support any L2, L3, L4-L7 policy actions.</t>
</section>
<section anchor="Models" title="Requirement to express policy in a generic model">
<t>Client-facing interface SHALL provide a generic metadata model that
defines once and then be used by appropriate model elements any times,
regardless of where they are located in the class hierarchy, as
necessary. </t>
<t>Client-facing interface SHALL provide a generic context model that
enables the context of an entity, and its surrounding environment, to
be measured, calculated, and/or inferred.</t>
<t>Client-facing interface SHALL provide a generic policy model that
enables context-aware policy rules to be defined to change the
configuration and monitoring of resources and services as context
changes.</t>
<t>Client-facing interface SHALL provide the ability to apply policy or
multiple sets of policies to any given object. Policy application process
SHALL allow for nesting capabilities of given policies or set of policies.
For example, an object or any given set of objects could have application
team applying certain set of policy rules, while network team would apply
different set of their policy rules. Lastly, security team would have an
ability to apply its set of policy rules, being the last policy to be
evaluated against. </t>
</section>
<section anchor="Conflict"
title="Requirement to detect and correct policy conflicts">
<t>Client-facing interface SHALL be able to detect policy "conflicts",
and SHALL specify methods on how to resolve these "conflicts"</t>
<t>For example: two clients issues conflicting set of security
policies to be applied to the same Policy Endpoint Group.</t>
</section>
<section anchor="Backward"
title="Requirement for backward compatibility">
<t>It MUST be possible to add new capabilities to client-facing
interface in a backward compatible fashion.</t>
</section>
<section anchor="Third-Party"
title="Requirement for Third-Party integration">
<t>The security policies in the security administrator's network may
require the use of specialty devices such as honeypots, behavioral
analytics, or SIEM in the network, and may also involve threat feeds,
virus signatures, and malicious file hashes as part of comprehensive
security policies.</t>
<t>The client-facing interface must allow the security administrator
to configure these threat sources and any other information to provide
integration and fold this into policy management.</t>
</section>
<section anchor="Telemetry" title="Requirement to collect telemetry data">
<t>One of the most important aspect of security is to have visibility
into the networks. As threats become more sophisticated, the security
administrator must be able to gather different types of telemetry data
from various devices in the network. The collected data could simply
be logged or sent to security analysis engines for behavioral
analysis, policy violations, and for threat detection.</t>
<t>The client-facing interface MUST allow the security administrator
to collect various kinds of data from NSFs. The data source could be
syslog, flow records, policy violation records, and other available
data.</t>
<t>Detailed client-facing interface telemetry data should be available
between clients and security controllers. Clients should be able to
subscribe and receive these telemetry data.</t>
<t>client should be able to receive notifications when a policy is
dynamically updated.</t>
</section>
</section>
<section anchor="operational_reqs"
title="Operational Requirements for the Client-Facing Interface">
<section anchor="api_ver" title="API Versioning">
<t>The client-facing interface must support a version number for each
RESTful API. This is very important because the client application and
the controller application may most likely come from different
vendors. Even if the vendor is same, it is hard to imagine that
two different applications would be released in lock step.</t>
<t>Without API versioning, it is hard to debug and figure out issues
if application breaks. Although API versioning does not guarantee that
applications will always work, it helps in debugging if the problem is
caused by an API mismatch.</t>
</section>
<section anchor="api_ext" title="API Extensiblity">
<t>Abstraction and standardization of the client-facing interface is
of tremendous value to security administrators as it gives them the
flexibility of deploying any vendor's NSF without needing to
redefine their policies or change the client interface. However this
might also look like as an obstacle to innovation.</t>
<t>If a vendor comes up with new feature or functionality that
can't be expressed through the currently defined client-facing
interface, there must be a way to extend existing APIs or to create a
new API that is relevant for that NSF vendor only.</t>
</section>
<section anchor="apis_trans" title="APIs and Data Model Transport">
<t>The APIs for client interface must be derived from the YANG based
data model. The YANG data model for client interface must capture all
the requirements as defined in this document to express a security
policy. The interface between a client and controller must be reliable
to ensure robust policy enforcement. One such transport mechanism is
RESTCONF that uses HTTP operations to provide necessary CRUD
operations for YANG data objects, but any other mechanism can be
used.</t>
</section>
<section anchor="notif" title="Notification">
<t>The client-facing interface must allow the security administrator
to collect various alarms and events from the NSF in the network. The
events and alarms may be either related to security policy enforcement
or NSF operation. The events and alarms could also be used as a input
to the security policy for autonomous handling.</t>
</section>
<section anchor="aff" title="Affinity">
<t>The client-facing interface must allow the security administrator
to pass any additional metadata that a user may want to provide for a
security policy e.g. certain security policy needs to be applied only
on linux machine or windows machine or that a security policy must be
applied on the device with Trusted Platform Module chip.</t>
</section>
<section anchor="test" title="Test Interface">
<t>The client-facing interface must allow the security administrator
the ability to test the security policies before the policies are
actually applied e.g. a user may want to verify if a policy creates
potential conflicts with the existing policies or whether a certain
policy can be implemented. The test interface provides such
capabilities without actually applying the policies.</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document requires no IANA actions. RFC Editor: Please remove
this section before publication.</t>
</section>
<section anchor="acks" title="Acknowledgements">
<t>The authors would like to thank Adrian Farrel, Linda Dunbar and Diego R.Lopez
from IETF I2NSF WG for helpful discussions and advice.</t>
<t>The authors would also like to thank Kunal Modasiya, Prakash T. Sehsadri and
Srinivas Nimmagadda from Juniper networks for helpful discussions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.I-D.ietf-i2nsf-problem-and-use-cases"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:06:07 |