One document matched: draft-ietf-i2nsf-problem-and-use-cases-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4948 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4948.xml">
<!ENTITY RFC7297 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7277.xml">
<!ENTITY I-D.ietf-netmod-acl-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-netmod-acl-model-06.xml">
<!ENTITY I-D.ietf-opsawg-firewalls SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-opsawg-firewalls-01.xml">
<!ENTITY I-D.hares-i2nsf-gap-analysis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2nsf-gap-analysis.xml">
<!ENTITY I-D.lopez-i2nsf-packet SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.lopez-i2nsf-packet.xml">
<!ENTITY I-D.pastor-i2nsf-merged-use-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.pastor-i2nsf-merged-use-cases.xml">
<!ENTITY I-D.zarny-i2nsf-data-center-use-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zarny-i2nsf-data-center-use-cases.xml">
<!ENTITY I-D.qi-i2nsf-access-network-usecase SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.qi-i2nsf-access-network-usecase.xml">
<!ENTITY I-D.pastor-i2nsf-access-usecases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.pastor-i2nsf-access-usecases.xml">
<!ENTITY I-D.jeong-i2nsf-sdn-security-services SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-jeong-i2nsf-sdn-security-services-01.xml">
<!ENTITY I-D.zhou-i2nsf-capability-interface-monitoring SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zhou-i2nsf-capability-interface-monitoring.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-ietf-i2nsf-problem-and-use-cases-01.txt"
ipr="trust200902">
<front>
<title abbrev="I2NSF Problem/Use Case">I2NSF Problem Statement and
Use cases</title>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Huawei</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<phone>+1-734-604-0332</phone>
<email>shares@ndzh.com</email>
</address>
</author>
<author fullname="Linda Dunbar" initials="L" surname="Dunbar">
<organization>Huawei</organization>
<address>
<postal>
<street>5340 Legacy Drive, Suite 175</street>
<city>Plano</city>
<region>TX</region>
<code>75024</code>
<country>USA</country>
</postal>
<phone>+1-734-604-0332</phone>
<email>ldunbar@huawei.com</email>
</address>
</author>
<author fullname="Diego R. Lopex" initials="D" surname="Lopez">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Don Ramon de la Cruz, 82</street>
<city>Madrid</city>
<code>28006</code>
<country>Spain</country>
</postal>
<email>diego.r.lopez@telefonica.com</email>
</address>
</author>
<author fullname="Myo Zarny" initials="M" surname="Zarny">
<organization>Goldman Sachs</organization>
<address>
<postal>
<street>30 Hudson Street</street>
<city>Jersey City</city>
<region>NJ</region>
<code>07302</code>
<country>USA</country>
</postal>
<email>myo.zarny@gs.com</email>
</address>
</author>
<author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region>35000</region>
<code></code>
<country>France</country>
</postal>
<email>Christian.jacquenet@orange.com</email>
</address>
</author>
<date year="2016" />
<area>Security Area</area>
<workgroup>I2NSF</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>I2NSF</keyword>
<abstract>
<t>This document describes the problem statement for Interface to
Network Security Functions (I2NSF) as well as some companion use
cases.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document describes the problem statement for Interface to
Network Security Functions (I2NSF) as well as some I2NSF use cases. A
summary of the state of the art in the industry and IETF which is
relevant to I2NSF work is documented in <xref
target="I-D.hares-i2nsf-gap-analysis"> </xref>.</t>
<t>The growing challenges and complexity in maintaining a secure
infrastructure, complying with regulatory requirements, and controlling
costs are enticing enterprises into consuming network security functions
hosted by service providers. The hosted security service is especially
attractive to small and medium size enterprises who suffer from a lack
of security experts to continuously monitor networks, acquire new skills
and propose immediate mitigations to ever increasing sets of security
attacks.</t>
<t>According to <xref target="Gartner-2013"> </xref>, the demand for
hosted (or cloud-based) security services is growing. Small and
medium-sized businesses (SMBs) are increasingly adopting cloud-based
security services to replace on-premises security tools, while larger
enterprises are deploying a mix of traditional and cloud-based security
services.</t>
<t>To meet the demand, more and more service providers are providing
hosted security solutions to deliver cost-effective managed security
services to enterprise customers. The hosted security services are
primarily targeted at enterprises (especially small/medium ones), but
could also be provided to any kind of mass-market customer. As a result,
the Network Security Functions (NSFs) are provided and consumed in a
large variety of environments. Users of NSFs may consume network
security services hosted by one or more providers, which may be their
own enterprise, service providers, or a combination of both. This
document also briefly describes the following use cases summarized by
<xref target="I-D.pastor-i2nsf-merged-use-cases"></xref>:</t>
<t><list style="symbols">
<t><xref target="I-D.pastor-i2nsf-access-usecases"></xref>
(I2NSF-Access),</t>
<t><xref
target="I-D.zarny-i2nsf-data-center-use-cases"></xref>(I2NSF-DC),
and</t>
<t><xref target="I-D.qi-i2nsf-access-network-usecase"></xref>
(I2NSF-Mobile).</t>
</list></t>
</section>
<section title="Terminology">
<t><list style="hanging">
<t hangText="ACL: ">Access Control List</t>
<t hangText="B2B: ">Business-to-Business</t>
<t hangText="Bespoke: ">Something made to fit a particular person,
client or company.</t>
<t hangText="Bespoke security management: ">Security management
which is made to fit a particular customer.</t>
<t hangText="DC: ">Data Center</t>
<t hangText="FW: ">Firewall</t>
<t hangText="IDS: ">Intrusion Detection System</t>
<t hangText="IPS: ">Intrusion Protection System</t>
<t hangText="I2NSF: ">interface to Network Security Functions.</t>
<t hangText="NSF: ">Network Security Function. An NSF is a function
that detects abnormal activity and blocks/mitigates the effect of
such abnormal activity in order to preserve the availability of a
network or a service. In addition, the NSF can help in supporting
communication stream integrity and confidentiality.</t>
<t hangText="Flow-based NSF: ">An NSF which inspects network flows
according to a security policy. Flow-based security also means that
packets are inspected in the order they are received, and without
altering packets due to the inspection process (e.g., MAC rewrites,
TTL decrement action, or NAT inspection or changes).</t>
<t hangText="Virtual NSF: ">An NSF which is deployed as a
distributed virtual resource.</t>
<t hangText="VNFPool: ">Pool of Virtual Network Functions.</t>
</list></t>
</section>
<section anchor="prob-space" title="Problem Space">
<t>The following sub-section describes the problems and challenges
facing customers and security service providers when some or all of the
security functions are no longer physically hosted by the customer's
adminstrative domain.</t>
<t>Security service providers can be internal or external to the
company. For example, an internal IT Security group within a large
enterprise could act as a security service provider for the enterprise.
In contrast, an enterprise could outsource all security services to an
external security service provider. In this document, the security
service provider function whether it is internal or external, will be
denoted as "service provider".</t>
<t>The "Customer-Provider" relationship may be between any two parties.
The parties can be in different firms or different domains of the same
firm. Contractual agreements may be required in such contexts to
formally document the customer's security requirements and the
provider's guarantees to fulfill those requirements. Such agreements may
detail protection levels, escalation procedures, alarms reporting, etc.
There is currently no standard mechanism to capture those
requirements.</t>
<t>A service provider may be a customer of another service provider.</t>
<section title="Challenges Facing Security Service Providers">
<section title="Diverse Types of Security Functions">
<t>There are many types of NSFs. NSFs by different vendors can have
different features and have different interfaces. NSFs can be
deployed in multiple locations in a given network, and perhaps have
different roles.</t>
<t>Below are a few examples of security functions and locations or
contexts in which they are often deployed: <list style="hanging">
<t
hangText="External Intrusion and Attack Protection: ">Examples
of this function are firewall/ACL authentication, IPS, IDS, and
endpoint protection.</t>
<t hangText="Security Functions in a DMZ: ">Examples of this
function are firewall/ACLs, IDS/IPS, authentication and
authorization services, NAT, forwarding proxies, application,
and AAA services. These functions may be physically on-premise
in a server provider's network at the DMZ spots or located in a
"virtual" DMZ.</t>
<t
hangText="Internal Security Analysis and Reporting: ">Examples
of this function are security logs, event correlation, and
forensic analysis.</t>
<t hangText="Internal Data and Content Protection: ">Examples of
this function are encryption, authorization, and public/private
key management for internal database.</t>
</list></t>
<t>Given the diversity of security functions, the contexts in which
these functions can be deployed, and the constant evolution of these
functions, standardizing all aspects of security functions is
challenging, and most probably not feasible. Fortunately, it is not
necessary to standardize all aspects. For example, from an I2NSF
perspective, there is no need to standardize on how firewall filters
are created or applied.</t>
<t>What is needed is a standardized interface to control and monitor
the rule sets that NSFs use to treat packets traversing through. And
standardizing interfaces will provide an impetuous for standardizing
established security functions.</t>
</section>
<section title="Diverse Interfaces to Control NSFs">
<t>To provide effective and competitive solutions and services,
Security Service Providers may need to utilize multiple security
functions from various vendors to enforce the security policies
desired by their customers.</t>
<t>Since no widely accepted industry standard security interface
exists today, management of NSFs (device and policy provisioning,
monitoring, etc.) tends to be bespoke security management offered by
product vendors. As a result, automation of such services, if it
exists at all, is also bespoke. Thus, even in the traditional way of
deploying security features, there is a gap to coordinate among
implementations from distinct vendors. This is the main reason why
mono-vendor security functions are often deployed and enabled in a
particular network segment.</t>
<t>A challenge for monitoring is that an NSF cannot monitor what it
cannot view. Therefore, enabling a security function (e.g., firewall
<xref target="I-D.ietf-opsawg-firewalls"></xref>) does not mean that
a network is protected. As such, it is necessary to have a mechanism
to monitor and provide execution status of NSFs to security and
compliance management tools. There exist various network security
monitoring vendor-specific interfaces for forensics and
troubleshooting.</t>
</section>
<section title="Diverse Interface to Monitor the Behavior of NSFs">
<t>Obviously, enabling a security function (e.g., firewall <xref
target="I-D.ietf-opsawg-firewalls"></xref> does not mean that a
network is protected. Therefore, it is necessary to have a mechanism
to monitor the execution status of NSFs.</t>
</section>
<section title="More Distributed NSFs and vNSFs">
<t>The security functions which are invoked to enforce a security
policy can be located in different equipment and network
locations.</t>
<t>The European Telecommunications Standards Institute (ETSI)
Network Function Virtualization (NFV) initiative creates new
management challenges for security policies to be enforced by
distributed, virtual, and network security functions (vNSF).</t>
<t>A vNSF has higher risk of failure, migrating, and state changes
as their hosting VMs are being created, moved, or
decommissioned.</t>
</section>
<section title="More Demand to Control NSFs Dynamically">
<t>In the advent of Software-Defined Networking (see <xref
target="I-D.jeong-i2nsf-sdn-security-services"></xref>), more
clients, applications or application controllers need to dynamically
update their security policies that are enforced by NSFs. The
Security Service Providers have to dynamically update their
decision-making process (e.g., in terms of NSF resource allocation
and invocation) upon receiving requests from their clients.</t>
</section>
<section title="Demand for Multi-Tenancy to Control and Monitor NSFs">
<t>Service providers may need several operational units to control
and monitor the NSFs, especially when NSFs become distributed and
virtualized.</t>
</section>
<section title="Lack of Characterization of NSFs and Capability Exchange">
<t>To offer effective security services, service providers need to
activate various security functions in NSFs or vNSFs manufactured by
multiple vendors. Even within one product category (e.g., firewall),
security functions provided by different vendors can have different
features and capabilities. For example, filters that can be designed
and activated by a firewall may or may not support IPv6 depending on
the firewall technology.</t>
<t>The service provider's management system (or controller) needs a
way to retrieve the capabilities of service functions by different
vendors so that it could build an effective security solution. These
service function capabilities can be documented in a static manner
(e.g., a file) or via an interface which accesses a repository of
security function capabilities which the NSF vendors dynamically
update.</t>
<t>A dynamic capability registration is useful for automation
because security functions may be subject to software and hardware
updates. These updates may have implications on the policies
enforced by the NSFs.</t>
<t>Today, there is no standard method for vendors to describe the
capabilities of their security functions. Without a common technical
framework to describe the capabilities of security functions,
service providers cannot automate the process of selecting NSFs by
different vendors to accommodate customer's requirements.</t>
</section>
<section title="Lack of Mechanism for NSFs to Utilize External Profiles">
<t>Many security functions depend on signature files or profiles to
perform (e.g., IPS/IDS signatures, DOTS filters). Different policies
might need different signatures or profiles. Today, the construction
and use of black databases can be a win-win strategy for all parties
involved. There might be Open Source-provided signature/profiles
(e.g., by Snort or others) in the future.</t>
<t>There is a need to have a standard envelop (i.e., the format) to
allow NSFs to use external profiles.</t>
</section>
<section title="Lack of Mechanisms to Accept External Alerts to Trigger Automatic Configuration Changes">
<t>NSF can ask the I2NSF security controller to alter a specific
policy. For example, a DDoS alert could trigger a change to the
routing system to send traffic to a traffic scrubbing service to
mitigate the DDoS.</t>
<t>The DDoS protection has the following two parts: a) the
configuration of signaling of open threats and b) DDoS mitigation.
DOTS controller manages the signaling part of DDoS. I2NSF
controller(s) would manage the changing to the affected policies
(e.g., forwarding and routing, filtering, etc.). By monitoring the
network alerts from DDoS, I2NSF can feed an alerts analytics engine
that could recognize attacks and the I2NSF can thus enforce the
appropriate policies.</t>
<t>DDoS mitigation is enhanced if the provider's network security
controller can monitor, analyze, and investigate the abnormal events
and provide information to the client or change the network
configuration (see section x) for details on the interfaces.</t>
<t><xref
target="I-D.zhou-i2nsf-capability-interface-monitoring"></xref>
provides details on how monitoring aspects of the flow-based Network
Security Functions (NSFs) can use the I2NSF interfaces to receive
traffic reports and enforce policy.</t>
</section>
<section title="Lack of Mechanism for Dynamic Key Distribution to NSFs">
<t>There is a need for a controller to distribute various keys to
distributed NSFs. To distribute various keys, the keys must be
created and managed. While there are many key management methods and
key derivation functions (KDF), there is a lack of standard
interface to provision and manage keys.</t>
<t>The keys may be used for message authentication and integrity in
order to protect data flows. In addition, keys may be used to secure
the protocol and messages in the core routing infrastructure
(<xref target="RFC4948"></xref>)</t>
<t>As of now there is not much focus on an abstraction for keying
information that describes the interface between protocols,
operators, and automated key management.</t>
<t>The ability to utilize keys when routing protocols send or
receive messages will be enhanced by having an abstract key table
maintained by a security service. Conceptually, there must be an
interface defined for routing/signaling protocols to make requests
for automated key management when it is being used, to notify the
protocols when keys become available in the key table.</t>
<t>An abstract key service will work under the following conditions:
<list style="numbers">
<t>I2NSF needs to design the key table abstraction, the
interface between key management protocols and routing/other
protocols, and possibly security protocols at other layers.</t>
<t>For each routing/other protocol, I2NSF needs to define the
mapping between how the protocol represents key material and the
protocol-independent key table abstraction. (If protocols share
common mechanisms for authentication (e.g., TCP Authentication
Option), then the same mapping may be reused.)</t>
<t>Automated Key management must support both symmetric keys and
group keys via the service provided by items 1 and 2.</t>
</list></t>
</section>
</section>
<section title="Challenges Facing Customers">
<t>When customers invoke hosted security services, their security
policies may be enforced by a collection of security functions hosted
in different domains. Customers may not have the security skills to
express sufficiently precise requirements or security policies.
Usually, these customers express the expectations of their security
requirements or the intent of their security policies. These
expectations can be considered customer level security expectations.
Customers may also desire to express guidelines for security
management. Examples of such guidelines include: <list style="symbols">
<t>Which critical communications are to be preserved during
critical events (DOTS),</t>
<t>Which hosts are to continue service even during severe security
attacks (DOTS),</t>
<t>Reporting of attacks to CERT (MILE),</t>
<t>Managing network connectivity of systems out of compliance
(SACM),</t>
</list></t>
<section title="NSFs from Heterogeneous Administrative Domains">
<t>Many medium and large enterprises have deployed various
on-premises security functions which they want to continue to
deploy. These enterprises want to combine local security functions
with remote hosted security functions to achieve more efficient and
immediate counter-measures to both Internet-originated attacks and
enterprise network-originated attacks.</t>
<t>Some enterprises may only need the hosted security services for
their remote branch offices where minimal security
infrastructures/capabilities exist. The security solution will
consist of deploying NSFs on customer networks and on service
provider networks.</t>
</section>
<section title="Today's Control Requests are Vendor Specific">
<t>Customers may consume NSFs by multiple service providers.
Customers need to express their security requirements, guidelines,
and expectations to the service providers. In turn, the service
providers must translate this customer information into customer
security policies and associated configuration tasks for the set of
security functions in their network. Without a standard technical
characterization or a standard interface, the service provider faces
many challenges:<list style="hanging">
<t
hangText="No standard technical characterization and/or APIs :">Even
for the most common security services there is no standard
technical characterization or APIs. Most security services are
accessible only through disparate, proprietary interfaces (e.g.,
portals or APIs) in whatever format vendors choose to offer. The
service provider must have the customer's input to manage these
widely varying interfaces.</t>
<t hangText="No standard interface: ">Without standard
interfaces it is complex for customers to update security
policies or integrate the security functions in their enterprise
with the security services provided by the security service
providers. This complexity is induced by the diversity of the
configuration models, policy models, and supported management
interfaces. Without a standard interface, new innovative
security products find a large barrier to entry into the
market.</t>
<t hangText="Managing by scripts de-jour: ">The current
practices rely upon the use of scripts that generate other
scripts which automatically run to upload or download
configuration changes, log information and other things. These
scripts have to be adjusted each time an implementation from a
different vendor technology is enabled on a provider side.</t>
<t hangText="Lack of immediate feedback: ">Customers may also
require a mechanism to easily update/modify their security
requirements with immediate effect in the underlying involved
NSFs.</t>
<t hangText="Lack of explicit invocation request: ">While
security agreements are in place, security functions may be
solicited without requiring an explicit invocation means.
Nevertheless, some explicit invocation means may be required to
interact with a service function.</t>
</list></t>
<t>To see how standard interfaces could help achieve faster
implementation time cycles, let us consider a customer who would
like to dynamically allow an encrypted flow with specific port,
src/dst addresses or protocol type through the firewall/IPS to
enable an encrypted video conferencing call only during the time of
the call. With no commonly accepted interface in place, the customer
would have to learn about the particular provider's firewall/IPS
interface and send the request in the provider's required
format.</t>
<t><figure>
<artwork><![CDATA[
+------------+
| security |
| MGT system |
+----||------+
|| proprietary
|| or I2NSF standard
Picture: ||
Port 10 +--------+
--------| FW/IPS |-------------
Encrypted +--------+
Video Flow
Figure 1: Example of non-standard vs. standard interface
]]></artwork>
</figure></t>
<t>In contrast, if a firewall/IPS interface standard exists, the
customer would be able to send the request, without having to do the
extensive preliminary legwork. A standard interface also helps
service providers since they could now offer the same firewall/IPS
interface to represent firewall/IPS services for utilizing products
from many vendors. The result is that the service provider has now
abstracted the firewall/IPS services. The standard interface also
helps the firewall/IPS vendors to focus on their core security
functions or extended features rather than the standard building
blocks of a management interface.</t>
</section>
<section title="Difficulty to Monitor the Execution of Desired Policies">
<t>How a policy is translated into technology-specific actions is
hidden from the customers. However, customers still need ways to
monitor the delivered security service that results from the
execution of their desired security requirements, guidelines and
expectations.</t>
<t>Today, there is no standard way for customers to get security
service assurance of their specified security policies properly
enforced by the security functions in the provider domain. The
customer also lacks the ability to perform "what-if" scenarios to
assess the efficiency of the delivered security service.</t>
</section>
</section>
<section title="Difficulty to Validate Policies across Multiple Domains">
<t>One key aspect of a hosted security service with security functions
located at different premises is the ability to express, monitor and
verify security policies that combine several distributed security
functions. It is crucial to an effective service to be able to take
these actions via a standard interface. This standard interface
becomes more crucial to the hosted security service when NSFs are
instantiated in Virtual Machines which are sometimes widely
distributed in the network and sometimes are combined together in one
device to perform a set of tasks for delivering a service.</t>
<t>Without standard interfaces and security policy data models, the
enforcement of a customer-driven security policy remains challenging
because of the inherent complexity created by combining the invocation
of several vendor-specific security functions into a multi-vendor,
heterogeneous environment. Each vendor-specific function may require
specific configuration procedures and operational tasks.</t>
<t>Ensuring the consistent enforcement of the policies at various
domains is also challenging. Standard data models are likely to
contribute to addressing that issue.</t>
</section>
<section title="Lack of Standard Interface to Inject Feedback to NSF">
<t>Today, many security functions, such as IPS, IDS, DDoS and
Antivirus, depend heavily on the associated profiles. They can perform
more effective protection if they have the up-to-date profiles. As
more sophisticated threats arise, enterprises, vendors, and service
providers have to rely on each other to achieve optimal protection.
Cyper Threat Alliance (CA, http://cyberthreatalliance.org/) is one of
those initiatives that aim at combining efforts conducted by multiple
organizations.</t>
<t>Today there is no standard interface to exchange security profiles
between organizations.</t>
</section>
<section title="Lack of Standard Interface for Capability Negotiation">
<t>There could be situations when the selected NSFs cannot perform the
policies requested by the Security Controller, due to resource
constraints. The customer and security service provider should
negotiate the appropriate resource constraints before the security
service begins. However, unexpected events somethings happen
and the NSF may exhaust those negotiated resources. At this point,
the NSF should inform the security controller that the alloted
resources have been exhausted. To support the automatic control
in the SDN-era, it is necessary to have a set of messages for proper
notification (and a response to that notification) between the
Security Controller and the NSFs.</t>
</section>
</section>
<section title="Use Cases">
<t>Standard interfaces for monitoring and controlling the behavior of
NSFs are essential building blocks for Security Service Providers and
enterprises to automate the use of different NSFs from multiple vendors
by their security management entities. I2NSF may be invoked by any
(authorized) client. Examples of authorized clients are upstream
applications (controllers), orchestration systems, and security
portals.</t>
<section title="Basic Framework">
<t>Users request security services through specific clients (e.g., a
customer application, the NSP BSS/OSS or management platform) and the
appropriate NSP network entity will invoke the (v)NSFs according to
the user service request. This network entity is denoted as the
security controller in this document. The interaction between the
entities discussed above (client, security controller, NSF) is shown
in Figure 2:</t>
<t><figure>
<artwork><![CDATA[
+----------+
+-------+ | | +-------+
| | Interface 1 |Security | Interface 2 | NSF(s)|
|Client <-------------> <------------------> |
| | |Controller| | |
+-------+ | | +-------+
+----------+
Figure 2: Interaction between Entities
]]></artwork>
</figure></t>
<t>Interface 1 is used for receiving security requirements from client
and translating them into commands that NSFs can understand and
execute. The security controller also passes back NSF security reports
(e.g., statistics) to the client which the control has gathered from
NSFs. Interface 2 is used for interacting with NSFs according to
commands, and collect status information about NSFs.</t>
<t>Client devices or applications can require the security controller
to add, delete or update rules in the security service function for
their specific traffic.</t>
<t>When users want to get the executing status of a security service,
they can request NSF status from the client. The security controller
will collect NSF information through Interface 2, consolidate them,
and give feedback to client through Interface 1. This interface can be
used to collect not only individual service information, but also
aggregated data suitable for tasks like infrastructure security
assessment.</t>
<t>Customers may require validating NSF availability, provenance,
and correct execution. This validation process, especially relevant
for vNSFs, includes at least:
<list style="hanging">
<t hangText="Integrity of the NSF: ">by ensuring that the NSF is
not compromised;</t>
<t hangText="Isolation: ">by ensuring the execution of the NSF is
self-contained for privacy requirements in multi-tenancy
scenarios.</t>
<t hangText="Provenance of NSF: ">Customers may need to be
provided with strict guarantees about the origin of the NSF, its
status (e.g. available, idle, down, and others), and
feedback mechanisms so that a customer may be able to
check that a given NSF or set of NSFs properly conform to the
the customer's requirements and subsequent configuration tasks.
</t>
</list></t>
<t>In order to achieve this, the security controller may collect
security measurements and share them with an independent and trusted
third party (via interface 1) in order to allow for attestation of NSF
functions using the third party added information.</t>
</section>
<section title="Access Networks">
<t>This scenario describes use cases for users (e.g. enterprise user,
network administrator, and residential user) that request and manage
security services hosted in the network service provider (NSP)
infrastructure. Given that NSP customers are essentially users of
their access networks, the scenario is essentially associated with
their characteristics, as well as with the use of vNSFs.</t>
<t>The Virtual CPE described in [NFVUC] use cases #5 and #7 requires a
model of access virtualization that includes mobile and residential
access where the operator may offload security services from the
customer local environment (e.g., device or terminal) to its own
infrastructure.</t>
<t>These use cases define the interaction between the operator and the
vNSFs through automated interfaces, typically by means of B2B
communications.</t>
<t><figure>
<artwork><![CDATA[
Customer + Access + PoP/Datacenter
| | +--------+
| ,-----+--. |Network |
| ,' | `-|Operator|
+-------------+ | /+----+ | |Mgmt Sys|
| Residential |-+------/-+vCPE+----+ +--------+
+-------------+ | / +----+ | \ | :
| / | \ | |
+----------+ | ; +----+ | +----+ |
|Enterprise|---+---+----+ vPE+--+----+ NSF| |
+----------+ | : +----+ | +----+ |
| : | / |
+--------+ | : +----+ | / ;
| Mobile |-+-----\--+vEPC+----+ /
+--------+ | \ +----+ | ,-'
| `--. | _.-'
| `----+----''
+ +
Figure 3: NSF and actors
]]></artwork>
</figure></t>
<t>Different access clients may have different service requests: <list
style="hanging">
<t hangText="Residential: ">Interface for parental control;
Interface for threat management.</t>
<t hangText="Enterprise: ">Flow Security Policies; Managed
security services (Threat management).</t>
<t hangText="Mobile: ">User experience; content and access
management; Threat management for infrastructure, such as Botnet,
DDoS, Malware etc.</t>
</list></t>
<t>Some access customers may not care about which NSFs are utilized to
achieve the services they requested. In this case, provider network
orchestration systems can internally select the NSFs (or vNSFs) to
enforce the policies requested by the clients. Other access customers,
especially some enterprise customers, may want to get their dedicated
NSFs (most likely vNSFs) for direct control purposes. In this case,
here are the steps to associate vNSFs to specific customers:</t>
<t><list style="hanging">
<t hangText="vNSF Deployment: ">The deployment process consists in
instantiating a NSF on a Virtualization Infrastructure (NFVI),
within the NSP administrative domain(s) or with other external
domain(s). This is a required step before a customer can subscribe
to a security service supported in the vNSF.</t>
<t hangText="vNSF Customer Provisioning: ">Once a vNSF is
deployed, any customer can subscribe to it. The provisioning
lifecycle includes the following: <list style="symbols">
<t>Customer enrollment and cancellation of the subscription to
a vNSF;</t>
<t>Configuration of the vNSF, based on specific
configurations, or derived from common security policies
defined by the NSP.</t>
<t>Retrieve and list the vNSF functionalities, extracted from
a manifest or a descriptor. The NSP management systems can
demand this information to offer detailed information through
the commercial channels to the customer.</t>
</list></t>
</list></t>
</section>
<section title="Cloud Data Center Scenario">
<t>In a data center, network security mechanisms such as firewalls may
need to be dynamically added or removed for a number of reasons. These
changes may be explicitly requested by the user, or triggered by a
pre-agreed upon Service Level Agreement (SLA) between the user and the
provider of the service. For example, the service provider may be
required to add more firewall capacity within a set timeframe whenever
the bandwidth utilization hits a certain threshold for a specified
period. This capacity expansion could result in adding new instances
of firewalls on existing machines or provisioning a completely new
firewall instance in a different machine.</t>
<t>The on-demand, dynamic nature of security service delivery
essentially encourages that the network security "devices" be in
software or virtual form factors, rather than in a physical appliance
form. This requirement is a provider-side concern. Users of the
firewall service are agnostic (as they should) as to whether or not
the firewall service is run on a VM or any other form factor. Indeed,
they may not even be aware that their traffic traverses firewalls.</t>
<t>Furthermore, new firewall instances need to be placed in the "right
zone" (domain). The issue applies not only to multi-tenant
environments where getting the tenant in the right domain is of
paramount importance, but also in environments owned and operated by a
single organization with its own service segregation policies. For
example, an enterprise may mandate that firewalls serving Internet
traffic and Business-to-Business (B2B) traffic be separated. Another
example is that IPS/IDS services for investment banking and
non-banking traffic may be separated for regulatory reasons.</t>
<section title="On-Demand Virtual Firewall Deployment">
<t>A service provider-operated cloud data center could serve tens of
thousands of clients. Clients' compute servers are typically hosted
on virtual machines (VMs), which could be deployed across different
server racks located in different parts of the data center. It is
often not technically and/or financially feasible to deploy
dedicated physical firewalls to suit each client's security policy
requirements, which can be numerous. What is needed is the ability
to dynamically deploy virtual firewalls for each client's set of
servers based on established security policies and underlying
network topologies.</t>
<t><figure>
<artwork><![CDATA[
---+-----------------------------+-----
| |
+---+ +-+-+
|vFW| |vFW|
+---+ +-+-+
| Client #1 | Client #2
---+-------+--- ---+-------+---
+-+-+ +-+-+ +-+-+ +-+-+
|vM | |vM | |vM | |vM |
+---+ +---+ +---+ +---+
Figure 4: NSF in Data Centers
]]></artwork>
</figure></t>
</section>
<section title="Firewall Policy Deployment Automation">
<t>Firewall rule setting is often a time consuming, complex and
error-prone process even within a single organization/enterprise
framework. It becomes far more complex in provider-owned cloud
networks that serve myriads of customers.</t>
<t>Firewall rules today are highly tied with ports and addresses
that identify traffic. This makes it very difficult for clients of
cloud data centers to construct rules for their own traffic as the
clients only see the virtual networks and the virtual addresses. The
customer-visible virtual networks and addresses may be different
from the actual packets traversing the FWs.</t>
<t>Even though most vendors support similar firewall features, the
actual rule configuration keywords are different from vendors to
vendors, making it difficult for automation. Automation works best
when it can leverage a common set of standards that will work across
NSFs by multiple vendors. Without automation, it is virtually
impossible for clients to dynamically specify their desired rules
for their traffic.</t>
</section>
<section title="Client-Specific Security Policy in Cloud VPNs">
<t>Clients of service provider-operated cloud data centers need not
only to secure Virtual Private Networks (VPNs) but also virtual
security functions that apply the clients' security policies. The
security policies may govern communication within the clients' own
virtual networks as well as communication with external networks.
For example, VPN service providers may need to provide firewall and
other security services to their VPN clients. Today, it is generally
not possible for clients to dynamically view (let alone change)
what, where and how security policies are implemented on their
provider-operated clouds. Indeed, no standards-based framework
exists to allow clients to retrieve/manage security policies in a
consistent manner across different providers.</t>
</section>
<section title="Internal Network Monitoring">
<t>There are many types of internal traffic monitors that may be
managed by a security controller. This includes a new class of
services referred to as Data Loss Prevention (DLP), or Reputation
Protection Services (RPS). Depending on the class of event, alerts
may go to internal administrators, or external services.</t>
</section>
</section>
<section title="I2NSF Preventing Distributed DoS in Overlay Networks">
<t>In the internet where everything is connected, preventing unwanted
traffic that may cause Denial of Service (DoS) attack or distributed
DoS (DDoS) has become a challenge. One place where DDoS can be
challenging to prevent or mitigate is in overlay networks. Many
networks such as Internet of Things (IoT) networks,
Information-Centric Networks (ICN), Content Delivery Networks (CDN),
and cloud networks use overlay networks within their paths (or links).
The underlay networks that support overlay networks can be attacked by
DDoS, thereby saturating access links or links within the network. DoS
or DDoS attacks on the access links may also cause the overlay nodes'
CPUs or links to be saturated by DoS or DDoS traffic which will
prevent these links from being used by legitimate overlay traffic.
Overlay security solutions do not address underlay security threats so
there is a need for a distributed solution to prevent DDoS attacks
from spreading throughout overlay and underlay networks.
Such solution may for example rely upon the dynamic, highly-reactive,
enforcement of security filtering policies network-wise.
</t>
<t>Similar to traditional networks placing a firewall or Intrusion
Prevention System (IPS) on the wire to enforce traffic rules, the
interface to network security functions (I2NSF) can be used by overlay
networks to request underlay networks enforce certain flow-based
security rules. Using this mechanism, the overlay network can
coordinate with the underlay network to remove unwanted traffic
including DoS and DDoS in the underlay network.</t>
<t><figure>
<artwork><![CDATA[
+-------------------------------------------+
| Application controlloer |
| (e.g video conference service controller |
| from centralized control or orchestration |
+---+----------------------------+----------+
| consumer facing |
| interface (A) |
+----+----------------+ +---------------------+
| network operator | | network operator |
| security controller +--| | security controller +--|
| (underlay network) | | | overlay network | |
+----+----------------+ | +------+--------------+ |
| vendor facing | | vendor facing |
| interface (C) | | interface (C) |
| +----+---+ | +-------+-+
| | vendor | | | vendor |
| | system | | | system |
| +--------+ | +---------+
| |
| NSF facing inteface | NSF Facing interface
| (capabilty)(B) | (capability) (B)
---+-------------+----- ---+------------+---------
| | | |
+--+---+ +-+---+ +---+--+ +--+----+
| NSF |-------| NSF | | NSF |------| NSF |
+------+ +-----+ +------+ +-------+
vendor a vendor b vendor B Vendor C
Figure 5: I2NSF Preventing DDoS Attacks in Overlay Networks.
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Management Considerations">
<t>Management of NSFs usually include the following: <list
style="symbols">
<t>Lifecycle managment and resource management of NSFs,</t>
<t>Device configuration, such as address configuration, device
internal attributes configuration, etc.;</t>
<t>Signaling, and</t>
<t>Policy rule provisioning.</t>
</list> I2NSF will only focus on the policy provisioning part of NSF
management.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>No IANA considerations exist for this document.</t>
</section>
<section title="Security Considerations">
<t>Having a secure access to control and monitor NSFs is crucial for
hosted security services. An I2NSF security controller raises new
security threats. It needs to be resilient to attacks and quickly recover from
attacks. Therefore, proper secure communication channels have to be
carefully specified for carrying controlling and monitoring traffic
between the NSFs and their management entity (or entities).
</t>
<t>
In addition, the Flow security policies specified by customers
can conflict with providers' internal security policies which
may allow unauthorized traffic or unauthorized changes to flow polices
(e.g. customers changing flow policies that do not belong to them).
Therefore, it is crucial to have proper AAA to authorize access to the
network and access to the I2NSF management stream.
</t>
</section>
<section title="Contributors">
<t>I2NSF is a group effort. The following people actively contributed to
the initial use case text: Xiaojun Zhuang (China Mobile), Sumandra Majee
(F5), Ed Lopez (Fortinet), and Robert Moskowitz (Huawei).</t>
</section>
<section title="Contributing Authors">
<t>I2NSF has had a number of contributing authors. The following are
contributing authors: <list style="symbols">
<t>Antonio Pastur (Telefonica I+D),</t>
<t>Mohamed Boucadair (France Telecom),</t>
<t>Michael Georgiades (Prime Tel),</t>
<t>Minpeng Qi (China Mobile),</t>
<t>Shaibal Chakrabarty (US Ignite), and</t>
<t>Nic Leymann (Deutsche Telekom).</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&RFC4948;
&RFC7297;
&I-D.ietf-netmod-acl-model;
&I-D.ietf-opsawg-firewalls;
&I-D.jeong-i2nsf-sdn-security-services;
&I-D.hares-i2nsf-gap-analysis;
&I-D.lopez-i2nsf-packet;
&I-D.pastor-i2nsf-access-usecases;
&I-D.pastor-i2nsf-merged-use-cases;
&I-D.qi-i2nsf-access-network-usecase;
&I-D.zarny-i2nsf-data-center-use-cases;
&I-D.zhou-i2nsf-capability-interface-monitoring;
<reference anchor="Gartner-2013">
<front>
<title>Gartner: Cloud-based security as a service set to take
off</title>
<author fullname="E. Messmer" initials="E." surname="Messmer">
<organization>Network World</organization>
</author>
<date day="31" month="October" year="2013" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:07:53 |