RFC 8192
Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases
Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases 🎀
Okay bestie, let's get into it! ✨ This is RFC 8192, and it's giving problem statement energy. It's written by a squad of networking experts: S. Hares (Huawei), D. Lopez (Telefonica I+D), M. Zarny (vArmour), C. Jacquenet (France Telecom), R. Kumar (Juniper Networks), and J. Jeong (Sungkyunkwan University). 🫶
The category is Informational 🦋, which means it's not a Standards Track spec. It's published just to share info, not to set rules. It was published in July 2017 🌸 with ISSN 2070-1721, and it doesn't obsolete or update any other RFCs. It's a fresh start! 💅
Status: this doc is the consensus of the IETF community and was approved by the IESG. It also isn't a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 if you're curious. 👑
Want the errata or feedback info? Head to http://www.rfc-editor.org/info/rfc8192 💖
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. Please review those docs carefully, bestie, because they explain your rights and restrictions. Any Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in the Simplified BSD License. 🔥
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 . . . . . . . . . . . . . . . . . . . . . . . 281. Introduction ✨
This document lays out the problem statement for the Interface to Network Security Functions (I2NSF) and walks through some use cases. 🦋 If you want the state of the art in industry and the IETF that's relevant to I2NSF work, check out [I2NSF-ANALYSIS]. 💅
The challenges of keeping infrastructure secure, staying compliant with regulations, and controlling costs are pushing enterprises to consume network security functions hosted by service providers. 🌸 This hosted security service is especially appealing to small- and medium-size enterprises, which struggle with a lack of security experts to keep watch over networks, build new skills, and respond quickly to ever-growing sets of attacks. 😭
According to [Gartner], demand for hosted (or cloud-based) security services is growing. 📈 Small- and medium-size businesses (SMBs) are increasingly moving to cloud-based security services to replace on-premises tools, while bigger enterprises are running a mix of traditional and cloud-based services. 🔥
To keep up, more and more service providers are offering hosted security solutions as cost-effective managed security services for enterprise customers. 💖 These are mainly aimed at enterprises (especially small and medium ones), but they could also be offered to any kind of mass-market customer. 🌈 So NSFs are provided and consumed in a huge variety of environments. Users of NSFs may consume network security services hosted by one or more providers, which might be their own enterprise, service providers, or a combo of both. 🫶
This document also briefly describes the following use cases, summarized by [I2NSF-USECASES]:
- I2NSF Access Use Cases [OAM-USECASE],
- I2NSF Data Center Use Cases [DC-USECASE], and
- Integrated Security with Access Network Use Case [ACCESS-USECASE].
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. 🌸
vPE: virtual Provider Edge
VPN: Virtual Private Network
3. Problem Space 🎀
The sub-sections below describe the problems and challenges that customers and security service providers face 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 inside a large enterprise could act as a security service provider for that enterprise. Meanwhile, an enterprise could outsource all security services to an external security service provider. In this document, the security service provider function, whether internal or external, will be denoted as "service provider". 💜
The "Customer-Provider" relationship may exist between any two parties. 🤝 The parties can be in different organizations or in different domains of the same organization. Contractual agreements may be needed in such contexts to formally document the customer's security requirements and the provider's guarantees to meet them. 📝 Such agreements may spell out protection levels, escalation procedures, alarm reporting, etc. Right now there is 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 ✨
okay so there are SO many kinds of NSFs 😭 different vendors make them with different features and interfaces, and they can be deployed in a bunch of different spots in a network and have different jobs. no cap it's a lot 💅
here are a few security functions and the places they usually show up:
External Intrusion and Attack Protection: this one covers firewall/ACL authentication, IPS, IDS, and endpoint protection 🛡️
Security Functions in a Demilitarized Zone (DMZ): this is where you'll find firewall/ACLs, IDS/IPS, one or all of AAA services, NAT, forwarding proxies, and application filtering 🎀 these can be physically on-premise in a server provider's network at the DMZ spots, or they can live in a "virtual" DMZ ☁️
Centralized or Distributed Security Functions: security functions can be deployed in a centralized way for ease of management and network design, or in a distributed way for scaled requirements 🦋 no matter how a function is deployed and provisioned, it is desirable to have the same interface to provision security policies. otherwise security admin gets way more complex and you'd need to know firewall and network design just to do your job 🙈
Internal Security Analysis and Reporting: examples are security logs, event correlation, and forensic analysis 🔍
Internal Data and Content Protection: examples are encryption, authorization, and public/private key management for internal databases 🔐
Security Gateways and VPN Concentrators: examples are IPsec gateways, secure VPN concentrators that handle bridging secure VPNs, and secure VPN controllers for data flows 🌈
okay so given how diverse these functions are, where they get deployed, and how they keep evolving, standardizing every aspect of security functions is challenging and probably not feasible 😩 but honestly? it's not necessary to standardize all of it. from an I2NSF perspective, there's no need to standardize how every firewall's filtering is created or applied. some features in a specific vendor's filtering might be unique to their product, so it's not necessary to standardize those either 💜
what IS needed is a standardized interface to control and monitor the rule sets that NSFs use to treat packets traversing through them 🧚 so standardizing interfaces will give an impetus for standardizing established security functions. it's giving "build the interface first, the rest follows" 👑
I2NSF may specify some filters, but these filters will be linked to specific common functionality developed by I2NSF in information models or data models ✨
3.1.2. Diverse Interfaces to Control and Monitor NSFs 🌸
so service providers might need to use multiple security functions from various vendors to offer effective, competitive solutions and services, and to enforce the security policies their customers want 💅
since there's no widely accepted industry standard interface to NSFs today 💀, managing NSFs (device and policy provisioning, monitoring, etc.) tends to be custom-made security management offered by product vendors. and as a result, automating these services (if it even exists at all) is also custom made 🙃 so even in the traditional way of deploying security features, there's a gap that needs filling, and that would take coordination among implementations from distinct vendors 🫶
a challenge for monitoring prior to mitigating an 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 that provides monitoring feedback, so you can tell whether the intrusion has actually been stopped 😤 so it's necessary to have a mechanism to monitor and provide execution status of NSFs to security and compliance management tools. these 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, and that's the dream ✨
3.1.3. More Distributed NSFs and vNSFs 🦋
the security functions 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 a higher risk of changes to the state of network connections, interfaces, or traffic, because their hosting Virtual Machines (VMs) are being created, moved, or decommissioned 🌪️
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 enforced by NSFs 🚀 security service providers have to dynamically update their decision-making process (e.g., in terms of NSF resource allocation and invocation) whenever they get 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 made by multiple vendors 🛠️ even within one product category (e.g., firewall), security functions from different vendors can have different features and capabilities 🤷♀️ for example, filters that a firewall can design and activate 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 from different vendors so it can build an effective security solution 🧠 these capabilities can be documented in a static way (e.g., a file) or via an interface that accesses a repository of security function capabilities that NSF vendors dynamically update 📂
a dynamic capability registration is useful for automation, because security functions may be subject to software and hardware updates 🔄 and those updates may have implications on the policies enforced by the NSFs ⚠️
today there's no standard method for vendors to describe the capabilities of their security functions 😭 without a common technical framework for that, service providers can't automate selecting NSFs from different vendors to meet customers' security requirements 🥲
the I2NSF work will focus on developing a standard method to describe capabilities of security functions 🎯
3.1.7. Lack of Mechanism for NSFs to Utilize External Profiles 🧚♀️
lots of 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's a need for a standard envelope (i.e., a message format) so NSFs can 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, and I2NSF controller(s) would control any changes to affected policies (e.g., forwarding and routing, filtering, etc.) 🗂️ by monitoring network alerts about DDoS attacks (e.g., from DOTS servers or clients), the I2NSF controller(s) can feed an alerts analytics engine that could recognize attacks, so 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 then 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's a need for a controller to create, manage, and distribute various keys to distributed NSFs 🗝️ there are lots of key management methods and cryptographic suites (e.g., encryption algorithms, key derivation functions, etc.) and other functions, but there's a lack of a standard interface to provision and manage security associations 😩
the keys may be used for message authentication and integrity to protect data flows 🛡️ keys may also be used to secure the protocols and messages in the core routing infrastructure (see [RFC4948]) 🏗️
as of now, there's 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 might give 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 those 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 managing IPsec security associations on Software-Defined Networks 🌐
an abstract key service will work under the following conditions:
- 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 🧩
- 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 🎀
- 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) 🫧
3.2. Challenges Facing Customers 🎀
okay bestie, so when customers use hosted security services, their security policies might get enforced by a whole squad of security functions chilling in different domains 🌸 Customers often don't have the security skills to write super precise requirements or policies 😭 So usually they just share 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 want to spell out guidelines for security management. Examples of these guidelines include:
- which critical communications are to be preserved during critical events and which hosts will continue services over the network,
- 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),
- reporting of attacks to CERT (within the scope of the MILE Working Group), and
- managing network connectivity of systems out of compliance (within the scope of the SACM Working Group).
3.2.1. NSFs from Heterogeneous Administrative Domains 🦋
Lots of medium and large enterprises already have a bunch of on-premises security functions they're obsessed with and want to keep using 💜 These enterprises want to mix their local security functions with remote hosted security functions so they can respond faster and more efficiently to attacks coming from the Internet and from their own enterprise networks. Iconic behavior, honestly 👑
Some enterprises may only need 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 Vendor-Specific Control Requests 💅
Customers may use NSFs from multiple service providers. Customers need to tell the service providers their security requirements, guidelines, and expectations 🫶 Then the service providers have to translate that customer info into customer security policies and associated configuration tasks for the whole set of security functions in their network. Without a standardized interface that gives a clear technical characterization, the service provider runs into a bunch of challenges, and ngl it's a lot:
- 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 only reachable through disparate, proprietary interfaces (e.g., portals or APIs) in whatever format vendors feel like offering. The service provider has to process the customer's input through these wildly different interfaces and differing configuration models for security devices and security policy. Without a standard interface, new innovative security products face a huge barrier to entry into the market 😭
- Lack of immediate feedback: Customers may also need a way to easily update or 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 get solicited without needing an explicit invocation means. Still, some explicit invocation means may be required to interact with a service function 🙈
- Managing by scripts du jour: The current practices rely on 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 every single time a provider enables an implementation from a different vendor technology 🥲
To see how standard interfaces could help achieve faster implementation time cycles, let's look at a customer who wants to dynamically allow an encrypted flow with a specific port, src/dst addresses, or protocol type through the firewall/IPS, so an encrypted video conferencing call can get through 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 the particular provider's firewall/IPS interface and send the request in the provider's required format 😩
+------------+
| Security |
| Management |
| System |
+----||------+
|| Proprietary
|| or I2NSF Standard
Video: ||
Port 10 +--------+
--------| FW/IPS |-------------
Encrypted +--------+
Video Flow
Figure 1: Example of Non-standard vs. Standard InterfaceIn 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 then use that same standard interface to represent firewall/IPS services implemented with products from many vendors 🧚
3.2.3. Difficulty for Customers to Monitor the Execution of Desired Policies 👀
How a policy gets translated into technology-specific actions is hidden from the customers 🙃 But customers still need ways to monitor the delivered security service that results from executing their desired security requirements, guidelines, and expectations. Customers want to check which policies are in effect, how many security attacks are being prevented, and how much bandwidth efficiency security enforcement costs 📊
Today, there's no standard way for customers to get these details from the security service. As a result, there's 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 info from the security system so they can 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 cut down the time it takes to design and deploy workable security policies that deal with new threats. Main character energy for security planning 💖
It is the objective of the I2NSF work to provide a standard way to get the information that security service assurance systems need, so they can give customers an evaluation of the current security systems and quickly plan future security policies using "what-if" scenarios based on today's information ✨
3.3. Lack of Standard Interface to Inject Feedback to NSF 🍓
Today, lots of security functions in the NSF, such as IPS, IDS, DDoS mitigation, and antivirus, depend heavily on their associated profiles. NSF devices can do more effective protection if they have up-to-date profiles for these functions. But right now, there's no standard interface to provide these security profiles for the NSF 😬
As more sophisticated threats show up, protection will depend on enterprises, vendors, and service providers being able to work together to develop optimal profiles. One example of this cooperation is the Cyber Threat Alliance [CTA] 🤝 The standard interface that provides 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 where the selected NSFs can't perform the policies the security controller requested because of resource constraints 🫠 The customer and the security service provider should negotiate the appropriate resource constraints before the security service begins. However, unexpected events may happen that make the NSF exhaust those negotiated resources. At that point, the NSF should inform the security controller that the allotted resources have been exhausted 🚨 To support automatic control in the SDN era, we need a set of messages for proper notification (and a response to that notification) between the security controller and the NSFs. It's giving teamwork 🧚
3.5. Difficulty in Validating Policies across Multiple Domains 🌐
As discussed in the previous four sub-sections, both service providers and customers need to express policies and profiles, monitor systems, verify that security policy has been installed in NSFs within a security domain, and set limits for the services NSFs can safely perform 📋 This sub-section and the next one (Section 3.6) look at 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 🦋
Hosted security services may instantiate NSFs in virtual machines that are sometimes widely distributed across the network, and sometimes 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. To make sure the security service the customer bought actually follows the customer's policy, the central controller(s) for this service need to monitor and validate it 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 own domain and across domains to negotiate the services needed.
Without standard interfaces and security policy data models, enforcing a customer-driven security policy stays really challenging 😩 That's 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 its own specific configuration procedures and operational tasks.
Making sure policies are consistently enforced across various domains is also challenging. Standard data models are likely to help solve 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 messing with applications or how they work. Workload can be moved around easily and seamlessly across private and public clouds. SDN techniques also optimize resource usage and are now being deployed in all kinds of networking environments beyond cloud infrastructures. Yet this SDN-conferred agility may raise specific security issues 😳 For example, a security administrator must make sure a security policy can be enforced no matter where the workload lives, which raises concerns about whether SDN computation logic can 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 🫶
4. Use Cases ✨
okay bestie, standard interfaces for monitoring and controlling how NSFs behave are literally the building blocks that security service providers and enterprises need 💅 They use them to automate the use of NSFs from multiple vendors through their security management entities. I2NSF may be invoked by any (authorized) client 🫶 Examples are upstream applications (controllers), orchestration systems, and security portals.
4.1. Basic Framework
So users request security services through specific clients 💖 Think a customer application, the BSSs/OSSs of Network Service Providers (NSPs), or a management platform. Then the right NSP network entity invokes the (v)NSFs based on that user request. This entity is called the security controller in this document 👑 Here's how the three entities (client, security controller, and NSF) vibe together in Figure 2:
+----------+
+-------+ | | +-------+
| | Interface 1 |Security | Interface 2 | NSF(s)|
|Client <--------------> <------------------> |
| | |Controller| | |
+-------+ | | +-------+
+----------+
Figure 2: Interaction between EntitiesInterface 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 NSF security reports (e.g., statistics) it has gathered from NSFs back to the client. Interface 2 is used for interacting with NSFs according to commands (e.g., enact/revoke a security policy or distribute a policy) and for 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 see the executing status of a security service, they can request NSF status from the client ✨ The security controller collects NSF information through Interface 2, consolidates it, and gives feedback to the 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 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.
To achieve this 🧚, the security controller may collect security measurements and share them with an independent and trusted third party (via Interface 1). That lets the third party attest NSF functions using the 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 is all about users (e.g., residential user, enterprise user, mobile user, and management system) who request and manage security services hosted in the NSP infrastructure 🌈 NSP customers are basically users of their access networks, so this scenario is tied to their characteristics as well as to 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] needs a model of access virtualization that covers 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 🫶
These use cases define the interaction between the operator and the vNSFs through automated interfaces that support business communications between a customer and a 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 ActorsDifferent 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.
- 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 don't care which NSFs are used to get the services they asked for 🤷♀️ In that case, provider network orchestration systems can internally select the NSFs (or vNSFs) to enforce the security policies the clients requested.
Other access customers, especially some enterprise customers, may want to contract separately for dedicated NSFs (most likely vNSFs) for direct control purposes 👑 If that's you, here are the steps to associate vNSFs with 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.
- 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 service provider. 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 📈 That capacity expansion could mean adding new firewall instances on existing machines, or provisioning a completely new firewall instance on a different machine.
The on-demand, dynamic nature of security service delivery basically encourages network security "devices" to be software or virtual rather than physical appliances 💻 This is a provider-side concern. Users of the firewall service are agnostic (as they should be) about whether the firewall runs on a VM or any other form factor. Honestly, they may not even know their traffic goes through firewalls 🙈
Also, new firewall instances need to be placed in the "right zone" (domain) 🗺️ This matters not only in multi-tenant environments, where getting the tenant into 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 on transferring investment banking information 🏦✨
4.3.1. On-Demand Virtual Firewall Deployment
okay so picture a cloud data center run by a service provider, serving tens of thousands of clients 🏢✨ each client's compute servers usually live on VMs, and those VMs can be spread across different server racks in different parts of the building 🧚 buying dedicated physical firewalls for every single client's security policy is often not technically or financially doable, and those policies can be super numerous 😭 so what we really need is a way to spin up virtual firewalls for each client's set of servers on the fly, based on established security policies and the underlying network topology 💅 Figure 4 shows what that looks like inside a data center:
---+-----------------------------+-----
| |
+---+ +-+-+
|vFW| |vFW|
+---+ +-+-+
| Client #1 | Client #2
---+-------+--- ---+-------+---
+-+-+ +-+-+ +-+-+ +-+-+
|VM | |VM | |VM | |VM |
+---+ +---+ +---+ +---+
Figure 4: NSF in Data Centers4.3.2. Firewall Policy Deployment Automation
firewall rules usually match traffic by addresses and ports, and that gets way more complicated in provider-owned cloud networks that serve myriads of customers 🌸
the thing is, firewall rules today are super tied to the ports and addresses that identify traffic 🙈 so clients of cloud data centers find it really hard to write rules for their own traffic, because they only ever see their virtual networks and virtual addresses 😭 the customer-visible networks and addresses can be totally different from the actual packets moving through the firewalls 🌀
and here's the kicker: most vendors support pretty similar firewall features, but the rule configuration keywords are different from vendor to vendor 💀 that makes automation a nightmare. Automation works best when it can lean on a common set of standards that works across NSFs from multiple vendors and uses dynamic key management 🔥
4.3.3. Client-Specific Security Policy in Cloud VPNs
clients of cloud data centers run by a service provider need to secure Virtual Private Networks (VPNs) and virtual security functions that apply their own security policies 🎀 those policies can govern traffic inside the clients' own virtual networks, and traffic going out to external networks too. For example, VPN service providers may need to offer firewall and other security services to their VPN clients 🦋
right now it's generally not possible for clients to dynamically view (let alone change) what, where, and how security policies are implemented on the provider's cloud 🙃 and honestly? No standards-based framework exists that lets clients retrieve and manage security policies consistently across different providers 😤
as we covered above, dynamic key management is critical for securing the VPN and for distributing policies 🔐✨
4.3.4. Internal Network Monitoring
there are a lot of types of internal traffic monitors that a security controller might manage 👀 this includes the class of services called Data Loss Prevention (DLP) or Reputation Protection Services (RPS) 🛡️ depending on the kind of event, alerts can go to internal administrators or to external services 📣
4.4. Preventing DDoS, Malware, and Botnet Attacks
on the Internet, where literally everything is connected, stopping unwanted traffic that could cause a DoS attack or a DDoS attack has become a real challenge 😩 a network can also be exposed to malware attacks, and then it becomes an attack vector that can jeopardize other networks, through remote commands for example 💀 lots of networks that carry groups of information are exposed to these remote attacks too, like Internet of Things (IoT) networks, Information-Centric Networks (ICNs), Content Delivery Networks (CDNs), Voice over IP (VoIP) packet networks, and Voice over LTE (VoLTE) 📡 there are many examples of remote attacks on these networks, but these ones really show the issues:
- a malware attack on an IoT network that carries sensor readings and instructions might try to alter the sensor instructions to disable a key sensor 🤖
- a malware attack on VoIP or VoLTE networks involves software that tries to place unauthorized long-distance calls 📞
- botnets can overwhelm nodes in ICNs and CDNs so the networks can't pass critical data 🌊
so, to help organizations better secure their networks against these kinds 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, an I2NSF interface like that could be used to provision security policy configuration that looks for specific malware signatures 🔍 and botnet attacks could be easily prevented by provisioning security policies through the I2NSF client-side interface that blocks access to botnet command and control servers 🙅♀️✨
4.5. Regulatory and Compliance Security Policies
organizations have to protect their networks against attacks, and they also have to follow 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 they get 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 whether there's any policy violation 👀 that info can be handed over during an audit as proof that traffic is isolated between specific endpoints, in full compliance with the required regulations 🎀 receipts, bestie 🫶
5. Management Considerations
management of NSFs usually includes the following:
- life-cycle management and resource management of NSFs,
- device configuration, such as address configuration, device internal attributes configuration, etc.,
- signaling of events, notifications, and changes, and
- policy rule provisioning.
I2NSF will only focus on the policy provisioning part of NSF management 🎯 the rest is somebody else's main character moment 💁♀️
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, so it needs to be resilient to attacks and quickly recover from them 🚨 that's why proper secure communication channels have to be carefully specified for carrying, controlling, and monitoring traffic between the NSFs and their management entity (or entities) 🛡️
the traffic flow security policies specified by customers can conflict with providers' internal traffic flow security policies, and 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 have 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 used to protect an individual's home, phone, or other personal data 🏠📱 in that case, any solution should carefully consider whether combining management streams abides by the recommendations of [RFC6973] for data minimization, user participation, and security 🫧 no cutting corners on privacy, periodt 💖
8. Informative References ✨
okay bestie, this is the reference list, aka the receipts 🧾 every claim in this doc gets backed up here. these are all informative, so they're context, not requirements 💅
[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.[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>.[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 doc got 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). thank you, legends ✨
Contributors 🌸
I2NSF is a group effort, and it takes a village 🧚. 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 bunch of contributing authors too 💜. The following are considered co-authors:
- Linda Dunbar (Huawei)
- Antonio Pastur (Telefonica I+D)
- Mohamed Boucadair (France Telecom)
- Michael Georgiades (Prime Tel)
- Minpeng Qi (China Mobile)
- Shaibal Chakrabarty (US Ignite)
- Nic Leymann (Deutsche Telekom)
- Anil Lohiya (Juniper)
- David Qi (Bloomberg)
- Hyoungshick Kim (Sungkyunkwan University)
- Jung-Soo Park (ETRI)
- Tae-Jin Ahn (Korea Telecom)
- Se-Hui Lee (Korea Telecom)
Authors' Addresses 🎀
here's where you can find the authors, bestie 💌
Susan Hares
Huawei
7453 Hickory Hill
Saline, MI 48176
United States of America
Phone: +1-734-604-0332
Email: shares@ndzh.com
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📦 where this page comes from
- ietf: rfc8192 2017-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms