I2NSF Problem Statement and Use cases
draft-ietf-i2nsf-problem-and-use-cases-04
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (i2nsf WG) | |
|---|---|---|---|
| Authors | Susan Hares , Diego Lopez , Myo Zarny , Christian Jacquenet , Rakesh Kumar , Jaehoon Paul Jeong | ||
| Last updated | 2016-11-13 | ||
| Replaces | draft-hares-i2nsf-merged-problem-use-cases | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text xml pdf htmlized pdfized bibtex | ||
| Reviews |
GENART Telechat review
(of
-15)
Ready with Nits
GENART Telechat review
(of
-12)
Ready with Nits
SECDIR Last Call review
(of
-12)
Has Nits
GENART Last Call review
(of
-11)
Ready with Nits
|
||
| Stream | WG state | WG Document | |
| Document shepherd | Adrian Farrel | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | "Adrian Farrel" <adrian@olddog.co.uk> |
draft-ietf-i2nsf-problem-and-use-cases-04
I2NSF S. Hares
Internet-Draft Huawei
Intended status: Standards Track D. Lopez
Expires: May 17, 2017 Telefonica I+D
M. Zarny
Goldman Sachs
C. Jacquenet
France Telecom
R. Kumar
Juniper Networks
J. Jeong
Sungkyunkwan University
November 13, 2016
I2NSF Problem Statement and Use cases
draft-ietf-i2nsf-problem-and-use-cases-04
Abstract
This document describes the problem statement for Interface to
Network Security Functions (I2NSF) as well as some companion use
cases.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 17, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Hares, et al. Expires May 17, 2017 [Page 1]
Internet-Draft I2NSF Problem/Use Case November 2016
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Challenges Facing Security Service Providers . . . . . . 5
3.1.1. Diverse Types of Security Functions . . . . . . . . . 5
3.1.2. Diverse Interfaces to Control and Monitor NSFs . . . 6
3.1.3. More Distributed NSFs and vNSFs . . . . . . . . . . . 7
3.1.4. More Demand to Control NSFs Dynamically . . . . . . . 7
3.1.5. Demand for Multi-Tenancy to Control and Monitor NSFs 7
3.1.6. Lack of Characterization of NSFs and Capability
Exchange . . . . . . . . . . . . . . . . . . . . . . 7
3.1.7. Lack of Mechanism for NSFs to Utilize External
Profiles . . . . . . . . . . . . . . . . . . . . . . 8
3.1.8. Lack of Mechanisms to Accept External Alerts to
Trigger Automatic Rule and Configuration Changes . . 8
3.1.9. Lack of Mechanism for Dynamic Key Distribution to
NSFs . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Challenges Facing Customers . . . . . . . . . . . . . . . 10
3.2.1. NSFs from Heterogeneous Administrative Domains . . . 10
3.2.2. Today's Control Requests are Vendor Specific . . . . 10
3.2.3. Difficulty to Monitor the Execution of Desired
Policies . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Difficulty to Validate Policies across Multiple Domains . 12
3.4. Lack of Standard Interface to Inject Feedback to NSF . . 13
3.5. Lack of Standard Interface for Capability Negotiation . . 13
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Basic Framework . . . . . . . . . . . . . . . . . . . . . 14
4.2. Access Networks . . . . . . . . . . . . . . . . . . . . . 15
4.3. Cloud Data Center Scenario . . . . . . . . . . . . . . . 18
4.3.1. On-Demand Virtual Firewall Deployment . . . . . . . . 18
4.3.2. Firewall Policy Deployment Automation . . . . . . . . 19
4.3.3. Client-Specific Security Policy in Cloud VPNs . . . . 19
4.3.4. Internal Network Monitoring . . . . . . . . . . . . . 20
4.4. I2NSF Preventing Distributed DoS in Overlay Networks . . 20
4.5. Software-Defined Networks . . . . . . . . . . . . . . . . 21
4.5.1. Centralized Firewall System . . . . . . . . . . . . . 24
4.5.2. Centralized DDoS-attack Mitigation System . . . . . . 24
4.5.3. Centralized VoIP/VoLTE Security System . . . . . . . 25
Hares, et al. Expires May 17, 2017 [Page 2]
Internet-Draft I2NSF Problem/Use Case November 2016
5. Management Considerations . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative References . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
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
[I-D.hares-i2nsf-gap-analysis].
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.
According to [Gartner-2013], 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.
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
[I-D.pastor-i2nsf-merged-use-cases]:
o [I-D.pastor-i2nsf-access-usecases] (I2NSF-Access),
Hares, et al. Expires May 17, 2017 [Page 3]
Internet-Draft I2NSF Problem/Use Case November 2016
o [I-D.zarny-i2nsf-data-center-use-cases](I2NSF-DC), and
o [I-D.qi-i2nsf-access-network-usecase] (I2NSF-Mobile).
2. Terminology
ACL: Access Control List
B2B: Business-to-Business
Bespoke: Something made to fit a particular person, client or
company.
Bespoke security management: Security management which is made to
fit a particular customer.
DC: Data Center
FW: Firewall
IDS: Intrusion Detection System
IPS: Intrusion Protection System
I2NSF: interface to Network Security Functions.
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.
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).
Virtual NSF: An NSF which is deployed as a distributed virtual
resource.
VNFPool: Pool of Virtual Network Functions.
3. Problem Space
The following sub-section describes the problems and challenges
facing customers and security service providers when some or all of
Hares, et al. Expires May 17, 2017 [Page 4]
Internet-Draft I2NSF Problem/Use Case November 2016
the security functions are no longer physically hosted by the
customer's adminstrative domain.
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".
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.
A service provider may be a customer of another service provider.
3.1. Challenges Facing Security Service Providers
3.1.1. Diverse Types of Security Functions
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.
Below are a few examples of security functions and locations or
contexts in which they are often deployed:
External Intrusion and Attack Protection: Examples of this function
are firewall/ACL authentication, IPS, IDS, and endpoint
protection.
Security Functions in a DMZ: Examples of this function are
firewall/ACLs, IDS/IPS, one or all of AAA services NAT, forwarding
proxies, and application filtering. These functions may be
physically on-premise in a server provider's network at the DMZ
spots or located in a "virtual" DMZ.
Internal Security Analysis and Reporting: Examples of this function
are security logs, event correlation, and forensic analysis.
Hares, et al. Expires May 17, 2017 [Page 5]
Internet-Draft I2NSF Problem/Use Case November 2016
Internal Data and Content Protection: Examples of this function are
encryption, authorization, and public/private key management for
internal database.
Security gateways and VPN concentrators: Examples of these
functions are; IP-sec gateways, Secure VPN concentrators that
handle bridging secure VPNs, and Secure VPN controllers for data
flows.
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 how every firewall's
filtering is created or applied. Some features in a specific
vendor's filtering may be unique to the vendor's product so it is not
necessary to standardize these features.
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.
I2NSF may specify some filters, but these filters will be linked to
specific common functionality developed by I2NSF in informational
models or data models.
3.1.2. Diverse Interfaces to Control and Monitor NSFs
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.
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.
A challenge for monitoring is that an NSF cannot monitor what it
cannot view. Therefore, enabling a security function (e.g., firewall
[I-D.ietf-opsawg-firewalls]) does not mean that a network is
Hares, et al. Expires May 17, 2017 [Page 6]
Internet-Draft I2NSF Problem/Use Case November 2016
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.
3.1.3. More Distributed NSFs and vNSFs
The security functions which are invoked to enforce a security policy
can be located in different equipment and network locations.
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).
A vNSF has higher risk of failure, migrating, and state changes as
their hosting VMs are being created, moved, or decommissioned.
3.1.4. More Demand to Control NSFs Dynamically
In the advent of Software-Defined Networking (see
[I-D.jeong-i2nsf-sdn-security-services]), 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.
3.1.5. Demand for Multi-Tenancy to Control and Monitor NSFs
Service providers may need several operational units to control and
monitor the NSFs, especially when NSFs become distributed and
virtualized.
3.1.6. Lack of Characterization of NSFs and Capability Exchange
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.
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
Hares, et al. Expires May 17, 2017 [Page 7]
Internet-Draft I2NSF Problem/Use Case November 2016
(e.g., a file) or via an interface which accesses a repository of
security function capabilities which the NSF vendors dynamically
update.
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.
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.
3.1.7. Lack of Mechanism for NSFs to Utilize External Profiles
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 list 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.
There is a need to have a standard envelop (i.e., the format) to
allow NSFs to use external profiles.
3.1.8. Lack of Mechanisms to Accept External Alerts to Trigger
Automatic Rule and Configuration Changes
NSF can ask the I2NSF security controller to alter a specific rules
and/or configurations. 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.
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.
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 automatically.
Hares, et al. Expires May 17, 2017 [Page 8]
Internet-Draft I2NSF Problem/Use Case November 2016
[I-D.zhou-i2nsf-capability-interface-monitoring] 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.
3.1.9. Lack of Mechanism for Dynamic Key Distribution to NSFs
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
cryptographic uites (e.g. encryptoni algorithms, key deriation
functions, etc.) and other functions), there is a lack of standard
interface to provision and manage security associations.
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
([RFC4948])
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.
An example of a solution, may provide some insight into why the lack
of a mechanism is a problem. If you had an abstract key table
maintained by security services, you could use these keys for routing
and seurity devices.
What does this take?
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. One potential use of such an interface
is to manage IPSec security associations on SDN networks.
An abstract key service will work under the following conditions:
1. 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.
2. 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.)
Hares, et al. Expires May 17, 2017 [Page 9]
Internet-Draft I2NSF Problem/Use Case November 2016
3. Automated Key management must support both symmetric keys and
group keys via the service provided by items 1 and 2.
3.2. Challenges Facing Customers
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:
o Which critical communications are to be preserved during critical
events (DOTS),
o Which hosts are to continue service even during severe security
attacks (DOTS),
o Reporting of attacks to CERT (MILE),
o Managing network connectivity of systems out of compliance (SACM),
3.2.1. NSFs from Heterogeneous Administrative Domains
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.
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.
3.2.2. Today's Control Requests are Vendor Specific
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
Hares, et al. Expires May 17, 2017 [Page 10]
Internet-Draft I2NSF Problem/Use Case November 2016
standard interface that provides a clear technical characterization,
the service provider faces many challenges:
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.
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.
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.
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.
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.
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.
Hares, et al. Expires May 17, 2017 [Page 11]
Internet-Draft I2NSF Problem/Use Case November 2016
+------------+
| security |
| MGT system |
+----||------+
|| proprietary
|| or I2NSF standard
Picture: ||
Port 10 +--------+
--------| FW/IPS |-------------
Encrypted +--------+
Video Flow
Figure 1: Example of non-standard vs. standard interface
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.
3.2.3. Difficulty to Monitor the Execution of Desired Policies
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.
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.
3.3. Difficulty to Validate Policies across Multiple Domains
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
Hares, et al. Expires May 17, 2017 [Page 12]
Internet-Draft I2NSF Problem/Use Case November 2016
distributed in the network and sometimes are combined together in one
device to perform a set of tasks for delivering a service.
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.
Ensuring the consistent enforcement of the policies at various
domains is also challenging. Standard data models are likely to
contribute to addressing that issue.
3.4. Lack of Standard Interface to Inject Feedback to NSF
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.
Today there is no standard interface to exchange security profiles
between organizations.
3.5. Lack of Standard Interface for Capability Negotiation
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.
4. Use Cases
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
Hares, et al. Expires May 17, 2017 [Page 13]
Internet-Draft I2NSF Problem/Use Case November 2016
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.
4.1. Basic Framework
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:
+----------+
+-------+ | | +-------+
| | Interface 1 |Security | Interface 2 | NSF(s)|
|Client <-------------> <------------------> |
| | |Controller| | |
+-------+ | | +-------+
+----------+
Figure 2: Interaction between Entities
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 (e.g. enact policy and distribuge), and
collecting status information about NSFs.
Client devices or applications can require the security controller to
add, delete or update rules in the security service function for
their specific traffic.
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.
Customers may require validating NSF availability, provenance, and
correct execution. This validation process, especially relevant for
vNSFs, includes at least:
Hares, et al. Expires May 17, 2017 [Page 14]
Internet-Draft I2NSF Problem/Use Case November 2016
Integrity of the NSF: by ensuring that the NSF is not compromised;
Isolation: by ensuring the execution of the NSF is self-contained
for privacy requirements in multi-tenancy scenarios.
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.
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.
4.2. Access Networks
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.
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.
These use cases define the interaction between the operator and the
vNSFs through automated interfaces, typically by means of B2B
communications.
Hares, et al. Expires May 17, 2017 [Page 15]
Internet-Draft I2NSF Problem/Use Case November 2016
Customer + Access + PoP/Datacenter
| | +--------+
| ,-----+--. |Network |
| ,' | `-|Operator|
+-------------+ | /+----+ | |Mgmt Sys|
| Residential |-+------/-+vCPE+----+ +--------+
+-------------+ | / +----+ | \ | :
| / | \ | |
+----------+ | ; +----+ | +----+ |
|Enterprise|---+---+----+ vPE+--+----+ NSF| |
+----------+ | : +----+ | +----+ |
| : | / |
+--------+ | : +----+ | / ;
| Mobile |-+-----\--+vEPC+----+ /
+--------+ | \ +----+ | ,-'
| `--. | _.-'
| `----+----''
+ +
Figure 3: NSF and actors
Different access clients may have different service requests:
Residential: service requests for parental control, content
management, and threat management.
Parental control requests may include identity based filters for
web content or usage. Content management may include identifying
and blocking malicious activities from web contents, mail, or
files downloaded. Threat management may include identifying and
blocking botnets or malware.
Enterprise: service requests for enterprise flow security policies
and managed security services
Flow security policies include access (or isolation) to data from
various internal groups, access (or isolation) from varous web
sites or social media applications, and encryption on data
transferred between corporates sites (main office, enterprise
branch offices, and remote campuses). Managed security services
may include detection and mitigation of external and internal
threats. External threats can include application or phishing
attacks, malware, botnet, DDoS, and others. Internal threats (aka
lateral threats) can include detecting programs moving from one
enterprise site to another without permission.
Hares, et al. Expires May 17, 2017 [Page 16]
Internet-Draft I2NSF Problem/Use Case November 2016
Service Provider: Service requests for policies that protect
service providers networks against various threats (including
DDoS, botnets and malware). Such policies are meant to securely
and reliably deliver contents (e.g., data, voice, video) to
various customers, including residential, mobile and corporate
customers. These security policies are also enforced to guarantee
isolation between multiple tenants, regardless of the nature of
the corresponding connectivity services.
Mobile: service requests from interfaces which monitor and ensure
user quality of experience, content management, parental controls,
and external threat management.
Content management for the mobile device includes identifying and
blocking malicious activities from web contents, mail, files.
Threat management for infrastructure includes detecting and
removing malicious programs such as Botnet, DDoS, and Malware.
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:
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.
vNSF Customer Provisioning: Once a vNSF is deployed, any customer
can subscribe to it. The provisioning lifecycle includes the
following:
* Customer enrollment and cancellation of the subscription to a
vNSF;
* Configuration of the vNSF, based on specific configurations, or
derived from common security policies defined by the NSP.
* 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.
Hares, et al. Expires May 17, 2017 [Page 17]
Internet-Draft I2NSF Problem/Use Case November 2016
4.3. Cloud Data Center Scenario
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.
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.
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.
4.3.1. On-Demand Virtual Firewall Deployment
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.
Hares, et al. Expires May 17, 2017 [Page 18]
Internet-Draft I2NSF Problem/Use Case November 2016
---+-----------------------------+-----
| |
+---+ +-+-+
|vFW| |vFW|
+---+ +-+-+
| Client #1 | Client #2
---+-------+--- ---+-------+---
+-+-+ +-+-+ +-+-+ +-+-+
|vM | |vM | |vM | |vM |
+---+ +---+ +---+ +---+
Figure 4: NSF in Data Centers
4.3.2. Firewall Policy Deployment Automation
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.
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.
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.
Another feature that aids automation of firewalls that must be
covered in automation is dynamic key management.
4.3.3. Client-Specific Security Policy in Cloud VPNs
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,
Hares, et al. Expires May 17, 2017 [Page 19]
Internet-Draft I2NSF Problem/Use Case November 2016
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.
As described above, the dynamic key mechanisms are critical for the
securing the VPN and the distribution of policies.
4.3.4. Internal Network Monitoring
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.
4.4. I2NSF Preventing Distributed DoS in Overlay Networks
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.
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.
Hares, et al. Expires May 17, 2017 [Page 20]
Internet-Draft I2NSF Problem/Use Case November 2016
+-------------------------------------------+
| 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.
4.5. Software-Defined Networks
This scenario decribes the use cases of security services in the
networks using software-defined networking (SDN) [RFC7149]. SDN is a
set of techniques that enables users to directly program,
orchestrate, control and manage network resources through software
(e.g., SDN applications). It relocates the control of network
resources to a dedicated network element, namely SDN controller
(called switch controller). The SDN controller uses interfaces to
arbitrate the control of network resources in a logically centralized
manner. It also manages and configures the distributed network
resources, and provides the abstracted view of the network resources
to the SDN applications. The SDN applications can customize and
automate the operations (including management) of the abstracted
network resources in a programmable manner via the interfaces
[I-D.jeong-i2nsf-sdn-security-services].
Hares, et al. Expires May 17, 2017 [Page 21]
Internet-Draft I2NSF Problem/Use Case November 2016
Due to the increase of sophisticated network attacks, the legacy
security services become difficult to cope with such network attacks
in an autonomous manner. SDN has been introduced to make networks
more controllable and manageable, and this SDN technology will be
promising to autonomously deal with such network attacks in a prompt
manner.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Security Functions |
| (e.g., firewall, DDoS-attack mitigation, | Application
|VoIP/VoLTE, web filter, deep packet inspection)| Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--------------------------------------------------------------------
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Application-
| Application Support | Control Interface)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Orchestration | Switch Controller
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Layer
| Abstraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--------------------------------------------------------------------
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (Resource-
| Control Support | Control Interface)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Transport and Processing | Resource Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: High-level Architecture for SDN-based Security Services
As shown in Figure 6, network security functions (NSFs) as security
services (e.g., firewall, DDoS-attack mitigation, VoIP/VoLTE, web
filter, and deep packet inspection) run on the top of Switch
Controller (i.e., SDN Controller) [ITU-T.Y.3300]
[ONF-SDN-Architecture][ONF-OpenFlow]. When an administrator enforces
security policies for such security services through an application
interface, Switch Controller generates the corresponding access
control policy rules to meet such security policies in an autonomous
and prompt manner. According to the generated access control policy
rules, the network resources such as switches take an action to
mitigate network attacks, for example, dropping packets with
suspicious patterns.
Hares, et al. Expires May 17, 2017 [Page 22]
Internet-Draft I2NSF Problem/Use Case November 2016
+------------+
| I2NSF User |
+------------+
^
| Consumer-Facing Interface
v
+-------------------+ Registration +-----------------------+
|Security Controller|<-------------------->|Developer's Mgnt System|
+-------------------+ Interface +-----------------------+
^
| NSF-Facing Interface
v
+-------------------+ +-------------------+ +-------------------+
| NSF-1 |-| NSF-2 |....| NSF-n |
+-------------------+ +-------------------+ +-------------------+
^
| SDN Northbound Interface
v
+-----------------+
|Switch Controller|
+-----------------+
^
| SDN Southbound Interface
v
+--------+ +--------+ +--------+
|Switch-1|-|Switch-2|......|Switch-m|
+--------+ +--------+ +--------+
Figure 7: A Framework for SDN-based Security Services using I2NSF
Figure 7 shows a framework to support SDN-based security services
using I2NSF [I-D.ietf-i2nsf-framework]. As shown in the figure,
I2NSF User can use security services by delivering their high-level
security policies to security controller via Consumer-Facing
Interface. Security Controller asks NSFs to perform function-level
security services via NSF-Facing Interface. The NSFs run on top of
virtual machines through Network Functions Virtualization (NFV)
[ETSI-NFV]. NSFs ask switch controller to perform their required
security services on switches under the supervision of Switch
Controller. In addition, security controller uses Registration
Interface to communicate with Developer's Management System (denoted
as Developer's Mgnt System) for registering (or deregistering) the
developer's NSFs into (or from) the NFV system using the I2NSF
framework.
Based on the I2NSF framework having SDN networks in Figure 7, this
document introduces the following three use cases for security
services based on SDN: (i) centralized firewall system, (ii)
Hares, et al. Expires May 17, 2017 [Page 23]
Internet-Draft I2NSF Problem/Use Case November 2016
centralized DDoS-attack mitigation system, and (iii) centralized
VoIP/VoLTE security system.
4.5.1. Centralized Firewall System
For the centralized firewall system, a centralized network firewall
can manage each network resource and firewall rules can be managed
flexibly by a centralized server for firewall (called Firewall). The
centralized network firewall controls each switch for the network
resource management and the firewall rules can be added or deleted
dynamically.
The procedure of firewall operations in the centralized firewall
system is as follows:
1. Switch forwards an unknown flow's packet to Switch Controller.
2. Switch Controller forwards the unknown flow's packet to an
appropriate security service application, such as Firewall.
3. Firewall analyzes the headers and contents of the packet.
4. If Firewall regards the packet as a malware's packet with a
suspicious pattern, it reports the malware's packet to Switch
Controller.
5. Switch Controller installs new rules (e.g., drop packets with the
suspicious pattern) into switches.
6. The malware's packets are dropped by switches.
For the above centralized firewall system, the existing SDN protocols
can be used through standard interfaces between the firewall
application and switches [RFC7149][ITU-T.Y.3300][ONF-OpenFlow]
[ONF-SDN-Architecture].
4.5.2. Centralized DDoS-attack Mitigation System
For the centralized DDoS-attack mitigation system, a centralized
DDoS-attack mitigation can manage each network resource and
manipulate rules to each switch through a centralized server for
DDoS-attack mitigation (called DDoS-attack Mitigator). The
centralized DDoS-attack mitigation system defends servers against
DDoS attacks outside private network, that is, from public network.
Servers are categorized into stateless servers (e.g., DNS servers)
and stateful servers (e.g., web servers). For DDoS-attack
mitigation, traffic flows in switches are dynamically configured by
Hares, et al. Expires May 17, 2017 [Page 24]
Internet-Draft I2NSF Problem/Use Case November 2016
traffic flow forwarding path management according to the category of
servers [AVANT-GUARD]. Such a managenent should consider the load
balance among the switches for the defense against DDoS attacks.
The procedure of DDoS-attack mitigation operations in the centralized
DDoS-attack mitigation system is as follows:
1. Switch periodically reports an inter-arrival pattern of a flow's
packets to Switch Controller.
2. Switch Controller forwards the flow's inter-arrival pattern to an
appropriate security service application, such as DDoS-attack
Mitigator.
3. DDoS-attack Mitigator analyzes the reported pattern for the flow.
4. If DDoS-attack Mitigator regards the pattern as a DDoS attack, it
computes a packet dropping probability corresponding to
suspiciousness level and reports this DDoS-attack flow to Switch
Controller.
5. Switch Controller installs new rules into switches (e.g., forward
packets with the suspicious inter-arrival pattern with a dropping
probability).
6. The suspicious flow's packets are randomly dropped by switches
with the dropping probability.
For the above centralized DDoS-attack mitigation system, the existing
SDN protocols can be used through standard interfaces between the
DDoS-attack mitigator application and switches [RFC7149]
[ITU-T.Y.3300][ONF-OpenFlow][ONF-SDN-Architecture].
4.5.3. Centralized VoIP/VoLTE Security System
For the centralized VoIP/VoLTE security system, a centralized VoIP/
VoLTE security system can monitor each VoIP/VoLTE flow and manage
VoIP/VoLTE security rules controlled by a centralized server for
VoIP/VoLTE security service (called VoIP IPS). The VoIP/VoLTE
security system controls each switch for the VoIP/VoLTE call flow
management by manipulating the rules that can be added, deleted or
modified dynamically.
The procedure of VoIP/VoLTE security operations in the centralized
VoIP/VoLTE security system is as follows:
1. A switch forwards an unknown call flow's signal packet (e.g., SIP
packet) to Switch Controller. Also, if the packet belongs to a
Hares, et al. Expires May 17, 2017 [Page 25]
Internet-Draft I2NSF Problem/Use Case November 2016
matched flow's packet related to SIP (called matched SIP packet),
Switch forwards the packet to Switch Controller so that the
packet can be checked by an NSF for VoIP (i.e., VoIP IPS) via
Switch Controller, which monitors the behavior of its SIP call.
2. Switch Controller forwards the unknown flow's packet or the
matched SIP packet to an appropriate security service function,
such as VoIP IPS.
3. VoIP IPS analyzes the headers and contents of the signal packet,
such as IP address, calling number, and session description
[RFC4566].
4. If VoIP IPS regards the packet as a spoofed packet by hackers or
a scanning packet searching for VoIP/VoLTE devices, it requests
the Switch Controller to block that packet and the subsequent
packets that have the same call-id.
5. Switch Controller installs new rules (e.g., drop packets) into
switches.
6. The illegal packets are dropped by switches.
For the above centralized VoIP/VoLTE security system, the existing
SDN protocols can be used through standard interfaces between the
VoIP IPS application and switches [RFC7149][ITU-T.Y.3300]
[ONF-OpenFlow][ONF-SDN-Architecture].
5. Management Considerations
Management of NSFs usually include the following:
o Lifecycle managment and resource management of NSFs,
o Device configuration, such as address configuration, device
internal attributes configuration, etc.;
o Signaling, and
o Policy rule provisioning.
I2NSF will only focus on the policy provisioning part of NSF
management.
Hares, et al. Expires May 17, 2017 [Page 26]
Internet-Draft I2NSF Problem/Use Case November 2016
6. IANA Considerations
No IANA considerations exist for this document.
7. Security Considerations
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).
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 [RFC2904] to authorize
access to the network and access to the I2NSF management stream.
8. Contributors
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).
9. Contributing Authors
I2NSF has had a number of contributing authors. The following are
contributing authors:
o Linda Dunbar (Huawei),
o Antonio Pastur (Telefonica I+D),
o Mohamed Boucadair (France Telecom),
o Michael Georgiades (Prime Tel),
o Minpeng Qi (China Mobile),
o Shaibal Chakrabarty (US Ignite),
o Nic Leymann (Deutsche Telekom),
o Anil Lohiya (Juniper),
Hares, et al. Expires May 17, 2017 [Page 27]
Internet-Draft I2NSF Problem/Use Case November 2016
o David Qi (Bloomberg),
o Xiaobo Long,
o Hyoungshick Kim (Sungkyunkwan University),
o Jung-Soo Park (ETRI),
o Tae-Jin Ahn (Korea Telecom), and
o Se-Hui Lee (Korea Telecom).
10. Acknowledgements
This document was supported by Institute for Information and
communications Technology Promotion (IITP) funded by the Korea
government (MSIP) [R0166-15-1041, Standard Development of Network
Security based SDN].
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
11.2. Informative References
[AVANT-GUARD]
Shin, S., Yegneswaran, V., Porras, P., and G. Gu, "AVANT-
GUARD: Scalable and Vigilant Switch Flow Management in
Software-Defined Networks", ACM CCS, November 2013.
[ETSI-NFV]
ETSI GS NFV 002 V1.1.1, , "Network Functions
Virtualisation (NFV); Architectural Framework", October
2013.
[Gartner-2013]
Messmer, E., "Gartner: Cloud-based security as a service
set to take off", October 2013.
[I-D.hares-i2nsf-gap-analysis]
Hares, S., Zhang, D., Moskowitz, R., and H. Rafiee,
"Analysis of Existing work for I2NSF", draft-hares-i2nsf-
gap-analysis-01 (work in progress), December 2015.
Hares, et al. Expires May 17, 2017 [Page 28]
Internet-Draft I2NSF Problem/Use Case November 2016
[I-D.ietf-i2nsf-framework]
Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security
Functions", draft-ietf-i2nsf-framework-04 (work in
progress), October 2016.
[I-D.ietf-netmod-acl-model]
Bogdanovic, D., Koushik, K., Huang, L., and D. Blair,
"Network Access Control List (ACL) YANG Data Model",
draft-ietf-netmod-acl-model-06 (work in progress),
December 2015.
[I-D.ietf-opsawg-firewalls]
Baker, F. and P. Hoffman, "On Firewalls in Internet
Security", draft-ietf-opsawg-firewalls-01 (work in
progress), October 2012.
[I-D.jeong-i2nsf-sdn-security-services]
Jeong, J., Kim, H., Jung-Soo, P., Ahn, T., and s.
sehuilee@kt.com, "Software-Defined Networking Based
Security Services using Interface to Network Security
Functions", draft-jeong-i2nsf-sdn-security-services-05
(work in progress), July 2016.
[I-D.lopez-i2nsf-packet]
Ed, E., "Packet-Based Paradigm For Interfaces To NSFs",
draft-lopez-i2nsf-packet-00 (work in progress), March
2015.
[I-D.pastor-i2nsf-access-usecases]
Pastor, A. and D. Lopez, "Access Use Cases for an Open OAM
Interface to Virtualized Security Services", draft-pastor-
i2nsf-access-usecases-00 (work in progress), October 2014.
[I-D.pastor-i2nsf-merged-use-cases]
Pastor, A., Lopez, D., Wang, K., Zhuang, X., Qi, M.,
Zarny, M., Majee, S., Leymann, N., Dunbar, L., and M.
Georgiades, "Use Cases and Requirements for an Interface
to Network Security Functions", draft-pastor-i2nsf-merged-
use-cases-00 (work in progress), June 2015.
[I-D.qi-i2nsf-access-network-usecase]
Wang, K. and X. Zhuang, "Integrated Security with Access
Network Use Case", draft-qi-i2nsf-access-network-
usecase-02 (work in progress), March 2015.
Hares, et al. Expires May 17, 2017 [Page 29]
Internet-Draft I2NSF Problem/Use Case November 2016
[I-D.zarny-i2nsf-data-center-use-cases]
Zarny, M., Leymann, N., and L. Dunbar, "I2NSF Data Center
Use Cases", draft-zarny-i2nsf-data-center-use-cases-00
(work in progress), October 2014.
[I-D.zhou-i2nsf-capability-interface-monitoring]
Zhou, C., Xia, L., Boucadair, M., and J. Xiong, "The
Capability Interface for Monitoring Network Security
Functions (NSF) in I2NSF", draft-zhou-i2nsf-capability-
interface-monitoring-00 (work in progress), October 2015.
[ITU-T.Y.3300]
Recommendation ITU-T Y.3300, , "Framework of Software-
Defined Networking", June 2014.
[ONF-OpenFlow]
ONF, , "OpenFlow Switch Specification (Version 1.4.0)",
October 2013.
[ONF-SDN-Architecture]
ONF, , "SDN Architecture", June 2014.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
D. Spence, "AAA Authorization Framework", RFC 2904,
DOI 10.17487/RFC2904, August 2000,
<http://www.rfc-editor.org/info/rfc2904>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the
IAB workshop on Unwanted Traffic March 9-10, 2006",
RFC 4948, DOI 10.17487/RFC4948, August 2007,
<http://www.rfc-editor.org/info/rfc4948>.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider
Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<http://www.rfc-editor.org/info/rfc7149>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 7277, DOI 10.17487/RFC7277, June 2014,
<http://www.rfc-editor.org/info/rfc7277>.
Hares, et al. Expires May 17, 2017 [Page 30]
Internet-Draft I2NSF Problem/Use Case November 2016
Authors' Addresses
Susan Hares
Huawei
7453 Hickory Hill
Saline, MI 48176
USA
Phone: +1-734-604-0332
Email: shares@ndzh.com
Diego R. Lopex
Telefonica I+D
Don Ramon de la Cruz, 82
Madrid 28006
Spain
Email: diego.r.lopez@telefonica.com
Myo Zarny
Goldman Sachs
30 Hudson Street
Jersey City, NJ 07302
USA
Email: myo.zarny@gs.com
Christian Jacquenet
France Telecom
Rennes, 35000
France
Email: Christian.jacquenet@orange.com
Rakesh Kumar
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
USA
Email: rkkumar@juniper.net
Hares, et al. Expires May 17, 2017 [Page 31]
Internet-Draft I2NSF Problem/Use Case November 2016
Jaehoon Paul Jeong
Department of Software
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419
Republic of Korea
Phone: +82 31 299 4957
Fax: +82 31 290 7996
Email: pauljeong@skku.edu
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
Hares, et al. Expires May 17, 2017 [Page 32]