summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8192.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8192.txt')
-rw-r--r--doc/rfc/rfc8192.txt1627
1 files changed, 1627 insertions, 0 deletions
diff --git a/doc/rfc/rfc8192.txt b/doc/rfc/rfc8192.txt
new file mode 100644
index 0000000..f771ab5
--- /dev/null
+++ b/doc/rfc/rfc8192.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Hares
+Request for Comments: 8192 Huawei
+Category: Informational D. Lopez
+ISSN: 2070-1721 Telefonica I+D
+ M. Zarny
+ vArmour
+ C. Jacquenet
+ France Telecom
+ R. Kumar
+ Juniper Networks
+ J. Jeong
+ Sungkyunkwan University
+ July 2017
+
+
+ Interface to Network Security Functions (I2NSF):
+ Problem Statement and Use Cases
+
+Abstract
+
+ This document sets out the problem statement for Interface to Network
+ Security Functions (I2NSF) and outlines some companion use cases.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc8192.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hares, et al. Informational [Page 1]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+Copyright Notice
+
+ Copyright (c) 2017 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
+ (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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hares, et al. Informational [Page 2]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1. Challenges Facing Security Service Providers . . . . . . 6
+ 3.1.1. Diverse Types of Security Functions . . . . . . . . . 6
+ 3.1.2. Diverse Interfaces to Control and Monitor NSFs . . . 8
+ 3.1.3. More Distributed NSFs and vNSFs . . . . . . . . . . . 8
+ 3.1.4. More Demand to Control NSFs Dynamically . . . . . . . 9
+ 3.1.5. Demand for Multi-tenancy to Control and Monitor NSFs 9
+ 3.1.6. Lack of Characterization of NSFs and Capability
+ Exchange . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.1.7. Lack of Mechanism for NSFs to Utilize External
+ Profiles . . . . . . . . . . . . . . . . . . . . . . 10
+ 3.1.8. Lack of Mechanisms to Accept External Alerts to
+ Trigger Automatic Rule and Configuration Changes . . 10
+ 3.1.9. Lack of Mechanism for Dynamic Key Distribution to
+ NSFs . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 3.2. Challenges Facing Customers . . . . . . . . . . . . . . . 12
+ 3.2.1. NSFs from Heterogeneous Administrative Domains . . . 12
+ 3.2.2. Today's Vendor-Specific Control Requests . . . . . . 13
+ 3.2.3. Difficulty for Customers to Monitor the Execution of
+ Desired Policies . . . . . . . . . . . . . . . . . . 14
+ 3.3. Lack of Standard Interface to Inject Feedback to NSF . . 15
+ 3.4. Lack of Standard Interface for Capability Negotiation . . 15
+ 3.5. Difficulty in Validating Policies across Multiple Domains 15
+ 3.6. Software-Defined Networks . . . . . . . . . . . . . . . . 16
+ 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 4.1. Basic Framework . . . . . . . . . . . . . . . . . . . . . 17
+ 4.2. Access Networks . . . . . . . . . . . . . . . . . . . . . 18
+ 4.3. Cloud Data Center Scenario . . . . . . . . . . . . . . . 21
+ 4.3.1. On-Demand Virtual Firewall Deployment . . . . . . . . 21
+ 4.3.2. Firewall Policy Deployment Automation . . . . . . . . 22
+ 4.3.3. Client-Specific Security Policy in Cloud VPNs . . . . 22
+ 4.3.4. Internal Network Monitoring . . . . . . . . . . . . . 23
+ 4.4. Preventing DDoS, Malware, and Botnet Attacks . . . . . . 23
+ 4.5. Regulatory and Compliance Security Policies . . . . . . . 24
+ 5. Management Considerations . . . . . . . . . . . . . . . . . . 24
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
+ 8. Informative References . . . . . . . . . . . . . . . . . . . 25
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
+ Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 28
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
+
+
+
+
+
+
+Hares, et al. Informational [Page 3]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+1. Introduction
+
+ This document sets out the problem statement for Interface to Network
+ Security Functions (I2NSF) and outlines some use cases. A summary of
+ the state of the art in the industry and IETF that is relevant to
+ I2NSF work is documented in [I2NSF-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 which 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], the demand for hosted (or cloud-based)
+ security services is growing. Small- and medium-size 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 and 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 [I2NSF-USECASES]:
+
+ o I2NSF Access Use Cases [OAM-USECASE],
+
+ o I2NSF Data Center Use Cases [DC-USECASE], and
+
+ o Integrated Security with Access Network Use Case [ACCESS-USECASE].
+
+
+
+
+
+
+
+
+
+
+Hares, et al. Informational [Page 4]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+2. Terminology
+
+ AAA: Authentication, Authorization, and Accounting [RFC2904]
+
+ ACL: Access Control List
+
+ Bespoke security management: Security management that 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 is used
+ to ensure integrity, confidentiality, or availability of network
+ communication; to detect unwanted network activity; or to block,
+ or at least mitigate, the effects of unwanted activity.
+
+ Flow-based NSF: An NSF that 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., Medium Access Control
+ (MAC) rewrites, TTL decrement action, or NAT inspection or
+ changes). (Note: Some existing firewalls store packets and look
+ at the packets in logical order, which is not the order these are
+ received in time. This document restricts flow-based NSF to this
+ definition.)
+
+ Security service provider: A provider of security services to the
+ customers (end users or enterprises) using NSF equipment purchased
+ from vendors or created by the service provider.
+
+ SDN: Software-Defined Networking. (See [RFC7426] for architecture
+ and terminology or [RFC7149] for a service provider view.)
+
+ vCPE: virtual Customer Premises Equipment
+
+ vEPC: virtual Evolved Packet Core [EPC-3GPP]
+
+ vNSF: Virtual NSF. An NSF that is deployed as a distributed virtual
+ resource.
+
+
+
+
+Hares, et al. Informational [Page 5]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+ vPE: virtual Provider Edge
+
+ VPN: Virtual Private Network
+
+3. Problem Space
+
+ The following sub-sections describe the problems and challenges
+ facing customers and security service providers when some or all of
+ the security functions are no longer physically hosted by the
+ customer's administrative 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 organizations or different domains of
+ the same organization. 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.
+
+ It is the objective of the I2NSF work to address these problems and
+ challenges.
+
+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 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.
+
+
+
+
+Hares, et al. Informational [Page 6]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+ Security Functions in a Demilitarized Zone (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.
+
+ Centralized or Distributed Security Functions: The security
+ functions could be deployed in a centralized fashion for ease of
+ management and network design or in a distributed fashion for
+ scaled requirement. No matter how a security function is deployed
+ and provisioned, it is desirable to have the same interface to
+ provision security policies; otherwise, the job of security
+ administration is more complex, requiring knowledge of firewall
+ and network design.
+
+ Internal Security Analysis and Reporting: Examples of this function
+ are security logs, event correlation, and forensic analysis.
+
+ Internal Data and Content Protection: Examples of this function are
+ encryption, authorization, and public/private key management for
+ internal databases.
+
+ Security Gateways and VPN Concentrators: Examples of these functions
+ are IPsec 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 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 these
+ NSFs. Thus, standardizing interfaces will provide an impetus for
+ standardizing established security functions.
+
+ I2NSF may specify some filters, but these filters will be linked to
+ specific common functionality developed by I2NSF in information
+ models or data models.
+
+
+
+
+
+
+
+Hares, et al. Informational [Page 7]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+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 interface to NSFs exists
+ today, management of NSFs (device and policy provisioning,
+ monitoring, etc.) tends to be custom-made security management offered
+ by product vendors. As a result, automation of such services, if it
+ exists at all, is also custom made. Thus, even in the traditional
+ way of deploying security features, there is a gap that needs to be
+ filled; this would require coordination among implementations from
+ distinct vendors.
+
+ A challenge for monitoring prior to mitigation of a security
+ intrusion is that an NSF cannot monitor what it cannot view. For
+ example, enabling a security function to mitigate an intrusion (e.g.,
+ firewall [FIREWALLS]) must include a mechanism to provide monitoring
+ feedback in order to determine the intrusion has been stopped.
+ Therefore, it is necessary to have a mechanism to monitor and provide
+ execution status of NSFs to security and compliance management tools.
+ Such mechanisms exist in vendor-specific network security interfaces
+ for forensics and troubleshooting, but an industry standard interface
+ could provide monitoring across a variety of NSFs.
+
+3.1.3. More Distributed NSFs and vNSFs
+
+ The security functions that are invoked to enforce a security policy
+ can be located in different equipment and network locations.
+
+ The European Telecommunications Standards Institute (ETSI) Network
+ Functions Virtualization (NFV) initiative [ETSI-NFV] creates new
+ management challenges for security policies to be enforced by
+ distributed vNSFs.
+
+ A vNSF has higher risk of changes to the state of network connection,
+ interfaces, or traffic, as their hosting Virtual Machines (VMs) are
+ being created, moved, or decommissioned.
+
+
+
+
+
+
+
+
+
+
+
+Hares, et al. Informational [Page 8]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+3.1.4. More Demand to Control NSFs Dynamically
+
+ In the advent of Software-Defined Networking (SDN) (see
+ [SDN-SECURITY]), 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 security-
+ related requests from their clients.
+
+3.1.5. Demand for Multi-tenancy to Control and Monitor NSFs
+
+ Service providers may need to deploy several NSF controllers 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 can build an effective security solution. These
+ service function capabilities can be documented in a static manner
+ (e.g., a file) or via an interface that accesses a repository of
+ security function capabilities that 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 customers' security requirements.
+
+ The I2NSF work will focus on developing a standard method to describe
+ capabilities of security functions.
+
+
+
+
+Hares, et al. Informational [Page 9]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+3.1.7. Lack of Mechanism for NSFs to Utilize External Profiles
+
+ Many security functions depend on signature files or profiles (e.g.,
+ IPS/IDS signatures and DDoS Open Threat Signaling (DOTS) filters).
+ Different policies might need different signatures or profiles.
+ Today, blacklist databases can be a beneficial strategy for all
+ parties involved (except the attackers), but in the future, there
+ might be open-source signatures and profiles distributed as part of
+ IDS systems (e.g., by Snort, Suricata, Bro, and Kismet).
+
+ There is a need to have a standard envelope (i.e., a message 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
+
+ NSFs can ask the I2NSF security controller to alter specific rules
+ and/or configurations. For example, a Distributed Denial of Service
+ (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 two parts: a) the configuration of signaling
+ of open threats and b) DDoS mitigation. The DOTS controller manages
+ the signaling part of DDoS. I2NSF controller(s) would control any
+ changes to affected policies (e.g., forwarding and routing,
+ filtering, etc.). By monitoring the network alerts regarding DDoS
+ attacks (e.g., from DOTS servers or clients), the I2NSF controller(s)
+ can feed an alerts analytics engine that could recognize attacks so
+ the I2NSF can 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 customer or change the network
+ configuration automatically.
+
+ [CAP-INTERFACE] 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 appropriate
+ policies.
+
+3.1.9. Lack of Mechanism for Dynamic Key Distribution to NSFs
+
+ There is a need for a controller to create, manage, and distribute
+ various keys to distributed NSFs. While there are many key
+ management methods and cryptographic suites (e.g., encryption
+ algorithms, key derivation functions, etc.) and other functions,
+ there is a lack of a standard interface to provision and manage
+ security associations.
+
+
+
+Hares, et al. Informational [Page 10]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+ 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 protocols and messages in the core routing infrastructure (see
+ [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 a device had an abstract key table
+ maintained by security services, it could use these keys for routing
+ and security devices.
+
+ What does this take?
+
+ Conceptually, there must be an interface defined for routing/
+ signaling protocols that can a) make requests for automated key
+ management when it is being used and b) 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 Software-
+ Defined 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 several protocols
+ share common mechanisms for authentication (e.g., TCP
+ Authentication Option [RFC5925]), then the same mapping may be
+ used for all usages of that mechanism.
+
+ 3. Automated key management needs to support both pairwise keys and
+ group keys via the abstract key service provided by items 1 and
+ 2. I2NSF controllers within the NSF that are required to
+ exchange data with NSFs may exchange data with individual NSFs
+ using individual pairwise keys or with a group of NSFs
+ simultaneously using an IP group address secured by a group
+ security key(s).
+
+
+
+
+
+
+
+
+Hares, et al. Informational [Page 11]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+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 and which hosts will continue services over the network,
+
+ o what signaling information is passed to a controller during a DDoS
+ in order to ask for mitigation services (within the scope of the
+ DOTS Working Group),
+
+ o reporting of attacks to CERT (within the scope of the MILE Working
+ Group), and
+
+ o managing network connectivity of systems out of compliance (within
+ the scope of the SACM Working Group).
+
+3.2.1. NSFs from Heterogeneous Administrative Domains
+
+ Many medium and large enterprises have deployed various on-premises
+ security functions that they want to continue to use. These
+ enterprises want to combine local security functions with remote
+ hosted security functions to achieve more efficient and immediate
+ countermeasures to attacks originating on both the Internet and
+ enterprise networks.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hares, et al. Informational [Page 12]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+3.2.2. Today's Vendor-Specific Control Requests
+
+ Customers may utilize NSFs provided 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 standardized
+ interface that provides a clear technical characterization, the
+ service provider faces many challenges:
+
+ No standard technical characterization, APIs, or interface(s):
+ Even for the most common security services, there is no standard
+ technical characterization, APIs, or interface(s). 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 process the customer's
+ input with these widely varying interfaces and differing
+ configuration models for security devices and security policy.
+ Without a standard interface, new innovative security products
+ find a large barrier to entry into the market.
+
+ 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.
+
+ Managing by scripts du 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 by a
+ provider.
+
+ 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 a 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, as shown in Figure 1,
+ 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. Informational [Page 13]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+ +------------+
+ | Security |
+ | Management |
+ | System |
+ +----||------+
+ || Proprietary
+ || or I2NSF Standard
+ Video: ||
+ Port 10 +--------+
+ --------| FW/IPS |-------------
+ Encrypted +--------+
+ Video Flow
+
+ Figure 1: Example of Non-standard vs. Standard Interface
+
+ In contrast, as Figure 1 shows, if a firewall/IPS interface standard
+ exists, the customer would be able to send the request to a security
+ management system, and the security management would send it via a
+ I2NSF standard interface. Service providers could now utilize the
+ same standard interface to represent firewall/IPS services
+ implemented using products from many vendors.
+
+3.2.3. Difficulty for Customers 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.
+ Customers want to monitor existing policies to determine such things
+ as which policies are in effect, how many security attacks are being
+ prevented, and how much bandwidth efficiency does security
+ enforcement cost.
+
+ Today, there is no standard way for customers to get these details
+ from the security service. As a consequence, there is no way to
+ assure customers that their specified security policies are properly
+ enforced by the security functions located in the provider domain.
+
+ Customers also want this monitoring information from the security
+ system in order to plan for the future using "what-if" scenarios with
+ real data. A tight loop between the data gathered from security
+ systems and the "what-if" scenario planning can reduce the time to
+ design and deploy workable security policies that deal with new
+ threats.
+
+ It is the objective of the I2NSF work to provide a standard way to
+ get the information that security service assurance systems need to
+
+
+
+Hares, et al. Informational [Page 14]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+ provide customers an evaluation about the current security systems
+ and to quickly plan for future security policies using "what-if"
+ scenarios based on today's information.
+
+3.3. Lack of Standard Interface to Inject Feedback to NSF
+
+ Today, many security functions in the NSF, such as IPS, IDS, DDoS
+ mitigation, and antivirus, depend heavily on the associated profiles.
+ NSF devices can perform more effective protection if these NSF
+ devices have the up-to-date profiles for these functions. Today,
+ there is no standard interface to provide these security profiles for
+ the NSF.
+
+ As more sophisticated threats arise, protection will depend on
+ enterprises, vendors, and service providers being able to cooperate
+ to develop optimal profiles; one example of this cooperation is the
+ Cyber Threat Alliance [CTA]. The standard interface to provide
+ security profiles to the NSF should interwork with the formats that
+ exchange security profiles between organizations.
+
+ One objective of the I2NSF work is to provide this type of standard
+ interface to security profiles.
+
+3.4. 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 may happen that cause the
+ NSF to exhaust those negotiated resources. At this point, the NSF
+ should inform the security controller that the allotted 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.
+
+3.5. Difficulty in Validating Policies across Multiple Domains
+
+ As discussed in the previous four sub-sections, both service
+ providers and customers have need to express policies and profiles,
+ monitor systems, verify security policy has been installed in NSFs
+ within a security domain, and establish limits for services NSFs can
+ safely perform. This sub-section and the next sub-section
+ (Section 3.6) examine what happens in two specific network scenarios:
+ a) multi-domain control of security devices hosted on virtual and
+ non-virtual NSFs and b) Software-Defined Networking.
+
+
+
+
+Hares, et al. Informational [Page 15]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+ Hosted security service may instantiate NSFs in virtual machines that
+ are sometimes widely distributed in the network and sometimes are
+ combined together in one device to perform a set of tasks for
+ delivering a service. Hosted security services may be connected
+ within a single service provider or via multiple service providers.
+ Ensuring that the security service purchased by the customer adheres
+ to customer policy requires that the central controller(s) for this
+ service monitor and validate this service across multiple networks on
+ NSFs (some of which may be virtual networks on virtual machines). To
+ set up this cross-domain service, the security controller must be
+ able to communicate with NSFs and/or controllers within its domain
+ and across domains to negotiate for the services needed.
+
+ 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 across multiple domains.
+ 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 solving that issue.
+
+3.6. Software-Defined Networks
+
+ Software-Defined Networks have changed the landscape of data-center
+ designs by introducing overlay networks deployed over Top-of-Rack
+ (ToR) switches that connect to a hypervisor. SDN techniques are
+ meant to improve the flexibility of workload management without
+ affecting applications and how they work. Workload can thus be
+ easily and seamlessly managed across private and public clouds. SDN
+ techniques optimize resource usage and are now being deployed in
+ various networking environments besides cloud infrastructures. Yet,
+ such SDN-conferred agility may raise specific security issues. For
+ example, a security administrator must make sure that a security
+ policy can be enforced regardless of the location of the workload,
+ thereby raising concerns about the ability of SDN computation logic
+ to send security policy-provisioning information to the participating
+ NSFs. A second example is workload migration to a public cloud
+ infrastructure, which may raise additional security requirements
+ during the migration.
+
+
+
+
+
+
+
+
+Hares, et al. Informational [Page 16]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+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
+ 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 Business Support Systems / Operations
+ Support Systems (BSSs/OSSs) of Network Service Providers (NSPs), or a
+ 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, and 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 a 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 that the security controller
+ has gathered from NSFs. Interface 2 is used for interacting with
+ NSFs according to commands (e.g., enact/revoke a security policy or
+ distribute a policy) 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 it, and
+ give feedback to the client through Interface 1. This interface can
+
+
+
+
+Hares, et al. Informational [Page 17]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+ 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
+ execution. This validation process, especially relevant to vNSFs,
+ includes at least:
+
+ Integrity of the NSF: Ensuring that the NSF is not compromised;
+
+ Isolation: Ensuring the execution of the NSF is self-contained for
+ privacy requirements in multi-tenancy scenarios; and
+
+ Provenance of the 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 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.
+
+ This implies that there may be the following two types of clients
+ using Interface 1: the end user and the trusted, independent third
+ party. The I2NSF work may determine that Interface 1 creates two
+ sub-interfaces to support these two types of clients.
+
+4.2. Access Networks
+
+ This scenario describes use cases for users (e.g., residential user,
+ enterprise user, mobile user, and management system) that request and
+ manage security services hosted in the 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. Figure 3 shows how different types of
+ customers connect through virtual access nodes (vCPE, vPE, and vEPC)
+ to an NSF.
+
+ The vCPE described in use case #7 in [NFVUC] requires a model of
+ access virtualization that includes mobile and residential access
+ networks where the operator may offload security services from the
+ customer's local environment (e.g., device or terminal) to its own
+ infrastructure.
+
+
+
+
+
+Hares, et al. Informational [Page 18]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+ These use cases define the interaction between the operator and the
+ vNSFs through automated interfaces that support the business
+ communications between customer and provider or between two business
+ entities.
+
+ Customer + Access + PoP / Data Center
+ | | +--------+
+ | ,-----+--. |Network |
+ | ,' | `-|Operator|
+ +-------------+ | /+----+ | |Mgmt Sys|
+ | Residential |-+------/-+vCPE+----+ +--------+
+ +-------------+ | / +----+ | \ | :
+ | / | \ | |
+ +----------+ | ; +----+ | +----+ |
+ |Enterprise|---+---+----+ vPE+--+----+ NSF| |
+ +----------+ | : +----+ | +----+ |
+ | : | / |
+ +--------+ | : +----+ | / ;
+ | Mobile |-+-----\--+vEPC+----+ /
+ +--------+ | \ +----+ | Service /
+ | `--. | Provider /
+ | `----+---------..
+ + + ^^
+ ||
+ Service Provider
+ encompasses
+ everything
+ in circle
+
+ vCPE - virtual customer premises equipment
+ vPE - virtual provider edge
+ vEPC - virtual evolved packet core
+ PoP - point of presence
+
+ Figure 3: NSF and Actors
+
+ Different access clients may have different service requests:
+
+ Residential: service requests for parental control, content
+ management, and threat management.
+
+ Threat 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.
+
+
+
+Hares, et al. Informational [Page 19]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+ Flow security policies identify and block malicious activities
+ during access to (or isolation from) web sites or social media
+ applications. Managed security services for an enterprise may
+ include detection and mitigation of external and internal threats.
+ External threats can include application or phishing attacks,
+ malware, botnet, DDoS, and others.
+
+ Service Provider: service requests for policies that protect service
+ provider networks against various threats (including DDoS,
+ botnets, and malware). Such policies are meant to securely and
+ reliably deliver contents (e.g., data, voice, and 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 that 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, and files
+ uploaded/downloaded. Threat management for infrastructure
+ includes detecting and removing malicious programs such as botnet,
+ malware, and other programs that create DDoS attacks).
+
+ 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 security policies requested by the clients.
+
+ Other access customers, especially some enterprise customers, may
+ want to contract separately for 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 of instantiating an
+ NSF on an NFV 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 life cycle includes the
+ following:
+
+ * Customer enrollment and cancellation of the subscription to a
+ vNSF.
+
+
+
+Hares, et al. Informational [Page 20]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+ * Configuration of the vNSF, based on specific configurations or
+ derived from common security policies defined by the NSP.
+
+ * Retrieval 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.
+
+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 demand level in the 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 of time frames 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 forms rather than in a physical appliance form.
+ This requirement is a provider-side concern. Users of the firewall
+ service are agnostic (as they should be) 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 within the organization be separated from inter-organization
+ traffic. Another example is IPS/IDS services that split investment
+ banking traffic from other data traffic to comply with regulatory
+ restrictions for transfer of investment banking information.
+
+4.3.1. On-Demand Virtual Firewall Deployment
+
+ A cloud data center operated by a service provider could serve tens
+ of thousands of clients. Clients' compute servers are typically
+ hosted on 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
+
+
+
+Hares, et al. Informational [Page 21]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+ 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.
+ Figure 4 shows an example topology of virtual firewalls within a data
+ center.
+
+ ---+-----------------------------+-----
+ | |
+ +---+ +-+-+
+ |vFW| |vFW|
+ +---+ +-+-+
+ | Client #1 | Client #2
+ ---+-------+--- ---+-------+---
+ +-+-+ +-+-+ +-+-+ +-+-+
+ |VM | |VM | |VM | |VM |
+ +---+ +---+ +---+ +---+
+
+ Figure 4: NSF in Data Centers
+
+4.3.2. Firewall Policy Deployment Automation
+
+ Firewall rules apply to traffic usually identified with addresses and
+ ports. 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 firewalls.
+
+ Even though most vendors support similar firewall features, the
+ specific rule configuration keywords are different from vendor to
+ vendor, 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 and utilize dynamic key management.
+
+4.3.3. Client-Specific Security Policy in Cloud VPNs
+
+ Clients of cloud data centers operated by a service provider need to
+ secure Virtual Private Networks (VPNs) and 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
+
+
+
+Hares, et al. Informational [Page 22]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+ to dynamically view (let alone change) what, where, and how security
+ policies are implemented on their provider-operated clouds. Indeed,
+ no standards-based framework exists to allow clients to retrieve/
+ manage security policies in a consistent manner across different
+ providers.
+
+ As described above, the dynamic key management is critical for
+ 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 the 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. Preventing DDoS, Malware, and Botnet Attacks
+
+ On the Internet, where everything is connected, preventing unwanted
+ traffic that may cause a DoS attack or a DDoS attack has become a
+ challenge. Similarly, a network could be exposed to malware attacks
+ and become an attack vector that may jeopardize the operation of
+ other networks, by means of remote commands for example. Many
+ networks that carry groups of information (such as Internet of Things
+ (IoT) networks, Information-Centric Networks (ICNs), Content Delivery
+ Networks (CDNs), Voice over IP (VoIP) packet networks, and Voice over
+ LTE (VoLTE)) are also exposed to such remote attacks. There are many
+ examples of remote attacks on these networks, but the following
+ examples will illustrate the issues. A malware attack on an IoT
+ network that carries sensor readings and instructions may attempt to
+ alter the sensor instructions in order to disable a key sensor. A
+ malware attack on VoIP or VoLTE networks involves software that
+ attempts to place unauthorized long-distance calls. Botnets may
+ overwhelm nodes in ICNs and CDNs so that the networks cannot pass
+ critical data.
+
+ In order for organizations to better secure their networks against
+ these kind of attacks, the I2NSF framework should provide a client-
+ side interface that is use case independent and technology agnostic.
+ Technology agnostic is defined to be generic, technology independent,
+ and able to support multiple protocols and data models. For example,
+ such an I2NSF interface could be used to provision security policy
+ configuration information that looks for specific malware signatures.
+ Similarly, botnet attacks could be easily prevented by provisioning
+ security policies using the I2NSF client-side interface that prevents
+ access to botnet command and control servers.
+
+
+
+
+Hares, et al. Informational [Page 23]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+4.5. Regulatory and Compliance Security Policies
+
+ Organizations must protect their networks against attacks and must
+ also adhere to various industry regulations: any organization that
+ falls under a specific regulation, like the Payment Card Industry -
+ Data Security Standard (PCI-DSS) [PCI-DSS] for the payment industry
+ or the Health Insurance Portability and Accountability Act [HIPAA]
+ for the healthcare industry, must be able to isolate various kinds of
+ traffic. They must also show records of their security policies
+ whenever audited.
+
+ The I2NSF client-side interface could be used to provision regulatory
+ and compliance-related security policies. The security controller
+ would keep track of when and where a specific policy is applied and
+ if there is any policy violation; this information can be provided in
+ the event of an audit as proof that traffic is isolated between
+ specific endpoints, in full compliance with the required regulations.
+
+5. Management Considerations
+
+ Management of NSFs usually include the following:
+
+ o Life-cycle management and resource management of NSFs,
+
+ o Device configuration, such as address configuration, device
+ internal attributes configuration, etc.,
+
+ o Signaling of events, notifications, and changes, and
+
+ o Policy rule provisioning.
+
+ I2NSF will only focus on the policy provisioning part of NSF
+ management.
+
+6. IANA Considerations
+
+ This document does not require any IANA actions.
+
+7. Security Considerations
+
+ Having 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 them. 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).
+
+
+
+
+Hares, et al. Informational [Page 24]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+ The traffic flow security policies specified by customers can
+ conflict with providers' internal traffic flow security policies.
+ This conflict can be resolved in one of two ways: a) installed
+ policies can restrict traffic if either the customer traffic flow
+ security policies or the provider's internal security policies
+ restrict traffic, or b) installed policies can only restrict traffic
+ if both the customer traffic flow security policies and the
+ provider's internal traffic flow security policies restrict data.
+ Either choice could cause potential problems. It is crucial for the
+ management system to flag these conflicts to the customers and to the
+ service provider.
+
+ It is important to proper AAA [RFC2904] to authorize access to the
+ network and access to the I2NSF management stream.
+
+ Enforcing the appropriate privacy is key to all IETF protocols (see
+ [RFC6973]) and is especially important for IETF security management
+ protocols since they are deployed to protect the network. In some
+ circumstances, security management protocols may be utilized to
+ protect an individual's home, phone, or other personal data. In this
+ case, any solution should carefully consider whether combining
+ management streams abides by the recommendations of [RFC6973] for
+ data minimization, user participation, and security.
+
+8. Informative References
+
+ [ACCESS-USECASE]
+ Wang, K. and X. Zhuang, "Integrated Security with Access
+ Network Use Case", Work in Progress,
+ draft-qi-i2nsf-access-network-usecase-02, March 2015.
+
+ [CAP-INTERFACE]
+ Zhou, C., Xia, L., Boucadair, M., and J. Xiong, "The
+ Capability Interface for Monitoring Network Security
+ Functions (NSF) in I2NSF", Work in Progress,
+ draft-zhou-i2nsf-capability-interface-monitoring-00,
+ October 2015.
+
+ [CTA] "Cyber Threat Alliance", <http://cyberthreatalliance.org>.
+
+ [DC-USECASE]
+ Zarny, M., Majee, S., Leymann, N., and L. Dunbar, "I2NSF
+ Data Center Use Cases", Work in Progress,
+ draft-zarny-i2nsf-data-center-use-cases-00, October 2014.
+
+ [EPC-3GPP] Firmin, F., "The Evolved Packet Core", January 2017.
+
+
+
+
+
+Hares, et al. Informational [Page 25]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+ [ETSI-NFV] ETSI, "Network Functions Virtualisation (NFV);
+ Architectural Framework", ETSI GS NFV 002 V1.2.1, December
+ 2014.
+
+ [FIREWALLS]
+ Baker, F. and P. Hoffman, "On Firewalls in Internet
+ Security", Work in Progress,
+ draft-ietf-opsawg-firewalls-01, October 2012.
+
+ [Gartner] Messmer, E., "Gartner: Cloud-based security as a service
+ set to take off", October 2013.
+
+ [HIPAA] US Congress, "Health Insurance Portability and
+ Accountability Act of 1996 (Public Law 104-191)", August
+ 1996, <https://www.hhs.gov/hipaa/>.
+
+ [I2NSF-ANALYSIS]
+ Hares, S., Moskowitz, R., and D. Zhang, "Analysis of
+ Existing work for I2NSF", Work in Progress,
+ draft-ietf-i2nsf-gap-analysis-03, March 2017.
+
+ [I2NSF-USECASES]
+ 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", Work in Progress,
+ draft-pastor-i2nsf-merged-use-cases-00, June 2015.
+
+ [NFVUC] ETSI, "Network Functions Virtualization (NFV); Use Cases",
+ ETSI GR NFV 001 V1.2.1, May 2017.
+
+ [OAM-USECASE]
+ Pastor, A. and D. Lopez, "Access Use Cases for an Open OAM
+ Interface to Virtualized Security Services", Work in
+ Progress, draft-pastor-i2nsf-access-usecases-00, October
+ 2014.
+
+ [PCI-DSS] PCI Security Standards Council, "Payment Card Industry
+ (PCI) Data Security Standard -- Requirements and Security
+ Assessment Procedures", PCS DSS v3.2, April 2016,
+ <https://www.pcisecuritystandards.org/pci_security/>.
+
+ [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>.
+
+
+
+
+Hares, et al. Informational [Page 26]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+ [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>.
+
+ [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
+ Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
+ June 2010, <http://www.rfc-editor.org/info/rfc5925>.
+
+ [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
+ Morris, J., Hansen, M., and R. Smith, "Privacy
+ Considerations for Internet Protocols", RFC 6973,
+ DOI 10.17487/RFC6973, July 2013,
+ <http://www.rfc-editor.org/info/rfc6973>.
+
+ [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>.
+
+ [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
+ Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
+ Defined Networking (SDN): Layers and Architecture
+ Terminology", RFC 7426, DOI 10.17487/RFC7426, January
+ 2015, <http://www.rfc-editor.org/info/rfc7426>.
+
+ [SDN-SECURITY]
+ Jeong, J., Kim, H., Park, J., Ahn, T., and S. Lee,
+ "Software-Defined Networking Based Security Services using
+ Interface to Network Security Functions", Work in
+ Progress, draft-jeong-i2nsf-sdn-security-services-05, July
+ 2016.
+
+Acknowledgments
+
+ This document was supported by the Institute for Information &
+ Communications Technology Promotion (IITP), which is funded by the
+ Ministry of Science, ICT & Future Planning (MSIP) (R0166-15-1041,
+ Standard Development of Network Security based SDN).
+
+
+
+
+
+
+
+
+
+
+
+
+Hares, et al. Informational [Page 27]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+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 (Curveball Networks), and Robert Moskowitz
+ (Huawei).
+
+ I2NSF has had a number of contributing authors. The following are
+ considered co-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)
+
+ o David Qi (Bloomberg)
+
+ o Hyoungshick Kim (Sungkyunkwan University)
+
+ o Jung-Soo Park (ETRI)
+
+ o Tae-Jin Ahn (Korea Telecom)
+
+ o Se-Hui Lee (Korea Telecom)
+
+Authors' Addresses
+
+ Susan Hares
+ Huawei
+ 7453 Hickory Hill
+ Saline, MI 48176
+ United States of America
+
+ Phone: +1-734-604-0332
+ Email: shares@ndzh.com
+
+
+
+
+
+Hares, et al. Informational [Page 28]
+
+RFC 8192 I2NSF Problem Statement & Use Cases July 2017
+
+
+ Diego R. Lopez
+ Telefonica I+D
+ Don Ramon de la Cruz, 82
+ Madrid 28006
+ Spain
+
+ Email: diego.r.lopez@telefonica.com
+
+
+ Myo Zarny
+ vArmour
+ 800 El Camino Real, Suite 3000
+ Mountain View, CA 94040
+ United States of America
+
+ Email: myo@varmour.com
+
+
+ Christian Jacquenet
+ France Telecom
+ Rennes, 35000
+ France
+
+ Email: Christian.jacquenet@orange.com
+
+
+ Rakesh Kumar
+ Juniper Networks
+ 1133 Innovation Way
+ Sunnyvale, CA 94089
+ United States of America
+
+ Email: rakeshkumarcloud@gmail.com
+
+
+ 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. Informational [Page 29]
+