One document matched: draft-kumar-i2nsf-controller-northbound-framework-00.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-controller-northbound-framework-00" ipr="trust200902">
<front>
<title abbrev="Northbound Security Interfaces">Northbound Interfaces for Security Policy Controllers : A Framework and Information Model</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="Xiaobo Long" initials="X." surname="Long">
<organization></organization>
<address>
<postal>
<street>4 Cottonwood Lane</street>
<city>Warren</city>
<region>NJ</region>
<country>US</country>
<code>07059</code>
</postal>
<email>long.xiaobo@gmail.com</email>
</address>
</author>
<date year="2016" />
<area>Security</area>
<workgroup>I2NSF Working Group</workgroup>
<keyword>I2NSF</keyword>
<abstract>
<t>This document provides a framework and information model for the definition of northbound
interfaces for a security policy controller. The interfaces are based on user-intent
instead of vendor-specific or device-centric approaches that would require deep knowledge
of vendor products and their security features. The document identifies the common
interfaces needed to enforce the user-intent-based 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 is a fairly complex task and requires very deep
knowledge of the vendors' devices in order to implement a security policy. This has been the
biggest challenge for both Service Providers and Enterprise, henceforth known as end-customers,
to keep up-to-date with the security of their networks and assets. The challenge is amplified
due to virtualization because security appliances come in both physical and virtual forms and
are supplied by a variety of vendors who have their own proprietary interfaces to manage and
implement the security policies on their devices.</t>
<t>Even if an end-customer deploys a single vendor solution across its entire network, it is
difficult to manage security policies due to the complexity of network security features
available in the devices. The end-customer may use a vendor-provided management system that
gives some abstraction in the form of GUI and helps in provisioning and managing security
policies. The single vendor approach is highly restrictive in today's network as explained
below:
<list style="symbols">
<t>The end-customer cannot rely on a single vendor because one vendor may not be able keep
up to date with its security needs.</t>
<t>The large end-customer may have a presence across different sites and regions and that
may mean it is not possible to have a single vendor solution due to technical or
business reasons.</t>
<t>If and when the end-customer migrates from one vendor to another, it is not possible to
migrate security policies from one management system to another without complex manual
work.</t>
<t>Due to virtualization within data centers, end-customers are using physical and virtual
forms of security functions with a wide variety of vendors, including open source, to
control their costs.</t>
<t>The end-customer might choose various devices in the network (such as routers, switches,
firewall devices, and overlay-networks) as enforcement points for security policies for
any reason (such as network design simplicity, cost, most-effective place, scale and
performance).</t>
</list></t>
<t>In order to provide the end-customer with a solution where they can deploy security policies
across different vendors and devices whether physical or virtual, the Interface to Network
Security Functions (I2NSF) working group in the IETF is defining a set of northbound
interfaces.</t>
<t>This document discusses the requirements for these northbound interfaces and describes a
framework and information model so that these interfaces can be easily used by end-customer
security administrators without knowledge of specific security devices or features. We refer
to this as "user-intent-based interfaces".</t>
</section>
<section anchor="conventions" title="Conventions Used in this Document">
<t>
<list style="hanging">
<t hangText="BSS:"> Business Support System.</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="FW:"> Firewall.</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="Security Provisioning Framework">
<t>The IETF I2NSF working group has defined a framework for Interfaces to Network Security Functions
that defines following terminology:
<list style="hanging">
<t hangText="Client:"> A client could be a GUI system used by a security administrator, an
OSS/BSS system used by an end-customer, or a security controller system or application in
the end-customer's management system.</t>
<t hangText="Client-Facing Interface:"> A client-facing interface is an interface used to
configure and manage security a framework across the entire network independent of
device-specific interface so that same interface can be used for any device from any
vendor.</t>
</list></t>
<t>The "Client Facing Interface" ensures that an end-customer can deploy any device from any vendor
and still be able to use same consistent interface. In essence, these interfaces give a framework
to manage end-customer's security policies. Henceforth in this document, we "security policy
management interface" interchangeably when we refer to these northbound interfaces.</t>
<section anchor="models" title="Deployment Models for Implementing Security Policies">
<t>This document describes a framework for security policy management interfaces. This document
does not describe a framework for southbound interface: those may be defined in another draft.</t>
<t>Traditionally, medium and larger end-customers deploy management systems to manage their security
policies. This approach may not be suitable for modern datacenters that are virtualized and manage
their resources using controllers.</t>
<t>There are two different deployment models:
<list style="letters">
<t>Management without an explicit management system for control of devices and NSFs. In this
deployment, the security policy controller acts as a NSF policy management system that takes
information passed over the northbound policy interface and translates into data on the I2NSF
southbound 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>
<![CDATA[
RESTful API
SUPA or I2NSF Policy Management
^
Northbound |
Security Policy Interface |
(Independent of individual |
NSFs, devices, and vendors) |
|
------------------------------
| |
| Security Policy Controller |
| |
------------------------------
| ^
Southbound Security | I2NSF |
Capability 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 policy controller interacts
with a dedicated management system which could either proxy I2NSF southbound interfaces
or could provide a layer where security devices or NSFs do not support an I2NSF agent
to process I2NSF southbound interfaces. This deployment model is shown in
<xref target="with" />.
<figure anchor="with" title="Deployment with Management System or I2NSF Proxy Agent">
<artwork>
<![CDATA[
RESTful API
SUPA or I2NSF Policy Management
^
Northbound |
Security Policy Interface |
(Independent of individual |
NSFs, devices, and vendors) |
|
------------------------------
| |
| Security Policy Controller |
| |
------------------------------
| ^
Southbound Security | I2NSF |
Capability 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
northbound security policy interface, they do give an overall context for defining
a security policy interface based on abstraction.</t>
</section>
<section anchor="client" title="Client Perspective on Security Policy Configuration and Management">
<t>In order to provide I2NSF northbound interface for security policies to client that
are not specific to any vendor, device or feature implementation, it is important
that security policies shall be configured and managed from a client's perspective.
We refer to this as the user-intent based model since it is primarily driven by how
security administrators view security policies from the deployment perspective.</t>
<t>The client perspective ensures that policy management is not only easy to understand
for them (the actual users), but is also independent of vendor, device, and specific
implementation which is the foremost goal for a northbound interface.</t>
</section>
</section>
<section anchor="requirements" title="Functional Requirements for the Northbound Interface">
<t>As mentioned earlier, it is important that the northbound interface be primarily driven by
user-intent which is what a client understands well. In order to define this interface, we
must understand the requirements and framework used by the security administrator.</t>
<t>A security policy that is based on user-intent is completely agnostic of how this policy is
enforced in the end-customer's network. The security controller may choose to implement
such a policy on any device (router, switch, firewall) in a physical or virtual form factor.
The security policy controller's implementation is outside the scope of this document
and the I2NSF working group.</t>
<t>At a high level, the objects that are required in order to express and build the security
policies fall into the following categories:
<list style="symbols">
<t>Multi-tenancy and RBAC for policy management</t>
<t>Policy lifecycle management</t>
<t>Policy endpoint groups</t>
<t>Policy rules</t>
<t>Policy actions</t>
<t>Third party integration</t>
<t>Telemetry data</t>
</list></t>
<t>The above categories are by no means a complete list and may not be sufficient for all
use-cases and all end-customers, but should be a good start for a wide variety of use-cases
in both Service Provider networks and Enterprise networks.</t>
<t>The following sections provide further details on the above mentioned security policies
categories.</t>
<section anchor="tenancy" title="Multi-Tenancy and RBAC for Policy Management">
<t>An end-customer that uses security policies may have internal tenants and would like
to have a framework wherein each tenant manages its own security policies to provide
isolation across different tenants.</t>
<t>An end-customer may be a cloud service provider with multi-tenant deployments where
each tenant is a different organization and must allow complete isolation across
different tenants.</t>
<t>The RBAC objects and method needed to build such a framework is defined below.
<list style="hanging">
<t hangText="Policy-Tenant:"> An entity that owns and manages the security policies.</t>
<t hangText="Policy-User:"> A user within a Policy-Tenant authorized to manage security
policies for that tenant.</t>
<t hangText="Policy-Authorization-Role:"> A role assigned to a Policy-User that determines
whether the user has read-write access, read-only access, or no access for certain
resources.</t>
<t hangText="Authentication and Authorization Scheme:"> There must be a scheme for a
Policy-User to be authenticated and authorized to use the policy controller.</t>
</list></t>
</section>
<section anchor="lifecycle" title="Policy Lifecycle Management">
<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 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/enforced or deactivated based on
dynamic threats faced by the end-customer. 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>The northbound interface should support the following mechanisms 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.</t>
<t hangText="Event-Enforced:"> The policy configuration specifies the event profile that
determines when policy is activated/enforced.</t>
</list></t>
</section>
<section anchor="endpoint" title="Policy Endpoint Groups">
<t>Typically, when the security administrator configures a security policy, the intention is 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 changes). If the policy is created based on static
information such as user names, application, or network subnets, then every time that this
static information changes policies would 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>Changes to policy could be highly taxing to the end-customer for various operational reasons.
The policy management framework must allow "Policy Endpoint Group" to be dynamic in nature so
that changes to the group (HR-users in our example) automatically result in updates to its
content.</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.</t>
<t>The northbound policy interface must support endpoint groups for user-intent based policy
management. The following meta-data driven groups are typically 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 user information is dynamically derived from systems such as
Active Directory or LDAP. For example, an end-customer 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 device information is dynamically derived from systems
such as CMDB. For example, an end-customer 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 application information is dynamically derived
from systems such as CMDB. For example, an end-customer 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.</t>
<t hangText="Location-Group:"> This group identifies a set of locations based on a tag or on
static information. The tag to location information is dynamically derived from systems such
as CMDB. For example, an end-customer may want to classify all sites/locations in a geographic
region as one group.</t>
</list></t>
</section>
<section anchor="policy_rules" title="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
northbound 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 also be a way to express whether a group is a source or a destination so that the
security administrator can apply the rule in only one direction of a communication.</t>
<t>There must also 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.</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="policy_actions" title="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 rule is
matched. Although this may be enough for most of the simple policies, the I2NSF northbound interface
must also provide a more comprehensive set of actions so that the interface can be used effectively
across various security functions.
<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.</t>
<t hangText="Deny:"> This action means stop further rule processing and drop the packet.</t>
<t hangText="Drop connection:"> This action means stop further rule 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 packet
flows.</t>
</list></t>
</section>
<section anchor="third_party" title="Third-Party Integration">
<t>The security policies in the end-customer'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 northbound 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="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 and for threat detection.</t>
<t>The northbound 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>
</section>
</section>
<section anchor="operational_reqs" title="Operational Requirements for the Northbound Interface">
<section anchor="api_ver" title="API Version">
<t>The northbound interface must support a version number for each RESTful API. This is very important
because the client application and the controller application will 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 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 northbound interface is of tremendous value to end-customers
as it gives them the flexibility of deploying any vendors' NSF. However this might also look
like as an obstacle to innovation.</t>
<t>If an NSF vendor comes up with new feature or functionality that can't be expressed through the
currently defined northbound 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>
<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 editors would like to thank Adrian Farrel for helpful discussions and advice.</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:02 |