One document matched: draft-hares-i2nsf-merged-problem-use-cases-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!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-hares-i2nsf-merged-problem-use-cases-00.txt" ipr="trust200902">
<front>
<title abbrev="I2NSF Existing Work Analysis">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="Antonio Pastor" initials="A" surname="Pastor">
<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> antonio.pastorperales@telefonica.com</email>
</address>
</author>
<author fullname="Diego R. Lopez" initials="D." surname="Lopez">
<organization>Telefonica I+D </organization>
<address>
<postal>
<street>Don Ramon de la Cruz, 82</street>
<city>Madrid</city>
<region></region>
<code>28006</code>
<country>Spain</country>
</postal>
<phone>+34 913 129 041</phone>
<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="Nic Leymann" initials="N." surname="Leymann">
<organization>Deutsche Telekom</organization>
<address>
<email>N.Leymann@telekom.de</email>
</address>
</author>
<author fullname="Michael Georgiades" initials="M." surname="Georgiades">
<organization>Prime Tel</organization>
<address>
<email>michaelq@prime-tel.com</email>
</address>
</author>
<author fullname="Minpeng Qi" initials="M." surname="Qi">
<organization>China Mobile</organization>
<address>
<postal>
<street> 32 Xuanwumenxi Ave,Xicheng District </street>
<city>Beijing</city>
<region></region>
<code>100053</code>
<country>China</country>
</postal>
<email>qiminpeng@chinamobile.com</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street> </street>
<city>Rennes</city>
<region>35000</region>
<code></code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.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>
<author fullname="Shaibal Chakrabarty" initials="S" surname="Chakrabarty">
<organization>US Ignite</organization>
<address>
<postal>
<street>1776 Massachusetts Ave NW, Suite 601</street>
<city>Washington</city>
<region>DC</region>
<code>20036</code>
<country>USA</country>
</postal>
<phone> (214) 708-6163</phone>
<email>shaibalc@us-ignite.org</email>
</address>
</author>
<date year="2015" />
<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)
and summary of the I2NSF use cases.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document describes the problem statement for Interface to Network
Security Functions (I2NSF) and summary of the I2NSF use cases.
A summary of the I2NSF state of the art in the industries and
IETF which is relevant to I2NSF work is contained 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,
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 the result, the Network security functions (NSFs) are provided and consumed in increasingly
diverse 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 make 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="NSF: ">Network security function. An NSF is a function that
that detects unwanted activity and blocks/mitigates the effect of such unwanted
activity in order to support availability of a network. In addition, the NSF
can help in supporting communication stream integrity and confidentiality. </t>
<t hangText="Flow-based NSF: ">A NSF which inspects network flows according to a
policy intended for enforcing security properties. Flow based security also
means that packets are inspected in the order they are received, and without
modification to the packet due to the inspection process (MAC rewrites,
TTL decrement action, or NAT inspection or changes).
</t>
<t hangText="Virtual NSF: "> A NSF which is deployed as a distributed
virtual device. </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 describe the problems and challenges facing customers
and security service providers when some or all of the security functions are
no longer physical hosted by the customer’s administrative domain.
</t>
<t>
Security service providers can be internal to the company or external security
service providers. 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 a global service provider. In 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 procedure,
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="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 at “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 a firewall filters are created or applied.
</t>
<t>
What is needed is having 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 interfaces 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 enable 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 being created, moved, or decommissioned.
</t>
</section>
<section title="More Demand to Control NSFs Dynamically">
<t>
In the advent of SDN (see <xref target="I-D.jeong-i2nsf-sdn-security-services"></xref>), more clients, applications or
application controllers need to dynamically update their communication policies
that are enforced by NSFs. The Security Service Providers have to dynamically update control
requests to NSFs upon receiving the requests from their clients
</t>
</section>
<section title="Demand for multi-tenancy to control and monitor NSFs">
<t>
Service providers may require having 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 access 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 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 network policy. For example, a DDoS alert could
trigger a change to 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 network policy.
By monitoring the network alerts from DDoS, I2NSF can feed a alerts analytics
engine that could recognize attacks and the I2NSF can implement the needed new 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 controller to distribute various keys to distributed NSFs.
To distribute various keys, the keys must be created and managed.
While there is 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 flow. In addition, keys may be used to secure
the protocol and messages in the core routing infrastructure.
</t>
<t>
As of now there is no much focus on an abstraction for keying
information that describes the interface between protocols, operators,
and automated key management.
</t>
<t>
The keys may be used for message authentication and integrity in
order to protect data flow. In addition, keys may be used to
secure the protocol and messages in the core routing infrastructure.
</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 services. Conceptually, there must be an interface defined for
routing/signaling protocols to make requests of 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 needs to have three things:
<list style="numbers">
<t>I2NSF need 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 need 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 title="Background on Core Routing Security">
<t>
A recommendation from a workshop held by the Internet Architecture
Board (IAB) held a workshop on the topic of "Unwanted Internet Traffic"
<xref target="RFC4948"></xref> suggest since a "simple risk analysis"
suggests an “ideal attack target of minimal cost but
maximal disruption is the core routing infrastructure",
it is important to “tightening the security of the core routing infrastructure".
One of the ways to tighten security of the core routing infrastructure is to
tighten the security of protocol packets on the wire is by protecting the messages by use of keys.
</t>
<t>
Conceptually, when routing protocols send or receive messages,
they might need to look up the key to use in this abstract key table.
Conceptually, there must be an interface defined for a protocols to
make requests of automated key management when it is being used;
when keys become available, they might be made available in the key table.
</t>
</section>
</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 are the following:
<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 NSFs on customer networks and NSFs 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 sets for the
set of security functions in their network. Without a standard
technical characterizations or a standard interface, the
service provide faces many challenges.
</t>
<t>Due the lack of standard technical characterizations
and a standard interfaces, the following problems exists:
<list style="hanging">
<t hangText="No standard technical characterization and/or APIs :">
Even 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
the customer’s input to 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
on the use of scripts which generate other scripts which the
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
is enabled in 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>
+------------+
| security |
| MGT system |
+----||------+
|| proprietary
|| or I2NSF standard
Picture: ||
Port 10 +--------+
--------| FW/IPS |-------------
Encrypted +--------+
Video Flow
Figure 2: 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 asks in 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 the 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 ameliorating 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
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 NSFs selected cannot perform the policies
requested by the Security Controller, due to resource constraints. To support
the automatic control in the SDN-era, it is necessary to have a set of messages
for proper negotiation 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="General Use Cases">
<t>
User 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. We will call this network
entity the security controller. The interaction between the entities discussed
above (client, security controller, NSF) is shown in the following diagram:
</t>
<t>
<figure>
<artwork>
+----------+
+-------+ | | +-------+
| | 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 security service, they can request
the information of NSFs 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>
</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 the 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 the
operator infrastructure supporting the access network.
</t>
<t>
These use cases defines the operator interaction with vNSFs
through automated interfaces, typically by B2B communications.
</t>
<t>
<figure>
<artwork>
Customer + Access + PoP/Datacenter
| | +--------+
| ,-----+--. |Network |
| ,' | `-|Operator|
+-------------+ | /+----+ | |Mgmt Sys|
| Residential |-+------/-+vCPE+----+ +--------+
+-------------+ | / +----+ | \ | :
| / | \ | |
+-------+ | ; +----+ | +----+ |
| Cloud |---+---+----+ vPE+--+----+ NSF| |
+-------+ | : +----+ | +----+ |
| : | / |
+--------+ | : +----+ | / ;
| Mobile |-+-----\--+vEPC+----+ /
+--------+ | \ +----+ | ,-'
| `--. | _.-'
| `----+----''
+ +
Figure 3: NSF and actors
</artwork>
</figure>
</t>
<t> The following are actions required for this access use case:
<list style="hanging">
<t hangText="vNSF Deployment: ">
The deployment process consists of 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 of 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 Datacenter Scenario">
<t>In a datacenter, network security mechanisms such as firewalls may need
to be added or removed dynamically 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 deployment essentially requires 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 separate. Another example is that
IPS/IDS services for investment banking and non-banking traffic may be need to
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.
Often it is not technically and/or financially feasible to deploy dedicated physical
firewalls to suit each client's myriad security policy requirements. 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>
---+-----------------------------+-----
| |
+---+ +-+-+
|vFW| |vFW|
+---+ +-+-+
| Client #1 | Client #2
---+-------+--- ---+-------+---
+-+-+ +-+-+ +-+-+ +-+-+
|vM | |vM | |vM | |vM |
+---+ +---+ +---+ +---+
Figure 4: NSF in Data Center
</artwork>
</figure>
</t>
</section>
<section title="Firewall Policy Deployment Automation">
<t>
Firewall rules 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 myriad customers.
</t>
<t>
Firewall rules today are highly tied with ports and addresses of the traffic.
This makes it very difficult for clients of cloud data center 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 key words 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
secure virtual private networks (VPNs) but also virtual security functions
that enforce 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 (much less change) what, where and how security policies are
implemented on their provider-operated clouds. Indeed, no
standards-based framework that allows clients to retrieve/manage
security policies in a consistent manner across different providers exists.
</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 DLP, Data Loss Prevention, or Reputation Protection Services. Depending
on the class of event, alerts may go to internal administrators, or
external services.
</t>
</section>
</section>
</section>
<section title="Management Considerations">
<t>
Management of NSFs usually include configuration of devices,
signaling and policy provisioning. I2NSF will only focus on the
policy provisioning part.
</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 service. The new NSF security controller
introduces a new attack surface. It needs to be resilient to
attack and recovery from attack needs to be quick and trivial
(thus making attacking it 'uninteresting'). Therefore, proper
secure communication channels have to be carefully specified for
carrying the controlling and monitoring information between the NSFs and their
management entity (or entities).
</t>
</section>
<section title="Contributors">
<t>I2NSF is a group effort. The following people contributed actively to the
initial use case text: Diego R. Lopez (Telefonica I+D), Xiaojun Zhuang (China Mobile),
Minpeng Qi (China Mobile), Sumandra Majee (F5), Nic Leymann (Deutsche Telekom),
Ed Lopez (Fortinet), and Robert Moskowitz (Huawei).
</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 initials="E." surname="Messmer"
fullname="E. Messmer">
<organization>Network World</organization>
</author>
<date month="October" day="31" year="2013" />
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 04:11:13 |